bugreport是什么，怎么用？

Android系统想要成为一个功能完备，生态繁荣的操作系统，那就必须提供完整的应用开发环境。而在应用开发中，app程序的调试分析是日常生产中进程会进行的工作。Android为了方便开发人员分析整个系统平台和某个app在运行一段时间之内的所有信息，专门开发了bugreport工具。这个工具使用起来十分简单，只要在终端执行（linux或者win）：

即可生成bugreport文件。但是有一个问题是，这个生成的文件有的时候异常庞大，能够达到15M+,想一想对于一个txt文本格式的文件内容长度达到了15M+是一个什么概念，如果使用文本工具打开查看将是一个噩梦。因此google针对android 5.0（api 21）以上的系统开发了一个叫做battery historian的分析工具，这个工具就是用来解析这个txt文本文件，然后使用web图形的形式展现出来，这样出来的效果更加人性化，更加可读。它的基本界面像下面这个样子：

目前google已经将bettery histZ喎�"/kf/ware/vc/" target="_blank" class="keylink">vcmlhbr+q1LTBy6Osv6rUtM/uxL+1xLXY1rejujxiciAvPg0KPGEgaHJlZj0="https://github.com/google/battery-historian">https://github.com/google/battery-historian
google写了一个比较详细的说明文档，大家可以自行查阅一下。这个工具可以查看以下信息：

数据还是比较详细的。
当然，同样的bugreport数据也可以有不同的解析和阅读方式，你如果不太喜欢google的battery historian的话，你还有别的选择，那就是选择Sony开源的ChkBugReport，这个工具提供了不同于battery historian的视角去解读bugreport文件，见面简单明了：

这个项目的文档：
http://developer.sonymobile.com/2012/01/25/new-bugreport-analysis-tool-released-as-open-source/
开源地址首页：
https://github.com/sonyxperiadev/ChkBugReport
这里说明一下，笔者使用过ChkBugReport这个工具，感觉很不错，最好结合google的battery historian；另外ChkBugReport这个工具还有一点bug，不过不影响使用。

bugreport的原理是什么？

下面我们简要分析一下adb bugreport运行的原理。我们知道，使用bugreport只要执行adb bugreport命令就可以了，因此我们的分析肯定是从adbd这个daemon进程开始，我们查看这个进程的代码的时候发现这里处理了bugreport选项：
adb_commandline@system/core/adb/commandline.cpp

我们可以清楚地看到，这里判断如果附带的参数是bugreport的话，那就直接调用send_shell_command函数处理，这个函数的代码比较简单，我们就不分析了，这个函数的功能就是使用shell执行参数中的命令，因此我们这里相当于执行了bugreport命令。
在android设备中，bugreport命令存在于system/bin/目录下，这是一个可执行文件，所以我们要查看这个可执行文件实现的地方，它的实现代码在/frameworks/native/cmds/bugreport/目录下：

我们看到，bugreport的实现是比较简单的，只有一个Android.mk和一个cpp实现代码，我们先看一下Android.mk文件：

这里我们看到该目录下的代码会被编译成一个名字叫做bugreport的可执行文件，这就是我们想要找的。现在我们看一下bugreport.cpp文件的实现，这个文件中代码比较简单，只有一个main函数：

这里的代码非常简单，主要的逻辑就是：
1.启动dumpstate service
2. 和dumpstate service建立socket链接
3. 从socket中读取数据，并且答应到stdout中
4. 读取完成之后关闭socket，然后退出
因此，我们分析的重点需要转移到dumpstate中了。这里说明一下，前面启动dumpstate service的方法是使用系统属性来实现，这个属性的改变消息会被init进程收到，然后init进程会启动dumpstate这个服务。
dumpstate其实也是一个可执行文件，也存在于system/bin目录下。现在我们明白了，其实bugreport就是dumpstate，只是bugreport将dumpstate包装了一下而已。
现在我们需要分析一下dumpstate的实现，它的实现代码在：frameworks/native/cmds/dumpstate目录下，我们看下这个目录下的代码结构：

这里的代码也是十分简单，只要少数的几个实现文件，其中main函数在dumpstate.c文件中，这个main函数我们这里不详细分析了，总结下它的主要工作：
1. 根据启动参数，初始化相关资源
2. 如果启动参数中带有-s的话（init启动会加上这个参数），就表示使用socket，那么就启动socket，并且在这个socket中等待链接。
3. 如果client端（也就是bugreport进程）链接成功，那就初始化所要用到的内存，并且设置优先级为较高优先级，防止被OOM干掉。
4. 然后使用vibrator震动一下（如果设备有这个硬件的话），提示用户开始截取log了
5. 调用dumpstate函数开始真正的dump工作
6. dump完成之后再次调用vibrator震动3次，提示用户dump完成。
现在我们看下dumpstate函数的实现：

上面的代码比较长，是因为所要dump的模块太多，但是基本逻辑还是比较清楚的，我们看到基本的数据来源就是：
1.系统属性
2./proc和/sys节点文件
3.执行shell命令获得相关输出
4.logcat输出
5.Android Framework Services信息基本使用dumpsys命令通过binder调用服务中的dump函数获得信息
这里我们需要看一下dumpsys命令的实现，这个命令也是比较简单，实现全部在main函数中：

我们看到它的代码逻辑就是，通过Binder的SM查找参数中的service，然后通过：

这句来调用service的dump函数。
dumpstate会调用到所有binder中的service的dump函数，因为dumpstate函数执行了这一句：

直接执行dumpsys，没有参数，并且注释中也说的很清楚，就是采集所有的信息。这会执行以下service的dump函数（执行dumpsys | grep “DUMP OF SERVICE”可以看到）：

这里总结以下，上面的bugreport整体逻辑如下图描述（如果图片太小看不清，请下载图片并查看）：


adb bugreport的其他选项

bugreport本身并没有什么选项，主要是通过dumpsys等命令配合完成，详见battery historian项目主页：https://github.com/google/battery-historian，以下是个总结：
1）. 重置电池统计信息：

2）. Wakelock analysis全部wakelock信息：

3）. Kernel trace analysis分析内核，主要分析wakeup source和wakelock activities，首先使能kernel分析：

然后获得log：