Research on Android 5.0 process A and APK b dependency relationship problem

(This article came from a chat with a friend of the blog, but unfortunately I did not receive the reply after the friend's answer.) Therefore, this issue and the introduction of the people, hope to be able to stimulate

The question for this friend is this:

The application a runtime runs in process a, which can load another application B through ClassLoader at run time. Of course, Application B can also run, and it runs in process B. Before Android 5.0, process B and process a were not related. However, after 5.0, if process B is stop, process a will be killed as well. This is the process A/b dependency that Android 5.0 brings. There are several key technical points to this question: 1 Process A how to load application B. This is done through ClassLoader, where the main code is shown below: (from this friend's tip:)   

private static class<?> Loadpluginclass (Context launchercontext, String PackageName, string className, int type) { C0/>try {              Context context = Launchercontext.createpackagecontext (PackageName,                            context.context_ignore_ SECURITY | Context.context_include_code);             Final String Apkpath = Context.getapplicationinfo (). SourceDir;              Pathclassloader L = new Pathclassloader (Apkpath, Context.getclassloader ());             Return L.loadclass (ClassName);          } ......}

At load time: 1 before Android 5.0, go torelationship between process A and application B: no relationship is displayed. is the normal loading2 on Android 5.0 and later, the relationship between process A and application B: shows the bindings. Code in Loadedapk.java-Each loaded apk corresponds to a loaderapk object. Code in Loadedapk.java
Public loadedapk (Activitythread activitythread, ApplicationInfo Ainfo,
Compatibilityinfo Compatinfo, ClassLoader Baseloader,
Boolean securityviolation, Boolean Includecode, Boolean registerpackage) {
Final int myuid = Process.myuid ();
Ainfo = Adjustnativelibrarypaths (Ainfo);
......
mregisterpackage = registerpackage;//Be "bound" here
Mdisplayadjustments.setcompatibilityinfo (Compatinfo);
}

Why is Android 5.0 doing this? What is the use of a dependency between process A and apk B?

Originally, after Android 5.0:

1 when process a loads a package, the framework calls Activitymanagerservice's addpackagedependency

This function binds the process A and apk B (that is, package B) together.

Where is this function called? Also in the Loadedapk.java:

Public ClassLoader getClassLoader () {        synchronized (this) {            if (mclassloader! = null) {                return mclassloader;            }            if (Mincludecode &&!mpackagename.equals ("Android")) {                ...                if (mregisterpackage) {                    try {                        activitymanagernative.getdefault (). addpackagedependency (mpackagename);                    } catch (RemoteException e) {                    }                }

2 process B (which is the process in which package B itself runs) is killed, and process A that has dependencies is also eliminated. Here are a few points to note:

2.1 If process B is itself crash or killed by the shell, then dependency does not affect process a

2.2 If process B is called killbackgroundprocess or forcestoppackage, because Activitymanagerservice really calls the killpackageprocesseslocked

Then dependency can cause a to be killed. From a design standpoint, this is also true in itself, because APK B runs in its own process B and is also loaded into process a to run.

You should stop process B and a When you kill package B.

Of course, Google did not deal with this problem because it was not considered so fine before 5.0.

Of course, the introduction of this dependency is also due to some of the new features of Android 5.0 in application installation:

1 previous APK files side load to/daa/app and other monitoring directories will not cause Pacakgemanagerservice to install them. Instead, the system will not scan and install them until the next restart of the scan

2 adb install APK, in the/data/app directory will create a package-name (such as com.google.xxx) folder, and the apk file is placed in this Package-name directory, changed to name base.apk

The purpose of this is because Android finally supports a process can load multiple apk (of course, but now, when installed, base-apk is the main logic, upgrade later, or add new features, do not need to reinstall the new base, but install an additional new apk , the new apk will be loaded into the process of base. This feature has been shown in the SDK documentation, but the content is not very detailed

In short, the base apk and the new APK need the package name, the signature will be the same.

Research on Android 5.0 process A and APK b dependency relationship problem