Android Hot Patch Dynamic Repair technology (end of article): Automatically generate packaging with signature patches, refactoring projects

First, about the previous four blog posts

Android Hot Patch Dynamic Repair Technology (i): from the Dex subcontracting principle to the hot patch
Android Hot Patch Dynamic Repair Technology (ii): actual combat! Class_ispreverified problem!
Android Hot Patch Dynamic Repair Technology (iii)--using javassist to inject bytecode, complete the hot Patch Frame prototype (available)
Android Hot Patch Dynamic Repair Technology (IV): Automated patch generation-solving confusion problems

The first two posts mainly introduce some principles and implementation of hot patch repair technology.
The next two posts are mainly about how to use code to implement the entire hot patch framework, but the framework is really poorly written and a lot of extra work. And that's a big part of the reason for using transform, and transform doesn't work when it's confusing.

Here's a hot patch framework I've refactored on GitHub to find the Star (??? ' ω′?
Https://github.com/AItsuki/HotFix
1. Support for confusion
2. Automatic generation of signed patch packages
3. The signature check is performed when the patch package is loaded

The patch folder in the diagram is the auto-generated patch pack that contains the class that precedes the jar package and can continue to be packaged manually if the Patch.jar package fails.

More detailed introduction and use of the method please go to GitHub, again: Ask Star (?? ' ω′?

Second, the framework of the realization of ideas

In the Fourth Article blog post, we find that in the case of confusion, transform is really anti-human because transform can only manipulate the class before it is confused and cannot add transform to the confusion.
So the following ideas, I gave up the use of transform, but directly in the Dextransform this task Dofirst to operate.

Before refactoring the project, I recorded these ideas and processes, and then the process to implement the hot patch Framework, the efficiency is really much faster.

2.1 Defining how the hot patch framework is used

1. Release Signature packaging as a release version, each release package will regenerate Hash.txt and Mapping.txt (in case of confusion, only mapping)

2. Each time the debug runs (directly running the project or BUILDAPK), the signed fix pack is generated by verifying hash.txt and Mapping.txt.
   Hot fix is done by simply putting the package in SDcard

3. Signature checks are required to load patches to prevent malicious code injection

2.2 Code Flow

Discard the transform and use the pure hook method to achieve.
The main hook's task has these several:

• Transformclasseswithdexforrelease
• Transformclasseswithdexfordebug
• Transformclassesandresourceswithproguardforrelease
• Transformclassesandresourceswithproguardfordebug

not to confuse the situation:
Transformclasseswithdexforrelease
dofirst--traversal input file, generate MD5 Save (hash.txt), then inject code

Transformclasseswithdexfordebug
dofirst--traverse the input file, generate MD5, and hash, copy the changed class to the patch folder, then inject the code

The situation of confusion:
Transformclassesandresourceswithproguardforrelease
dolast--traverse the output file, generate MD5 Save (hash.txt), then inject the code, save the mapping.

Transformclassesandresourceswithproguardfordebug (need to use applymapping)
dolast--traverse the output file, generate MD5, and hash, copy the changed class to the patch folder, then inject the code

the order in which the task executes after the obfuscation is turned on is proguard–> Dex
Because Dex is always executed on the last side, injecting the code and generating the patches requires only hook Dex.
But when it comes to confusion, what Dex Dofirst needs to do is a bit different, and we can control the Def minify = False by a variable.

Hook proguard, copy minify = True at Proguardtransform execution time
This allows you to control the confusion and not confuse the two cases.

2.3 Actual problems encountered

1, not clean project, the second run release packaging will not inject code
This is because Gradle is built incrementally, Up-to-date,task does not perform
How to resolve:
DexRelease.outputs.upToDateWhen {false} to have the task execute all the time
Http://stackoverflow.com/questions/7289874/resetting-the-up-to-date-property-of-gradle-tasks

2. If a custom control is used, the null pointer exception is reported in the preview window of the XML
This is because the custom control has been injected into the code, while the preview window does not load Hack.jar, cannot find the antilazyload.class, so the null pointer.
How to resolve:
Using Pluginextention, configure the variable in the Build.gradle to control whether the code is injected in debug mode.
, we have added two extention

3, how to applymapping
The function of applymapping is to reuse the last confusion rule.
So we need to apply the mapping.txt generated by release to the obfuscation of debug, otherwise it might not be possible to generate patches correctly.
How to resolve:
The first type:
Manually configure the obfuscation file for debug

The second type:
1. Under Gradle 1.5, you can dynamically add the code by task.applymapping (file file) directly
2. In the gradle1.5 above, because Proguard's transform is a special task, so can not directly applymapping, need to do some strong turn.
(Proguarddebug is Transformclassesandresourceswithproguardfordebug)

4, open the confusion after the release signature packaging, if the debug mode does not turn on confusion, will all the classes are packaged into patches.
This is because, if the debug mode does not turn on the confusion, then will take the non-confusing code and release has been confused code to verify, MD5 certainly inconsistent, so will all the classes packaged into a patch package.
How to resolve:
There is no good way, honestly open the confusion. Debug whether open confusion to be consistent with release

5. How to sign a patch
The signature of the patch is mainly used by the JDK tool, Jarsigner.exe. You can use code to invoke the command line

6, how to perform signature verification
First, the debug installed app does not need to be checked, which is the way to detect if the current app is a debug signature.
http://blog.csdn.net/luohai859/article/details/44679085

Then, this is the consistency of the checksum package and the app signature
http://blog.csdn.net/hudashi/article/details/8245105

7. Android 6.0 cannot load patch pack from SDcard
The problem with the runtime permissions mechanism is that you can put the fix pack into the app's private space to load.

8, Androidstudio 2.0 or more used to instantrun, whether this will be automatically generated by the debug patch package has an impact.
I have not tested this problem, and if it does have an impact, there is a very simple solution, and the direct use of signature packaging debug can also generate a patch package.

Iii. Reference Projects

Https://github.com/jasonross/Nuwa
Https://github.com/bunnyblue/DroidFix
Https://github.com/Livyli/AndHotFix
is mainly the third one, the idea of signature verification comes from it

Four, write in the back

Finally is the completion of the hot patch framework, the process is really tiring Ah!
The whole framework of the implementation of the idea is clear and simple, the code volume is not more than 1000 lines, it is suitable for learning this technology friends.

For Star, star, the first project to be uploaded to GitHub for Star (??? ' ω′?
Https://github.com/AItsuki/HotFix

Android Hot Patch Dynamic Repair technology (end of article): Automatically generate packaging with signature patches, refactoring projects