閱讀錯誤報告

錯誤在任何類型的開發中都是現實的,錯誤報告對於識別和解決問題至關重要。所有版本的Android都支援使用Android調試橋(adb)捕獲錯誤報告; Android 4.2 及更高版本支援開發者選項,用於取得錯誤報告並透過電子郵件、雲端硬碟等進行共享。

Android 錯誤報告包含文字 (.txt) 格式的dumpsysdumpstatelogcat數據,讓您可以輕鬆搜尋特定內容。以下部分詳細介紹了錯誤報告組件,描述了常見問題,並提供了有用的提示和grep命令來查找與這些錯誤相關的日誌。大多數部分還包括grep命令和輸出和/或dumpsys輸出的範例。

日誌貓

logcat日誌是所有logcat資訊的基於字串的轉儲。系統部分是為框架保留的,並且比包含其他所有內容的main 部分具有更長的歷史。每行通常以timestamp UID PID TID log-level開頭,但舊版的 Android 中可能不會列出UID

查看事件日誌

此日誌包含二進位格式日誌訊息的字串表示形式。它比logcat日誌噪音小,但也有點難讀。查看事件日誌時,您可以在此部分搜尋特定進程 ID (PID),以查看進程正在執行的操作。基本格式為: timestamp PID TID log-level log-tag tag-values

日誌等級包括以下內容:

  • 五:冗長
  • D:調試
  • 一:訊息
  • W:警告
  • E:錯誤

有關其他有用的事件日誌標籤,請參閱/services/core/java/com/android/server/EventLogTags.logtags

ANR 和死鎖

錯誤報告可以幫助您確定導致應用程式無回應 (ANR)錯誤和死鎖事件的原因。

識別無響應的應用程式

當應用程式在一定時間內沒有回應時(通常是由於主執行緒阻塞或繁忙),系統會終止該進程並將堆疊轉儲到/data/anr 。要發現 ANR 背後的罪魁禍首,請在二進位事件日誌中 grep 查找am_anr

您也可以在logcat日誌ANR in ,其中包含有關 ANR 發生時 CPU 使用情況的更多資訊。

查找堆疊追蹤

您經常可以找到與 ANR 相對應的堆疊追蹤。確保虛擬機器追蹤上的時間戳記和 PID 與您正在調查的 ANR 匹配,然後檢查進程的主線程。記住:

  • 主執行緒僅告訴您發生 ANR 時執行緒正在做什麼,這可能對應也可能不對應 ANR 的真正原因。 (錯誤報告中的堆疊可能是無辜的;其他東西可能已經被卡住了很長一段時間——但還沒有足夠長的時間來ANR——然後才被解除卡住。)
  • 可能存在不只一組堆疊追蹤( VM TRACES JUST NOWVM TRACES AT LAST ANR )。確保您查看的是正確的部分。

查找死鎖

死鎖通常首先表現為 ANR,因為線程被卡住。如果死鎖發生在系統伺服器上,看門狗最終將殺死它,從而導致日誌中出現類似以下內容的條目: WATCHDOG KILLING SYSTEM PROCESS 。從使用者的角度來看,設備會重新啟動,儘管從技術上講,這是運行時重新啟動而不是真正的重新啟動。

  • 運行時重新啟動中,系統伺服器死亡並重新啟動;使用者看到設備返回到啟動動畫。
  • 重新啟動時,核心崩潰了;使用者看到裝置返回 Google 啟動徽標。

要查找死鎖,請檢查 VM 追蹤部分以了解線程 A 等待線程 B 持有的內容,而線程 B 又等待線程 A 持有的內容的模式。

活動

活動是一個應用程式元件,它提供用戶互動的螢幕來執行一些操作,例如撥打號碼、拍照、發送電子郵件等。從錯誤報告的角度來看,活動是用戶可以執行的單一、集中的操作,這使得定位崩潰期間的焦點活動非常重要。活動(透過 ActivityManager)運行進程,因此尋找給定活動的所有進程停止和啟動也可以幫助故障排除。

查看重點活動

若要查看重點活動的歷史記錄,請搜尋am_focused_activity

檢視進程啟動

若要查看進程啟動的歷史記錄,請搜尋Start proc

確定設備是否抖動

若要確定裝置是否出現抖動,請檢查短時間內am_proc_diedam_proc_start周圍的活動是否異常增加。

記憶

由於 Android 裝置的實體記憶體通常有限,因此管理隨機存取記憶體 (RAM) 至關重要。錯誤報告包含多個記憶體不足的指示器以及提供記憶體快照的轉儲狀態。

識別低內存

記憶體不足可能會導致系統崩潰,因為它會殺死一些進程以釋放內存,但會繼續啟動其他進程。若要查看記憶體不足的確鑿證據,請檢查二進位事件日誌中am_proc_diedam_proc_start條目的集中情況。

記憶體不足也會減慢任務切換速度並阻礙返回嘗試(因為使用者嘗試返回的任務已終止)。如果啟動器被終止,當使用者觸摸主頁按鈕時它會重新啟動,並且日誌顯示啟動器重新載入其內容。

查看歷史指標

二進位事件日誌中的am_low_memory條目指示最後一個快取的程序已死亡。之後,系統開始殺死服務。

查看抖動指標

系統抖動的其他指標(分頁、直接回收等)包括kswapdkworkermmcqd消耗週期。 (請記住,收集的錯誤報告可能會影響抖動指標。)

