當前位置：首頁 > 运维知识 > Android >内容正文

Android

Android日志[进阶篇]五-阅读错误报告

發布時間：2025/3/12 Android 21 豆豆

生活随笔收集整理的這篇文章主要介紹了 Android日志[进阶篇]五-阅读错误报告小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Android日志[進階篇]一-使用 Logcat 寫入和查看日志
Android日志[進階篇]二-分析堆棧軌跡(調試和外部堆棧)
Android日志[進階篇]三-Logcat命令行工具
Android日志[進階篇]四-獲取錯誤報告
Android日志[進階篇]五-閱讀錯誤報告

- Logcat
- - 查看事件日志
- ANR 和死鎖
- - 找出無響應的應用
  - 查找堆棧跟蹤
  - 查找死鎖
- Activity
- - 查看處于聚焦狀態的 Activity
  - 查看進程啟動事件
  - 設備是否發生系統顛簸？
- 內存
- - 發現內存不足的情況
  - - 查看歷史指標
    - 查看系統顛簸指標
  - 獲取內存快照
- 廣播
- - 查看歷史廣播
  - 查看待發送的廣播
  - 查看廣播收聽方
- 顯示器爭用
- 后臺編譯
- 敘述
- - 同步時間軸
  - 確定錯誤報告的生成時間
- 電源
- 程序包
- 進程
- - 確定進程運行時
  - 某個進程為什么正在運行？
- 掃描

無論是任何類型的開發工作，出錯都在所難免，重要的是根據錯誤報告找出和解決問題。Android 的所有版本都支持通過 Android 調試橋 (adb) 獲取錯誤報告；Android 4.2 及更高版本支持一個旨在獲取錯誤報告以及通過電子郵件、云端硬盤等分享報告的開發人員選項。

Android 錯誤報告中包含文本 (.txt) 格式的 dumpsys、dumpstate 和 logcat 數據，以便您輕松搜索特定內容。以下各部分詳細說明了錯誤報告的組成部分、介紹了常見問題，并提供了關于查找與這些錯誤相關的日志的實用提示和 grep 命令。大多數部分中還包括 grep 命令及輸出和/或 dumpsys 輸出方面的示例。

Logcat

logcat 日志是所有 logcat 信息的轉儲，并采用字符串形式。system（系統）部分專門用于記錄框架方面的信息，與包含所有其他內容的 main（主要內容）部分相比，該部分包含更長時間內的記錄。每行都以 timestamp PID TID log-level 開頭。

顯示示例：

------ SYSTEM LOG (logcat -v threadtime -d *:v) ------
--------- beginning of system
Blah
Blah
Blah

--------- beginning of main
Blah
Blah
Blah

查看事件日志

該日志中包含將二進制格式轉換成了字符串形式的日志消息。它比 logcat 日志要清晰明了，但也有些難以閱讀。在查看事件日志時，可以在這一部分中搜索特定進程 ID (PID)，以查看相應進程一直在做什么。基本格式為：timestamp PID TID log-level log-tag tag-values。

日志級別包括以下幾種：

V：詳細
D：調試
I：信息
W：警告
E：錯誤

顯示示例:

------ EVENT LOG (logcat -b events -v threadtime -d *:v) ------
09-28 13:47:34.179 785 5113 I am_proc_bound: [0,23054,com.google.android.gms.unstable]
09-28 13:47:34.777 785 1975 I am_proc_start: [0,23134,10032,com.android.chrome,broadcast,com.android.chrome/org.chromium.chrome.browser.precache.PrecacheServiceLauncher]
09-28 13:47:34.806 785 2764 I am_proc_bound: [0,23134,com.android.chrome]
…

有關其他實用的事件日志標記，請參閱 https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/EventLogTags.logtags。

ANR 和死鎖

錯誤報告有助于我們找出導致應用無響應 (ANR) 錯誤和死鎖事件的原因。

找出無響應的應用

當某個應用在一定時間內沒有響應（通常是由于主線程被阻塞或繁忙）時，系統會終止該進程并將堆棧轉儲到 /data/anr。要找出 ANR 背后的罪魁禍首，請為二進制事件日志中的 am_anr 執行 grep 命令。

顯示示例

grep “am_anr” bugreport-2015-10-01-18-13-48.txt
10-01 18:12:49.599 4600 4614 I am_anr : [0,29761,com.google.android.youtube,953695941,executing service com.google.android.youtube/com.google.android.apps.youtube.app.offline.transfer.OfflineTransferService]
10-01 18:14:10.211 4600 4614 I am_anr : [0,30363,com.google.android.apps.plus,953728580,executing service com.google.android.apps.plus/com.google.android.apps.photos.service.PhotosService]

我們也可以為 logcat 日志（其中包含關于發生 ANR 時是什么在占用 CPU 的更多信息）中的 ANR in 執行 grep 命令。

顯示示例

grep “ANR in” bugreport-2015-10-01-18-13-48.txt
10-01 18:13:11.984 4600 4614 E ActivityManager: ANR in com.google.android.youtube
10-01 18:14:31.720 4600 4614 E ActivityManager: ANR in com.google.android.apps.plus
10-01 18:14:31.720 4600 4614 E ActivityManager: PID: 30363
10-01 18:14:31.720 4600 4614 E ActivityManager: Reason: executing service com.google.android.apps.plus/com.google.android.apps.photos.service.PhotosService
10-01 18:14:31.720 4600 4614 E ActivityManager: Load: 35.27 / 23.9 / 16.18
10-01 18:14:31.720 4600 4614 E ActivityManager: CPU usage from 16ms to 21868ms later:
10-01 18:14:31.720 4600 4614 E ActivityManager: 74% 3361/mm-qcamera-daemon: 62% user + 12% kernel / faults: 15276 minor 10 major
10-01 18:14:31.720 4600 4614 E ActivityManager: 41% 4600/system_server: 18% user + 23% kernel / faults: 18597 minor 309 major
10-01 18:14:31.720 4600 4614 E ActivityManager: 32% 27420/com.google.android.GoogleCamera: 24% user + 7.8% kernel / faults: 48374 minor 338 major
10-01 18:14:31.720 4600 4614 E ActivityManager: 16% 130/kswapd0: 0% user + 16% kernel
10-01 18:14:31.720 4600 4614 E ActivityManager: 15% 283/mmcqd/0: 0% user + 15% kernel
…
10-01 18:14:31.720 4600 4614 E ActivityManager: 0.1% 27248/irq/503-synapti: 0%
10-01 18:14:31.721 4600 4614 I ActivityManager: Killing 30363:com.google.android.apps.plus/u0a206 (adj 0): bg anr

查找堆棧跟蹤

通常我們可以找到與 ANR 對應的堆棧跟蹤。請確保 VM 跟蹤上的時間戳和 PID 與正在調查的 ANR 相符，然后再檢查進程的主線程。請注意：

主線程只能讓我們了解發生 ANR 時它在做什么，這可能是導致 ANR 的真正原因，也可能不是。（錯誤報告中的堆棧可能是無關的；可能有其他線程在恢復正常之前粘滯了很長時間，但不足以導致 ANR。）
可能存在多組堆棧跟蹤（VM TRACES JUST NOW 和 VM TRACES AT LAST ANR）。請確保查看的是正確的部分。

顯示示例

