1page.title=Processes and Application Life Cycle
2@jd:body
3
4<p>In most cases, every Android application runs in its own Linux process.
5This process is created for the application when some of its code needs to
6be run, and will remain running until it is no longer needed <em>and</em>
7the system needs to reclaim its memory for use by other applications.</p>
8
9<p>An unusual and fundamental feature of Android is that an application process's
10lifetime is <em>not</em> directly controlled by the application itself.
11Instead, it is determined by the system through a combination of the parts of the application
12that the system knows are running, how important these things are to the user,
13and how much overall memory is available in the system.</p>
14
15<p>It is important that
16application developers understand how different application components
17(in particular {@link android.app.Activity}, {@link android.app.Service},
18and {@link android.content.BroadcastReceiver}) impact the lifetime
19of the application's process.  <strong>Not using these components correctly can
20result in the system killing the application's process while it is doing
21important work.</strong></p>
22
23<p>A common example of a process life-cycle bug is a
24{@link android.content.BroadcastReceiver} that starts a thread when it
25receives an Intent in its {@link android.content.BroadcastReceiver#onReceive
26BroadcastReceiver.onReceive()}
27method, and then returns from the function.  Once it returns, the system
28considers the BroadcastReceiver to be no longer active, and thus, its hosting
29process no longer needed (unless other application components are active in
30it).  So, the system may kill the process at any time to reclaim memory, and in doing so,
31it terminates the spawned thread running in the process.  The solution to this problem
32is to start a {@link android.app.Service} from the BroadcastReceiver, so the
33system knows that there is still active work being done in the process.</p>
34
35<p>To determine which processes should be killed when low on memory, Android
36places each process into an "importance hierarchy" based on the components running in
37them and the state of those components. These process types are (in order of importance):</p>
38
39<ol>
40
41<li>A <strong>foreground process</strong> is one that is required for
42what the user is currently doing.  Various application components can
43cause its containing process to be considered foreground in different
44ways.  A process is considered to be in the foreground if any of the
45following conditions hold:
46 <ul>
47  <li> It is running an {@link android.app.Activity}
48  at the top of the screen that the user is interacting with (its
49  {@link android.app.Activity#onResume} method has been called).</li>
50  <li> It has a {@link android.content.BroadcastReceiver} that is currently running
51  (its {@link android.content.BroadcastReceiver#onReceive 
52  BroadcastReceiver.onReceive()} method is executing).</li>
53  <li>It has a {@link android.app.Service} that is currently executing code
54  in one of its callbacks ({@link android.app.Service#onCreate Service.onCreate()},
55  {@link android.app.Service#onStart Service.onStart()}, or
56  {@link android.app.Service#onDestroy Service.onDestroy()}).</li>
57 </ul>
58</li>
59<p>There will only ever be a few such processes in the system, and these will only
60be killed as a last resort if memory is so low that not even these processes
61can continue to run.  Generally, at this point, the device has
62reached a memory paging state, so this action is required in order to keep the user
63interface responsive.</p>
64</li>
65
66<li>A <strong>visible process</strong> is one holding an {@link android.app.Activity}
67that is visible to the user on-screen but not in the foreground (its
68{@link android.app.Activity#onPause} method has been called).  This may
69occur, for example, if the foreground Activity is displayed as a dialog
70that allows the previous Activity to be seen behind it.  Such a
71process is considered extremely important and will not be killed unless doing so is
72required to keep all foreground processes running.
73</li>
74
75<li>A <strong>service process</strong> is one holding a {@link android.app.Service}
76that has been started with the
77{@link android.content.Context#startService startService()} method.  Though these
78processes are not directly visible to the user, they are generally doing things
79that the user cares about (such as background mp3 playback or background
80network data upload or download), so the system will always keep such processes
81running unless there is not enough memory to retain all foreground and visible process.
82</li>
83
84<li>A <strong>background process</strong> is one holding an {@link android.app.Activity}
85that is not currently visible to the user  (its
86{@link android.app.Activity#onStop} method has been called).  These processes
87have no direct impact on the user experience.  Provided they implement
88their Activity life-cycle correctly
89(see {@link android.app.Activity} for more details), the system
90can kill such processes at any time to reclaim memory for one of the three
91previous processes types.  Usually there are many of these processes running,
92so they are kept in an LRU list to ensure the process that was most recently seen
93by the user is the last to be killed when running low on memory.
94</li>
95
96<li>An <strong>empty process</strong> is one that doesn't hold any active application
97components.  The only reason to keep such a process around is as a cache to
98improve startup time the next time a component of its application needs to
99run.  As such, the system will often kill these processes in order to
100balance overall system resources between these empty cached processes and the
101underlying kernel caches.
102</li>
103
104</ol>
105
106<p>When deciding how to classify a process, the system will base its decision on the most
107important level found among all the components currently active in the process.
108See the {@link android.app.Activity}, {@link android.app.Service}, and
109{@link android.content.BroadcastReceiver} documentation for more detail on how
110each of these components contribute to the overall life-cycle of a process.
111The documentation for each of these classes describes in more detail how
112they impact the overall life-cycle of their application.</p>
113
114<p>A process's priority may also be increased based on other dependencies
115a process has to it.  For example, if process A has bound to a
116{@link android.app.Service} with
117the {@link android.content.Context#BIND_AUTO_CREATE Context.BIND_AUTO_CREATE}
118flag or is using a
119{@link android.content.ContentProvider} in process B, then process B's
120classification will always be at least as important as process A's.</p>
121