Android Survival Guide: Explanation of Bug strategies and ideas

Now there are more and more demands for maintaining and customizing Android, and more people are working on it. There are many bugs and unreasonable issues in the source code directly released by Google, especially native applications, such as Mms, browser, Email, and Contacts. The first step to customize or implement Android solutions is to fix native bugs to get a stable system.
1. Carefully observe the characteristics of bugs
Understand the procedures and modules involved in a Bug, and what kind of Bug, Exception? Functional? Or UI/UE design issues. Different methods may be taken to address different problems. For exceptions, you must first analyze the Log file to determine the cause of the Exception. For functional problems, you may first try to reproduce it; for UI/UE problems, you may need to first ask the UI Designer to check whether the changes need to be made.
2. Identify the determining factors and eliminate secondary and irrelevant factors.
Analyze, repeat, and try again to eliminate secondary, irrelevant factors and operation steps. If it is related to some specific data, it is necessary to split the data to remove the unaffected part until the special data that causes the problem is found.
3. Comparison
Compare it with the normal process, compare it with the normal version, and compare it with the same series of products to see what exceptions and inconsistencies exist.
4. Single Variable Principle
Each time you change a change, you can see what causes the problem or solves the problem. If there are two changes at the same time, it is very difficult to tell which one has taken effect.
5. Divide and conquer
Gradually narrow down the scope by means of grouping. First, analyze in a module to determine whether there is a problem or no problem, and then go to its module to analyze in one of the logic or files, then go to other ones to avoid blind searches.
6. Simulation Scenario
Use special data or modify code to simulate the scenario where a Bug occurs. This is particularly useful for the reproduction of non-essential bugs and thread problems.
7. How to locate the problem: Experience + Log + Debugging tool
Experience can be obtained only by accumulation. Generally, people familiar with code and processes can quickly locate them. Log is a simple and crude method of Log files and printing; debugging tools refer to breakpoint single-step tools such as Eclipse and GDB. We usually use experience and Log to locate a wide range. When we have a certain understanding of the process, we have located it in a slightly smaller scope, for example, when a function or file is in, you can use a tool to perform breakpoint and one-step debugging for precise positioning. When the range is large, debugging tools will be slow and it is difficult to find a valid breakpoint. The single step is too cumbersome and can easily lead to confusion and loss of ideas.
8. reverse reasoning and insights
In the process of debugging and solving bugs, reverse reasoning is very important, because what you get is a result (Bug), and you need to find the cause of it, it is necessary to reason and guess where the problem may be. Another important capability is insight, observation of logs, operations, and so on. Pay attention to some minor differences and discover some hidden clues. Of course, this is not so easy to cultivate as it is different from the experience!
9. Specific methods and tools
A. Compile
Obviously, to use logs and other methods, you must modify the source code, add logs, and compile the logs. You can use make to compile Android as a whole. After completing the compilation once, you can locally compile the Android SDK. run mm in the directory of the mk file to re-compile the Directory into apk, jar, or so
B. Run
After compilation, you need to run the newly compiled Apk, jar, or so to see the differences. You can directly push apk, jar, and so to your mobile phone through adb (apk to/system/app, jar to/system/framework, so to/system/lib ). Or use the mm snod command to regenerate system. img and then use it (the simulator can do this ).
C. debugging tools
Apk can be directly called using Eclipse, and the premise must be compiled.
Jar must also be debugged using Eclipse.
So because they are all Native C/C ++ code, you must use GDB for debugging. Run gdbserver on the mobile phone, and use gdb to debug the compiled symbols/library in the PC. gdb and gdbserver use the specified port on the mobile phone to communicate with each other.