Content sharing implementation mechanism after android Signature

Content sharing implementation mechanism after android Signature
Apk generally occupies a dalvik, a process, and a task. A task is the stack of an activity, where "may" contains the activity from multiple apps.

Category	APK	Task
Workspace	Dalvik Virtual Machine	Activity Stack
Process	In a process	In a process
Exist in multiple processes	Yes	No
Store Activty of other processes		Yes
Setting Method	Under Application (Same signature) Android: sharedUserId = "com. xx" Android: process: "com. aa"	Under Application (Same signature) Android: sharedUserId = "com. xx" Under Activity Android: process: "com. aa"

By default, all components in the same application run in the same process, and most applications do the same. However, if we want to control that a specific component belongs to a process, we can Manifest. xmlFile.

In the manifest entries of each component element (activity, service, Cycler, and provider), one"Android: process"Through this attribute, we can specify the process that a component runs. You can set this attribute to run each component onSet ProcessAnd only some components can share a process. You can set the "android: process" attribute to run components in different applications in the same process.Sharing the same Linux User ID and having the same certificate is an important prerequisite.

The element also has an "android: process" attribute. You can set a default value for all components.
When the number of available memory is low, and some processes that interact with users instantly need memory, Android may terminate a process at any time. Components running in the terminated process will be destroyed, mainly because tasks are destroyed. However, when these components are required to work again, another process will be started.
When deciding which process to terminate, the Android system will weigh their importance to users. For example, it is more reasonable to terminate a process that is invisible to activities than to run a process that is visible to activities. Whether to terminate a process depends on the status of components running in the process.

If you cannot put two activities in the same application, you can set the following attributes in their respective manifest to force these two activities to run in the same process, in this way, the resources shared in the process can be fully utilized to reduce memory usage:

(1) set the same User Id:
 
  
2 MB.
  

  
The above proof that the APK sharing process requires two conditions(1) set the same UserId: (2) set the following attributes for the called activity: the Java code uses confirmed examples to illustrate the problem.
1. Process status verification when multiple activities in the same package in the same Apk are called
[1] creating a Project: projectname: FirstProject

   
  

    
   
Package: com. demo
    
   
Default Activity: MainActivity
   
  
[2] Add a new Activity:

   
  

    
   
Name: SecondActivity
   
  
[3] modify the layout. Add a Button in the MainActivity layout. When you click this Button, start SecondActivity. Place a Textview in the SecondActivity layout to prove that SecondActivity has been started.
[4] run the program to view the process of the App:

   
  

    
   
USER: app_36PID: 8360 NAME: com. demo
   
  
[5] click the button to start SecondActivity and view the process again:

   
  

    
   
USER: app_36PID: 8360 NAME: com. demo
   
  
Conclusion: The Process List does not change. The two activities run in the same process.
2. process status verification when calling Activity of different packages in the same Apk [1] Move SecondActivity to package com. demo. in second, modify AndroidManifest accordingly. the name in xml is com. demo. second. secondActivity
[2] run the program and check the process at this time:

   
  

    
   
USER: app_36PID: 10593 NAME: com. demo
   
  
[3] click the button to start SecondActivity and view the process status at this time:

   
  

    
   
USER: app_36PID: 10593 NAME: com. demo
   
  
Conclusion: The Process List does not change. The two activities run in the same process. That is, the process name is only affected by the package attribute of the manifset node in AndroidManifest. xml.
3. after the Activity process attribute in the same Apk is modified, the process status verification [1] adds the process attribute for SecondActivity. The value is ": abc", or "other ": A string starting with ": remote ":

   
  

    
   

   
  
[2] run the program and check the process:

   
  

    
   
USER: app_36PID: 12137 NAME: com. demo
   
  
[3] click the button to start SecondActivity and view the process status:
   
  

    
   
USER: app_36PID: 12303 NAME: com. demo: abc
   
  
Conclusion: There is one more entry in the progress table. Each Activity has a process. The SecondActivity process name is package name + suffix.
4. verify the status of the Activity process with different package names in different Apk [1] Run FirstProject:

   
  

    
   
USER: app_36PID: 12137 NAME: com. demo
   
  
[2] Create SecondProject: projectname: SecondProject

   
  

    
   
