Shulou(Shulou.com)05/31 Report--

This article will explain in detail what is the dynamic repair technology of Android App hot patch. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

1. Background

When an App is released, it suddenly discovers that a serious bug needs urgent repair, and all parties in the company are busy: repackaging the App, testing, changing packages to various application markets and channels, prompting users to upgrade, downloading, and overwriting the installation. Sometimes it costs a lot of money to change and redistribute just to change a line of code.

At this point, a question is raised: is there any way to dynamically fix emergency Bug in the form of patches so that there is no need to reissue App, no longer need users to redownload and overwrite the installation?

Although the Android system does not provide this technology, but fortunately to tell you that the answer is: yes, we Qzone proposed hot patch dynamic repair technology to solve these problems.

two。 Actual case

Space Android independent version 5.2 after the release, received user feedback, the combined version can not jump to the independent version of the guest interface, a large number of feedback every day. In the past, we could only change the package urgently and reissue it. The cost is very high, and it also affects the reputation of users. Finally, we decided to use the hot patch dynamic repair technology to send Patch to the user, which repaired the external network problem without the user's perception, and achieved very good results.

3. Solution

This scheme is based on the android dex subcontracting scheme. There are several explanations about the dex subcontracting scheme on the Internet, so I won't repeat it here. For more information, please see here.

In a nutshell, multiple dex files are stuffed into the classloader of app, but the classes in the android dex unpacking scheme are not duplicated. If there are duplicate classes in classes.dex and classes1.dex, which class will the system choose to load when the duplicate class is used?

Let's take a look at the code loaded by the class:

A ClassLoader can contain multiple dex files, each dex file is an Element, multiple dex files are arranged into an ordered array dexElements, when looking for classes, they will traverse the dex files in order, and then look for classes from the current traversing dex files. If you can't find them, you will continue to look for them from the next dex file.

In theory, if the same class exists in different dex, then the class in the previous dex file will be preferred, as shown in the following figure:

On this basis, we conceive a hot patch scheme, package the problematic class into a dex (patch.dex), and then insert the dex at the front of the Elements, as shown in the following figure:

OK, this scheme is based on the second scheme of splitting dex. If you understand the principle of splitting dex, you should soon implement this scheme. If there is no project to split dex, you can refer to Google's multidex solution. Then insert the patch pack at the front when inserting the array.

OK, it seems that the problem is very simple and easy to solve. Let's try it, modify a class, package it into dex, insert it into classloader, and appear when the class is loaded (in this case, QzoneActivityManager will be replaced):

Why did the above problems arise?

In the sense of log, ModuleManager refers to QzoneActivityManager, but finds that the dex where the two classes are located is not together, where:

ModuleManager in classes.dex

QzoneActivityManager in patch.dex

As a result, an error occurred.

There is a problem here: many of the classes that split dex are not in the same dex. Why is there no problem?

Let's search for the code that threw the error, have sex, and find the code:

From a code point of view, if two associated classes are in different dex, the error will be reported, but the split dex will not report an error. This is why. The original premise of this check is:

If the class referrer (that is, ModuleManager) is marked with the CLASS_ISPREVERIFIED flag, then the dex will be checked. So when was this sign put on? Let's continue to search for the code, have sex, and find the code on DexPrepare.cpp:

This code is part of the code that converts dex to odex (dexopt). We know that when an apk is installed, the classes.dex in apk is optimized into an odex file by the virtual machine (dexopt) before it is executed.

When the virtual machine starts, there will be many startup parameters, one of which is the verify option. When the verify option is turned on, the above doVerify variable is true, then dvmVerifyClass will be executed to verify the class. If the dvmVerifyClass verification class is successful, then the class will be marked with the CLASS_ISPREVERIFIED flag, so what is the specific verification process like?

This code is in DexVerify.cpp, as follows:

Verify the clazz- > directMethods method, directMethods contains the following methods:

Static method

Private method

Constructor function

Clazz- > virtualMethods

Virtual function = override method?

To sum up, if the class directly referenced in the above method (first-level relationship, no recursive search) is in the same dex as clazz, then the class will be labeled CLASS_ISPREVERIFIED:

So in order to implement the patch scheme, you must start with these methods to prevent the class from being marked with the CLASS_ISPREVERIFIED flag.

The final space solution is to insert a piece of code into the constructors of all classes, as follows:

If (ClassVerifier.PREVENT_VERIFY) {System.out.println (AntilazyLoad.class);}

The AntilazyLoad class will be packaged into a separate hack.dex, so that when installing apk, the classes in the classes.dex will refer to an AntilazyLoad class in a different dex, which prevents the class from being marked with the CLASS_ISPREVERIFIED flag, and any class that is not marked with this flag can be patched.

Then when the application starts, the dex package where the AntilazyLoad class is located must be loaded first, otherwise the AntilazyLoad class will be marked as non-existent, even if the hack.dex package is subsequently loaded, then it does not exist, so the screen will show a large number of classes AntilazyLoad can not find the log.

So Application as the entry point of the application cannot be inserted into this code. (because the code loaded into hack.dex is executed in onCreate in Application, if this code is inserted into the constructor of Application, the class is used before the hack.dex is loaded. If the class cannot be found once, it will be marked forever.)

Where:

The constructor is chosen because it does not increase the number of methods, and a class has an implicit default constructor even if it does not have an explicit constructor.

The space uses bytecode insertion instead of source code insertion, and the javaassist library is used for bytecode insertion.

Hidden danger:

The purpose of the virtual machine to mark the class with CLASS_ISPREVERIFIED during installation is to improve performance. will it affect the performance if we forcibly prevent the class from being marked? Here we will do a more detailed performance test. But the problem of splitting dex in large projects is already serious, and many classes are not marked with this flag.

How to package a patch pack:

When the space is released in the official version, it generates a cache file that records the md5 of all class files, as well as a mapping confusion file.

Use the-applymapping option in subsequent versions, apply the official version of the mapping file, then calculate the md5 of the compiled class file to compare with the official version, and package the different class files into a fix package.

Note: this solution is now also applied to our compilation process, compilation does not need to repackage dex, just need to modify the class class file into patch dex, and then put under sdcard, then the changed code will take effect.

On Android App hot patch dynamic repair technology is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.