------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2015-10-01 18:14:41) ------
----- pid 30363 at 2015-10-01 18:14:11 -----
Cmd line: com.google.android.apps.plus
Build fingerprint: ‘google/angler/angler:6.0/MDA89D/2294819:userdebug/dev-keys’
ABI: ‘arm’
Build type: optimized
Zygote loaded classes=3978 post zygote classes=27
Intern table: 45068 strong; 21 weak
JNI: CheckJNI is off; globals=283 (plus 360 weak)
Libraries: /system/lib/libandroid.so /system/lib/libcompiler_rt.so /system/lib/libjavacrypto.so /system/lib/libjnigraphics.so /system/lib/libmedia_jni.so /system/lib/libwebviewchromium_loader.so libjavacore.so (7)
Heap: 29% free, 21MB/30MB; 32251 objects
Dumping cumulative Gc timings
Total number of allocations 32251
Total bytes allocated 21MB
Total bytes freed 0B
Free memory 9MB
Free memory until GC 9MB
Free memory until OOME 490MB
Total memory 30MB
Max memory 512MB
Zygote space size 1260KB
Total mutator paused time: 0
Total time waiting for GC to complete: 0
Total GC count: 0
Total GC time: 0
Total blocking GC count: 0
Total blocking GC time: 0

suspend all histogram: Sum: 119.728ms 99% C.I. 0.010ms-107.765ms Avg: 5.442ms Max: 119.562ms
DALVIK THREADS (12):
“Signal Catcher” daemon prio=5 tid=2 Runnable
| group=“system” sCount=0 dsCount=0 obj=0x12c400a0 self=0xef460000
| sysTid=30368 nice=0 cgrp=default sched=0/0 handle=0xf4a69930
| state=R schedstat=( 9021773 5500523 26 ) utm=0 stm=0 core=1 HZ=100
| stack=0xf496d000-0xf496f000 stackSize=1014KB
| held mutexes= “mutator lock”(shared held)
native: #00 pc 0035a217 /system/lib/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, char const*, art::ArtMethod*, void*)+126)
native: #01 pc 0033b03b /system/lib/libart.so (art::Thread::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) const+138)
native: #02 pc 00344701 /system/lib/libart.so (art::DumpCheckpoint::Run(art::Thread*)+424)
native: #03 pc 00345265 /system/lib/libart.so (art::ThreadList::RunCheckpoint(art::Closure*)+200)
native: #04 pc 00345769 /system/lib/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+124)
native: #05 pc 00345e51 /system/lib/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+312)
native: #06 pc 0031f829 /system/lib/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+68)
native: #07 pc 00326831 /system/lib/libart.so (art::SignalCatcher::HandleSigQuit()+896)
native: #08 pc 003270a1 /system/lib/libart.so (art::SignalCatcher::Run(void*)+324)
native: #09 pc 0003f813 /system/lib/libc.so (__pthread_start(void*)+30)
native: #10 pc 00019f75 /system/lib/libc.so (__start_thread+6)
(no managed stack frames)

“main” prio=5 tid=1 Suspended
| group=“main” sCount=1 dsCount=0 obj=0x747552a0 self=0xf5376500
| sysTid=30363 nice=0 cgrp=default sched=0/0 handle=0xf74feb34
| state=S schedstat=( 331107086 164153349 851 ) utm=6 stm=27 core=3 HZ=100
| stack=0xff00f000-0xff011000 stackSize=8MB
| held mutexes=
kernel: __switch_to+0x7c/0x88
kernel: futex_wait_queue_me+0xd4/0x130
kernel: futex_wait+0xf0/0x1f4
kernel: do_futex+0xcc/0x8f4
kernel: compat_SyS_futex+0xd0/0x14c
kernel: cpu_switch_to+0x48/0x4c
native: #00 pc 000175e8 /system/lib/libc.so (syscall+28)
native: #01 pc 000f5ced /system/lib/libart.so (art::ConditionVariable::Wait(art::Thread*)+80)
native: #02 pc 00335353 /system/lib/libart.so (art::Thread::FullSuspendCheck()+838)
native: #03 pc 0011d3a7 /system/lib/libart.so (art::ClassLinker::LoadClassMembers(art::Thread*, art::DexFile const&, unsigned char const*, art::Handle<art::mirror::Class>, art::OatFile::OatClass const*)+746)
native: #04 pc 0011d81d /system/lib/libart.so (art::ClassLinker::LoadClass(art::Thread*, art::DexFile const&, art::DexFile::ClassDef const&, art::Handle<art::mirror::Class>)+88)
native: #05 pc 00132059 /system/lib/libart.so (art::ClassLinker::DefineClass(art::Thread*, char const*, unsigned int, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::DexFile::ClassDef const&)+320)
native: #06 pc 001326c1 /system/lib/libart.so (art::ClassLinker::FindClassInPathClassLoader(art::ScopedObjectAccessAlreadyRunnable&, art::Thread*, char const*, unsigned int, art::Handle<art::mirror::ClassLoader>, art::mirror::Class**)+688)
native: #07 pc 002cb1a1 /system/lib/libart.so (art::VMClassLoader_findLoadedClass(_JNIEnv*, _jclass*, _jobject*, _jstring*)+264)
native: #08 pc 002847fd /data/dalvik-cache/arm/system@framework@boot.oat (Java_java_lang_VMClassLoader_findLoadedClass__Ljava_lang_ClassLoader_2Ljava_lang_String_2+112)
at java.lang.VMClassLoader.findLoadedClass!(Native method)
at java.lang.ClassLoader.findLoadedClass(ClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
at android.app.ActivityThread.installProvider(ActivityThread.java:5141)
at android.app.ActivityThread.installContentProviders(ActivityThread.java:4748)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4688)
at android.app.ActivityThread.-wrap1(ActivityThread.java:-1)
at android.app.ActivityThread $H . h a n d l e M e s s a g e (A c t i v i t y T h r e a d . j a v a : 1405) a t a n d r o i d . o s . H a n d l e r . d i s p a t c h M e s s a g e (H a n d l e r . j a v a : 102) a t a n d r o i d . o s . L o o p e r . l o o p (L o o p e r . j a v a : 148) a t a n d r o i d . a p p . A c t i v i t y T h r e a d . m a i n (A c t i v i t y T h r e a d . j a v a : 5417) a t j a v a . l a n g . r e f l e c t . M e t h o d . i n v o k e! (N a t i v e m e t h o d) a t c o m . a n d r o i d . i n t e r n a l . o s . Z y g o t e I n i t$ MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

…
Stacks for other threads in this process follow
…

查找死鎖

由于線程出現粘滯，死鎖往往首先表現為 ANR。如果系統服務器發生死鎖，監控程序最終會將其終止，從而導致日志中出現類似以下的條目：WATCHDOG KILLING SYSTEM PROCESS。對于用戶來說，他們看到的是APP重新啟動，但從技術上來講這是運行時重啟，而不是真正的設備重新啟動。

在運行時重啟時，系統服務器已死機并會重啟，并且用戶會看到設備返回到顯示啟動動畫。
在設備重新啟動時，內核已崩潰，并且用戶會看到設備返回到顯示設備啟動徽標。

要查找死鎖，請檢查 VM 跟蹤部分中是否存在以下模式：線程 A 在等待線程 B 占用的某些資源，而線程 B 也在等待線程 A 占用的某些資源。

顯示示例

