My app has both Service and Activities.
Suppose the process of my app is running. And after a while, the Android OS kills the service in my app due to low memory. My question is, is it possible that Android kills the service only and keeps the process alive? Or when a service is killed, the process must be killed too?
Thanks.
I'm 99,9% sure of this: if the service goes, there goes the process too. The conditions to kill a service are pretty demanding such as in low memory situations. My own experience is that the whole app is killed when the service dies. The service and the process are tied together. Yes, you can manually stop your service without killing your process, but I'm almost certain that when the OS kills your service because of low memory, then bye-bye process.
See Hackbod's answer and comments: Android service killed
See http://developer.android.com/reference/android/app/Service.html and onLowMemory:
This is called when the overall system is running low on memory, and
would like actively running process to try to tighten their belt.
While the exact point at which this will be called is not defined,
generally it will happen around the time all background process have
been killed, that is before reaching the point of killing processes
hosting service and foreground UI that we would like to avoid killing.
Background info: http://about-android.blogspot.com/2010/07/lifecycle-of-android-application.html
This is also interesting: Will we leak the android service connection if the client's process is killed by android?
Related
do you have any idea what can bee root cause of my Android app service stop working when i run random another app/game?
I do not have code available, i just need causes.
Thank you.
Service runs in your app process. If your app is garbage collected, the service will stop until:
You start the service in new process via manifest file declaration
You make the service sticky (recommended).
go ahead and research above two and let me know if you would like more explanation or code
UPDATE
If you see official documentation of Service, Google clearly explains why and when service will be destroyed. What is useful in your scenario:
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)
using startForeground will ensure your service keeps running in the same process. some pointers:
A service with attached client will not be destroyed even on low memory scenarios
A service will be killed in low memory scenarios, regardless of the process. Running in a different process is better but does not guarantee it won't be destroyed by system.
Don't use system.exit(0) to end your app. call finish() on activity.
Starting sticky service just ensures that service is restarted when memory is freed.
hope it helps!
Say my app has an Activity that the user is interacting with.
My Application process priority is now 1 - highest.
Say I also have a background started service in my application. (that is not bound)
In extreme memory pressure, (assume all lower priority processes has been killed) can the O.S kill my service (meaning to remove its reference to the service and call its onDestroy method) but still keep my application process alive?
I have read the official documentation,
Also, Dianne's response to this thread:
Android service killed
And also this thread:
When Service is killed, can the process be still alive?
However, I want to be 100% sure that this is not an option, not 99%.
Is there an official documentation that the O.S in this situation will kill the entire process?
Thanks
In extreme memory pressure, (assume all lower priority processes has been killed) can the O.S kill my service (meaning to remove its reference to the service and call its onDestroy method) but still keep my application process alive?
First, you only have one process by default.
Second, if that process is the foreground UI ("my app has an Activity that the user is interacting with"), it is not going to be terminated due to low memory conditions. Only background processes are subject to termination.
I am wondering that why there is still a process running even I had already left(pressing back button) the Flickr and the Messenger apps in the picture above?
Recently I wrote an app that contains a service, I've found that if there is still a process running, the service will less likely be killed by the system.
So how does the apps above keep processes running in background?
They uses background service that will stay alive even if you quit the app.. as the documentation said
The Android system will attempt to keep the process hosting a service around as long as the service has been started or has clients bound to it
As long the app is not ended service will stay alive unless there is no memory left.
When running low on memory and needing to kill existing processes, the priority of a process hosting the service will be the higher of the following possibilities:
If the service is currently executing code in its onCreate(), onStartCommand(), or onDestroy() methods, then the hosting process will be a foreground process to ensure this code can execute without being killed.
If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible. Because only a few processes are generally visible to the user, this means that the service should not be killed except in extreme low memory conditions.
If there are clients bound to the service, then the service's hosting process is never less important than the most important client. That is, if one of its clients is visible to the user, then the service itself is considered to be visible.
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)
you can learn more about Service here
The back button doesn't end the app, its like minimizing them in Windows. TO end them they need to be call finish. Androiud's design (which I think is a stupid, insecure idea, but its how it works) is that apps will not exit unless they exit themselves with finish or you run low on memory and the OS kills them.
I have an app with a service in background. The service runs since the boot, but when the app is started, and closed, the service keeps all the memory that the app uses.
How can I clean all that memory for the service to run light like in the boot ?
Stop the service, if you are not doing so already (via stopService() or stopSelf()).
After that, your process will eventually be terminated by the OS, when it needs the RAM for other processes.
It seems that when I don't need interprocess communication, there's almost no reason to use a Service. The only reason I am aware of is this: if my process has a started Service, the process is less likely to be killed.
I could just have a utility class with dontWantToBeKilled() and canBeKilled() methods, which would start / stop a dummy Service. Apart from that, I won't use Services. Is this right?
Yes, there are other reasons.
Your application runs in a process which can be killed by the system whenever it needs more resources.
According to this a running service has a higher priority than an Activity that isn't in the foreground, meaning that the system is more likely to kill an application process that has an Activity in the background than one that has a Service running in the background.
The documentation for Service states that:
If the service has been started, then its hosting process is
considered to be less important than any processes that are currently
visible to the user on-screen, but more important than any process not
visible. Because only a few processes are generally visible to the
user, this means that the service should not be killed except in
extreme low memory conditions.
So, you can use Services to decrease the likelihood of your application process being killed.
Even though the Service runs in the same process as an Activity nothing guarantees you that your Activity will not be killed.
From Processes and Threads:
For example, an activity that's uploading a picture to a web site
should start a service to perform the upload so that the upload can
continue in the background even if the user leaves the activity. Using
a service guarantees that the operation will have at least "service
process" priority, regardless of what happens to the activity. This is
the same reason that broadcast receivers should employ services rather
than simply put time-consuming operations in a thread.
Conclusion:
If you want to do a background operation that will take a while and it's important it finishes correctly, use a Service.
Its not necessary that if A process started service then,Process is likely to be killed.Actually process remain alive or not it does not affect service.As its completely background procedure.May be the situation that you have started a process to just start a service.So process and service can not interrelated like that.
AFAIK i did not got your final question properly.