Usage of android:process

I have this AndroidManifest.xml file:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1" android:versionName="1.0.0.0721"
android:process="com.lily.process" package="com.lily.test">

    <provider android:authorities="com.lily.test"
      android:name="com.lily.test.provider" 
      android:process="com.lily.process">
    </provider>

"android:process"开发者_JS百科 is added both as manifest tag and provider tag, I know if it is added as a provider tag, the provider can be run in the "com.lily.process" process. But what's the usage of it when written as a manifest tag? I have tried, but not all components could be running in the process it identified.

I would agree that not many people would find android:process to be useful as an attribute of the application tag. However, I have found it to be useful as an attribute of the activity tag.

The purpose of android:process on an activity is to specify that your activity should be launched in a process having a specific name. The choice of that name may be used either to isolate the activity in its own process (different from the one that launched it), or to force it to cohabit in a single process with other activities that use the same name.

Per the Dev Guide (http://developer.android.com/guide/topics/manifest/activity-element.html):

"If the name assigned to this attribute begins with a colon (':'), a new process, private to the application, is created when it's needed and the activity runs in that process. If the process name begins with a lowercase character, the activity will run in a global process of that name, provided that it has permission to do so. This allows components in different applications to share a process, reducing resource usage."

I have recently found this attribute to be useful in solving a problem I had with launching a help activity for an app that, under certain circumstances, was fairly close to the 16MB heap limit that still applies to some devices. Launching its help activity was, in those situations, pushing my app over the limit, resulting in a force close.

By using the android:process tag, I was able to specify that my help activity should be launched in a separate process of its own. This process had its own 16MB heap, and it was not counted against the heap of my main app that launched it. This permanently and completely prevented my app from running out of heap space and crashing when help was launched.

If your launching app has the package name

com.mycompany.mymainapp

and is therefore assigned a process name that is that same string, then, if you use

android:process=":myhelp"

on your launched activity, it will be assigned the process name

com.mycompany.mymainapp:myhelp

and that process will have its own, separate process ID, which you can view (for example in DDMS).

That, at least, has been my experience. My testing has so far been performed on an old Moto Droid running CM6 (Android 2.2.1), configured to have a 16MB heap limit.

In my case, since I did not want the user to perceive the help as being separate from my app, I included the

android:excludeFromRecents="true"

attribute to prevent the help activity from appearing on the recent apps (long-press Home) list. I also included

android:taskAffinity="com.mycompany.mymainapp.HelpActivity"

where HelpActivity is the name of the help activity, to segregate the activity in its own task

I also added:

android:launchMode="singleInstance"

to prevent multiple instances of this app from being created each time the user invoked help.

I also added the flag:

Intent.FLAG_ACTIVITY_NEW_TASK

to the Intent used to launch the help activity.

These parameters may or may not be needed, depending upon the use that you are making of the android:process attribute.

Considering how often one encounters memory limits when developing for Android devices, having a technique that can, in some cases, allow you to break out parts of your app into separate processes, each with its own heap, seems like a wonderful gift. There may be hidden hazards in doing this that I have not yet considered or experienced, but so far, so good, in my particular instance.

@Carl

There may be hidden hazards:

• Memory can not be released When there is a background service(e.g:android:process=":myhelp") in the same process.
• Singleton pattern can not be used.

Ref : http://developer.android.com/training/articles/memory.html#MultipleProcesses

The process has now almost tripled in size, to 4MB, simply by showing some text in the UI. This leads to an important conclusion: If you are going to split your app into multiple processes, only one process should be responsible for UI. Other processes should avoid any UI, as this will quickly increase the RAM required by the process (especially once you start loading bitmap assets and other resources). It may then be hard or impossible to reduce the memory usage once the UI is drawn.

android:process should be used with caution

(Quote from the link below)

A little-known and seemingly undocumented behaviour of Android is that each process of an application has is own Application instance.

So, if you have a service which runs in a different process, calling startService() will init the Appplication class for your app.

More info — Starting Service in Android calls Applications onCreate

android:process and shareduserid can be used to pass on resources between packages. In my case, this is coming handy now :)

Source code example: https://github.com/ikust/hello-sharedprocess