I was looking for a hook, like action intent, which can call my app (having a service), when an OS update has happened. (The boot when OS update has happened.)
I checked the standard action content on the Android website, but couldn't find one which I can use directly.
Thanks.
There is no special version of ACTION_BOOT_COMPLETED or other Intent actions that is unique to a reboot after an OS upgrade.
When your service gets control for any reason, compare the current Build information to some cached copy that you maintain, to see if there is a difference that matters to you.
You can check firmware version by Build.RADIO or Build.getRadioVersion() on each system reboot to find out if update occured.
Related
I would like to implement a java application (server application) that can download a new version (.jar file) from a given url, and then update itself at runtime.
What is the best way to do this and is it possible?
I guess that the application can download a new .jar file and start it. But how should I do the handover, e.g. know when the new application is started and then exit. Or is there a better way to do this?
The basic structure of a solution is as follows:
There is a main loop responsible for repeatedly loading the latest version of the app (if required) and launching it.
The application does its thing, but periodically checks the download URL. If it detects a new version it exits back to the launcher.
There are a number of ways you could implement this. For example:
The launcher could be a wrapper script or binary application that starts a new JVM to run the application from a JAR file that gets replaced.
The launcher could be a Java application that creates a classloader for the new JAR, loads an entrypoint class and calls some method on it. If you do it this way, you have to watch for classloader storage leaks, but that's not difficult. (You just need to make sure that no objects with classes loaded from the JAR are reachable after you relaunch.)
The advantages of the external wrapper approach are:
you only need one JAR,
you can replace the entire Java app,
any secondary threads created by the app, etc will go away without special shutdown logic, and
you can also deal with recovery from application crashes, etc.
The second approach requires two JARs, but has the following advantages:
the solution is pure Java and portable,
the changeover will be quicker, and
you can more easily retain state across the restart (modulo leakage issues).
The "best" way depends on your specific requirements.
It should also be noted that:
There are security risks with auto-updating. In general, if the server that provides the updates is compromised, or if the mechanisms for providing the updates are susceptible to attack, then auto-updating can lead to a compromise of the client(s).
Pushing a update to a client that cause damage to the client could have legal risks, and risks to your business' reputation.
If you can find a way to avoid reinventing the wheel, that would be good. See the other answers for suggestions.
I am currently developing a JAVA Linux Daemon and also had the need to implement an auto-update mechanism. I wanted to limit my application to one jar file, and came up with a simple solution:
Pack the updater application in the update itself.
Application: When the application detects a newer version it does the following:
Download update (Zipfile)
Extract Application and ApplicationUpdater (all in the zipfile)
Run updater
ApplicationUpdater: When the updater runs it does the following:
Stop the Application (in my case a daemon via init.d)
Copy the downloaded jar file to overwrite current Application
Start the Application
Cleanup.
Hope it helps someone.
I've recently created update4j which is fully compatible with Java 9's module system.
It will seamlessly start the new version without a restart.
This is a known problem and I recommend against reinventing a wheel - don't write your own hack, just use what other people have already done.
Two situations you need to consider:
App needs to be self-updatable and keep running even during update (server app, embedded apps). Go with OSGi: Bundles or Equinox p2.
App is a desktop app and has an installer. There are many installers with update option. Check installers list.
I've written a Java application that can load plugins at runtime and start using them immediately, inspired by a similar mechanism in jEdit. jEdit is open source so you have the option of looking to see how it works.
The solution uses a custom ClassLoader to load files from the jar. Once they're loaded you can invoke some method from the new jar that will act as its main method. Then the tricky part is making sure you get rid of all references to the old code so that it can be garbage collected. I'm not quite an expert on that part, I've made it work but it wasn't easy.
First way: use tomcat and it's deploy facilities.
Second way: to split application on two parts (functional and update) and let update part replace function part.
Third way: In your server appliction just download new version, then old version releases bound port, then old version runs new version (starts process), then old version sends a request on application port to the new version to delete old version, old version terminates and new version deletes old version. Like this:
This isn't necessarily the best way, but it might work for you.
You can write a bootstrap application (ala the World of Warcraft launcher, if you've played WoW). That bootstrap is responsible for checking for updates.
If an update is available, it will offer it to the user, handle the download, installation, etc.
If the application is up to date, it will allow the user to launch the application
Optionally, you can allow the user to launch the application, even if it isn't up to date
This way you don't have to worry about forcing an exit of your application.
If your application is web based, and if it is important that they have an up to date client, then you can also do version checks while the application runs. You can do them at intervals, while performing normal communication with the server (some or all calls), or both.
For a product I recently worked on, we did version checks upon launch (without a boot strapper app, but before the main window appeared), and during calls to the server. When the client was out of date, we relied on the user to quit manually, but forbid any action against the server.
Please note that I don't know if Java can invoke UI code before you bring up your main window. We were using C#/WPF.
If you build your application using Equinox plugins, you can use the P2 Provisioning System to get a ready-made solution to this problem. This will require the server to restart itself after an update.
I see a security problem when downloading a new jar (etc.), e.g., a man in the middle attack. You always have to sign your downloadable update.
On JAX2015, Adam Bien told about using JGit for updating the binaries.
Sadly I could not find any tutorials.
Source in German.
Adam Bien created the updater see here
I forked it here with some javaFX frontend. I am also working on an automatic signing.
I just had my app crash and now after alot of work its back to were I had it, I was wondering how would I back up the app so I can reInstall is again if this ever happens again?
u should use a version control system, example: git version control
http://git-scm.com/
happy coding!
use a version control system.. like svn or git ... in any case even if you were not using this, you should have taken backup of your code regularly... these version control system manages this for you easily...
This question is not specific to Java or Android, but rather, how to "backup" code properly. As others have already mentioned, you should be using source control systems such as Git or Subversion. Not only will this "backup" your code, it will allow you to track the changes you make to the code as well as maintain multiple versions of your code.
want to make a check in my installer before starting installation if any other installation is running beforehand. Like I want to make a check if windows update or any other installer is running i'll not start my installer.
I'm planning to check if any msiexec instance is running before hand. Is there any better approach, and will that be same for checking windows update. FYI my installer is in java
You should know that msiexec.exe will still be running for a couple of minutes after an installation is finished. This is a default behavior in the OS, it keeps the process alive for a couple of minutes, in case the user will start another installation, to save time from starting it all over again. So checking for the process could give you incorrect data.
Also, if you have your installer written in Java can you please explain why do you need to check for msiexec.exe processes?
Since your installer is in Java, I see no reason to check whether other installers are running, moreover there's no robust way to do so.
Does your installer try to replace system files? It should not.
Does your installer try to update a file in use? It must do it gracefully. And ask user to close an offending application; if it's not possible or user does not want to close the application right away, your installer asks user to restart the system when it completed installation.
Too much to care about, without other installers running. That's why it's wiser to use a specialized installer tool.
To check the OS for installations in progress you can use the following registry entry:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\InProgress
Please note that Windows Installer does not allow multiple InstallExecuteSequences to be executed simultaneously, however you can launch multiple installation UIs from different packages. The package enters InstallExecuteSequence usually at the moment you press "Install" and grant all the permissions for starting the system changes (creating registry, copying files, etc...).
Here you can find more information about InstallUISequence and InstallExecuteSequence:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372404(v=vs.85).aspx
Thank u guys for your suggestions, I final decided to go with creating a windows native dll to check the status of WindowsInstaller. The Windows Installer service is currently running if the value of the dwControlsAccepted member of the returned SERVICE_STATUS_PROCESS structure is SERVICE_ACCEPT_SHUTDOWN. Then used JNI to to call it from my java class.
I developed an android app ver 1.0 in which i stored the user data in shared preferences.
Now I am developing ver 2.0 and I have the following questions about updating it
1.How to detect if version 1.0 is already installed? I mean if it is a pure install(direct 2.0 install) or update from 1.0
2.If it is detected as 1.0 I want to dump the shared preferences values into database. Will the shared preferences be overwritten during update? How to prevent this? If they are not overwritten I want to write an activity which loads the values and dumps them into db
What parameter should i set so that market gives notification that update is available. Should i set that in android manifest with same keystore?
Please kindly help me out
Thanking You,
ChinniKrishna Kothapalli
The Android Documentation has a part explaining how to update your apps.
Basically you increase the number of your android:versionCode in the manifest. You should also change the android:versionName field so your users can see it's a different version.
As for your problem with dumping preferences into a database: The preferences allow you to use a default value if a certain preference is not found (when the downloads a fresh install).
I'm not sure if there is a way of detecting wether your application has been installed or not, except if you have something like a database already in your earlier version, then you could just check if it exists or not. Might not be the best practice to solve this tough.
Is there some event/receiver or something for handling first execution after installation or directly after installation? Or Do I need it emulate with preferences?
There is the ACTION_PACKAGE_ADDED Broadcast Intent, but the application being installed doesn't receive this.
So checking if a preference is set is probably the easiest solution.
SharedPreferences p = PreferenceManager.getDefaultSharedPreferences(this);
boolean firstRun = p.getBoolean(PREFERENCE_FIRST_RUN, true);
p.edit().putBoolean(PREFERENCE_FIRST_RUN, false).commit();
See Get referrer after installing app from Android Market - you can put whatever you want in there. I believe this is how Plan B works - the app that can send back your phone's location after it's stolen, that you install from the website after it's been stolen.
I don't think there is such a thing, and I don't think this would be a good idea : usually you have to handle not only installations but some updates (say : a new version with features) or the proper initialization of some resources.
For the resources, the best way is to check them directly.
For the version, I use the database, it's so easy.
The SQLiteOpenHelper's OnUpgrade method is called when the database version changed. I suppose this could be used to do other things than just handling the new schema.