I've got some methods in onDestroy in my service. They must be called to set some application settings. Maybe there is a possibility to receive some kind of broadcast to set the settings values? As I understand, this service won't be active after the system reboots. Any ideas?
I've got some methods in onDestroy in my service
onDestroy() is not guaranteed to be called on a service. For example, if the user force-stops you from Settings, or you crash with an exception, or Android needs RAM in a hurry and terminates your process, onDestroy() is not called.
They must be called to set some application settings.
Then you should be calling them sometime other than onDestroy().
Maby there is a possibility to recive some kind of broadcast and even set the settings values?
You can try having your service listen for the ACTION_SHUTDOWN broadcast, but that will not solve your problem, as there are other scenarios in which onDestroy() will not be called, as noted above.
As I anderstand, this service when the system reboot won't be active
Correct.
Related
I would like to issue broadcast when service goes down. What callback is guaranteed to run when this happens? I want other apps to know its down, I cannot take a chance that it goes down and no one knows about it. So at point in the service lifecycle (which method) should I issue the sendBroadcast(ImGoingDown)? For example, how soon would onDestroy() be called?
While most answers here are aiding in the onDestroy approach, there are many events on your service being destroyed that you cannot intervene. For instance, if the user has force closed your application, your service is destroyed, but onDestroy will NOT be executed.
On a common scenario, your service would be destroyed when it has ran out of operations (mostly know as finished), when no other process that are bound to the service, or when its stopSelf()is executed, and most common, when the device is running low on RAM.
onDestroy would be the scenario where you can restart it.
As a suggestion, if the device has killed your process due to low RAM, dont restart it right away. set a Handler or AlarmManager to start it a bit later (so the lack of memmomry dont execute in back again.)
You can fire the broadcast in onDestroy(). This is the last call the service receives before getting destroyed. Service lifecycle ends with this call.
If you are running a background service that means you must be doing something in background, sending broadcast from onDestroy() might not be a best practice.
Think, your service gets destroyed because the task you wanted to run is completed, then you might don't want to send a broadcast in that case. You want to send a broadcast only when the service is killed right? So the better approach is to setting a boolean, say isTaskFinised, and if it returns false only then your onDestroy() should send a broadcast.
#Override
public void onDestroy(){
if(!isTaskFinished){
//send a broadcast
}
}
I'm writing an app which has a long-running service.
I've written some state-saving code in the service's onDestroy method.
My intention is that this should be invoked if the service ever gets killed by Android, due to memory pressure.
How can I simulate the service being killed by memory pressure?
I've tried adb shell am force-stop com.example.app but the service's onDestroy method was not invoked.
Is onDestroy a sensible site for service-shutdown-state-saving?
If so, how can I make a service's onDestroy be invoked by Android, for debugging/testing purposes?
You should not rely on onDestroy() because it only gets called, when service is properly stopped (by calling stopService() or stopSelf() method).
If you want to save service state, you should either save it as you go (for instance a player service can store it when play/pause function is activated), or use a timer to save it periodically.
If you want to react to memory events, you should use ComponentCallbacks2 class, which will notify you, when Android needs more memory. If you free memory inside those callbacks, you will increase probability your service will stay in memory longer.
Hope this helps.
If you want to programmatically stop your Service, within the Service, call stopSelf().
Alternatively go to the app settings and do a force stop.
A force stop will not call onDestroy on any components, neither service nor activity. It completely closes the app without any further considerations.
I'm not sure about this but if your service isn't running as foreground service you can close it by removing the app from recent apps menu.
I've got a Service, that starting with BOOT_COMPLETED. This Service periodicaly sends GPS data to the server. Sometimes OS kills this Service in the wake of memory, but onDestroy() method of Service didn't called. Where can i put some values for saving and restoring when my Service is restarted?
Simple put: You can't with the regular service lifecycle events.
If the onDestroy() method is not called the system killed the process the hard way, without terminating it properly. As there is no event for that you have to use other callbacks to detect a possible kill situation.
The only possibility which could help is to listen to onTrimMemeroy or onLowMemeroy although these callbacks do not mean that your service will be killed it might help as an indicator when you should save your data.
More can be found here: http://developer.android.com/reference/android/content/ComponentCallbacks2.html
For reference, here is the lifecycle of a service if terminated properly:
You can ovveride the onTrimMemeroy() and onLowMemeroy() method to handle this problem, the detailed illustration about these two method that you can get from here
I have a long running service which responds to multiple BroadcastReceivers (created in code, not manifest). Most of the time the service is running well, but from time to time it gets somehow stopped (the BroadcastReceivers stop to work) - I guess the system pauses it somehow (when I look into the running processes on the device I can clearly see the service is still "runnning").
I don't know the right reason why the service is being paused, but I'd like to know whether in these cases the onDestroy() method is called or whether there's a chance to handle this somehow.
I presume onDestroy() is not being called, because the service is still visible in the Running processes tab. I also have the service return the START_STICKY flag so the system should restart it whenever it's killed for memory reasons. Also if it is "paused" somehow, is it possible to create a WakeLock for this not to occur?
I know that the best solution would be to put all the BroadcastReceivers into the manifest and create a one shot-service called from their onReceive() methods. However I have chosen to go with the way of long running service because the initialization stage is very intensive it's better to initialize everything just once.
onDestroy() will be called only when service is being killed by lack of resources or when you explicitly stop it.
The service can be "paused" when your phone goes idle (usually when screen is off) because the CPU stops. To make services run always you should use PowerManager.PARTIAL_WAKE_LOCK - but use it wisely because it does not stop your CPU and thus draining the battery. You should never leave your apps running always. Just do what you need holding a WakeLock and then release it.
http://developer.android.com/reference/android/os/PowerManager.html
http://developer.android.com/reference/android/os/PowerManager.WakeLock.html
You can use AlarmManager to "wake" your apps periodically and do something.
http://developer.android.com/reference/android/app/AlarmManager.html
I'm aware that a Service's onDestroy() method may never be called but can someone tell me when such a scenario might occur? I'm especially interested in whether it's possible for a Service to be killed, yet its VM would continue to run.
I ask because I have a service that registers ContentObservers in the service's onStartCommand() method and unregisters them onDestroy(). If the service's onDestroy() method was never called because the whole VM was killed (along with the observers it created,) that would be fine. But I'm wondering if it's possible for a service to "go away" without onDestroy() being called, while the observers it created would live on and continue to receive changes.
I'm aware that a Service's onDestroy() method may never be called but can someone tell me when such a scenario might occur?
Here are three off the top of my head:
If the user Force Stops you from the Settings app
If Android needs RAM in a hurry (e.g., to process an incoming phone call) and elects to terminate your process to free up that RAM
You terminate the process from DDMS
Also, if your service crashes with an unhandled exception somewhere, Android may consider the service to be defunct and skip onDestroy(). I'm not sure about this one, as I haven't specifically tried it.
But I'm wondering if it's possible for a service to "go away" without onDestroy() being called, while the observers it created would live on and continue to receive changes.
Other than the unhandled-exception possibility I mention above, I am reasonably certain that if the process will be terminated in the conditions where onDestroy() is not called.
Also if the app is reinstalled/updated , ondestroy() is never called.