Android Hot Fix principle Summary

Background

When the app after the release of an emergency online bug, the whole company will be busy, the company if the line of serious P1-level bug, or even the whole project team in the middle of the night to get emergency repair on-line, and the cause of the bug may just pass the wrong parameters, or write the wrong line of code, And the repaired app has to be re-shelves until the bug is corrected after the user updates. The emergence of the hot repair technology can greatly alleviate this situation, after the repair does not need to be re-shelves, users do not need to re-download the installation.

Principle

The hot fix Framework on GitHub, such as the Nuwa,hotfix principle, is based on the Android app hot patch dynamic Fix technology Introduction and Android Dex subcontracting program
These two articles, I am here also just for these two articles to do a summary of their own deepen understanding.
About the use of the Nuwa framework see another blog the use of the hotfix framework Nuwa
The heat recovery principle is based on the Android subcontracting scheme, then what is the Android subcontracting scheme? Android2.3 before executing dexopt's memory only 5 m, each Dex method number can not exceed 65535, when the app is complex, the class and methods are particularly many times in the compile time error. Description of the Android Dex subcontracting Scenario:

When the functionality of an app becomes more complex, and the amount of code becomes more and more, one day you may suddenly encounter the following phenomena:

1. Generated APK before 2.3 machine cannot install, prompt install_failed_dexopt

2. Too many methods, errors at compile time, prompt:

Conversion to Dalvik format failed:unable to execute Dex:method ID
Not in [0, 0xFFFF]: 65536

This problem occurs because:

1. Android2.3 and previous versions of memory used to perform dexopt (for optimizing Dex files) are allocated only 5M

2. A DEX file supports a maximum of 65,536 methods.

The solution is to make the compiled class file into two Dex packages, which are injected into the ClassLoader at runtime. How to inject it, first look at the Android ClassLoader system, the picture is the sub-package plan.

You can see that the implementation class has two Dexclassloader and Pathclassloader, where Pathclassloader is the loader that Android uses to load Android system classes and apps, The dexclassloader is used to load the. Dex and. jar Class.dex files. Take a look at the method of Basedexclassloader load class, from the PathList according to the class name, can not find it on class not found. PathList is an object in Basedexclassloader, it contains a dexelements collection, looking for class is to listen to the collection, to get Dexfile to find classes.

A classloader can contain multiple Dex files, each dex file is an element, and multiple Dex files are arranged into an ordered array dexelements, and when the class is found, the Dex file is traversed sequentially, and then the class is found from the currently traversed Dex file. If the lookup class is returned, if it is not found, continue looking from the next Dex file. (From: Android app hot patch Dynamic Repair Technology Introduction)

#BaseDexClassLoader@OverrideprotectedClass<?>Findclass(String name) throws ClassNotFoundException {Class clazz = pathlist.findclass (name);if(Clazz = =NULL) {Throw NewClassNotFoundException (name); }returnClazz;}#DexPathList PublicClassFindclass(String name) { for(Element element:dexelements) {Dexfile dex = Element.dexfile;if(Dex! =NULL{Class clazz = dex.loadclassbinaryname (name, definingcontext);if(Clazz! =NULL) {returnClazz; }        }    }return NULL;}#DexFile PublicClassLoadclassbinaryname(String name, ClassLoader loader) {returnDefineClass (name, loader, Mcookie);}PrivateNativeStaticClassDefineClass(String name, ClassLoader loader,intCookies);

So we will have the bug class into Patch.jar and then insert into the dexelements of the first position, Findclass will be found in our Patch.jar, found the class after the return, the problematic class is replaced by the patch package. Then there is a class_ispreverified problem, detailed can see the Android app Hot patch Dynamic Repair technology Introduction is mainly to say, if the class and its reference class if not in the same Dex package will be an error, the premise of the school check out this error is the reference class was hit Class_ Ispreverified identity, when this identity is hit, when the virtual machine is launched, if a class of private,static, or the constructor method directly referenced to the class in the same Dex package will give the current class this identity, so to prevent this expression is hit, We want the class to refer to a class in an external Dex package, inserting a section into the constructors of all classes

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

So we also need a hack.dex, write an empty class Antilazyload into Dex package, and must first load this package, otherwise reference this class will be class not fount, loading method is the same as before, pay attention to

Application cannot insert this code as an entry for an application. (because the code that loads the Hack.dex is executed in OnCreate in application, if the code is inserted inside the application constructor, then it is used before the Hack.dex is loaded, and the class cannot be found once and will never be found. ) (From: Introduction to the Android app hot patch dynamic Repair technology).

Android Hot Fix principle Summary