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.