“Binder_B” prio=5 tid=73 Blocked
| group=“main” sCount=1 dsCount=0 obj=0x13faa0a0 self=0x95e24800
| sysTid=2016 nice=0 cgrp=default sched=0/0 handle=0x8b68d930
| state=S schedstat=( 9351576559 4141431119 16920 ) utm=819 stm=116 core=1 HZ=100
| stack=0x8b591000-0x8b593000 stackSize=1014KB
| held mutexes=
at com.android.server.pm.UserManagerService.exists(UserManagerService.java:387)
- waiting to lock <0x025f9b02> (a android.util.ArrayMap) held by thread 20
at com.android.server.pm.PackageManagerService.getApplicationInfo(PackageManagerService.java:2848)
at com.android.server.AppOpsService.getOpsRawLocked(AppOpsService.java:881)
at com.android.server.AppOpsService.getOpsLocked(AppOpsService.java:856)
at com.android.server.AppOpsService.noteOperationUnchecked(AppOpsService.java:719)
- locked <0x0231885a> (a com.android.server.AppOpsService)
at com.android.server.AppOpsService.noteOperation(AppOpsService.java:713)
at com.android.server.AppOpsService$2.getMountMode(AppOpsService.java:260)
at com.android.server.MountService$MountServiceInternalImpl.getExternalStorageMountMode(MountService.java:3416)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:3228)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:3170)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:3059)
at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:1070)
- locked <0x044d166f> (a com.android.server.am.ActivityManagerService)
at com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:16950)
at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:494)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2432)
at android.os.Binder.execTransact(Binder.java:453)
…
“PackageManager” prio=5 tid=20 Blocked
| group=“main” sCount=1 dsCount=0 obj=0x1304f4a0 self=0xa7f43900
| sysTid=1300 nice=10 cgrp=bg_non_interactive sched=0/0 handle=0x9fcf9930
| state=S schedstat=( 26190141996 13612154802 44357 ) utm=2410 stm=209 core=2 HZ=100
| stack=0x9fbf7000-0x9fbf9000 stackSize=1038KB
| held mutexes=
at com.android.server.AppOpsService.noteOperationUnchecked(AppOpsService.java:718)
- waiting to lock <0x0231885a> (a com.android.server.AppOpsService) held by thread 73
at com.android.server.AppOpsService.noteOperation(AppOpsService.java:713)
at com.android.server.AppOpsService$2.getMountMode(AppOpsService.java:260)
at com.android.server.AppOpsService$2.hasExternalStorage(AppOpsService.java:273)
at com.android.server.MountService$MountServiceInternalImpl.hasExternalStorage(MountService.java:3431)
at com.android.server.MountService.getVolumeList(MountService.java:2609)
at android.os.storage.StorageManager.getVolumeList(StorageManager.java:880)
at android.os.Environment$UserEnvironment.getExternalDirs(Environment.java:83)
at android.os.Environment.isExternalStorageEmulated(Environment.java:708)
at com.android.server.pm.PackageManagerService.isExternalMediaAvailable(PackageManagerService.java:9327)
at com.android.server.pm.PackageManagerService.startCleaningPackages(PackageManagerService.java:9367)
- locked <0x025f9b02> (a android.util.ArrayMap)
at com.android.server.pm.PackageManagerService$PackageHandler.doHandleMessage(PackageManagerService.java:1320)
at com.android.server.pm.PackageManagerService$PackageHandler.handleMessage(PackageManagerService.java:1122)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.os.HandlerThread.run(HandlerThread.java:61)
at com.android.server.ServiceThread.run(ServiceThread.java:46)

Activity

Activity 是四大組件之一的應用組件，可提供一個屏幕，用戶能夠通過與該屏幕互動來執行某些操作，例如撥打電話號碼、拍照、發送電子郵件，等等。從錯誤報告的角度來看，一個 Activity 是用戶可以執行一項明確具體的操作，這使得查找在崩潰期間處于聚焦狀態的 Activity 變得非常重要。Activity 通過 ActivityManager 運行進程，因此找出指定 Activity 的所有進程停止和啟動事件也有助于進行問題排查。

查看處于聚焦狀態的 Activity

要查看記錄的處于聚焦狀態的 Activity，請搜索 am_focused_activity。

顯示示例

grep “am_focused_activity” bugreport-2015-10-01-18-13-48.txt
10-01 18:10:41.409 4600 14112 I am_focused_activity: [0,com.google.android.GoogleCamera/com.android.camera.CameraActivity]
10-01 18:11:17.313 4600 5687 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]
10-01 18:11:52.747 4600 14113 I am_focused_activity: [0,com.google.android.GoogleCamera/com.android.camera.CameraActivity]
10-01 18:14:07.762 4600 5687 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

查看進程啟動事件

要查看記錄的進程啟動事件，請搜索 Start proc。

顯示示例

grep “Start proc” bugreport-2015-10-01-18-13-48.txt
10-01 18:09:15.309 4600 4612 I ActivityManager: Start proc 24533:com.metago.astro/u0a240 for broadcast com.metago.astro/com.inmobi.commons.analytics.androidsdk.IMAdTrackerReceiver
10-01 18:09:15.687 4600 14112 I ActivityManager: Start proc 24548:com.google.android.apps.fitness/u0a173 for service com.google.android.apps.fitness/.api.services.ActivityUpsamplingService
10-01 18:09:15.777 4600 6604 I ActivityManager: Start proc 24563:cloudtv.hdwidgets/u0a145 for broadcast cloudtv.hdwidgets/cloudtv.switches.SwitchSystemUpdateReceiver
10-01 18:09:20.574 4600 6604 I ActivityManager: Start proc 24617:com.wageworks.ezreceipts/u0a111 for broadcast com.wageworks.ezreceipts/.ui.managers.IntentReceiver
…

設備是否發生系統顛簸？

要確定設備是否發生系統顛簸，請檢查 am_proc_died 和 am_proc_start 前后在短時間內是否出現活動異常增加。

顯示示例

grep -e “am_proc_died” -e “am_proc_start” bugreport-2015-10-01-18-13-48.txt
10-01 18:07:06.494 4600 9696 I am_proc_died: [0,20074,com.android.musicfx]
10-01 18:07:06.555 4600 6606 I am_proc_died: [0,31166,com.concur.breeze]
10-01 18:07:06.566 4600 14112 I am_proc_died: [0,18812,com.google.android.apps.fitness]
10-01 18:07:07.018 4600 7513 I am_proc_start: [0,20361,10113,com.sony.playmemories.mobile,broadcast,com.sony.playmemories.mobile/.service.StartupReceiver]
10-01 18:07:07.357 4600 4614 I am_proc_start: [0,20381,10056,com.google.android.talk,service,com.google.android.talk/com.google.android.libraries.hangouts.video.CallService]
10-01 18:07:07.784 4600 4612 I am_proc_start: [0,20402,10190,com.andcreate.app.trafficmonitor:loopback_measure_serivce,service,com.andcreate.app.trafficmonitor/.loopback.LoopbackMeasureService]
10-01 18:07:10.753 4600 5997 I am_proc_start: [0,20450,10097,com.amazon.mShop.android.shopping,broadcast,com.amazon.mShop.android.shopping/com.amazon.identity.auth.device.storage.LambortishClock$ChangeTimestampsBroadcastReceiver]
10-01 18:07:15.267 4600 6605 I am_proc_start: [0,20539,10173,com.google.android.apps.fitness,service,com.google.android.apps.fitness/.api.services.ActivityUpsamplingService]
10-01 18:07:15.985 4600 4612 I am_proc_start: [0,20568,10022,com.android.musicfx,broadcast,com.android.musicfx/.ControlPanelReceiver]
10-01 18:07:16.315 4600 7512 I am_proc_died: [0,20096,com.google.android.GoogleCamera]

內存

