What is bugreport, how to use it?
Android system wants to be a full-featured, eco-prosperous operating system, and it must provide a complete application development environment. In application development, the debugging analysis of the app program is the work that will be performed in the daily production process. Android has developed the bugreport tool to make it easy for developers to analyze the entire system platform and all the information that an app has been running for a while. This tool is very simple to use, as long as it is executed in the terminal (linux or win):
<code class="hljs avrasm has-numbering">adb bugreport > bugreport<span class="hljs-preprocessor">.txt</span></code><ul style="" class="pre-numbering"> <li>1</li></ul>
A bugreport file can be generated. But there is a problem, this generated file is sometimes very large, can reach 15M+, think about the concept of a file content length of 15M+ for a txt text format, if using the text tool to open the view will be a nightmare . Therefore, google developed an analysis tool called battery historian for android 5.0 (api 21) and above. This tool is used to parse the txt text file and then display it in the form of web graphics. The effect is more humane. More readable.
Of course, the same bugreport data can also have different parsing and reading methods. If you don't like google's battery historian, you have other choices, that is, choose Sony open source ChkBugReport, this tool provides a different from battery historian The perspective of the bugreport file, the interface is simple and clear.
What is the principle of bugreport?
Below we briefly analyze the principle of adb bugreport operation. We know that using bugreport just executes the adb bugreport command, so our analysis is definitely starting from the adbd daemon process. When we look at the code of this process, we found that the bugreport option was handled here:
Adb_commandline@system/core/adb/commandline.cpp
We can clearly see that if the attached parameter is bugreport, it will directly call the send_shell_command function. The code of this function is relatively simple, we will not analyze it. The function of this function is to use the command in the shell to execute the parameters. So we are here to execute the bugreport command.
In the android device, the bugreport command exists in the system/bin/ directory. This is an executable file, so we need to check the implementation of this executable file. The implementation code is in the /frameworks/native/cmds/bugreport/ directory. under:
We see that the implementation of bugreport is relatively simple, only one Android.mk and one cpp implementation code, let's take a look at the Android.mk file:
Here we see that the code in this directory will be compiled into an executable called bugreport, which is what we want to find.
The code here is very simple, the main logic is:
1. Start the dumpstate service
2. Create a socket link with the dumpstate service
3. Read data from the socket and promise to stdout
4. Close the socket after the read is complete, then exit
Therefore, the focus of our analysis needs to be transferred to dumpstate. Here to explain, the previous method to start the dumpstate service is to use the system properties to achieve, this property change message will be received by the init process, and then the init process will start the dumpstate service.
Dumpstate is also an executable file, also exists in the system / bin directory. Now we understand, in fact, bugreport is dumpstate, but bugreport wraps dumpstate.
Now we need to analyze the implementation of dumpstate, its implementation code is in: frameworks/native/cmds/dumpstate directory, we look at the code structure in this directory:
The code here is also very simple, as long as a few implementation files, the main function in the dumpstate.c file, this main function we do not analyze in detail here, summarize its main work:
1. Initialize related resources according to startup parameters
2. If the startup parameter has -s (init starts with this parameter), it means that the socket is used, then the socket is started, and the link is waiting in this socket.
3. If the client side (that is, the bugreport process) is successfully linked, initialize the memory to be used and set the priority to a higher priority to prevent it from being killed by OOM.
4. Then use vibrator to vibrate (if the device has this hardware), prompt the user to start intercepting the log.
5. Call the dumpstate function to start the real dump work.
6. After the dump is completed, call the vibrator again to vibrate 3 times, prompting the user to complete the dump.
The above code is relatively long because there are too many modules to be dumped, but the basic logic is still relatively clear. We see that the basic data sources are:
1. System properties
2./proc and /sys node files
3. Execute the shell command to get the relevant output
4.logcat output
5.Android Framework Services information basically uses the dumpsys command to obtain information through the dump function in the binder call service.
Other options for adb bugreport
There are no options for bugreport itself, mainly through commands such as dumpsys. See the battery historian project homepage: https://github.com/google/battery-historian. Here is a summary:
1). Reset battery statistics:
<code class="hljs livecodeserver has-numbering">adb <span class="hljs-built_in">shell</span> dumpsys batterystats <span class="hljs-comment">--reset</span></code><ul style="" class="pre-numbering"><li>1</li></ul>
2). Wakelock analysis all wakelock information:
<code class="hljs lasso has-numbering">adb shell dumpsys batterystats <span class="hljs-subst">--</span>enable <span class="hljs-literal">full</span><span class="hljs-attribute">-wake</span><span class="hljs-attribute">-history</span></code><ul style="" class="pre-numbering"><li>1</li></ul>
3). Kernel trace analysis analysis kernel, mainly analyze wakeup source and wakelock activities, first enable kernel analysis:
Then get the log:
<code class="hljs smalltalk has-numbering"><span class="hljs-char">$ </span>echo <span class="hljs-number">0</span> > /d/tracing/tracing_on
<span class="hljs-char">$ </span>adb pull /d/tracing/trace <some path>
# <span class="hljs-class">Take</span> a bug report at this time.
<span class="hljs-char">$ </span>adb bugreport > bugreport.txt</code>