Content sharing implementation mechanism after Android signature

APK generally occupies a dalvik, a process, a task. A task is a stack of activity that "may" contain activity from multiple apps

Classification	APK	Task
Working space	Dalvik virtual Machines	Activity stack
Process	In a process	In a process
exists in multiple processes	OK	No
Activty to store other processes		OK
Setup method	Application (same as signature) Android:shareduserid= "com.xx" Android:process: "Com.aa"	Application (same as signature) Android:shareduserid= "com.xx" Under the activity Android:process: "Com.aa"

By default, all components in the same application run in the same process, and most applications do. However, if we want to control that a particular component belongs to a process, we can manifest.xmlConfiguration in the file.

In the manifest entries for each component element (activity, service, receiver, provider), a property of "Android:process" is supported, which, through this property, We can specify the processes that a component runs on. You can set this property so that each component runs in a set process , or only some components share a process. We want to allow components in different applications to run in the same process by setting the "Android:process" property, and these applications need to share the same Linux user ID and have the same certificate, which is an important premise .

<application>Element also has a "android:process" property that can set a default value that applies to all components.
Android may terminate a process at any time when the amount of available memory is low and some processes that interact with the user require memory. The components that run in the terminated process are therefore destroyed, primarily because the task is destroyed, but when these components are needed again to work, a process is started.
When deciding which process to terminate, the Android system will weigh their importance to the user. For example, it is more reasonable to terminate a process that runs an invisible activities than a process that is running a visible activities. Whether to terminate a process that relies on the state of the components running in this process.

If you cannot put two activity in the same application, you can make the two activity mandatory in the same process by setting the following properties in the respective manifest so that you can take advantage of the resources that are shared within the process and reduce the memory footprint:

(1) Set the same user Id: <manifest android:shareduserid= "com.xx" (2) The called Activity sets the following properties: <activity android:multiprocess = "true" or <activity android:process= "Com.aa"

For 3D OpenGL programs, after modifying the above properties, the memory consumption of the called activity will be significantly reduced, for example: 30MB, 2MB.

<strong> proof that the APK sharing process will have two conditions </strong> (1) Set the same userid: (2) The invoked activity sets the following properties: Java code <activity android: Multiprocess= "true" or <activity android:process= "Com.aa"

Here are some examples of what others have proven to illustrate the problem.

1. Process state validation when multiple activity calls in the same package in the same apk

[1] Creating Project:projectname:FirstProject

Package:com.demo

Default Activity:mainactivity

[2] Add a new activity:

Name:secondactivity

[3] Modify the layout. Add a button to the Mainactivity layout and start secondactivity When you click the button. Place a textview in the layout of the secondactivity to prove that Secondactivity has started.
[4] Run the program to view this app process:

User:app_36pid:8360name:com.demo

[5] Click on the button, start secondactivity, see the process again:

User:app_36pid:8360name:com.demo

Conclusion: The list of processes does not change, and two activity runs in the same process.

2. Process state validation during activity invocation of different packages in the same apk [1] Move the secondactivity to the package Com.demo.second, modify the name in the Androidmanifest.xml to: com.demo.second.SecondActivity
[2] Run the program to see the status of the process at this time:

User:app_36pid:10593name:com.demo

[3] Click the button to start secondactivity, see the process at this time:

User:app_36pid:10593name:com.demo

Conclusion: The list of processes does not change, and two activity runs in the same process. That is, the process name is only affected by the package property of the Manifset node in Androidmanifest.xml.

3. The activity process property in the same apk is modified after the status validation [1] for secondactivity Add process attribute, its value is ": ABC", can also be casually other ":" The beginning of the string, the common name is ": Remote":

<activityandroid:name= "Com.demo.second.SecondActivity" android:process= ": ABC" ></activity>

[2] Run the program to view the process status:

User:app_36pid:12137name:com.demo

[3] Click on the button, start secondactivity, view the process situation:

User:app_36pid:12303name:com.demo:abc

Conclusion: The process table has one more item. Two activity each has a process, the secondactivity process name is the package name + suffix.

4. Activity process status verification for different package names in different apk [1] Run Firstproject:

User:app_36pid:12137name:com.demo

[2] Creating SecondProject:projectname:SecondProject

Package:com.demo2

Default Activity:mainactivity

