Deeply understand the principles of Android plug-in technology

[[431328]]

Preface

The plug-in technology originally originated from the idea of ​​running apk without installation. This installation-free apk can be understood as a plug-in.

Apps that support plug-in can load and run plug-ins at runtime, so that some uncommon functional modules in the app can be made into plug-ins, which can reduce the size of the installation package on the one hand and realize the dynamic expansion of app functions on the other hand;

Today we will talk about plug-in

1. Introduction to plug-in

1. Introduction to plug-in

In the Android system, applications exist in the form of Apk, and applications need to be installed before they can be used. But in fact, the way to install applications in the Android system is quite simple, which is actually to copy the application Apk to different directories of the system and then unzip it;

Common application installation directories are:

• /system/app: system applications
• /system/priv-app: system applications
• /data/app: User applications

The composition of Apk, a common Apk will contain the following parts:

• classes.dex: Java code bytecode
• res: resource directory
• lib:so directory
• assets: static assets directory
• AndroidManifest.xml: manifest file

In fact, after opening the application, the Android system only opens a process, then uses ClassLoader to load classes.dex into the process and executes the corresponding components;

Then you may wonder, since Android itself also uses a reflection-like form to load code execution, why can't we execute the code in an Apk?

This is actually the purpose of plug-in, which allows the code in the Apk (mainly Android components) to run without installation, which can bring a lot of benefits. The most obvious advantage is actually hot update and hot repair through the network;

2. Difficulties of plug-in technology

• Reflect and execute the code in the plugin Apk (ClassLoader Injection)
• Allow the system to call components in the plugin Apk (Runtime Container)
• Correctly identify resources in plugin APK (Resource Injection)

3. Parent delegation mechanism

ClassLoader calls the loadClass method to load the class. The code is as follows:

 protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
 //First search from the loaded classes
        Class<?> clazz = findLoadedClass(className);
 if (clazz == null ) {
            ClassNotFoundException suppressed = null ;
 try {
 //If it has not been loaded, call the parent loader's loadClass first
                clazz = parent.loadClass(className, false );
            } catch (ClassNotFoundException e) {
                suppressed = e;
 }
 if (clazz == null ) {
 try {
 //If the parent loader is not loaded, try to load
                    clazz = findClass(className);
                } catch (ClassNotFoundException e) {
                    e.addSuppressed(suppressed);
 throw e;
 }
 }
 }
 return clazz;
 }

It can be seen that when ClassLoader loads a class, it first checks whether it has loaded the class. If it has not loaded it, it will first ask the parent loader to load it. If the parent loader cannot load the class, it will call its own findClass method to load it. This mechanism avoids repeated loading of classes to a large extent.

2. Detailed explanation of plug-in

1. ClassLoader Injection

In short, in a plug-in scenario, there will be multiple ClassLoaders in the same process:

• Host ClassLoader: The host is the installed application, which is automatically created when running
• Plugin ClassLoader: Created using new DexClassLoader

We call this process ClassLoader injection;

After the injection is completed, all classes from the host are loaded using the host's ClassLoader, and all classes from the plugin Apk are loaded using the plugin ClassLoader;

Due to the parent delegation mechanism of ClassLoader, the system classes are not affected by the class isolation mechanism of ClassLoader, so the host Apk can use the component classes from the plug-in in the host process;

2. Runtime Container

After the ClassLoader is injected, you can use the classes in the plugin Apk in the host process. However, we all know that Android components are started by system calls. Components in an uninstalled Apk are not registered with AMS and PMS. It is like if you directly use startActivity to start a component in a plugin Apk, the system will tell you that it cannot be found.

Our solution is very simple, namely runtime container technology. In simple terms, it is to embed some empty Android components in the host Apk. Taking Activity as an example, I preset a ContainerActivity extends Activity in the host and register it in AndroidManifest.xml;

What it has to do is very simple, that is, to help us as a container for the plug-in Activity. It accepts several parameters from the Intent, which are different information about the plug-in, such as:

• pluginName;
• pluginApkPath;
• pluginActivityName, etc. In fact, the most important ones are pluginApkPath and pluginActivityName. When ContainerActivity starts, we load the plug-in's ClassLoader and Resource, and reflect the Activity class corresponding to pluginActivityName;

When loading is complete, ContainerActivity does two things:

• Forward all lifecycle callbacks from the system to the plugin Activity
• Accepts the system call of Activity method and forwards it back to the system

