Reprint please indicate the source: http://blog.csdn.net/snailbaby_soko/article/details/69524380

* This article has been published exclusively by guolin_blog, an official wechat account

Android hot update scheme Robust

I believe that a lot of people know about hot repair, hot update, hot patch (for this technology is not a special standard of a method, I unified called hot update), after a year, a variety of hot update programs springing up like spring rain, more familiar with Nuwa, Tinker, Andfix and Dexposed and so on, The differences between them and their strengths and weaknesses are not discussed here, but given their practical uses and limitations, the Meituan development team has plenty of imagination.

Last year, Google released Android Studio 2.0 to much fanfany, and one of the most important new features, Instant Run, allows code changes to take effect in real time (hot plug). After understanding the principle of Instant Run, the development team of Meituan realized a hot update scheme with stronger compatibility, which is the productized Hotpatch framework —–Robust

The principle of the Robust will be discussed in the following articles. This paper is only for beginners who want to get started quickly. Those who want to understand the principle and technical core of the Robust first, please go to

Android hot update scheme Robust

Android hot update scheme Robust open source, new automatic patch tools

Github demo address for Meituan Robust

** Usage scenarios **

Firstly, I would like to introduce the application scenario of Robust. Just like the previous hot update, it is difficult to have an effective solution to the online accident. Every release of the Robust is like stepping on thin ice at the edge of the abyss. A bug does not only affect dozens of users. The crash or bug of some entrepreneurial apps may directly cause users to uninstall and never use them. For such a fatal and helpless problem, Robust is the time to step out and touch your head, and say quietly and confidently, “Don’t be afraid, you have me”.

** General process **

1. After the Robust is integrated, APK is generated. Save the obfuscation file mapping.txt during, as well as the Robust generation record file methodmap.robust 2. Use the @modify annotation or RobustModify. Modify () to mark the method 3 that needs to be fixed. Start the patch plug-in and run the generate APK command to obtain patch package patch.jar 4. Notify app that a patch is available and needs to be repaired through push or interface. 5. You do not need to restart the application to load the patch file

* * to * *

Firstly, some plug-ins of the Robust are remotely relied on to assist generation of patch.jar. We don’t need to go into it at this point, we just need to know that it is used to assist. Add two plug-ins to build. Gradle, the outermost layer of the project

Classpath ‘com. At meituan. Robust: gradle – plugin: 0.3.3’ classpath ‘com. At meituan. Robust: auto – patch – plugin: 0.3.3’

Then add it to your project’s build.gradle

//apply plugin: ‘auto-patch-plugin’ apply plugin: ‘robust’

The compile ‘com. At meituan. Robust: robust: 0.3.3’

At this point, the first step has not been completed. Don’t worry, we need to manually copy a robust. XML configuration file to the app directory

All right, all set up. With these things, we can create a one-click patch patch.jar when we need to fix it. But don’t worry, you don’t know how to load the patch yet…

The apply plugin:’robust’ is used when generating APK. This plugin generates a method record file called methodmap. robust, which is used to distinguish which methods need to be fixed during patching. That’s why you can patch it. There’s also the mapping.txt file, which lists the original class, method, and field names with the obfuscated code. This file is important for translating obfuscated code. But it’s not necessary, if you don’t want to confuse it, you don’t need to keep it. After the two files in the generated apk, respectively in the build/outputs/robust/methodsMap robust, build/outputs/mapping/mapping. TXT (need) can only be seen after open the confusion, We need to copy them to app/robust by ourselves, create a new folder called robust in app directory, and just put these two files in it.

At this point, step 2 is complete. We get apk, Mapping.txt, methodMap.robust, and with them we continue to generate patch patch.jar. However, the pitfall I have stepped on is that the above steps can be done without a signature file, but when installing apK, I will be told that the APK is corrupt, so I will add the signature file as normal signature.

** Make patches and use **

Our new project is very simple, with only 2 buttons, one for loading the patch and one for jumping. As shown in the picture, the home page and the page that jumps when no patch is loaded. Just now we said, how to use the patch file, look at the following button to load the patch event, see if there is no, so a sentence can be implemented to load the patch.

New PatchExecutor(XXX, callback).start()

What is the XXX in the middle, but also need to write? Copy is a copy of an IO stream from a regular file. The patch.jar method is a copy of an IO stream from a regular file. The verifyPatch method was originally used to verify the validity of the patch, but was later changed to a callback for the backup patch because it was not so demanding for ordinary users. The ensurePatchExist method detects the existence of the patch. FetchPatchList is the main method. If we want to load the patch, we need to know where the patch is. This method is to find the patch and give it to the one above. So, the location of the patch you can find by pulling it down and saving it, just give the path to setLocalPath. Another setPatchesInfoImplClassFullName package name need and robust. The XML configuration

What we need to do after the jump is to modify the contents of the TextView, so how to mark the modified method on the modified page, just like this. First, we need to introduce some limitations of modification methods and fields, as mentioned in the notes of robust. That’s because of the inlining and optimization of Android’s ProGuard itself. So to get around this problem, you have to follow some rules… I’ll talk about that in the future. Gradle: Turn on patching and turn off generating APK. The command line that generates apK is then executed again on the terminal. Until auto patch end successfully appears on the terminal (the last build failed is normal, don’t be nervous, kid). The next step is to push patch.jar to the phone directory path. Those who push their own download please debug correction, make sure the path is correct. And remember to give the application access to the memory card

Now that we’re here, we seem to have everything, so click on the LOAD PATCH button and see what happens. If you see Apply Result True, you’re done.

Finally, I want to show you how it looks

Thanks for the open source and contribution of Meituan development team, and special thanks to Zhang Meng, one of the authors of the Robust, for digging holes for the Robust (just kidding ha ha ha). We only hope to make the holes easier for everyone to use, there is still a long way to go… If you have any suggestions or comments, please leave a comment on Github.