On my Galaxy Nexus with Jelly Bean 4.1.1 (official) sometimes the OS goes on a killing spree and the log has these kinds of entries:
10-02 22:24:34.992 I/ActivityManager( 306): Killing 7517:com.google.android.apps.reader/u0a77: remove task
10-02 22:24:36.484 I/ActivityManager( 306): Killing 7465:com.tf.thinkdroid.sg:writedroid/u0a50: remove task
10-02 22:24:37.273 I/ActivityManager( 306): Killing 5924:com.metago.astro/u0a73: remove task
10-02 22:24:37.296 W/ActivityManager( 306): Scheduling restart of crashed service com.metago.astro/.jobs.JobService in 5000ms
10-02 22:24:37.656 I/ActivityManager( 306): Killing 7302:org.jtb.alogcat/u0a84: remove task
10-02 22:24:38.148 I/ActivityManager( 306): Killing 7120:com.google.android.gm/u0a19: remove task
Unfortunately one of the processes being killed is my remote service that has a running app bound to it. Indeed, the service is restarted immediately afterwards but this causes inconsistent behavior in my app.
In Service Lifecycle it says:
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.
My app binds to the remote service with Context.BIND_AUTO_CREATE so I was under the impression that the remote service will stay up as long as the main process is bound to it. How can I make Android not kill the remote service?
NOTE: The bounty is for explaining why the code doesn't seem to work according to the documentation.
Please, read this answer from Joel F here: How it is possible Service run indefinitely and also allow binding in android?
As mentioned, if there is really a need for resources, the only way of keeping your service unkillable is to use foreground service http://developer.android.com/guide/components/services.html#Foreground
The documentation is also written wrongly because the citation : "system will keep the service running as long as either it is started or there are one or more connections to it" is not true in 100% of cases. The Context.BIND_AUTO_CREATE flag will give a higher privilege to your service but not hight enough to keep it unkillable. The other services will be killed first and if there is still need for ressourcees, your privileged service will be also killed.
A Service is a component of an Application, which runs in a process. Though, according to the service lifecycle documentation, the process containing the service should not have been killed, but there are some other cases when Android may kill.
In case the OS has some resource shortage, it will prioritize the running processes and kill the process with lower priority. Now, if there are more than one processes running which have services which are promised not to be killed according to Service life cycle, Android will prioritize and kill the process with lower priority.
Android might decide to shut down a process at some point, when memory
is low and required by other processes that are more immediately
serving the user. Application components running in the process that's
killed are consequently destroyed. A process is started again for
those components when there's again work for them to do.
When deciding which processes to kill, the Android system weighs their
relative importance to the user. For example, it more readily shuts
down a process hosting activities that are no longer visible on
screen, compared to a process hosting visible activities. The decision
whether to terminate a process, therefore, depends on the state of the
components running in that process.
Quoted from here: http://developer.android.com/guide/components/processes-and-threads.html
When OS is running low in resouces, it is compelled to take decisions breaking fair promises :)
For setting services un-killable, please take a look on android persistant services: http://devescape.blogspot.ch/2011/02/persistent-services-in-android.html
Related
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 don't mind letting the application get killed by the Android OS, I'm trying to debug why the application is restarting after being killed by low memory situations. I'm using
adb shell dumpsys activity processes
To read the "Process LRU list (sorted by oom_adj):"
My current problem is when I do the following steps and read the dumpsys after each step.
App Running
Proc #)13: adj=fore /FA trm= 0 6124:com.thisoldthing (top-activity)
App closed by back button
Proc #20: adj=bak /B trm= 0 6124:com.thisoldthing (started-bg-ui-services)
Killed after running stressrobo
Proc #13: adj=svc /B trm=15 8488:com.thisoldthing (started-services)
Now the application is not killed when putting the device into a low memory situation. More worrisome is I want to know why it restarted.
Android will try to keep your service alive as long as possible. The documentation of Context.startService() says: "If any errors happen in the service's process, it will automatically be restarted." My understanding and experience let me believe that it will happen regardless you started with startService() or bindService(), but the last one has no mention to that though.
So, if you don't want get your service restarted, you need to close bound connections before kill it. Unfortunately the application can not rely in onDestroy() being called in killing conditions so any unbindService() calls will depend on application's life-cycle. You will need to handle it by yourself.
Finally, bind connections was not designed to remain forever. They should connect, do the job and unbind. Keeping this in mind, android does the right think restarting services with bound connections.
In my android application I am using a foreground service which is spawning a thread as a worker. Sometimes I observed the application is killed but the thread is still trying to refer some of the values which are no more available.
Can android decide to kill my application leaving the service still running?
I am stopping the thread in onDestroy() method of my service and hence want to know when Android kills the application, would it call Service:onDestroy().
All the applications in Android runs as a separate process similar to a linux process. So if your service is running in a separate process then the Android might decide to shut down a process at some point, when memory is low and required by other processes that are more immediately serving the user. Application components running in the process that's killed are consequently destroyed. A process is started again for those components when there's again work for them to do.
When deciding which processes to kill, the Android system weighs their relative importance to the user. For example, it more readily shuts down a process hosting activities that are no longer visible on screen, compared to a process hosting visible activities. The decision whether to terminate a process, therefore, depends on the state of the components running in that process. The rules used to decide which processes to terminate is discussed below.
Also you can control that if your service can run in the same process as of your application or in a separate process by using the android:process attribute in the manifest.
For more information You can read about processes and threads on below link:
http://developer.android.com/guide/components/processes-and-threads.html
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?