錯誤在任何類型的開發中都是現實——錯誤報告對於識別和解決問題至關重要。所有版本的 Android 都支持使用Android Debug Bridge (adb)捕獲錯誤報告； Android 4.2 及更高版本支持開發者選項，用於獲取錯誤報告並通過電子郵件、雲端硬盤等進行共享。
Android 錯誤報告包含文本 (.txt) 格式的dumpsys 、 dumpstate和logcat數據，使您能夠輕鬆搜索特定內容。以下部分詳細介紹了錯誤報告組件，描述了常見問題，並提供了有用的提示和grep命令以查找與這些錯誤相關的日誌。大多數部分還包括grep命令和輸出和/或dumpsys輸出的示例。
日誌貓
logcat日誌是所有logcat信息的基於字符串的轉儲。系統部分是為框架保留的，並且比包含其他所有內容的main具有更長的歷史。每行通常以timestamp UID PID TID log-level開頭，儘管UID可能不會在舊版本的 Android 中列出。
顯示示例
------ 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 。
日誌級別包括以下內容：
- 五：冗長
- D：調試
- 一：資料
- 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] ...
有關其他有用的事件日誌標籤，請參閱/services/core/java/com/android/server/EventLogTags.logtags 。
ANR 和死鎖
錯誤報告可以幫助您確定導致應用程序無響應 (ANR)錯誤和死鎖事件的原因。
識別無響應的應用程序
當應用程序在一定時間內沒有響應時，通常是由於主線程阻塞或繁忙，系統會終止進程並將堆棧轉儲到/data/anr 。要發現 ANR 背後的罪魁禍首，請在二進制事件日誌中 grep 查找am_anr 。
顯示示例
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 in grep，其中包含有關 ANR 時 CPU 使用情況的更多信息。
顯示示例
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.handleMessage(ActivityThread.java:1405) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:148) at android.app.ActivityThread.main(ActivityThread.java:5417) at java.lang.reflect.Method.invoke!(Native method) at com.android.internal.os.ZygoteInit$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的條目。從用戶的角度來看，設備會重新啟動，儘管從技術上講，這是運行時重新啟動，而不是真正的重新啟動。
- 在運行時重新啟動中，系統服務器死掉並重新啟動；用戶看到設備返回啟動動畫。
- 在重新啟動時，內核已經崩潰；用戶會看到設備返回到 Google 啟動徽標。
要查找死鎖，請檢查 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是用戶可以做的單一的、專注的事情，這使得定位在崩潰期間成為焦點的活動非常重要。活動（通過 ActivityManager）運行流程，因此定位給定活動的所有流程停止和啟動也有助於故障排除。
查看重點活動
要查看重點活動的歷史記錄，請搜索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) 至關重要。錯誤報告包含幾個內存不足的指標以及提供內存快照的轉儲狀態。
識別內存不足
內存不足會導致系統崩潰，因為它會殺死一些進程以釋放內存但繼續啟動其他進程。要查看內存不足的確鑿證據，請檢查二進制事件日誌中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 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獲取內存快照
內存快照是一個轉儲狀態，列出了正在運行的 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)廣播
應用程序生成廣播以在當前應用程序內或向另一個應用程序發送事件。廣播接收器訂閱特定消息（通過過濾器），使它們能夠收聽和響應廣播。錯誤報告包含有關已發送廣播和未發送廣播的信息，以及偵聽特定廣播的所有接收器的轉儲系統。
查看歷史廣播
歷史廣播是那些已經發送的廣播，按時間倒序排列。
摘要部分是最近 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]:
...詳細信息部分包含最後 50 個前台廣播和最後 50 個後台廣播的完整信息，以及每個廣播的接收器。接收器具有：
-
BroadcastFilter條目在運行時註冊，並且只發送到已經運行的進程。 -
ResolveInfo條目是通過清單條目註冊的。如果每個ResolveInfo尚未運行，則 ActivityManager 會啟動該進程。
顯示示例
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中的接收器解析器表。以下示例顯示了所有偵聽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 ) 日誌使用不同的時基，以自引導加載程序完成後的秒數標記日誌項。要將此時間刻度註冊到其他時間刻度，請搜索暫停退出和暫停進入消息：
<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
接下來，檢查Starting service 'bugreport'消息的內核日誌 ( dmesg ) 時間戳：
<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和Keep the CPU on 。）
聚合的喚醒鎖定持續時間統計信息僅跟踪喚醒鎖定實際負責保持設備喚醒的時間，不包括屏幕打開的時間。此外，如果同時持有多個喚醒鎖，則喚醒鎖持續時間將分佈在這些喚醒鎖上。
如需更多關於電源狀態可視化的幫助，請使用Battery Historian ，這是一種使用 Android 錯誤報告文件分析電池消耗者的 Google 開源工具。
套餐
DUMP OF SERVICE package部分包含應用程序版本（和其他有用信息）。
顯示示例
...
DUMP OF SERVICE package:
...
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流程
Bug 報告包含大量進程數據，包括啟動和停止時間、運行時長、關聯服務、 oom_adj分數等。有關 Android 如何管理進程的詳細信息，請參閱進程和線程。
確定流程運行時間
procstats部分包含有關進程和相關服務已運行多長時間的完整統計信息。如需快速、易於閱讀的摘要，請搜索AGGREGATED OVER以查看過去 3 小時或 24 小時的數據，然後搜索Summary:以查看進程列表、這些進程在不同優先級下運行的時間以及它們的 RAM使用格式為 min-average-max PSS/min-average-max 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) 和藍牙掃描。