I have a background service that sometimes gets killed by the OS when it is running low on memory.
- How to simulate this behaviour so I can debug it?
The dev guide simply says "if your service is started, then you must design it to gracefully handle restarts by the system. If the system kills your service, it restarts it as soon as resources become available again".
- What's the sequence of calls from when it gets killed to when it finishes restarting?
On a side (related) question, what happens to an actively running AsyncTask started in the service when the service gets killed by the OS, i.e., without service.onDestroy getting called? Does it keep running or get ripped silently along with the service?
Under newer versions, a service will have the following events triggered:
onCreate()
Followed by...
int onStartCommand(Intent intent, int flags, int startid)
I know in the comments above you mention using that, but it's worth repeating: Don't use the old "onStart()" event. onStartCommand is the new way of doing things.
the onCreate() can be used to create any objects, etc. but do the actually code of your service in the onStartCommand().
When done with the onStartCommand() you should return a result. Using "START_STICKY" tells the OS it can restart if it needs to kill it. Using "START_NOT_STICKY" tells the os not to bother trying to restart it after memory becomes available again. That means your application would need to manually start the service again. There are other options as well - check the API docs.
Checking those flags will allow you to see why your service has started - if your own app launched it or if the OS launched it to restart it. You'll need to be periodically storing the state of any important variables so that if the OS has relaunched it you can retrieve those - you could probably use a SharedPreferences private storage to store those. Definitely store any in the onDestroy event, but don't count on that being called.
Also, it's recommended that you store the startID field in a variable and use it with a stopSelfResult(startId) when your service is done running.
Keep in mind that if your service is killed by the OS you may not have the chance to store any variables. You need to be able to see if your state is where you expect when restarted by the OS and if not just reset everything or gracefully die maybe.
As far as debugging, have you considered writing another app that does nothing but suck memory in an Activity in order to force a low memory condition? The top activity should get preference to the memory and force the service to die.
Additional threads launched in the service are still part of the same application process, so they would be killed along with the service (and the rest of the application.) You can verify this by adding regular log statements inside the threads and then killing the service.
Something else that might be useful for you is checking to see if your service is already running from inside your application. Here's a function to do that:
// Determine if one of my services is currently running
public static boolean isMyServiceRunning(Context context, String servicename) {
ActivityManager manager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
for (RunningServiceInfo service : manager.getRunningServices(Integer.MAX_VALUE)) {
if (servicename.equals(service.service.getClassName())) {
return true;
}
}
return false;
}
If it's a local Service (the default), as opposed to a remote Service, then it is running in the same process as your app. This means you can emulate killing it by just killing your app's process. You can do that using ddms for example in eclipse or from the command line, or even from your phone (settings -> applications).
The Kotlin version of Tony Maro's answer:
@Suppress("DEPRECATION")
fun <T> Context.isServiceRunning(service: Class<T>): Boolean {
return (getSystemService(ACTIVITY_SERVICE) as ActivityManager)
.getRunningServices(Integer.MAX_VALUE)
.any { it.service.className == service.name }
}
来源:https://stackoverflow.com/questions/7257378/how-to-force-a-service-restart