Okay now here's the question that I can't get rid off unless I have the correct answer for this.I read the Android documentation and walk through some of the interesting links as well but none of them satisfied me.
What I can conclude on the basis of my search result is The foreground activity, being the most important among the other states, is only killed or terminated as a last resort, especially if it is already consuming too much memory. When a memory paging state has been reach by a foreground activity, then it is killed so that the user interface can retain its responsiveness to the user.
What I want is just a rigid answer.
If system is low on memory it kills some processes to make some space that operating system can run. So that it starts killing starting from low priority to high (5 to 1). If your foreground activity is destroyed, system has very very low memory to run and even operating system may crash soon.
Foreground process
Visible process
Service process
Background process
empty process
Related
I have a Service running in the same process as my Application.
Sometimes the Android OS decides to kill my service (probably due to low memory).
My question is: does my Application get killed along with the Service? or how does it work exactly?
Thanks!
First be sure to read: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle
The key to this is that on Android a process is just a container for code -- or specifically one or more components (activities, services, receivers, providers). By default all components in a .apk get their own, dedicated process, that they all run in together. This is almost always what you want.
When the user is directly interacting with a component of that process (that is an activity) Android will try very hard to keep that process running, and you won't see it killed except under extraordinary circumstances.
When the user is no longer directly interacting with the process, then it becomes expendable relative to other processes as described in the referenced documentation. That is, empty processes (no interesting components) will be killed before processes holding activities that the user had been using, which will be killed before processes with running services. So having a running service will tend to keep your process around at the expense of other processes.
At the same time, we need to deal well with more and more applications leaving services running, often indefinitely, and often with memory leaks. So has a service runs for an increasingly long time, Android will try less and less hard to keep its process going. Effectively this means moving it down to the background bucket until the out of memory killer takes it out. After that, if the service still wants to run, then a new process will be created for it to be restarted in.
The upshot is that for normal services that are running a long time, it is expected behavior that their process will get killed after a while. This doesn't need to stop the service; a service that wants to continue running will do so, it will just need to be instantiated in a new process.
Of course as long as the user is interacting with an activity in your process, the process won't be killed, since this pulls it to the foreground category regardless of what is going on with any services in it.
Processes are killed by the low memory killer, not Applications. So unless you do extra work to get your Service running in a different process, then your Activities are killed along with your Service.
The low memory killer doesn't try to destroy any objects in your process, although the activity manager may call onDestroy on Activity objects that are no longer needed. But that happens as part of the regular activity lifecycle, not due to low memory conditions.
(By the way, I'm unclear whether you mean "application" in general, or your object that extends Application, or whether you mean your Activities that show the UI.)
An application is something that has a user interface and if you have included a service along with it, then definitely it will be killed since Applications are terminated once the cached application queue becomes full
so create Service separate from application or in other words create an other project for it :)
btw, i'm not an experienced Android developer but thats i think what i learned by watching the Android development life cycle videos by Google
According to the documentation, both should have the same priority:
Android ranks a process at the highest level it can, based upon the importance of the components currently active in the process.
Using a service guarantees that the operation will have at least "service process" priority, regardless of what happens to the activity.
Is this really the case? Isn't memory usage a factor? If the services in both processes consume the same amount of memory while the killed activity consumes alot more (not garbage collected yet or because of leaks), would that make its process more eligible for termination?
Context:
My app consists of a service and an activity. It's important (for the user) that the service remains running even when the activity is not so to decrease the probability that it will be terminated I decided to assign each a separate process. The justification for this so far is possible unhandled exceptions in the activity that can bring down the whole process. I want to know if I should consider termination policies as another reason.
*Foreground service is not an option.
*The service is sticky (I just want to decrease downtime).
P.S., English is not my first language. Feel free to rephrase my question and correct any technical or grammar mistakes.
For your context you can make the service Sticky which will restart it upon destroyed.
Starting service in different process is not the solution, if you need it to run continuously. I am guessing you did it because your service got destroyed when Activity crashed. This happens because process is terminated when activity crashes or is force closed. Also, make sure your service is not bounded to Activitie's lifecycle
Is having a foreground service protective for the entire process? The documentation is a bit unclear, saying the service is highly unlikely to be killed. However, I've learned there's a big different between a service (or an activity) being destroyed versus the process (which contains all the activities and services, unless you are specifically forcing your service to be in a different process) being killed.
Any ideas?
Thanks.
First off, nothing prevents a process from being killed, and unfortunately there is very little you can do about it. Android uses a modified form of Linux's "out of memory" process killer to periodically kill processes. Memory does not even have to be low for a task to be killed - it can simply have been running for too long. If you are root you can fiddle around with various files (under /sys or /proc, it's been a while since I have looked at this) in order to fight Android and try to keep a process from being killed, but unless you touch these files very rapidly (several times a second) Android will still likely to kill your process at an inopportune time.
Having a foreground service won't change any of this, it will merely bump your process to a higher priority so Android is more likely to kill other things first. But depending on what else you are doing it may still have little effect. For instance, I have a logger app which I wrote which takes 12-15MB of (non-shared) memory while running, and when foregrounded it still gets killed on a device with 512MB of RAM if I switch to (memory hungry) Firefox and do much of anything. Note that there are things you can do to recover from this, for instance, telling AlarmManager to send you an intent periodically, which if your service is killed will restart it. This will increase battery usage, however.
Now with regards to the Service itself versus the Activity class, Android can very well garbage collect your Activity after calling onPause without killing the process. In this case, for example, if you have a pointer to your Activity from your Service class you will find that it is suddenly null, so if you are referring to your Activity in this way you should always test for a null pointer before trying to call into a non-static member of your Activity.
Let's say I'm using an app which is both RAM and CPU intensive and I get a call which I'm bound to be on for say, a minute. In this case, I want to know what will be the fate of the application. Will it still continue its execution in the background and will its priority be changed?
Also, if at all the app uses higher amounts of RAM and CPU, is there any chance that the app will be shutdown by the android OS?
Please share any resources and documentation that discusses this subject. Thanks in advance. :)
Will it still continue its execution in the background
For at least a few milliseconds, yes. Regardless of how an application moves to the background, once in the background, its process is eligible to be terminated, to free up RAM for other apps. When that occurs depends upon a lot of variables -- it could be milliseconds, it could be hours.
and will its priority be changed?
Background applications' processes run in a class that helps limit their CPU utilization.
Also, if at all the app uses higher amounts of RAM and CPU, is there any chance that the app will be shutdown by the android OS?
Regardless of amounts of RAM and CPU, the app's process may be terminated by Android at any point when it is in the background.
It's important to distinguish between the app itself and the Activity that is being obscured. An Activity is just part of an application. When an Activity is hidden certain lifecycle methods are called depdning on whether it is partially hidden (onPause) or fully hidden (onStop). This does not necessarily affect the background processes that you started before the Activity was obscured. Even when an Activity is hidden, the app still exists. Background threads and services you started while a given Activity was the foreground will still be running (assuming the OS is not low on resources) as part of the existing app process.
What you should do is think about how to handle the result of these background processes within the other lifecycle methods (e.g. onResume) should they complete durring or after the obscured state ends.
According to the docs (ref: http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle), android will automatically restart a service that is killed due to low memory.
To quote:
Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service.
My questions are:
(1) How does the system decide which services to restart?
(2) When is "later"?
Processes on the Android work in a hierarchical structure, so whatever services are on the top of the list get restarted first. This also applies to active processes, so if you have a process in the foreground that you are running, that foreground service is at the top of the list and will be removed first. It's pretty much a stack. I think that processes under higher memory pressure are moved up in priority, but who knows, you would have to look at the belly of the beast to see what's actually happening.