How to decide when to run different android applications components in a separate process

Question

I have read the following statements here

By default, all components of the same application run in the same process and most applications should not change this. However, if one needs to control which process a certain component belongs to, he can do so in the manifest file. The manifest entry for each type of component element—<activity>, <service>, <receiver>, and <provider>—supports an android:process attribute that can specify a process in which that component should run. One can set this attribute so that each component runs in its own process or so that some components share a process while others do not.

I want to know in which scenarios a developer would like to do so and run different components in different processes and what advantage will he get by doing so?

Another statement that I have read is

The <application> element in the manifest file also supports an android:process attribute, to set a default value that applies to all components

Regarding the above statement I want to know Why would a developer do that, there is already one process associated with one application by default and all the components run inside that process.

Can anyone clarify these things for me as I am not getting any details on this anywhere else

thanks

Answer 1

Let us take the example of Google Chrome browser which has made best use of android:process attribute. Before that let us understand why multi-process architecture was considered.

Remember those age old days, when we were using co-operative multi-tasking operating system. There was one single process and applications used to run in that single process turn by turn. Problem with that architecture was, if one application misbehaves that single process dies off there by bringing entire system down.

Now a days modern operation system, run applications in their own processes. If one application misbehaves, the process hosting it dies off and does not affect rest of the system.

Same applies to the browser. If one web-page misbehaves, it brings down the entire browser there by making web-pages opened in other tabs unavailable. Hence multi-process architecture was built.

Separate processes are used for browser tabs to protect the browser application from bugs in the rendering engine. Each render process is run as an android service in separate process. This is done by using android:process tag of <service> element. Another important flag used for rendering engine process is android:isolateProcess. This flag ensures render process does not have access to the system resources like network, display and file system, there by making the browser application highly secure.

Here is the snippet of chrome's manifest file:

 <service android:name="org.chromium.content.app.SandboxedProcessService0" android:permission="com.google.android.apps.chrome.permission.CHILD_SERVICE" android:exported="false" android:process=":sandboxed_process0" android:isolatedProcess="true" />

Here is the output of adb shell:

USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
u0_a14    12926 317   694380 102828 ffffffff 00000000 S com.android.chrome
u0_i16    26875 317   590860 59012 ffffffff 00000000 S com.android.chrome:sandboxed_process5
u0_i17    27004 317   577460 47644 ffffffff 00000000 S com.android.chrome:sandboxed_process6

The element in the manifest file also supports an android:process attribute, to set a default value that applies to all components

By default the name of the application process will be the package name specified in <manifest> tag. This can be overridden by specifying the name in the android:process attribute of the <application> tag. One use case : if multiple applications want to run in the same process, provided those applications are signed by same certificate and share the user ID.

If the name of <android:process> starts with :, it becomes private to that application, as in case of chrome's rendering engine (com.android.chrome:sandboxed_process5). It implies applications except com.android.chrome cannot communicate with this rendering engine.

If the name of <android:process> starts with lowercase character, it becomes global process. From docs:

This allows components in different applications to share a process, reducing resource usage.

Summary of benefits:

• To improve overall application stability (crashes / hangs). One service process crash does not bring down entire application.
• Security by preventing access to the rest of the system.
• Reduce resource usage, by running component in a process and sharing it among different applications.

Basically you should be able to separate the concerns and decide whether it makes sense to apply multi-process architecture.

Update 1: Adding @Budius comment

Each process have only a certain amount of memory available. In the app I work at, we do computational intensive processing in large memory arrays. Those computational we always fire in a separate process to make sure we'll have enough memory for the whole thing to happen and not crash with OutOfMemory.

Answer 2

The reason one might want to do this is because Android can shut down your application process to free up memory in the system any time it wants to, and you may want to mitigate the situation.

Suppose you have a really, really important piece of code that takes a long while to complete that would be very bad to kill in the middle of it working (for instance, a financial transaction in bank software). Putting this piece of code in a Service that runs in a separate process from the rest of the application code will ensure Android doesn't kill your Service that is potentially still running after the user exited your application.

From the docs:

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.

You can read more here

Answer 3

In general, a Service is used when you expect a non-UI task to take a fairly long time to complete. An Activity that does not remain in the foreground can in all probability be terminated by the OS, while a Service can continue to run indefinitely.

A Service is created in a separate process when you don't want the garbage collector to affect its working. The garbage collector will, in that case, affect only the application process. Moreover, a Service in a separate process has the added advantage that it will consume slightly less memory than what it would if it were in the main application process.

The Service that you declare in a separate process can be either private to the application:

<service android:process=":my_private_process"

or it can be global:

<service android:process="my_global_process"

In the latter case there is no colon prefix. A Service in a private process can only interact with your application, while a Service in a public process can deal with other applications as well. This is mainly when a Service should be used in a separate process: when you want your application to share data or functionality with other applications, and to do it in the background without being disturbed by the OS or the GC. To quote the documentation:

This allows components in different applications to share a process, reducing resource usage.