Hot fixes are increasingly being used by developers in Android development, and there are many mature open source frameworks on the market. But hot fixes are still a familiar and unfamiliar term for most developers. Just knowing the role of thermal repair and using frames doesn’t mean much. We also need to know how hotfix works so that no matter how the framework changes, as long as the basic principles remain the same, we can either quickly master it or write a hotfix framework for the project.
Introduction to Hot Repair
1. Development process
When a project has an urgent bug, the traditional development process is to release a new version and direct users to override the installation. Regardless of the time it takes for the platform to go live, the user experience of repeated downloads and installations at least twice a day is very poor. The hot repair perfectly solves this problem. After receiving the repair package pushed by the server, users can repair it while the project is running. The whole process is completed in a state of user awareness, there is no need to download relatively large installation packages, and the cost is small.
Summarized as two advantages:
- No need to re – issue version, high repair efficiency
- No user perception, low cost
2. What can be repaired
- Resources to repair
- Code to repair
- So library repair
3. Classification of code repair techniques
At present, there are three main schemes:
- Dex piling/replacement was carried out based on class loading and Dex subcontracting scheme
- Native Hook for low-level replacement
- Install Run does the class injection
Due to the variety of customized systems of domestic mobile phone manufacturers, Dex piling/replacement is the most suitable scheme in my opinion.
Dex Piling principle
ClassLoader iterates through the dex file looking for relevant classes in dexElements[] in the pathList object by calling the findClass method. Since the dex at the front will be called by the system first, the concept of piling comes into being. Insert the fixed dex to the very front of dexElements[] so that the system calls the fixed insert class instead of the bug class later.
In the figure above, patch.dex is the inserted dex, and classes2.dex is the original bug dex. The ClassLoader obtains the D.C. lass in patch.dex first, so the D.C. lass in classes2.dex will not be called, thus completing the replacement of the D.C. lass and fixing the bug.
This paper briefly introduces the technical principle of code repair, and the next article will start from the system source code, combined with the code repair open source framework Fettler encapsulated by myself, to interpret each process of code repair in detail. If there are any mistakes in this article, please help to point out in the comments section, learning progress together, thank you.