The difference between apk,task,android:process and Android:shareduserid

Final Summary:

1. Different package apps are not shared by default in different processes.

2. Different package apps if you set the same Shareduserid, when their keystore is the same, the data can be shared, not the same process by default.

3. Different package apps when the Shareduserid/keystore is the same, set the same android:process in any node in the manifest.xml, and the same android: The node of process is in the same process.

APK generally occupies a dalvik, a process, a task. Multiple processes can also be set up by setting up multiple tasks.

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

[1] Create project:

Project Name: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_36 pid:8360 NAME:com.demo

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

user:app_36 pid:8360 NAME: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, the corresponding modification androidmanifest.xml in the name: com.demo.second.SecondActivity

[2] Run the program to see the status of the process at this time:

user:app_36 pid:10593 NAME:com.demo

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

user:app_36 pid:10593 NAME: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. Process state validation After the activity process property is modified in the same apk

[1] Add the Process property for secondactivity, the value is ": ABC", can also be casually other ":" The beginning of the string, the common name is ": Remote":

<activity android:name= "com.demo.second.SecondActivity" android:process= ": abc" > </activity>

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

user:app_36 pid:12137 NAME:com.demo

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

user:app_36 pid:12137 NAME:com.demo

user:app_36 pid:12303 NAME: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. Validation of activity process status for different package names in different apk

[1] Running Firstproject:

user:app_36 pid:12137 NAME:com.demo

[2] Create Secondproject:

Project Name:secondproject

Package:com.demo2

Default Activity:mainactivity

[3] Running Secondproject:

user:app_37 pid:14191 NAME: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 also for Com.demo, corresponding to modify the Androidmanifest.xml content.

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

user:app_36 pid:14944 NAME: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.

You can view the content by DDMS copy/data/system/packages.xml:

<package name= "Com.demo" codepath= "/data/app/com.demo.apk" system= "false" ts= "1279955425000" version= "1" userId= " 10036 ">

In this file, the package name is 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 Eclipse's Package Explorer navigation tree, select Firstproject, right-click.

[2] Android Tools-->export signed Application package, follow the wizard to create an APK bundle signed with the specified key.

[3] also export second Project.

[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,share User ID is same, the package name does not simultaneously process condition analysis

[1] Modifying the Manifset nodes of the Firstproject, Secondproject androidmanifest.xml, adding 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.demo2

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:

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

8. Different Apk,share User ID is the same, the package name is different, the process property of the specified activity is analyzed

[1] Modify the process property of the Secondproject mainactivity, specifying binding to the process named Com.demo:

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

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

User:app_35 pid:21387 NAME:com.demo

Conclusion: Two activity runs in the same process.

9. Different apk,share User ID is same, package name is different, signature key is different

After the experiment, installing the second apk will prompt install_failed_update_incompatible error, installation failure.

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."

The difference between apk,task,android:process and Android:shareduserid