由于 Android 設備的物理內存通常都存在限制，因此管理隨機存取存儲器 (RAM) 至關重要。錯誤報告中包含一些用于指示內存不足的指標以及一個提供內存快照的 dumpstate。

發現內存不足的情況

內存不足可能會導致系統發生顛簸，這是因為雖然內存不足時系統會終止某些進程來釋放內存，但又會繼續啟動其他進程。要查看內存不足的確鑿證據，請檢查二進制事件日志中 am_proc_died 和 am_proc_start 條目的密集程度。

內存不足還可能會減慢任務切換速度，并且可能會阻止進行返回嘗試（因為用戶嘗試返回到的任務已被終止）。如果啟動器被終止，它會在用戶觸摸主屏幕按鈕時重啟，并且日志中會顯示啟動器重新加載其內容。

查看歷史指標

二進制事件日志中的 am_low_memory 條目表示最后一個緩存的進程已終止。在此之后，系統開始終止各項服務。

顯示示例

grep “am_low_memory” bugreport-2015-10-01-18-13-48.txt
10-01 18:11:02.219 4600 7513 I am_low_memory: 41
10-01 18:12:18.526 4600 14112 I am_low_memory: 39
10-01 18:12:18.874 4600 7514 I am_low_memory: 38
10-01 18:12:22.570 4600 14112 I am_low_memory: 40
10-01 18:12:34.811 4600 20319 I am_low_memory: 43
10-01 18:12:37.945 4600 6521 I am_low_memory: 43
10-01 18:12:47.804 4600 14110 I am_low_memory: 43

查看系統顛簸指標

關于系統顛簸（分頁、直接回收等）的其他指標包括 kswapd、kworker 和 mmcqd 消耗的 CPU 周期。（請注意，收集錯誤報告可能會影響系統顛簸指標。）

顯示示例

------ CPU INFO (top -n 1 -d 1 -m 30 -t) ------

User 15%, System 54%, IOW 28%, IRQ 0%
User 82 + Nice 2 + Sys 287 + Idle 1 + IOW 152 + IRQ 0 + SIRQ 5 = 529

PID TID PR CPU% S VSS RSS PCY UID Thread Proc
15229 15229 0 19% R 0K 0K fg root kworker/0:2
29512 29517 1 7% D 1173524K 101188K bg u0_a27 Signal Catcher com.google.android.talk
24565 24570 3 6% D 2090920K 145168K fg u0_a22 Signal Catcher com.google.android.googlequicksearchbox:search
19525 19525 2 6% R 3476K 1644K fg shell top top
24957 24962 2 5% R 1706928K 125716K bg u0_a47 Signal Catcher com.google.android.GoogleCamera
19519 19519 3 4% S 0K 0K fg root kworker/3:1
120 120 0 3% S 0K 0K fg root mmcqd/1
18233 18233 1 3% S 0K 0K fg root kworker/1:1
25589 25594 1 2% D 1270476K 75776K fg u0_a8 Signal Catcher com.google.android.gms
19399 19399 2 1% S 0K 0K fg root kworker/2:2
1963 1978 1 0% S 1819100K 125136K fg system android.fg system_server
1963 1981 3 0% S 1819100K 125136K fg system android.display system_server

ANR 日志可以提供類似的內存快照。

顯示示例

10-03 17:19:59.959 1963 1976 E ActivityManager: ANR in com.google.android.apps.magazines
10-03 17:19:59.959 1963 1976 E ActivityManager: PID: 18819
10-03 17:19:59.959 1963 1976 E ActivityManager: Reason: Broadcast of Intent { act=android.net.conn.CONNECTIVITY_CHANGE flg=0x4000010 cmp=com.google.android.apps.magazines/com.google.apps.dots.android.newsstand.appwidget.NewsWidgetProvider (has extras) }
10-03 17:19:59.959 1963 1976 E ActivityManager: Load: 19.19 / 14.76 / 12.03
10-03 17:19:59.959 1963 1976 E ActivityManager: CPU usage from 0ms to 11463ms later:
10-03 17:19:59.959 1963 1976 E ActivityManager: 54% 15229/kworker/0:2: 0% user + 54% kernel
10-03 17:19:59.959 1963 1976 E ActivityManager: 38% 1963/system_server: 14% user + 23% kernel / faults: 17152 minor 1073 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 11% 120/mmcqd/1: 0% user + 11% kernel
10-03 17:19:59.959 1963 1976 E ActivityManager: 10% 2737/com.android.systemui: 4.7% user + 5.6% kernel / faults: 7211 minor 149 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 0.2% 1451/debuggerd: 0% user + 0.2% kernel / faults: 15211 minor 147 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 8.7% 6162/com.twofortyfouram.locale: 4% user + 4.7% kernel / faults: 4924 minor 260 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 6.1% 24565/com.google.android.googlequicksearchbox:search: 2.4% user + 3.7% kernel / faults: 2902 minor 129 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 6% 55/kswapd0: 0% user + 6% kernel
10-03 17:19:59.959 1963 1976 E ActivityManager: 4.9% 18819/com.google.android.apps.magazines: 1.5% user + 3.3% kernel / faults: 10129 minor 986 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 2.8% 18233/kworker/1:1: 0% user + 2.8% kernel
10-03 17:19:59.959 1963 1976 E ActivityManager: 4.2% 3145/com.android.phone: 2% user + 2.2% kernel / faults: 3005 minor 43 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 4.2% 8084/com.android.chrome: 2% user + 2.1% kernel / faults: 4798 minor 380 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 3.4% 182/surfaceflinger: 1.1% user + 2.3% kernel / faults: 842 minor 13 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 3% 18236/kworker/1:2: 0% user + 3% kernel
10-03 17:19:59.959 1963 1976 E ActivityManager: 2.9% 19231/com.android.systemui:screenshot: 0.8% user + 2.1% kernel / faults: 6119 minor 348 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 2.3% 15350/kworker/0:4: 0% user + 2.3% kernel
10-03 17:19:59.959 1963 1976 E ActivityManager: 2.2% 1454/mediaserver: 0% user + 2.2% kernel / faults: 479 minor 6 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 2% 16496/com.android.chrome:sandboxed_process10: 0.1% user + 1.8% kernel / faults: 3610 minor 234 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 1% 3119/com.android.nfc: 0.4% user + 0.5% kernel / faults: 1789 minor 17 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 1.7% 19337/com.jarettmillard.localeconnectiontype:background: 0.1% user + 1.5% kernel / faults: 7854 minor 439 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 0.7% 3066/com.google.android.inputmethod.latin: 0.3% user + 0.3% kernel / faults: 1336 minor 7 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 1% 25589/com.google.android.gms: 0.3% user + 0.6% kernel / faults: 2867 minor 237 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 0.9% 1460/sensors.qcom: 0.5% user + 0.4% kernel / faults: 262 minor 5 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 0.8% 3650/mpdecision: 0% user + 0.8% kernel / faults: 160 minor 1 major
10-03 17:19:59.959 1963 1976 E ActivityManager: 0.1% 3132/com.redbend.vdmc: 0% user + 0% kernel / faults: 1746 minor 5 major

獲取內存快照

內存快照是一種 dumpstate，其中會列出正在運行的 Java 進程和本機進程（有關詳情，請參閱查看整體內存分配）。請注意，快照僅提供特定時刻的狀態；在此快照之前，系統的狀況可能更好，也可能更糟。

要了解某個進程的運行時長，請參閱進程運行時。
要了解為什么某個進程當前正在運行，請參閱某個進程為什么正在運行？

