1. Background The company I work for is a start-up company in the field of Internet finance. Such companies always pursue rapid iterative and agile development. Therefore, our APP is basically an iteration every two weeks, sometimes with a tight schedule. In the absence of professional QA staff, it is inevitable that some potential bugs will be missed under the most primitive manual click test conducted by other partners in product and operation in the team. Therefore, when our application is released, After more than 100,000 users randomly click and generate random data suddenly found a serious bug need urgent repair, all parties in the company will be busy: restore the bug, fix, repackage the App, test, change packages to various App markets and channels, prompt users to upgrade, users download, overwrite installation. Sometimes just a single line of code needs to be changed and repackaged and redistributed at great cost. This raises the question: is there a way to fix urgent bugs dynamically as a patch, without redistributing the App and requiring users to re-download and overwrite the installation? Android doesn’t offer this technology, but fortunately, the answer is yes. Moreover, after the hot patch dynamic repair technology solution originally proposed by qzone team, major companies have followed suit, and many open source solutions have emerged online.
  2. The actual case

    Let’s take a look at some of the solutions available online:

    Xposed

    dexposed

    AndFix

    DroidFix

    DynamicAPK

    Nuwa

    According to its description, the principle comes from: Android DEX subcontracting scheme (Codecloud.net/android-hot…

    Here I will first talk about how I go to the hot repair framework for selection, we also see can achieve this function of the open source framework recently out of a lot of but not everyone is suitable for our current application, Xposed because it needs mobile phone to get root permission to take effect so first pass.

    Dexposed and AndFix is Ali based on Xposed ideas precipitation out of the two sets of hot repair solutions, but after the actual test found that it due to the lack of dynamic library so file on most models can not run normally:



    There were a lot of similar issues on github, so it had to be abandoned. The patch generator was perfect, but it didn’t work…

    DynamicAPK is a solution recently released by Ctrip, but because it has too many functions and its main function is to do multi-APK dynamic loading, the hot repair is not the key implementation.

    Finally, I focused on Nuwa, but after testing the actual deployment, I found that there were always compilation errors, so I looked at the issue list on Github and found that many people had similar problems. Finally, I fixed the problem by excluding the class in nuwa.init. The class file in which Nuwa is located is unfixable, so try to write only some initialization code and configuration in this file to ensure that nothing goes wrong. Then the next encounter is the patch package can not become the dilemma… Continue to Google:

    Github.com/jasonross/N…

    Well, considering that we have 20 channels and may have different versions of patch packages, I applied for an FTP server to be used as the storage path of each patch package, under this path:



    In this way, the client determines whether the current version needs to be patched by pulling the API of the Config configuration file each time. If so, it downloads the patch from the corresponding FTP server according to the current channel number. When the user opens the application for the second time, the patch will be loaded, and the problem is repaired without the user’s knowledge.

Share
Newer

Android continuous integration technology practice

Older

Android APP open screen advertising