本文主要介绍bugreport上报的log的文件结构，主要是给大家有个印象，知道有哪些信息我们能从log中获取。

1 介绍

测试日常上报的jira中提供的基本都是bugreport抓取的log，内有很多不同类型的log文件。

---

2 目录结构

一份bugreport的典型目录结构一般包含如下所示的几个目录。

2.1 anr

该目录存放anr trace，对应/data/anr目录。

如果没有发生anr，那么该目录可能为空。

即使不为空，也不代表发生了anr。

注意，如果有多份trace，请根据event log中的anr信息结合trace的subject来确定哪份是正真的ANR trace！

例如：

Event log中 am_anr 显示的anr信息如下。

10-19 04:33:48.292 1000 2389 18743 I am_anr : [0,10439,com.android.camera,551140933,Input dispatching timed out (49ad454 com.android.camera/com.android.camera.Camera (server) is not responding. Waited 5000ms for MotionEvent(deviceId=-1, eventTime=63249225000000, source=0x00001002, displayId=0, action=UP, actionButton=0x00000000, flags=0x00000000, metaState=0x00000000, buttonState=0x00000000, classification=NONE, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, xCursorPosition=nan, yCursorPosition=nan, pointers=[0: (866.0, 1387.0)]), policyFlags=0x6b000000)]

那么，请在提供的众多trace文件中找到subject相同的。

Subject: Input dispatching timed out (49ad454 com.android.camera/com.android.camera.Camera (server) is not responding. Waited 5000ms for MotionEvent(deviceId=-1, eventTime=63249225000000, source=0x00001002, displayId=0, action=UP, actionButton=0x00000000, flags=0x00000000, metaState=0x00000000, buttonState=0x00000000, classification=NONE, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, xCursorPosition=nan, yCursorPosition=nan, pointers=[0: (866.0, 1387.0)]), policyFlags=0x6b000000)

而其他subject可能是xxx内部的anr检测工具抓取的trace。

Subject: App Scout Exception

2.2

2.3 offlineLog

2.4 systemLog

main log

2.5 tombstones

发生native crash时，会在这里生成一份tombstone log。不论是APP/HAL/其他进程等。

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

Build fingerprint: 'xxx/xxx/xxx:12/SKQ1.220303.001/V13.0.0.0630.SLRCNXM:user/release-keys'

Revision: '0'

ABI: 'arm64'

Timestamp: 2022-06-30 11:49:36.365563228+0800

Process uptime: 0s

Cmdline: /system/bin/surfaceflinger

pid: 1553, tid: 2068, name: IdleTimer  >>> /system/bin/surfaceflinger <<<

uid: 1000

tagged_addr_ctrl: 0000000000000001

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2770

    x0  b4000073f8f93380  x1  0000000000000001  x2  0000007358715798  x3  000000735871587c

    x4  00ffffffffffffff  x5  00000000000011a4  x6  00000000ffffffff  x7  7f7f7f7f7f7f7f7f

    x8  0000000000002770  x9  0000000000002770  x10 0000000000000001  x11 0000000000000000

    x12 0000000000000000  x13 000000007fffffff  x14 00000000000011a4  x15 0000000000000000

    x16 00000073588a8720  x17 00000073f63d20d4  x18 0000007356c82000  x19 0000007358715798

    x20 b4000073f8f93380  x21 000000735871587c  x22 0000000000000000  x23 0000007358716000

    x24 0000007358716000  x25 b4000073f906eb60  x26 0000000000000000  x27 0000000000000000

    x28 0000000000000000  x29 0000007358715700

    lr  00234c73ee467d10  sp  00000073587156c0  pc  00000073588a8764  pst 0000000080001000