Package: com. demo2
    
   
Default Activity: MainActivity
   
  
[3] Run SecondProject:

   
  

    
   
USER: app_37PID: 14191 NAME: com. demo2
   
  
Conclusion: There is one more entry in the progress table. Each Activity has a process, and its process user ID and package name are also different, which does not affect each other.
5. verify the status of Activity processes with the same signature and package name for different Apk [1] modify the SecondProject package to com. demo and modify AndroidManifest. xml accordingly.
[2] Run SecondProject to view the process:

   
  

    
   
USER: app_36PID: 14944 NAME: com. demo
   
  
Conclusion: There is only one input table, but the FirstProject is actually overwritten at this time, and only the SecondProject exists in the system, because the signature keys used by the apk during simulator debugging are the same, and the keys are the same in the system, if the package name is the same, the package is replaced by the FirstProject. Software Update process.
You can use DDMS to copy/data/system/packages. xml to view the content:

    
     
In this file, packagename is unique and the user name is determined by userId.
    
6. verify the status of Activity processes with the same package name for different Apk and different signatures. [1] Right-click FirstProject in the PackageExplorer navigation tree of Eclipse.
[2] Androidtools --> ExportSignedApplicationPackage, follow the Wizard to create an apk package signed with the specified key.
[3] export SecondProject.
[4] switch the window to the simulator, press the Home Key --> press the Menu key --> set --> Application --> Manage Application --> SecondProject --> Uninstall. This is to prepare for installation using the command line.
[5] Start a command line window and run adb install firstproject.apk. A prompt is displayed, indicating that the installation is successful.
[6] Run adb install secondproject.apk to prompt installation failure.
Conclusion:

   
  

    
   
1> the default Apk is assigned with a new UserId during installation. In this case, the UserId of FirstProject and SecondProject can be considered different.
    
   
2> If the package name is different, it doesn't matter whether the signature key is the same. Both apk files can be installed. [4th labs]
    
   
3> If the package name is the same, if the signature key is the same, the 5th labs will be overwritten. If the signature is different, the installation of the second apk will fail. [6th labs]
   
  
7. For different Apk files, the consumer userid is the same, and the package name is different from the process. [1] modify the manifset node of AndroidManifest. xml of firstproject and secondproject to add attributes

   
  

    
   
Android: sharedUserId = "com. deshortname"
   
  
[2] modify the secondproject package to com. demo2, otherwise it will overwrite firsetproject.
[3] Run firsetproject and secondproject to view the process list:

   
  

    
   
USER: app_35 PID: 19993 NAME: com. demo
    
   
USER: app_35 PID: 20045 NAME: com. demo2
   
  
Conclusion:

   
  

    
   
There are still two processes. However, if the user name of the process is the same, the login userid is valid and the process pid is different.
    
   
Export/data/system/packages. xml again and view its content. You can see that the userids of both projects are 10035, which is indeed the same:
    
   
   
   
  
8. different Apk, producer userid is the same, package name is different, the process attribute of the specified Activity process analysis [1] modify the MainActivity attribute of SecondProject, specify to bind to the process name com. demo process:

   
  

    
   

   
  
[2] Run firstProject and SecondProject to view the process status:

   
  

    
   
User: app_35PID: 21387 NAME: com. demo
   
  
Conclusion: two activities run in the same process.
9. For different Apk, the consumer userid is the same, the package name is different, and the signature key is different. After experiment, the error INSTALL_FAILED_UPDATE_INCOMPATIBLE will be prompted when installing the second apk, and the installation fails.
Summary:
Different userids:

   
  

    
   
Different package names:
    
   
When the process attribute is not set, each Activity is in its own process. Even if the process specifies the package name, it will not share the process with another user with the same name.
    
   
The package name is the same:
    
   
Same signature: overwrite the old apk with the same package name. Different signatures: The New apk will fail to be installed. [Signature keys are generally different]
   
  
UserId:

   
  

    
   
Different package names:
    
   
When the process attribute is not set, each Activity is in its own process. If the process attribute is specified, the process can be shared.
    
   
The package name is the same:
    
   
Same signature: overwrite the old apk with the same package name. Different signatures: The New apk will fail to be installed. [Signature keys are generally different]
   
  
Reference: http://blog.csdn.net/llping2011/article/details/12705121