Android Process

Management
Facts about Android Processes
Much of the time, each Android application runs in its own linux process.

Android handles the process management, not the application.

Android tries to suspend processes, rather than killing them, if they’re not in use. This
saves power and CPU usage, as the process can be reactivated if needed without
creating from scratch.

Android may kill a process if it starts to run out of free memory, starting with
processes in the lowest levels in the classification (more details in following slides)
and continuing up to the highest levels.

An Android application has essential building blocks, called components. The

components and their states greatly affect the lifetime of an application.
Classification of Processes
1. Foreground process - It’s required for what the user is doing. E.g.
texting. A process is considered as one if (any):

• Its Activity component is running atop the screen with the

user interacting with it.

• Its BroadcastReceiver component is running.

• Its Service component is running and executing code.

2. Visible process - It’s a process which may be doing some work for
the user. E.g. performing search in the filesystem. A process is
visible if (any):

• Its Activity component is visible on-screen but is not on the

foreground (the component is paused).

• Its Service component is running as a foreground service.

E.g. Live wallpaper, input method service, etc.
 Broadcast 3. Service process - It’s responsible for tasks which the user
Activity Service cannot directly see but cares about. E.g. checking for updates,
Receiver
data upload/download, etc.

Foreground • It has to have a running Service component to be

Process classified as a service process.

• Long running services processes may be demoted and

Visible given less priority.
Process
4. Cached process - It’s a process with low priority, possibly having
an activity that may have no direct impact on user experience.
Service
Process • Its Activity component[s] is/are stopped, and not visible
to the user.

Cached • Android will start off with killing such processes if

Process memory is needed elsewhere.

• Android keeps cached processes in memory to improve

user experience, reduce power consumption, CPU usage,
etc.

• It’s often less expensive to reactivate a process in

memory rather than spawning one from scratch.
 Summing up everything
! By default, all the components of an app run in the same process.
! Android tries its best to classify a process as high as it can. When it runs out of memory, it’ll start with
killing the lowest level processes, moving up its way. E.g. a service process is likely to get killed before a
foreground process.
! A process which hosts visible items on the screen is less likely to be killed than a process which doesn’t.
! If you’re playing a resource hungry game (foreground process) and memory starts to run out, service apps
such as for music streaming, file downloads, etc may be killed.
! On the other side, when memory is abundant, Android uses cached processes, data, etc to make use of
free memory.
! Android may spawn processes in response to events. For example, certain apps may be started
automatically during startup, in response to captured photo, changed data connection, etc. This means
that apps do not have to necessarily wait for themselves in the background, Android can handle it itself,
making the system much more efficient.
! Newer versions of Android uses ART (Android Runtime) to manage the processes, instead of hosting
each process in a virtual machine (Dalvik). The ART also compiles apps to native code upon their
installation.