My application has 2 features: "base" and "extend".
manifest extend feature:
<dist:module
dist:onDemand="true"
dist:title="#string/title_extend">
<dist:fusing dist:include="true" />
</dist:module>
download feature with SplitInstallManager -> startInstall
unintsalling with SplitInstallManager -> deferredUninstall
Check installed modules with SplitInstallManager -> getInstalledModules
Extend feature is loading from play store success and work as expected. When this feature has become unnecessary - uninstall it.
more, SplitInstallManager has callbacks: SuccessListener, FailureListener, CompleteListener. Install and Uninstall completely with success (no errors).
But, after uninstalling Extend feature (and after restart application) it is stay installed.
How to delete uninstalled feature from the application (need remove no used code and resources) ?
As explained in the API of the deferredUninstall method:
Once called, the Play Store will try to eventually remove those modules in the background.
The uninstalled modules will be removed while the app is not working at some point in the next 24 hours.
Here is what I noticed.
1) Uninstalling the app removes the downloaded modules, so the next time you run the app, the app will download the modules again.
2) Clearing the app data (e.g. adb shell pm clear APP_PACKAGE_NAME) makes the module not available to the app immediately, but if the module is already downloaded before clearing the app data, it won't be downloaded again. In other words, you won't see SplitInstallSessionStatus.DOWNLOADING.
3) Once the downloadable module becomes available to the app, clearing the app data of "Google Play services" (i.e. adb shell pm clear com.google.android.gms) doesn't make a difference. But occasionally, the downloadable module sticks around even after uninstalling the app, especially when the module's name changes. Then 3) becomes handy to clear the stale modules.
I think what's happening here is when the app requests a downloadable module, Google Play services downloads the module, hands it over to the app, and caches a copy of it, just in case the app requests it again. If the app is uninstalled, Google Play services removes the cached module. deferredUninstall() is just asking Google Play services to uninstall the modules if necessary, but we have no control on when that would happen, if ever.
from https://developer.android.com/guide/app-bundle/playcore#uninstall_modules:
Module uninstalls do not occur immediately. That is, the device uninstalls them in the background as needed to save storage space. You can confirm that the device has deleted a module by invoking SplitInstallManager.getInstalledModules() and inspecting the result, as described in the previous section.
So You could try to fill up storage space on your device and see if that triggers an uninstall :)
By the way: On the play store page for the app that I am currently testing via "internal early access", there is a section "deferred actions" which lists all modules marked for deferred uninstall. There also is a button "run deferred actions" which actually removes those modules completely.
As far as my own testing has gone, uninstall is deferred until the app is updated by Play Store. Otherwise I assume Play Store services will eventually wait for the app to be totally inactivate to update its uninstalled module (the app has to be restarted for that update to occur).
I've filled a bug to find out if there's anyway to force the (un)install of on-demand modules: https://issuetracker.google.com/u/1/issues/172108742. And a way to tell which modules are truly installed.
Same goes for installing actually, until app is updated, on-demand modules are "emulated", which prevents those 2 things from happening:
The platform can not apply any new manifest entries introduced by the module.
The platform can not access the module’s resources for system UI components, such as notifications. If you need to use such resources immediately, consider including those resource in the base module of your app.
As explained here: https://developer.android.com/guide/playcore/play-feature-delivery#access_downloaded_modules
There seem to be a long road ahead before on-demand modules work properly.
Related
I had been working on Google app engine for some time with great success. However, recently I was forced to upgrade to Eclipse-Photon from Eclipse-Mars.
I can run a debugging version of the server on localhost:8080 just fine except when I change any of the TypeScript files. Formerly when I would run the TypeScript compiler to generate new JavaScript the server would automatically update the server. Now when I generate a new JavaScript file, the server continues to serve the old version. I have my expirations set to 0 and I have automatic publication turned on.
For a while I could make it work by telling the server to Publish. Now that has stopped working as well. If I save any file from inside of Eclipse I see a little message flash by indicating publication and then that file serves properly. If I load the generated JavaScript file and then modify it slightly then it will publish and serve correctly.
Obviously Photon is no longer tracking file changes that way that Mars did. I could easily copy the generated file to the correct place if I knew where that place was.
Are you running your TypeScript compilation from outside of Eclipse? If so, try doing a Refresh of your project. That should sync up Eclipse's notion of the filesystem state with what is on disk.
Cloud Tools for Eclipse relies on the Web Tools and Resources frameworks to determine whether a resource has changed and needs publishing. Eclipse is normally set up to detect resource changes automatically as configured by two options on the Preferences > General > Workspace preference page: Refresh on access and Refresh using native hooks or polling.
I need to demonstrate a test version of my app. I DON'T want to load it to the store yet. I want create an installer of my app, so the user can go to my site and install the application by clicking.
First of all, have you read the documentation including developer installation, enterprise installation, publishing on the Web Store only to test accounts, and recent announcements of changes? Assuming you have, then with the exceptions listed in those sources, all apps/extensions must be published in CWS. They don't have to be listed publicly, but they do have to be published there.
Your best bet is to use the test-account feature of CWS for your demonstration.
This is very easy, yo can create the installer vía chrome://extensions > Developer Mode > Package extension.
Then you got the .crx file, you can upload it anywhere and share it. To install it, user must open chrome//extensions and drop the file in the page.
The option to install from webpage by clicking was disabled in Chrome for security reasons.
We have a c#, .NET 4.0, windows application which we deploy to a terminal server. (Developed using VS 2010). This application makes use of several WCF services sitting on another server.
Our users access the front-end via remote desktop session. (They all have a .RDP file on their desktops.)
My question is regarding the deployment of this front-end. Currently, if we need to do an emergency deployment during business hours, we need to kick all the users off that are hooked into the app (as they are using the dll's that we need to replace). This is not ideal, obviously. We work in quite a business-critical environment, so these deployments are unavoidable. I've investigated ClickOnce, but have read that you cannot use this with terminal services application here. (Which kind of makes sense since it's essentially one app being "accessed" by several clients...)
I would like to be able to do a "silent" deployment whereby the user knows nothing about the fix until they restart their instance of the application. I'm not sure this is even possible?
I would appreciate any guidance or suggestions on this!
Yep, I do this all the time with a RD app -- you just need to move or rename the DLLs instead of deleting them. Windows allows moves and renames when DLLs are in use, but prevents you from deleting them. If you use Windows Installer to deploy your app, it will do the moves automatically (and delete the old versions when the system is next rebooted).
Once you replace the DLLs this way, existing sessions will continue to use the old, renamed versions, and new sessions will use the new versions. Of course, depending on how many DLLs you have, how long it takes your app to load them into memory, and how much activity you have on your server, you could run into a scenario where the app loads some of the old DLLs and some of the new ones when you're in the middle of updating them, but that would likely be rare.
I work in a service organization where users of our internal tools are often disconnected. It is often the case that service engineers on service assignments are "stranded" with an outdated version of some internal tool.
These tools are deployed using ClickOnce publish VS2010 .NET4 . If the users run all their apps while still connected to corporate network, they would get a notification that a new version was available. As the number of various tools increase, the chance increases that some app is not updated.
Is it possible to automate this process, by a batch file or something?
So that the engineers just need to run one file when connected to corporate nw to get all the newest versions of their installed tools?
Added:
An easier way of saying it would be to have "something like Windows update" operating on corporate net, but for internal ClickOnce apps.
Very interesting question. I can't think of a quick way to do this, but it's definitely possible.
I would create another ClickOnce app whose job is to update the other ClickOnce apps. This app needs the url of each app's .application file. If all engineers are supposed to have all apps, that's easy. If not, maybe you could look through their start menu and find all the ClickOnce Application Reference files. Those files contain the url.
Next, just launch the url and pass a query string argument...
http://server/MyApp/MyApp.application?UpdateOnly=true
In the startup of your applications, you can check the query string argument and shut down the app if it's run with UpdateOnly=true.
One side note. If you set the minimum required version of each of your apps to the latest version, users won't get prompted with the new version dialog. Seems like you'd want to do that or the user would still have to pay attention and do a lot of clicking.
This issue has come up three times in our environment. After installing the ClickOnce application, I expected it to startup automatically (as I have it set to do after install completes), but it did not.
I try running the application from the shortcut, and it brings up the "Launching Application" dialog, but then immediately closes and the application is not started. It's acting as if another instance of the application is currently running (I have it set to only run one instance at a time).
This issue is profile-specific. Installing it on the same machine using a different profile runs just fine, but for whatever reason, no amount of uninstalling, reinstalling, and restarting the computer seems to fix a profile once it runs into this problem.
Our current fix for this is to completely delete the profile and "reload" it. I'd really like to know what the actually problem is though, being that we've run into it three times now.
Some other information that may be of use:
This application was originally deployed using Windows Installer (MSI). I uninstalled the application from the Add/Remove Programs prior to installing the newer ClickOnce version.
These users were previously part of local administrators group (while running the MSI version). Their privileges have since been lowered to "standard user".
Do you have any logging at startup that shows exactly what the application is doing, so you can tell where it's crashing?
The user doesn't have Kensington mouse software installed, do they? There is a known conflict there, the symptoms of which are exactly as you report -- the user clicks the shortcut to start the application, it updates, and then does nothing.
I was able to fix those installations by creating a new certificate for the app. It appears this issue had to do with the certificate reaching its expiration date.
Instead of deleting the profile try this:
Log onto the PC as an admin
Delete/rename C:/Documents and Settings/(UserCorpID)/Local Settings/Application Data/Microsoft/Windows/UsrClass.dat file