I'm developing a Android Service. I would like the service to run even when the application not is active. So I start it without binding it:
startService(new Intent(Service.class.getName()));
Now it will run continuously until I choose to stop it, right?
If I, from another activity, bind the service will it stop when I unbind it?
Not necessarily. However, you have to remember that if there is memory pressure, it may be killed depending on the priorities (and if it is unbound, any visible app will probably have higher priority). The lifecycle is described here:
http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle
When the last client unbinds from the service, the system destroys the service (unless the service was also started by startService()).
It mean that your service will not stop even you unbind service from all activity in case of you had started service as startService()
For more details about bound service follow bellow link
Bound services
Related
In one case, one service being started by another component runs on the main UI thread of that component, while the service may live even that component is destroyed, so my question is where to execute the service if the component started that service is stopped?
Typically, when you call startService(), the service will remain running until you call stopService() from another component or stopSelf() from the service itself. And onStartCommand() will always run on UI thread.
If the service is running, subsequent calls to startService() will not create another instance of your service but run onStartCommand() again on the running one. This is slightly different if you are binding your component to a service. In this case, the service is automatically destroyed when you unbind all components. For more details on this, see: http://developer.android.com/guide/components/services.html#Lifecycle.
In addition, note that there different ways to keep a service running, depending on what you return from the onStartCommand():
START_STICKY is used for services that are explicitly started and
stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT
are used for services that should only remain running while processing
any commands sent to them.
To answer your question specifically, where and how to start your service depends on what exactly you want to do with it. If the component that started the service stopped, it is up to you to either 1) get a new reference to the service from another component and stop it or 2) stop the service from the service itself. But the service won't stop because the component did. Unless you are binding it to the service.
I am wondering what is the best way to keep a service running while the application is running (may be in background) and then the service stopping when the application has ended (the application in this case has completely stopped, not in the background).
Another sub-question is: How to stop a service when application stops?
I realize one solution is to use BoundServices but is this the best way or good enough?
For example if an activity binds a service and then the system kills the activity and brings
it alive again then how will the service behave? Or are there other issues I am not aware of?
What would be the best way to implement this? Thanks.
Check out http://developer.android.com/guide/components/bound-services.html.
A bound service is the server in a client-server interface. A bound service allows components (such as activities) to bind to the service, send requests, receive responses, and even perform interprocess communication (IPC). A bound service typically lives only while it serves another application component and does not run in the background indefinitely.
You have two options to start the service:
1. bindService() to activity
2. startForeground() and bind while it runs
Option 1 will only run as long as the activity is in view and the runnable active. (example use would be to use service to download a file)
Option 2 will run as long as the application is running (even when the activity is in the background) This option requires that your service be listed in the notification bar.
You can have a service stop itself by calling stopSelf(int) (I dont think this works if a activity is currently bound) or you can call stopService() from an activity.
As for the system killing the activity question.... Without knowing what your service will be handling its hard to give advice on how to handle this situation. For the most part a service running in the foreground will be the last resource the system will try to reclaim. If the system kills the activity the services onDestory method will be called where you should do some clean up so that the next time it starts you can continue in a safe manor.
http://developer.android.com/images/service_lifecycle.png
I have an Android app, in which Activities fire long running operations that run in the background. These operations interact with the Activities when done. I'm developing a component that handles the Activity/Long-Running-Task coupling, taking care of activities being destroyed and recreated.
Right now that component is implemented as an Android service. The activities call bindService and use the resulting IBinder to start and track tasks. I decided against using startService, because I prefer the richer API possible through a Java interface.
Now the problem. Activity A start ups, binds to the service and calls serviceApi.runTask(...). Activity A is then destroyed (because the user flips the phone, for instance) and recreated as Activity A'. A' then binds again to the service, announces its existence and everything should be running nicely.
Except that my Service gets destroyed. When Activity A is destroyed, it unbinds from the service. Android sees there are no more clients, and kills the service. When Activity A' is created, the service is created again, and I lose everything the old service had.
The only solution I can see is using a singleton for the service. And then it doesn't really have to be an Android service, just an instance that's accessible to everyone. Is that frowned upon in Android? Is there a better design that fits this problem?
Editted: Even if I call startService and then bind to it, nothing guarantees that the service instance will exist as long as the application is running. Android can kill sticky services if resources are low. Killing the service will cause the application to malfunction, and I can't have that.
Even if I call startService and then bind to it, nothing guarantees that the service instance will exist as long as the application is running.
Correct.
Android can kill sticky services if resources are low.
Also correct. All "sticky" means is that Android might restart the service.
Killing the service will cause the application to malfunction, and I can't have that.
It is impossible to create a service that is guaranteed to run forever. For starters, users can get rid of your service whenever they want, because users detest developers who have pointless services that run forever. Writing everlasting services is necessary only in very few cases; otherwise, it's just sloppy programming.
The only solution I can see is using a singleton for the service. And then it doesn't really have to be an Android service, just an instance that's accessible to everyone. Is that frowned upon in Android?
Singletons (a.k.a., static data members) will go away when the process is terminated. The process will be terminated eventually, particularly if there are no active services and none of your activities is in the foreground..
Call startService and in onStartCommand return START_STICKY. It should keep the service going.
You may also want to look into foreground services:
http://developer.android.com/reference/android/app/Service.html#startForeground(int, android.app.Notification)
Yo have to create persistent service. Refer to this manual.
In a few words - don't call bindService, call startService.
The application uses bound service. So, the service is NOT started using startService anywhere. Every activity which needs to access the service binds to it using bindService.
In some situations service is going foreground (with startForeground).
In particular there might be a situation when nothing is bound to service (which, according to the doc means that service will be stopped) but it's running in the foreground (which means that it wont' be stopped). Which of those rules have priority? Will system stop unbound service when it's running in foreground?
Thanks.
In some situations service is going foreground (with startForeground).
This is not particularly useful, as the process will already be in the foreground, because the activity using the service is in the foreground.
Which of those rules have priority?
The service will be destroyed after the last client has unbound from it. startForeground() does not impact this.
I currently I have an unbound service that is running continually grabbing my gps position that I start on boot. I then have an app that is suppose to plot where I've been by pulling data from the service.
I can't bind the the service to talk to it or it will be destroyed once I close the app.
Is there any good way to get data from an unbound service or keep a bound service from dying once I unbind it?
Cheers! :)
There is a workaround for keeping your service alive. Call your service by calling startService and then bind to the service. This way your activity is maintaining the the lifecycle of the service.
As the documentation states:
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
So first, start the service with startService(), then bind to it in onResume(), and unbind in onPause(). The service will continue to run nevertheless because it is started. And when you want to stop the service either call stopSelf() from within the service or stopService() from an activity. It will stop right away or as soon as you unbind from it if there's any connection alive.