ANR日誌可以提供類似的記憶體快照。

取得記憶體快照

記憶體快照是一個轉儲狀態,其中列出了正在運行的 Java 和本機進程(有關詳細信息,請參閱查看總體記憶體分配)。請記住,快照僅提供特定時刻的狀態;在快照之前,系統可能處於更好(或更差)的狀態。

廣播

應用程式產生廣播以將事件發送到當前應用程式內或發送到另一個應用程式。廣播接收者訂閱特定訊息(透過過濾器),使它們能夠收聽和回應廣播。錯誤報告包含有關已發送廣播和未發送廣播的信息,以及偵聽特定廣播的所有接收器的轉儲系統。

查看歷史廣播

歷史廣播是那些已經發送的廣播,按時間倒序排列。

摘要部分是最近 300 個前台廣播和最近 300 個後台廣播的概述。

詳細資訊部分包含最近 50 個前台廣播和最近 50 個後台廣播的完整信息,以及每個廣播的接收者。接收器具有:

  • BroadcastFilter條目在執行時註冊,並且僅傳送至已執行的進程。
  • ResolveInfo條目是透過清單條目註冊的。如果每個ResolveInfo尚未執行,則 ActivityManager 會啟動該進程。

查看活動廣播

活動廣播是那些尚未發送的廣播。隊列中的數量過多意味著系統無法足夠快地調度廣播以跟上。

查看廣播監聽者

若要查看偵聽廣播的接收器列表,請檢查dumpsys activity broadcasts中的接收器解析器表。以下範例顯示偵聽USER_PRESENT的所有接收器。

監控爭用

監視器爭用日誌記錄有時可以指示實際的監視器爭用,但大多數情況下表示系統負載過高,以至於一切都變慢了。您可能會在系統或事件日誌中看到 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]

後台編譯

編譯可能會很昂貴並且會載入設備。

下載 Google Play 商店更新時,編譯可能會在背景進行。在這種情況下,來自 Google Play 商店應用程式 ( finsky ) 和installd訊息會出現在dex2oat訊息之前。

當應用程式載入尚未編譯的 dex 檔案時,編譯也可能在背景發生。在這種情況下,您將看不到finskyinstalld日誌記錄。

敘述

建立問題的敘述(它是如何開始的、發生了什麼、系統如何反應)需要一個可靠的事件時間表。您可以使用錯誤報告中的資訊同步多個日誌的時間軸並確定錯誤報告的確切時間戳記。

同步時間軸

錯誤報告反映了多個平行時間軸:系統日誌、事件日誌、內核日誌以及用於廣播、電池統計資料等的多個專用時間軸。不幸的是,時間軸通常使用不同的時間基準來報告。

系統和事件日誌時間戳與使用者位於同一時區(大多數其他時間戳記也是如此)。例如,當使用者點擊主頁按鈕時,系統日誌報告:

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

接下來,檢查核心日誌 ( dmesg ) 時間戳中是否Starting service 'bugreport'訊息:

<5>[207064.285315] init: Starting service 'bugreport'...

逆向工作以關聯兩個事件,同時牢記同步時間軸中提到的注意事項。雖然啟動錯誤報告後會發生很多事情,但大多數活動都不是很有用,因為取得錯誤報告的行為會為系統帶來很大的負載。

力量

事件日誌包含螢幕電源狀態,其中 0 為螢幕關閉,1 為螢幕打開,2 為鍵盤保護完成。

錯誤報告還包含有關喚醒鎖定的統計信息,喚醒鎖定是應用程式開發人員用來指示其應用程式需要讓裝置保持開啟的機制。 (有關喚醒鎖的詳細信息,請參閱PowerManager.WakeLockKeep the CPU on 。)

聚合的喚醒鎖定持續時間統計資料追蹤喚醒鎖定實際負責保持裝置喚醒的時間,包括螢幕開啟的時間。此外,如果同時持有多個喚醒鎖定,則喚醒鎖定持續時間將分佈在這些喚醒鎖定上。

如需更多視覺化電源狀態的協助,請使用Battery Historian ,這是一款 Google 開源工具,可使用 Android 錯誤報告檔案來分析電池消耗者。

套餐

DUMP OF SERVICE package部分包含應用程式版本(以及其他有用資訊)。

流程

Bug 報告包含大量的進程數據,包括啟動和停止時間、運行時長、關聯服務、 oom_adj分數等。有關 Android 如何管理進程的詳細信息,請參閱進程和執行緒

確定流程運行時間

procstats部分包含有關進程和關聯服務運行時間的完整統計資料。要獲得快速、可讀的摘要,請搜尋AGGREGATED OVER以查看過去 3 小時或 24 小時的數據,然後搜尋Summary:以查看進程列表、這些進程在不同優先順序下運行的時間及其 RAM使用格式為最小-平均-最大PSS/最小-平均-最大USS。

進程運行的原因

dumpsys activity processes部分列出了所有目前正在運行的進程,按oom_adj分數排序(Android透過為進程分配一個oom_adj值來指示進程重要性,該值可以由ActivityManager動態更新)。輸出與記憶體快照的輸出類似,但包含有關導致進程運行的原因的附加資訊。在下面的範例中,粗體條目表示gms.persistent進程正在以vis (可見)優先權運行,因為系統程序綁定到其NetworkLocationService

掃描

使用以下步驟來識別執行過多藍牙低功耗 (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) 和藍牙掃描