backtrace:

      #00 pc 000000000001e764  /system_ext/lib64/libmisurfaceflinger.so (android::MiSurfaceFlingerImpl::setIdleFps(int, bool*)+68) (BuildId: 7fdd5533164929d182099bc2476713cd)

      #01 pc 0000000000263d0c  /system/lib64/libsurfaceflinger.so (android::scheduler::RefreshRateConfigs::getBestRefreshRateLocked(std::__1::vector<android::scheduler::RefreshRateConfigs::LayerRequirement, std::__1::allocator<android::scheduler::RefreshRateConfigs::LayerRequirement> > const&, android::scheduler::RefreshRateConfigs::GlobalSignals const&, android::scheduler::RefreshRateConfigs::GlobalSignals*) const+912) (BuildId: 21ca9a41ad2100b501c2b4d4f5c757cf)

      #02 pc 000000000026358c  /system/lib64/libsurfaceflinger.so (android::scheduler::RefreshRateConfigs::getBestRefreshRate(std::__1::vector<android::scheduler::RefreshRateConfigs::LayerRequirement, std::__1::allocator<android::scheduler::RefreshRateConfigs::LayerRequirement> > const&, android::scheduler::RefreshRateConfigs::GlobalSignals const&, android::scheduler::RefreshRateConfigs::GlobalSignals*) const+256) (BuildId: 21ca9a41ad2100b501c2b4d4f5c757cf)

      #03 pc 000000000026de80  /system/lib64/libsurfaceflinger.so (android::Scheduler::calculateRefreshRateModeId(android::scheduler::RefreshRateConfigs::GlobalSignals*)+152) (BuildId: 21ca9a41ad2100b501c2b4d4f5c757cf)

      #04 pc 000000000026e514  /system/lib64/libsurfaceflinger.so (bool android::Scheduler::handleTimerStateChanged<android::Scheduler::TimerState>(android::Scheduler::TimerState*, android::Scheduler::TimerState)+108) (BuildId: 21ca9a41ad2100b501c2b4d4f5c757cf)

      #05 pc 000000000026acf0  /system/lib64/libsurfaceflinger.so (android::Scheduler::idleTimerCallback(android::Scheduler::TimerState)+84) (BuildId: 21ca9a41ad2100b501c2b4d4f5c757cf)

      #06 pc 000000000025dbd4  /system/lib64/libsurfaceflinger.so (android::scheduler::OneShotTimer::loop()+496) (BuildId: 21ca9a41ad2100b501c2b4d4f5c757cf)

      #07 pc 000000000025e0a4  /system/lib64/libsurfaceflinger.so (void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (android::scheduler::OneShotTimer::*)(), android::scheduler::OneShotTimer*> >(void*)+64) (BuildId: 21ca9a41ad2100b501c2b4d4f5c757cf)

      #08 pc 00000000000f0d34  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: aec8135f170446601ecfbb3a8984afdb)

      #09 pc 000000000008d57c  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68) (BuildId: aec8135f170446601ecfbb3a8984afdb)

• Cmdline ：该行表示发生crash的进程名
• pid/tid/name：进程号，线程号等等
• signal：中断的信号，参见linux 定义的信号
• backtrace：异常堆栈

2.6 bugreport

通常该目录会是一个zip压缩包。需要我们解压，解压后可以看到一个类似如下命名的txt文件。

bugreport-xxxx-SKQ1.220303.001-2022-10-19-04-37-06.txt

该文件几乎包含所有debug所需的信息。

在 [3 bugreport文件结构]

---

3 bugreport文件结构

该文件由各种dumpsys信息、log以及各种系统工具查询结果拼接而成。

这里提供一个分割的方法，可以使用glogg 搜索 was the duration of ， 这样每段的结尾都会搜索出来，方便定位。

如果能做个工具自动分割就更好了。

接下来，介绍下自认为比较重要的模块。

3.1 DUMPSYS CRITICAL

这部分主要是打印系统各个重要模块的dumpsys信息。具体各个dump的含义就不一一介绍了，各位自行查询。

不过缺少了media.camera。 幸好在[3.11 Dumpsys media.camera]

• dumpsys SurfaceFlinger
• dumpsys activity
• dumpsys cpuinfo
• dumpsys input
• dumpsys input_method
• dumpsys notification
• dumpsys power
• dumpsys sensorservice
• dumpsys window

3.2 SYSTEM LOG

adb shell logcat -v threadtime -v printable -v uid -d *:v

这部分即为我们常说的main log，由logcat输出。

但是由于也包含了其他进程的log，也可以用来分析和其他进程交互的问题。

3.3 EVENT LOG

adb shell logcat -b events -v threadtime -v printable -v uid -d *:v

这部分即为event log，关于相机常用的event log解析，见该文档：

3.4 MEMORY INFO

adb shell cat /proc/meminfo