We can complete the first step by overriding the lifecycle method of ContainerActivity, and the second step is to define a PluginActivity. Then, when writing the Activity component in the plugin Apk, we no longer integrate android.app.Activity, but integrate it from our PluginActivity. Later, we can automate this operation by replacing the bytecode. I will explain why later. Let's look at the pseudo code first;

 public class ContainerActivity extends Activity {
    private PluginActivity pluginActivity;
 @Override
    protected void onCreate(Bundle savedInstanceState) {
        String pluginActivityName = getIntent().getString( "pluginActivityName" , "" );
        pluginActivity = PluginLoader.loadActivity(pluginActivityName, this);
        if (pluginActivity == null ) {
            super.onCreate(savedInstanceState);
 return ;
 }
        pluginActivity.onCreate();
 }
 @Override
    protected void onResume() {
        if (pluginActivity == null ) {
 super.onResume();
 return ;
 }
        pluginActivity.onResume();
 }
 @Override
    protected void onPause() {
        if (pluginActivity == null ) {
 super.onPause();
 return ;
 }
        pluginActivity.onPause();
 }
 // ...
 }
 public class PluginActivity {
    private ContainerActivity containerActivity;
 public PluginActivity(ContainerActivity containerActivity) {
        this.containerActivity = containerActivity;
 }
 @Override
 public <T extends View > T findViewById( int id) {
 return containerActivity.findViewById(id);
 }
 // ...
 }
 // The actual components written in the plugin `Apk`
 public class TestActivity extends PluginActivity {
 // ......
 }

But the principle is probably as simple as this. Starting the plug-in component requires relying on the container. The container is responsible for loading the plug-in component and completing two-way forwarding, forwarding the life cycle callbacks from the system to the plug-in component, and forwarding the system calls from the plug-in component to the system.

3. Resource Injection

The last thing to talk about is resource injection, which is actually quite important. Android application development actually advocates the concept of separation of logic and resources. All resources (layout, values, etc.) will be packaged into Apk, and then a corresponding R class will be generated, which contains reference ids to all resources;

It is not easy to inject resources. Fortunately, the Android system has left us a way out. The most important ones are these two interfaces:

• PackageManager#getPackageArchiveInfo: Parse the PackageInfo of an uninstalled Apk according to the Apk path;
• PackageManager#getResourcesForApplication: Create a Resources instance based on ApplicationInfo;

What we need to do is to use these two methods to create a plugin resource instance when loading the plugin Apk in the above ContainerActivity#onCreate. Specifically, we first use PackageManager#getPackageArchiveInfo to get the PackageInfo of the plugin Apk. After we have the PackageInfo, we can assemble an ApplicationInfo ourselves, and then create a resource instance through PackageManager#getResourcesForApplication. The code is roughly like this:

 PackageManager packageManager = getPackageManager();
 PackageInfo packageArchiveInfo = packageManager.getPackageArchiveInfo(
 pluginApkPath,
    PackageManager.GET_ACTIVITIES
    | PackageManager.GET_META_DATA
    | PackageManager.GET_SERVICES
    | PackageManager.GET_PROVIDERS
    | PackageManager.GET_SIGNATURES
 );
 packageArchiveInfo.applicationInfo.sourceDir = pluginApkPath;
 packageArchiveInfo.applicationInfo.publicSourceDir = pluginApkPath;
 Resources injectResources = null ;
 try {
    injectResources = packageManager.getResourcesForApplication(packageArchiveInfo.applicationInfo);
 } catch (PackageManager.NameNotFoundException e) {
 // ...
 }

After getting the resource instance, we need to merge the host's resources with the plugin resources and write a new Resources class to complete the automatic proxy in this way:

 public class PluginResources extends Resources {
    private Resources hostResources;
    private Resources injectResources;
 public PluginResources(Resources hostResources, Resources injectResources) {
        super(injectResources.getAssets(), injectResources.getDisplayMetrics(), injectResources.getConfiguration());
        this.hostResources = hostResources;
        this.injectResources = injectResources;
 }
 @Override
 public String getString( int id, Object... formatArgs) throws NotFoundException {
 try {
 return injectResources.getString(id, formatArgs);
                    } catch (NotFoundException e) { 
 
 return hostResources.getString(id, formatArgs);
 }
 }
 // ...
 }

Then, after ContainerActivity completes loading the plug-in component, we create a Merge resource and then override ContainerActivity#getResources to replace the obtained resources:

 public class ContainerActivity extends Activity {
    private Resources pluginResources;
 @Override
    protected void onCreate(Bundle savedInstanceState) {
 // ...
        pluginResources = new PluginResources(super.getResources(), PluginLoader.getResources(pluginApkPath));
 // ...
 }
 @Override
 public Resources getResources() {
        if (pluginActivity == null ) {
 return super.getResources();
 }
 return pluginResources;
 }
 }

This completes the injection of resources

4. Resolving resource conflicts

The merged resource processing method will introduce resource conflicts because the resource IDs in different plug-ins may be the same, so the solution is to make different plug-in resources have different resource IDs;

The resource id is represented by an 8-bit hexadecimal number, expressed as 0xPPTTNNNN. The PP segment is used to distinguish the package space. By default, it only distinguishes between application resources and system resources. The TT segment is the resource type. The NNNN segment increases from 0000 in the same APK.

Summarize

There are actually many plug-in frameworks on the market, such as Tecent's Shadow, Didi's VirtualApk, and 360's RePlugin. They each have their own strengths, but they are generally similar;

Their general principles are actually similar. When running, there will be a host Apk running in the process. The dormitory Apk is the actual installed application. The host Apk can load the components and codes in the plug-in Apk to run, and the plug-in Apk can be hot-updated at will;