I have a question related to how Android service behaves when stopped by system. As per my understanding, if system (OS) stops the service due to resources needed, it is responsibility of system to start it again. In this scenario, system would not call onDestroy() when stopping service and onCreate() when starting service, rather it would just call onStartCommand().
If I am creating a thread in onStartCommand(), how would I cleanup thread when system stops service. If I dont stop thread, onStartCommand() would create a new thread.
I think, it may come down to onStartCommand() parameters (intent, flags and startId). They might be different when system starts service after stopping it because it needed resources. Could anyone tell me what would be difference in parameters when service started by startService() command or by system itself (after stopping it)
I can create thread in onCreate() but I am not sure if thread still exists when system stops service. What would be the best way to handle this kind of scenario.
Thanks
As per my understanding, if system (OS) stops the service due to resources needed, it is responsibility of system to start it again.
That depends upon what you return from onStartCommand(). START_NOT_STICKY, for example, means the OS does not have to start your service again.
In this scenario, system would not call onDestroy() when stopping service and onCreate() when starting service, rather it would just call onStartCommand().
Whether it calls onDestroy() would depend a bit on how the service is stopped (e.g., directly or via process termination). However, it should still call onCreate() on the new instance, if and when the OS restarts the service.
If I am creating a thread in onStartCommand(), how would I cleanup thread when system stops service.
Ensure that in onDestroy(), something happens that will cause the thread to go away. Either onDestroy() will be called (and your service can do its cleanup), or your process is being terminated (and your thread goes away with it).
Could anyone tell me what would be difference in parameters when service started by startService() command or by system itself (after stopping it)
There is a START_FLAG_REDELIVERY that will be in the flags passed to onStartCommand(), but AFAIK it will only be set if you return START_REDELIVER_INTENT from onStartCommand().
Related
I handle Service and the return code: START_NOT_STICKY. I do not want to restart the service.
But documentation says "Do not recreate the service, unless there are pending intents to deliver."
Could you give me an example of these pending intents that cause restarting the service?
When you return START_NOT_STICKY, this means the following:
If Android kills the process hosting your Service (which it can pretty much do at any time if it needs the resources or if it thinks your Service isn't doing anything useful), the following happens:
If your process is killed after onStartCommand() is called, but before onStartCommand() has completed, Android will restart your Service and call onStartCommand() again, redelivering the Intent that was being processed when the process was killed
If your process is killed after onStartCommand() has completed, Android will only restart your Service if there are pending Intents for your Service. In this case a pending Intent would exist if any component called startService() for your Service and that call has not yet been completely processed by your Service. This could be the case, for example, if a component called startService() while your Service was dead. Or it could happen if a component called startService() while your Service was still in the onStartCommand() method (processing a previous call to startService()).
I'm trying a simple android app that starts and stops a simple service with startService(). I notice that each time I manually terminate the app process (by closing the app), another instance of my service is created.
In other words, the service that I created isn't destroyed, and an additional service is created. I can see that the onDestroy() isn't called, and the onCreate() & onStart() get called again
Why is that? How can I prevent it? You can see the source code I'm using in this example: Source Code
If you start your Service using Context.startService() and your Service returns START_STICKY from its onStartCommand() then the system is expecting the Service to either be explicitly stopped via something calling Context.stopService() or the Service itself calling stopSelf(). When you use the Recents screen to "swipe away" your app, you are forcefully killing the process but not explicitly stopping the Service.
I have a Service running in the foreground, and an Activity that interacts with it. If the Activity crashes, Android kills the entire process, including the foreground Service and its associated Threads.
However, the ongoing notification provided by the Service does not go away, and upon closer inspection, Android's task manager reveals that the Service itself is still running.
How can I kill the foreground Service in this circumstance?
Have you override onStartCommand method of the Service? What value is it returning? If not, try to override it and return START_NOT_STICKY from it.
START_STICKY: If this service's process is killed while it is started, then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service.
START_NOT_STICKY: If this service's process is killed while it is started, and there are no new start intents to deliver to it, then take the service out of the started state and don't recreate.
Not sure, as I have never worked on foreground services, but this might be the reason.
Are you sure the service is not running it its own process...
Also can you confirm whether the service is getting restarted..If its getting restarted-it is because you are returning START_STICKY from onStartCommand()
I execute stopSelf as service finishes working (from within service) but it is not destroyed (see using log output in onDestroy()) right after it. It leads that startService uses existing (stopped) service instead of starting new one. How can i force service to be destroyed right after it is stopped?
From Documentation:
A service can be both started and have connections bound to it. In
such a case, the system will keep the service running as long as
either it is started or there are one or more connections to it with
the Context.BIND_AUTO_CREATE flag. Once neither of these
situations hold, the service's onDestroy() method is called and
the service is effectively terminated.
From my little android knowledge I understand that android OS can kill my service under extreme memory conditions.
I have created a service that returns START_STICKY. The service is meant to run in background.
If android is about to kill my service, will it call onDestroy ?
And when it restarts it would it call onCreate ?
See here, the dev guide. http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle
onCreate() is only called when the process starts, which can either be the first time the service is running, or if it was killed on restarted, essentially this is called whenever it starts.
onStartCommand() is called whenever a client calls startService().
When a service is destroyed / completely stopped, Android is supposed to call onDestroy() on that service. I think it's possible for that to not happen (e.g. process is killed not through Android system). In the case of a bound service, this is when there are not more active client binders.
Edit: onCreate() Service starts; onStartCommand()someone uses service; onDestroy()Service is killed / stopped.
If someone calls Context.startService() then the system will retrieve
the service (creating it and calling its onCreate() method if needed)
and then call its onStartCommand(Intent, int, int) method with the
arguments supplied by the client
...
A service can be both started and have connections bound to it. In
such a case, the system will keep the service running as long as
either it is started or there are one or more connections to it with
the Context.BIND_AUTO_CREATE flag. Once neither of these situations
hold, the service's onDestroy() method is called and the service is
effectively terminated. All cleanup (stopping threads, unregistering
receivers) should be complete upon returning from onDestroy().
http://developer.android.com/reference/android/app/Service.html
EDIT: Quick answer. Yes to both questions