顯示示例

Total PSS by OOM adjustment:
86752 kB: Native
22645 kB: surfaceflinger (pid 197)
18597 kB: mediaserver (pid 204)
…
136959 kB: System
136959 kB: system (pid 785)
220218 kB: Persistent
138859 kB: com.android.systemui (pid 947 / activities)
39178 kB: com.android.nfc (pid 1636)
28313 kB: com.android.phone (pid 1659)
13868 kB: com.redbend.vdmc (pid 1646)
9534 kB: Persistent Service
9534 kB: com.android.bluetooth (pid 23807)
178604 kB: Foreground
168620 kB: com.google.android.googlequicksearchbox (pid 1675 / activities)
9984 kB: com.google.android.apps.maps (pid 13952)
188286 kB: Visible
85326 kB: com.google.android.wearable.app (pid 1535)
38978 kB: com.google.process.gapps (pid 1510)
31936 kB: com.google.android.gms.persistent (pid 2072)
27950 kB: com.google.android.gms.wearable (pid 1601)
4096 kB: com.google.android.googlequicksearchbox:interactor (pid 1550)
52948 kB: Perceptible
52948 kB: com.google.android.inputmethod.latin (pid 1566)
150851 kB: A Services
81121 kB: com.google.android.gms (pid 1814)
37586 kB: com.google.android.talk (pid 9584)
10949 kB: com.google.android.music:main (pid 4019)
10727 kB: com.motorola.targetnotif (pid 31071)
10468 kB: com.google.android.GoogleCamera (pid 9984)
33298 kB: Previous
33298 kB: com.android.settings (pid 9673 / activities)
165188 kB: B Services
49490 kB: com.facebook.katana (pid 15035)
22483 kB: com.whatsapp (pid 28694)
21308 kB: com.iPass.OpenMobile (pid 5325)
19788 kB: com.google.android.apps.googlevoice (pid 23934)
17399 kB: com.google.android.googlequicksearchbox:search (pid 30359)
9073 kB: com.google.android.apps.youtube.unplugged (pid 21194)
7660 kB: com.iPass.OpenMobile:remote (pid 23754)
7291 kB: com.pujie.wristwear.pujieblack (pid 24240)
7157 kB: com.instagram.android:mqtt (pid 9530)
3539 kB: com.qualcomm.qcrilmsgtunnel (pid 16186)
204324 kB: Cached
43424 kB: com.amazon.mShop.android (pid 13558)
22563 kB: com.google.android.apps.magazines (pid 13844)
…
4298 kB: com.google.android.apps.enterprise.dmagent (pid 13826)

廣播

應用會生成廣播，以便在當前應用內發送事件或向其他應用發送事件。廣播接收方可以通過過濾器訂閱特定消息，以便收聽和響應廣播。錯誤報告中包含已發送廣播和未發送廣播的相關信息，以及關于收聽特定廣播的所有接收方的 dumpsys。

查看歷史廣播

歷史廣播是指已發送的廣播，按時間逆序排列。

summary（摘要）部分用于提供最近 300 個前臺廣播和最近 300 個后臺廣播的概況。

顯示示例

Historical broadcasts summary [foreground]:
#0: act=android.intent.action.SCREEN_ON flg=0x50000010
+1ms dispatch +90ms finish
enq=2015-10-29 17:10:51 disp=2015-10-29 17:10:51 fin=2015-10-29 17:10:51
#1: act=android.intent.action.SCREEN_OFF flg=0x50000010
0 dispatch +60ms finish
enq=2015-10-29 17:10:05 disp=2015-10-29 17:10:05 fin=2015-10-29 17:10:05
…
Historical broadcasts summary [background]:

detail（詳情）部分包含最近 50 個前臺廣播和最近 50 個后臺廣播的完整信息，以及每個廣播的接收方。

具有 BroadcastRecord 條目的接收方是在運行時注冊的，并且只會被發送到已在運行的進程。
具有 ResolveInfo 條目的接收方是通過清單條目注冊的。ActivityManager 會為每個 ResolveInfo 啟動相應進程（如果相應進程尚未在運行）。

顯示示例

