I know there are tones of threads with similar title, but no one of them gives a definitive answer. We're currently stress testing the foreground service of our application by filling up the RAM with junk with another app and investigating what happens to our application and its foreground service.
So, our foreground service is started and notification is shown to the user, and its mode is START_STICKY. However, when we simulate extreme memory usage the application is killed (which is OK and we can do nothing about it), but the bad thing is that our foreground service never gets restarted. Perhaps I'm confusing something from the START_STICKY doc, but what I can understand from below doc is that system should guarantee the restart, isn't it?
Constant to return from
onStartCommand(Intent, int, int): if this service's process is killed while it is started (after returning fromonStartCommand(Intent, int, int)), then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service. Because it is in the started state, it will guarantee to callonStartCommand(Intent, int, int)after creating the new service instance; if there are not any pending start commands to be delivered to the service, it will be called with a null intent object, so you must take care to check for this.
The above doc is too vague.
First question is
- will it ALWAYS RESTART the service? If not, what are the conditions for the service being restarted and what are the conditions when it won't be restarted?
And the second question is
- What does it mean Later? Later when? Later next year or what? :D
To summarize, we do need to guarantee that our foreground service will restart whatever it takes. Any ideas?
EDIT 1: I did investigate the logcat logs a little bit more. Here's is what happens.
Process com.MY_PACKAGE_ID (pid 1192) has died: prcp FGS
Scheduling restart of crashed service com.MY_PACKAGE_ID/MyForegroundService in 1284608ms
Obviously, the system kills the application and schedules a restart. In this case it's approximately in 21 minutes. In other cases I would see that the reschedule time was 10.000ms aka 10 seconds. And, in 10 seconds the device would still be in memory stressful situation and the app will not be launched. Which implies, that in case the service fails to start at rescheduled time there won't be any 2nd rescheduling and the service will never restart. But, if at rescheduled time the device was in normal non-memory stressful conditions, the restart will happen successfully.