Sunday, May 20, 2012

Tuesday, May 1, 2012

On Android Services, Threads and Exceptions

So it turns out that if you actually read the developer documentation carefully, "Services" in Android are not "background jobs" or "daemons" as you might expect from the name.  No what they are is in fact simply a configuration mechanism to inform the Android OS that your application has work to do that can occur at times when your application Activities are not visible to the user.

Thus Services not only do not have their own separate Thread, but in fact are simply executed by your applications main thread, in response to events based on the service life-cycle. An important result of this is that within a Service or an Activity, all long-running jobs should be performed on a separate background as otherwise they will be run on the main thread.

The main source of confusion comes about because the Android developer documentation talks about Services being "killed" and restarted by the OS. But this actually simply referring to the process (i.e. the Linux process) which hosts each apps Dalvik VM and the fact that the OS can kill the process at anytime such as when memory is low. It's only in this case that Services would be "restarted" by the OS/Framework, but this of course only refers to the Services lifecycle callback methods (e.g. onCreate and onStartCommand) being called by your apps main thread after your app is restarted inside a new VM running within a new process. Once you understand this, the purpose of the "STICKY" flags then becomes obvious, as just being means to inform the framework how it should go about re-calling those callback methods after an app is restarted in a new VM.

An interesting result of all this is that there is no such thing as a Service "dying" in your app, except of course for the case of it throwing an uncaught exception, which would cause your apps main thread to exit and thus your whole app to "quit" bringing up the famous "Force Close" system dialog.  Should you wish however to handle that situation, you have available to you the Thread.setDefaultUncaughtExceptionHandler() method which will allow you to catch unhandled exceptions and doing something useful (like logging them to the device storage or some external service) prior to your current foreground Activity existing.