系统内存使用详细情况。这篇文档介绍的比较详细，感兴趣的可以看下。

gist.github.com/baymaxium/f…

3.5 CPU INFO

adb shell top -b -n 1 -H -s 6 -o pid,tid,user,pr,ni,%cpu,s,virt,res,pcy,cmd,name

即为linux 常用的top命令输出的结果。

显示系统中各个进程的资源占用状况。

3.6 PROCRANK

adb shell /system/xbin/su root procrank

查看进程的内存使用情况，并进行排序。

  PID       Vss      Rss      Pss      Uss     Swap    PSwap    USwap    ZSwap  cmdline

10439  24087892K  569192K  433054K  417060K  338488K  311032K  310612K   79349K  com.android.camera

 2389  11773452K  390428K  185 181K  102092K  129384K  104107K  103720K   26559K  system_server

 1266  15050336K  166264K  152646K  145620K  360136K  360136K  360136K   91876K  /vendor/bin/hw/vendor.qti.camera.provider@2.7-service_64

 5140  8072336K  150988K   69154K   59524K   70000K   42450K   42028K   10829K  com.android.systemui

23453  4924460K  106092K   58597K   53872K       0K       0K       0K       0K  app_process

  668  7915384K   89988K   29201K   25792K  120092K   87741K   87212K   22384K  com.xxx.home

关于VSS/RSS/PSS，见[调试工具(2)_Event log]

3.7 VM TRACES JUST NOW

当前所有进程的trace，其中可见找到我们相机APP的tarce，即使是非anr类问题，也能得到当时相机进程内线程得信息。

具体trace如何看见：[调试工具(3)_ANR Trace文件解析]

3.8 MEMINFO in pid

这里列举了所有应用的dumpsys meminfo信息。

adb shell dumpsys meminfo pkgname

详细可见官方文档：

developer.android.google.cn/studio/comm…

3.9 SYSTEM PROPERTIES

adb shell getprop

这里能获取到很多重要的prop！

例如我们代码里很多开关是读取的prop，在这里就可以查询了。

还有一些硬件信息的确认等等。

3.10 STORAGED IO INFO

adb shell storaged -u -p

详情可见：source.android.com/docs/core/t…

3.11 Dumpsys media.camera

adb shell dumpsys media.camera

详细信息可见：[调试工具(1)_Camera DumpSys]

---

4 分析流程

这里举一些常见的jira分析流程。

4.1 内存类问题分析

如果遇到内存不足，我们需要关注的log有：

1. [MEMORY INFO]
2. [CPU INFO]
3. [PROCRANK]
4. [MEMINFO in pid]
5. [EVENT LOG] 中可以看下am_pss的tag
6. [SYSTEM LOG]中也有类似lowmemorykiller的log

4.2 crash jira 分析

• 通常crash类jira，我们可以先通过，在event log中搜索am_crash，快速定位异常时间，进程号。
• 然后再在mainlog(SYSTEM LOG)中确定具体信息。
• 如果是Native的crash，可在tombstones目录中找到对应的tombstone文件。

4.3 anr jira分析

• Event log中搜索am_anr，快速定位anr发生的时间，进程号等信息。
• anr 目录中找到对应的trace
• 根据trace进行分析，是逻辑有问题，还是系统状态异常
• 如果是系统状态异常，可以结合系统信息（memory info、CPU INFO、PROCRANK、meminfo）等分析

4.4 相机无法连接

• 可以先搜索onCameraException，确定无法连接发生的时间点
• 然后在tombstone中查找有无hal发生crash的信息。name: vendor.qti.camera.provider@2.7-service_64
• 如果有的话有，可以先转HAL分析

4.5 dropbox

这里插播一条实用的技巧。

日常工作时遇到偶现的crash/anr，忘了抓284log的话，可以查看dropbox快速定位问题原因。

adb pull /data/system/dropbox ./

pull出的dropbox，一般会有以下几类txt文件。

且都是以时间戳结尾，标明发生的时间点。

这里列举一下常见的一些文件：

SYSTEM_TAGS	NOTE
system_app_crash	系统应用crash的异常堆栈
system_app_wtf	系统app发生严重错误
system_app_anr	系统app发生anr的trace文件。
SYSTEM_TOMBSTONE	Native进程崩溃日志