Historical broadcasts [foreground]:
…
Historical broadcasts [background]:
Historical Broadcast background #0:
…
Historical Broadcast background #5:
BroadcastRecord{18dbb16 u0 android.intent.action.USER_PRESENT} to user 0
Intent { act=android.intent.action.USER_PRESENT flg=0x24000010 }
caller=com.android.systemui 2925:com.android.systemui/u0a27 pid=2925 uid=10027
enqueueClockTime=2015-10-29 17:10:55 dispatchClockTime=2015-10-29 17:10:55
dispatchTime=-2s321ms (0 since enq) finishTime=-2s320ms (+1ms since disp)
Receiver #0: BroadcastFilter{8181cc1 u-1 ReceiverList{5d929a8 902 system/1000/u-1 local:eca4dcb}}
Receiver #1: BroadcastFilter{6371c97 u-1 ReceiverList{2938b16 902 system/1000/u-1 local:840b831}}
…
Receiver #19: BroadcastFilter{93f16b u0 ReceiverList{5c61eba 17016 com.google.android.gm/10079/u0 remote:24083e5}}
…
Historical Broadcast background #37:
BroadcastRecord{7f6dd6 u0 android.hardware.action.NEW_PICTURE} to user 0
Intent { act=android.hardware.action.NEW_PICTURE dat=content://media/external/images/media/6345 flg=0x10 }
caller=com.google.android.GoogleCamera 32734:com.google.android.GoogleCamera/u0a53 pid=32734 uid=10053
enqueueClockTime=2015-10-29 17:09:48 dispatchClockTime=2015-10-29 17:09:49
dispatchTime=-45s720ms (+399ms since enq) finishTime=-45s701ms (+19ms since disp)
resultTo=null resultCode=0 resultData=null
nextReceiver=4 receiver=null
Receiver #0: ResolveInfo{33d2857 com.google.android.gms/com.google.android.libraries.social.mediamonitor.MediaMonitor m=0x608000}
priority=0 preferredOrder=0 match=0x608000 specificIndex=-1 isDefault=false
ActivityInfo:
name=com.google.android.libraries.social.mediamonitor.MediaMonitor
packageName=com.google.android.gms
enabled=true exported=true processName=com.google.android.gms
…
Receiver #1: ResolveInfo{d9edf44 com.google.android.apps.maps/com.google.android.apps.gmm.ugc.clientnotification.StartPhotoTakenNotifierServiceReceiver m=0x608000}
priority=0 preferredOrder=0 match=0x608000 specificIndex=-1 isDefault=false
ActivityInfo:
name=com.google.android.apps.gmm.ugc.clientnotification.StartPhotoTakenNotifierServiceReceiver
packageName=com.google.android.apps.maps
enabled=true exported=true processName=com.google.android.apps.maps
…
Receiver #2: ResolveInfo{743f82d com.google.android.apps.photos/com.google.android.libraries.social.mediamonitor.MediaMonitor m=0x608000}
priority=0 preferredOrder=0 match=0x608000 specificIndex=-1 isDefault=false
ActivityInfo:
name=com.google.android.libraries.social.mediamonitor.MediaMonitor
packageName=com.google.android.apps.photos
enabled=true exported=true processName=com.google.android.apps.photos
…
Receiver #3: ResolveInfo{d5c9162 com.google.android.apps.plus/com.google.android.libraries.social.mediamonitor.MediaMonitor m=0x608000}
priority=0 preferredOrder=0 match=0x608000 specificIndex=-1 isDefault=false
ActivityInfo:
name=com.google.android.libraries.social.mediamonitor.MediaMonitor
packageName=com.google.android.apps.plus
enabled=true exported=true processName=com.google.android.apps.plus
…

查看待發送的廣播

待發送的廣播是指尚未發送的廣播。如果隊列中存在大量廣播，則意味著系統無法足夠快地發送廣播來跟上進度。

顯示示例

Active ordered broadcasts [background]:
Active Ordered Broadcast background #133: // size of queue

查看廣播收聽方

要查看收聽某個廣播的接收方列表，請查看 dumpsys activity broadcasts 中的 Receiver Resolver Table。以下示例顯示了收聽 USER_PRESENT 的所有接收方。

顯示示例

-------------------------------------------------------------------------------
ACTIVITY MANAGER BROADCAST STATE (dumpsys activity broadcasts)
…
Receiver Resolver Table:
Full MIME Types:
…
Wild MIME Types:
…
Schemes:
…
Non-Data Actions:
…
android.intent.action.USER_PRESENT:
BroadcastFilter{8181cc1 u-1 ReceiverList{5d929a8 902 system/1000/u-1 local:eca4dcb}}
BroadcastFilter{6371c97 u-1 ReceiverList{2938b16 902 system/1000/u-1 local:840b831}}
BroadcastFilter{320c00 u0 ReceiverList{d3a6283 902 system/1000/u0 local:799c532}}
BroadcastFilter{e486048 u0 ReceiverList{36fbaeb 902 system/1000/u0 local:5f51e3a}}
BroadcastFilter{22b02 u-1 ReceiverList{b3f744d 902 system/1000/u-1 local:de837e4}}
BroadcastFilter{3e989ab u0 ReceiverList{f8deffa 2981 com.google.process.gapps/10012/u0 remote:26bd225}}
BroadcastFilter{fb56150 u0 ReceiverList{22b7b13 2925 com.android.systemui/10027/u0 remote:c54a602}}
BroadcastFilter{63bbb6 u-1 ReceiverList{ba6c751 3484 com.android.nfc/1027/u-1 remote:5c4a478}}
BroadcastFilter{95ad20d u0 ReceiverList{d8374a4 3586 com.google.android.googlequicksearchbox/10029/u0 remote:feb3737}}
BroadcastFilter{fdef551 u0 ReceiverList{28ca78 3745 com.google.android.gms.persistent/10012/u0 remote:f23afdb}}
BroadcastFilter{9830707 u0 ReceiverList{aabd946 3745 com.google.android.gms.persistent/10012/u0 remote:a4da121}}
BroadcastFilter{83c43d2 u0 ReceiverList{d422e5d 3745 com.google.android.gms.persistent/10012/u0 remote:f585034}}
BroadcastFilter{8890378 u0 ReceiverList{26d2cdb 3745 com.google.android.gms.persistent/10012/u0 remote:dfa61ea}}
BroadcastFilter{7bbb7 u0 ReceiverList{214b2b6 3745 com.google.android.gms.persistent/10012/u0 remote:8353a51}}
BroadcastFilter{38d3566 u0 ReceiverList{de859c1 3745 com.google.android.gms.persistent/10012/u0 remote:e003aa8}}
BroadcastFilter{3435d9f u0 ReceiverList{6e38b3e 3745 com.google.android.gms.persistent/10012/u0 remote:8dd7ff9}}
BroadcastFilter{d0a34bb u0 ReceiverList{5091d4a 3745 com.google.android.gms.persistent/10012/u0 remote:d6d22b5}}
BroadcastFilter{d43c416 u0 ReceiverList{51a3531 3745 com.google.android.gms.persistent/10012/u0 remote:d0b9dd8}}
BroadcastFilter{aabf36d u0 ReceiverList{a88bf84 3745 com.google.android.gms.persistent/10012/u0 remote:a9d6197}}
BroadcastFilter{93f16b u0 ReceiverList{5c61eba 17016 com.google.android.gm/10079/u0 remote:24083e5}}
BroadcastFilter{68f794e u0 ReceiverList{4cb1c49 947 com.google.android.googlequicksearchbox:search/10029/u0 remote:251d250}}
…
MIME Typed Actions:

顯示器爭用

顯示器爭用日志記錄有時可以表明實際的顯示器爭用情況，但通常情況下會表明系統負載過重，從而導致所有進程都變慢了。您可能會在系統日志或事件日志中看到 ART 記錄的長時間占用顯示器的事件。

在系統日志中：

10-01 18:12:44.343 29761 29914 W art : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

在事件日志中：

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

后臺編譯

編譯可能會占用大量資源，而且會加重設備負載。

顯示示例

09-14 06:27:05.670 2508 2587 E ActivityManager: CPU usage from 0ms to 5857ms later:
09-14 06:27:05.670 2508 2587 E ActivityManager: 84% 5708/dex2oat: 81% user + 2.3% kernel / faults: 3731 minor 1 major
09-14 06:27:05.670 2508 2587 E ActivityManager: 73% 2508/system_server: 21% user + 51% kernel / faults: 10019 minor 28 major
09-14 06:27:05.670 2508 2587 E ActivityManager: 1% 3935/com.android.phone: 0.3% user + 0.6% kernel / faults: 2684 minor 2 major

下載 Google Play 商店更新時，編譯可能會在后臺進行。在這種情況下，來自 Google Play 商店應用 (finsky) 和 installd 的消息會顯示在 dex2oat 消息之前。

顯示示例

10-07 08:42:33.725 11051 11051 D Finsky : [1] InstallerTask.advanceState: Prepare to patch com.garmin.android.apps.virb (com.garmin.android.apps.virb) from content://downloads/my_downloads/3602 format 2
10-07 08:42:33.752 495 495 I installd: free_cache(48637657) avail 15111192576
…
10-07 08:42:39.998 2497 2567 I PackageManager.DexOptimizer: Running dexopt (dex2oat) on: /data/app/vmdl436577137.tmp/base.apk pkg=com.garmin.android.apps.virb isa=arm vmSafeMode=false debuggable=false oatDir = /data/app/vmdl436577137.tmp/oat bootComplete=true
…

當某個應用正在加載尚未編譯的 dex 文件時，編譯也可能會在后臺進行。在這種情況下，您將看不到 finsky 或 installd 日志記錄。

顯示示例

09-14 07:29:20.433 15736 15736 I dex2oat : /system/bin/dex2oat -j4 --dex-file=/data/user/0/com.facebook.katana/app_secondary_program_dex/program-72cef82b591768306676e10161c886b58b34315a308602be.dex.jar --oat-file=/data/user/0/com.facebook.katana/app_secondary_program_dex_opt/program-72cef82b591768306676e10161c886b58b34315a308602be.dex.dex
…
09-14 07:29:25.102 15736 15736 I dex2oat : dex2oat took 4.669s (threads: 4) arena alloc=7MB java alloc=3MB native alloc=29MB free=4MB

敘述

創建問題敘述（如何開始、發生了什么、系統是如何應對的）需要一個固定的事件時間軸。您可以利用錯誤報告中的信息來同步多個日志中的時間軸并確定錯誤報告的確切時間戳。

同步時間軸

錯誤報告會反映多個并行時間軸（系統日志、事件日志、內核日志）以及針對廣播、電池統計信息等的多個專用時間軸。遺憾的是，系統通常會使用不同的時間基準來報告時間軸。

系統日志時間戳和事件日志時間戳采用用戶所用的時區（與大多數其他時間戳一樣）。例如，當用戶點按主屏幕按鈕時，系統日志會報告以下內容：

10-03 17:19:52.939 1963 2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

對于上述操作，事件日志會報告以下內容：

10-03 17:19:54.279 1963 2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

內核 (dmesg) 日志采用不同的時間基準，按距離引導加載程序完成的時間來標記日志內容（以秒為單位）。要按照其他時間表的時間基準記錄此時間表，請搜索“suspend exit”（暫停退出）和“suspend entry”（暫停進入）消息。

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

由于內核日志在暫停狀態下可能不會包含時間，因此您應該分段記錄暫停進入和暫停退出消息之間的日志。此外，內核日志使用 UTC 時區，您必須將其調整為用戶時區。

確定錯誤報告的生成時間

要確定錯誤報告的生成時間，請先查看系統日志 (Logcat) 中的 dumpstate: begin：

10-03 17:19:54.322 19398 19398 I dumpstate: begin

接下來，查看內核日志 (dmesg) 時間戳中的 Starting service 'bugreport' 消息：

<5>[207064.285315] init: Starting service ‘bugreport’…

進行逆向推算以關聯這兩個事件，同時牢記同步時間軸中提到的注意事項。盡管在初始化錯誤報告之后發生了很多活動，但大多數活動并不是非常有用，因為生成錯誤報告這一活動會大大加重系統負載。

電源

事件日志中包含屏幕電源狀態，其中 0 表示屏幕關閉，1 表示屏幕打開，2 表示已鎖屏。

顯示示例

grep screen_toggled bugreport-2015-10-18-16-52-22.txt
10-18 15:05:04.383 992 992 I screen_toggled: 1
10-18 15:05:07.010 992 992 I screen_toggled: 0
10-18 15:23:15.063 992 992 I screen_toggled: 1
10-18 15:23:25.684 992 992 I screen_toggled: 0
10-18 15:36:31.623 992 992 I screen_toggled: 1
10-18 15:36:37.660 3283 3283 I screen_toggled: 2

錯誤報告中還包含關于喚醒鎖的統計信息，喚醒鎖是應用開發者采用的一種機制，用于表明其應用需要設備保持開啟狀態。（要詳細了解喚醒鎖，請參閱 PowerManager.WakeLock 和使 CPU 保持運行狀態。）

喚醒鎖總時長統計信息僅跟蹤喚醒鎖實際負責使設備保持喚醒狀態的時間，不包括屏幕處于開啟狀態的時間。此外，如果同時持有多個喚醒鎖，系統會在它們之間分配喚醒鎖時長。

如需直觀呈現電源狀態方面的更多幫助，請使用 Battery Historian（一種 Google 開放源代碼工具，能夠利用 Android 錯誤報告文件分析電池消耗進程）。

程序包

“DUMP OF SERVICE”程序包中包含應用版本（以及其他實用信息）。

顯示示例

…
Packages:
…
Package [com.google.android.gms] (3cf534b):
userId=10013
sharedUser=SharedUserSetting{98f3d28 com.google.uid.shared/10013}
pkg=Package{b8f6a41 com.google.android.gms}
codePath=/system/priv-app/PrebuiltGmsCore
resourcePath=/system/priv-app/PrebuiltGmsCore
legacyNativeLibraryDir=/system/priv-app/PrebuiltGmsCore/lib
primaryCpuAbi=arm64-v8a
secondaryCpuAbi=armeabi-v7a
versionCode=8186448 targetSdk=23
versionName=8.1.86 (2287566-448)
splits=[base]
applicationInfo=ApplicationInfo{5158507 com.google.android.gms}
flags=[ SYSTEM HAS_CODE ALLOW_CLEAR_USER_DATA ]
privateFlags=[ PRIVILEGED ]
dataDir=/data/user/0/com.google.android.gms
supportsScreens=[small, medium, large, xlarge, resizeable, anyDensity]
libraries:
com.google.android.gms
usesOptionalLibraries:
com.android.location.provider
com.google.android.ble
com.android.media.remotedisplay
usesLibraryFiles:
/system/framework/com.android.media.remotedisplay.jar
/system/framework/com.android.location.provider.jar
timeStamp=2015-10-14 15:17:56
firstInstallTime=2015-09-22 14:08:35
lastUpdateTime=2015-10-14 15:17:56
signatures=PackageSignatures{db63be6 [1af63d8]}
installPermissionsFixed=true installStatus=1
pkgFlags=[ SYSTEM HAS_CODE ALLOW_CLEAR_USER_DATA ]
declared permissions:
com.google.android.gms.permission.INTERNAL_BROADCAST: prot=signature, INSTALLED
…
com.google.android.gms.permission.CAR_VENDOR_EXTENSION: prot=dangerous, INSTALLED
User 0: installed=true hidden=false stopped=false notLaunched=false enabled=0
disabledComponents:
com.google.android.gms.icing.service.PowerConnectedReceiver
…
com.google.android.gms.icing.proxy.AppsMonitor
enabledComponents:
com.google.android.gms.mdm.receivers.GmsRegisteredReceiver
…
com.google.android.gms.subscribedfeeds.SyncService

進程

錯誤報告中包含大量的進程數據，例如啟動和停止時間、運行時時長、相關服務、oom_adj 得分等。要詳細了解 Android 如何管理進程，請參閱進程和線程。

確定進程運行時

procstats 部分包含有關進程及相關服務已運行時長的完整統計信息。要快速獲得便于用戶閱讀的摘要，請搜索 AGGREGATED OVER 以查看最近 3 個小時或 24 個小時的數據，然后搜索 Summary: 以查看進程列表、這些進程已以各種優先級運行的時長，以及它們使用 RAM 的情況（格式為“最小-平均-最大 PSS”/“最小-平均-最大 USS”）。

顯示示例

-------------------------------------------------------------------------------
DUMP OF SERVICE processinfo:
-------------------------------------------------------------------------------
DUMP OF SERVICE procstats:
COMMITTED STATS FROM 2015-10-19-23-54-56 (checked in):
…
COMMITTED STATS FROM 2015-10-20-03-00-00 (checked in):
…
CURRENT STATS:
…
AGGREGATED OVER LAST 24 HOURS:
System memory usage:
…
Per-Package Stats:
…
Summary:
…
* com.google.android.gms.persistent / u0a13 / v8186448:
TOTAL: 100% (21MB-27MB-40MB/20MB-24MB-38MB over 597)
Top: 51% (22MB-26MB-38MB/21MB-24MB-36MB over 383)
Imp Fg: 49% (21MB-27MB-40MB/20MB-25MB-38MB over 214)
…
Start time: 2015-10-19 09:14:37
Total elapsed time: +1d0h22m7s390ms (partial) libart.so

AGGREGATED OVER LAST 3 HOURS:
System memory usage:
…
Per-Package Stats:
…
Summary:
* com.google.android.gms.persistent / u0a13 / v8186448:
TOTAL: 100% (23MB-27MB-32MB/21MB-25MB-29MB over 111)
Top: 61% (23MB-26MB-31MB/21MB-24MB-28MB over 67)
Imp Fg: 39% (23MB-28MB-32MB/21MB-26MB-29MB over 44)
…
Start time: 2015-10-20 06:49:24
Total elapsed time: +2h46m59s736ms (partial) libart.so

某個進程為什么正在運行？

dumpsys activity processes 部分會列出當前正在運行的所有進程，并按 oom_adj 得分排序（Android 通過為進程分配 oom_adj 值來表明進程的重要性，該值可由 ActivityManager 動態更新）。這種輸出類似于內存快照的輸出，但包含有關是什么導致進程運行的更多信息。在以下示例中，以粗體顯示的條目表明 gms.persistent 進程正在以 vis（可見）優先級運行，因為該系統進程已經與其 NetworkLocationService 綁定。

顯示示例

-------------------------------------------------------------------------------
ACTIVITY MANAGER RUNNING PROCESSES (dumpsys activity processes)
…
Process LRU list (sorted by oom_adj, 34 total, non-act at 14, non-svc at 14):
PERS #33: sys F/ /P trm: 0 902:system/1000 (fixed)
PERS #32: pers F/ /P trm: 0 2925:com.android.systemui/u0a27 (fixed)
PERS #31: pers F/ /P trm: 0 3477:com.quicinc.cne.CNEService/1000 (fixed)
PERS #30: pers F/ /P trm: 0 3484:com.android.nfc/1027 (fixed)
PERS #29: pers F/ /P trm: 0 3502:com.qualcomm.qti.rcsbootstraputil/1001 (fixed)
PERS #28: pers F/ /P trm: 0 3534:com.qualcomm.qti.rcsimsbootstraputil/1001 (fixed)
PERS #27: pers F/ /P trm: 0 3553:com.android.phone/1001 (fixed)
Proc #25: psvc F/ /IF trm: 0 4951:com.android.bluetooth/1002 (service)
com.android.bluetooth/.hfp.HeadsetService<=Proc{902:system/1000}
Proc # 0: fore F/A/T trm: 0 3586:com.google.android.googlequicksearchbox/u0a29 (top-activity)
Proc #26: vis F/ /SB trm: 0 3374:com.google.android.googlequicksearchbox:interactor/u0a29 (service)
com.google.android.googlequicksearchbox/com.google.android.voiceinteraction.GsaVoiceInteractionService<=Proc{902:system/1000}
Proc # 5: vis F/ /T trm: 0 3745:com.google.android.gms.persistent/u0a12 (service)
com.google.android.gms/com.google.android.location.network.NetworkLocationService<=Proc{902:system/1000}
Proc # 3: vis F/ /SB trm: 0 3279:com.google.android.gms/u0a12 (service)
com.google.android.gms/.icing.service.IndexService<=Proc{947:com.google.android.googlequicksearchbox:search/u0a29}
Proc # 2: vis F/ /T trm: 0 947:com.google.android.googlequicksearchbox:search/u0a29 (service)
com.google.android.googlequicksearchbox/com.google.android.sidekick.main.remoteservice.GoogleNowRemoteService<=Proc{3586:com.google.android.googlequicksearchbox/u0a29}
Proc # 1: vis F/ /T trm: 0 2981:com.google.process.gapps/u0a12 (service)
com.google.android.gms/.tapandpay.hce.service.TpHceService<=Proc{3484:com.android.nfc/1027}
Proc #11: prcp B/ /IB trm: 0 3392:com.google.android.inputmethod.latin/u0a64 (service)
com.google.android.inputmethod.latin/com.android.inputmethod.latin.LatinIME<=Proc{902:system/1000}
Proc #24: svc B/ /S trm: 0 27071:com.google.android.music:main/u0a67 (started-services)
Proc #22: svc B/ /S trm: 0 853:com.qualcomm.qcrilmsgtunnel/1001 (started-services)
Proc # 4: prev B/ /LA trm: 0 32734:com.google.android.GoogleCamera/u0a53 (previous)
Proc #23: svcb B/ /S trm: 0 671:com.qualcomm.telephony/1000 (started-services)
Proc #20: cch B/ /CE trm: 0 27659:com.android.providers.calendar/u0a2 (provider)
com.android.providers.calendar/.CalendarProvider2<=Proc{27697:com.google.android.calendar/u0a40}
Proc #13: cch B/ /CE trm: 0 653:com.google.android.gms.wearable/u0a12 (cch-empty)
Proc #10: cch B/ /S trm: 0 4067:com.google.android.talk/u0a62 (cch-started-ui-services)
Proc # 7: cch B/ /S trm: 0 18868:com.google.corp.huddle.android/u0a95 (cch-started-ui-services)
Proc # 6: cch B/ /CA trm: 0 27697:com.google.android.calendar/u0a40 (cch-act)
Proc # 8: cch+1 B/ /CA trm: 0 25675:com.google.android.apps.genie.geniewidget/u0a81 (cch-act)
Proc #16: cch+2 B/ /CE trm: 0 1272:com.google.android.keep/u0a106 (cch-empty)
Proc #15: cch+2 B/ /CE trm: 0 885:android.process.media/u0a9 (cch-empty)
Proc #14: cch+2 B/ /CE trm: 0 15146:android.process.acore/u0a3 (cch-empty)
Proc # 9: cch+3 B/ /CA trm: 0 17016:com.google.android.gm/u0a79 (cch-act)
Proc #19: cch+4 B/ /CE trm: 0 973:com.google.android.apps.maps/u0a66 (cch-empty)
Proc #18: cch+4 B/ /CE trm: 0 1091:com.google.android.apps.photos/u0a71 (cch-empty)
Proc #17: cch+4 B/ /CE trm: 0 1141:com.google.android.apps.plus/u0a74 (cch-empty)
Proc #12: cch+5 B/ /CA trm: 0 22299:com.google.android.apps.dogfood/u0a105 (cch-act)
Proc #21: cch+6 B/ /CE trm: 0 995:com.google.android.partnersetup/u0a18 (cch-empty)>

掃描

我們可以按照以下步驟來確定過度執行藍牙低功耗 (BLE) 掃描的應用：

查找 BluetoothLeScanner 的日志消息：$ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt 07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
在日志消息中找到 PID。在此示例中，“24840”和“24851”分別為 PID（進程 ID）和 TID（線程 ID）。
找到與該 PID 關聯的應用：PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
在此示例中，程序包名稱為 com.badapp。
在 Google Play 上查找該程序包名稱，以找出相應的應用：https://play.google.com/store/apps/details?id=com.badapp。

注意：對于運行 Android 7.0 的設備，系統會收集 BLE 掃描數據，并會將這些活動與初始應用相關聯。有關詳情，請參閱低功耗 (LE) 和藍牙掃描。

總結

以上是生活随笔為你收集整理的Android日志[进阶篇]五-阅读错误报告的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： java通用异常_Java常用异常整理
下一篇：手机上网流量统计_数据统计 | 上半年手

Android

Android日志[进阶篇]五-阅读错误报告

目錄

Logcat

查看事件日志

ANR 和死鎖

找出無響應的應用

顯示示例

顯示示例

查找堆棧跟蹤

顯示示例

查找死鎖

顯示示例

Activity

查看處于聚焦狀態的 Activity

顯示示例

查看進程啟動事件

顯示示例

設備是否發生系統顛簸？

顯示示例

內存

發現內存不足的情況

查看歷史指標

顯示示例

查看系統顛簸指標

顯示示例

顯示示例

獲取內存快照

顯示示例

廣播

查看歷史廣播

顯示示例

顯示示例

查看待發送的廣播

顯示示例

查看廣播收聽方

顯示示例

顯示器爭用

后臺編譯

顯示示例

顯示示例

顯示示例

敘述

同步時間軸

確定錯誤報告的生成時間

電源

顯示示例

程序包

顯示示例

進程

確定進程運行時

顯示示例

某個進程為什么正在運行？

顯示示例

掃描

總結