[3] Running Secondproject:

User:app_37pid:14191name:com.demo2

Conclusion: The process table has one more item. Two activity each has a process, and its process user ID, package name is also different, non-impact.

5. Different apk, the same signature, the same package name of the activity process status verification [1] modified Secondproject package is also com.demo, corresponding to modify androidmanifest.xml content.
[2] Run the Secondproject to view the process status:

User:app_36pid:14944name:com.demo

Conclusion: There is only one item in the process table, but in fact Firstproject is already covered, the system only has secondproject, because the emulator uses the same signature key when debugging, and the system sees key like The package name thinks the package is firstproject, so it's covered. Software update process.
You can view the content by DDMS copy/data/system/packages.xml:
<packagename= "Com.demo" codepath= "/data/app/com.demo.apk" system= "false" ts= "1279955425000" version= "1" userId= " 10036 ">
In this file, PackageName are unique, and you can see that the user name is determined by the UserID.

6. Different apk, the signature is not the same, the package name of the same activity process status verification [1] in the Eclipse packageexplorer navigation tree selected Firstproject, right-click.
[2] Androidtools-->exportsignedapplicationpackage, follow the wizard to create an APK package signed with the specified key.
[3] likewise exported secondproject.
[4] Switch the window to the emulator, press home---press Menu--and then click on the app---Manage application-->secondproject--> uninstall. This is intended to be prepared with the command-line installation.
[5] Launching a command-line window, executing adb install firstproject.apk, will prompt the successful installation.
[6] Executing the ADB install secondproject.apk, indicating that the installation failed.
Conclusion:

1> The default apk is assigned a new UserID when it is installed, i.e. the userid of Firstproject and Secondproject can be considered different at this time.

2> package name is different, whether the signature key is the same doesn't matter, two apk can be installed. "4th Experiment"

3> package name in the same time, the same signature key will overwrite the "5th experiment"; the second APK installation will fail if the signature is different. "6th Experiment"

7. Different Apk,shareuserid same, package name not simultaneous process situation analysis [1] Modify Firstproject, Secondproject androidmanifest.xml manifset nodes, add attributes

Android:shareduserid= "Com.demouser"

[2] Modify Secondproject package for Com.demo2, otherwise it will overwrite firsetproject.
[3] Run Firsetproject, secondproject, view the list of processes:

User:app_35 pid:19993 NAME:com.demo

User:app_35 pid:20045 NAME:com.demo2

Conclusion:

There are still two processes. However, the user name of the process is the same, stating that Shareuserid is actually valid and the process PID is not the same.

Export/data/system/packages.xml again to view its contents, and you can see that the UserID for the two items is 10035, which is exactly the same:

<packagename= "Com.demo" codepath= "/data/app/com.demo.apk" system= "false" ts= "1279957484000" version= "1" Shareduserid= "10035" ><packagename= "Com.demo2" codepath= "/data/app/com.demo2.apk" system= "false" ts= " 1279957473000 "version=" 1 "shareduserid=" 10035 ">

8. The process property of the specified activity is the same as the different Apk,shareuserid, the package name is different, and [1] modifies the Secondproject's mainactivity. Specifies the binding to a process named Com.demo:

<activityandroid:name= ". Mainactivity "android:label=" @string/app_name "android:process=" Com.demo ">

[2] Run Firstproject, secondproject, view the process status:

User:app_35pid:21387name:com.demo

Conclusion: Two activity runs in the same process.

9. Different Apk,shareuserid same, package name is different, signature key is different experiment, install the second apk will prompt install_failed_update_incompatible error, installation failed.
Summarize:
UserID is different:

Package name is different:

When the process attribute is not set, the individual activity is in the respective process. The process is not shared with the same name as another user, even if the package name is specified by the process.

The package name is the same:

Same signature: Overwrite the old same package name APK. Different signatures: The new apk will fail to install. "Signature keys are generally different."

userid In the same phase:

Package name is different:

When the process attribute is not set, the individual activity is in the respective process. Process property is specified, you can share processes.

The package name is the same:

Same signature: Overwrite the old same package name APK. Different signatures: The new apk will fail to install. "Signature keys are generally different."

Reference: http://blog.csdn.net/llping2011/article/details/12705121

Content sharing implementation mechanism after Android signature