In most cases, every Android application runs in its own Linux process. This process is created for the application when some of its code needs to be run, and will remain running until it is no longer needed and the system needs to reclaim its memory for use by other applications.
An unusual and fundamental feature of Android is that an application process's lifetime is not directly controlled by the application itself. Instead, it is determined by the system through a combination of the parts of the application that the system knows are running, how important these things are to the user, and how much overall memory is available in the system.
It is important that
application developers understand how different application components
BroadcastReceiver) impact the lifetime
of the application's process. Not using these components correctly can
result in the system killing the application's process while it is doing
A common example of a process life-cycle bug is a
BroadcastReceiver that starts a thread when it
receives an Intent in its
method, and then returns from the function. Once it returns, the system
considers the BroadcastReceiver to be no longer active, and thus, its hosting
process no longer needed (unless other application components are active in
it). So, the system may kill the process at any time to reclaim memory, and in doing so,
it terminates the spawned thread running in the process. The solution to this problem
is to start a
Service from the BroadcastReceiver, so the
system knows that there is still active work being done in the process.
To determine which processes should be killed when low on memory, Android places each process into an "importance hierarchy" based on the components running in them and the state of those components. These process types are (in order of importance):
- A foreground process is one that is required for
what the user is currently doing. Various application components can
cause its containing process to be considered foreground in different
ways. A process is considered to be in the foreground if any of the
following conditions hold:
- It is running an
Activityat the top of the screen that the user is interacting with (its
onResume()method has been called).
- It has a
BroadcastReceiverthat is currently running (its
BroadcastReceiver.onReceive()method is executing).
- It has a
Servicethat is currently executing code in one of its callbacks (
- It is running an
- A visible process is one holding an
Activitythat is visible to the user on-screen but not in the foreground (its
onPause()method has been called). This may occur, for example, if the foreground Activity is displayed as a dialog that allows the previous Activity to be seen behind it. Such a process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
- A service process is one holding a
Servicethat has been started with the
startService()method. Though these processes are not directly visible to the user, they are generally doing things that the user cares about (such as background mp3 playback or background network data upload or download), so the system will always keep such processes running unless there is not enough memory to retain all foreground and visible process.
- A background process is one holding an
Activitythat is not currently visible to the user (its
onStop()method has been called). These processes have no direct impact on the user experience. Provided they implement their Activity life-cycle correctly (see
Activityfor more details), the system can kill such processes at any time to reclaim memory for one of the three previous processes types. Usually there are many of these processes running, so they are kept in an LRU list to ensure the process that was most recently seen by the user is the last to be killed when running low on memory.
- An empty process is one that doesn't hold any active application components. The only reason to keep such a process around is as a cache to improve startup time the next time a component of its application needs to run. As such, the system will often kill these processes in order to balance overall system resources between these empty cached processes and the underlying kernel caches.
There will only ever be a few such processes in the system, and these will only be killed as a last resort if memory is so low that not even these processes can continue to run. Generally, at this point, the device has reached a memory paging state, so this action is required in order to keep the user interface responsive.
When deciding how to classify a process, the system will base its decision on the most
important level found among all the components currently active in the process.
BroadcastReceiver documentation for more detail on how
each of these components contribute to the overall life-cycle of a process.
The documentation for each of these classes describes in more detail how
they impact the overall life-cycle of their application.
A process's priority may also be increased based on other dependencies
a process has to it. For example, if process A has bound to a
flag or is using a
ContentProvider in process B, then process B's
classification will always be at least as important as process A's.