讀取錯誤報告

錯誤回報都是所有類型的開發中的實際錯誤,而錯誤報告 是找出及解決問題的關鍵所有 Android 版本支援 擷取錯誤報告的 Debug Bridge (ADB);Android 4.2 以上版本支援 開發人員 提供取得錯誤報告,並透過電子郵件、雲端硬碟等分享

Android 錯誤報告包含 dumpsysdumpstatelogcat 格式的文字 (.txt) 資料,方便您輕鬆搜尋 特定內容。以下各節將詳細說明錯誤報告元件。 說明常見問題,並提供實用提示和 grep 指令 以尋找與這些錯誤相關的記錄檔大部分部分也提供範例 ,適用於 grep 指令和輸出和/或 dumpsys 輸出內容。

Logcat

logcat 記錄是所有 logcat 以字串為基礎的傾印 可能不準確或不適當系統部分會保留給架構, 記錄的時間比 main (包含所有其他項目) 更長。 每一行通常以 timestamp UID PID TID log-level 開頭。 但 UID 可能不會顯示在舊版 Android 中。

查看事件記錄

這份記錄包含二進位格式記錄訊息的字串形式。這項服務 的雜訊比 logcat 記錄小,但又不易讀取。 查看事件記錄時,您可以在這個部分搜尋特定程序 ID (PID),瞭解程序執行了哪些作業。基本格式如下: timestamp PID TID log-level log-tag tag-values

記錄層級包括:

  • V:詳細
  • D:偵錯
  • I:資訊
  • W:警告
  • E:錯誤

 

如需其他實用的事件紀錄標記,請參閱 /services/core/java/com/android/server/EventLogTags.logtags

ANR 與死結

錯誤報告可協助你找出原因 帶入個人需求 無回應 (ANR) 錯誤和死結事件。

找出無回應的應用程式

如果應用程式未在特定時間內回應,通常是因為 系統會終止程序並將堆疊轉儲 /data/anr。如要找出 ANR 背後的根本原因, am_anr

您也可以在 logcat 記錄中針對 ANR in 執行雜訊。 ,進一步瞭解 ANR 發生時的 CPU 使用率。

尋找堆疊追蹤

您通常可以找到與 ANR 對應的堆疊追蹤。請確認 VM 追蹤記錄的時間戳記和 PID,與您正在調查的 ANR 事件相符, 檢查處理程序的主執行緒注意事項:

  • 主要執行緒只會告訴您執行緒在進行執行緒作業時正在執行的工作 ANR 事件:這不一定代表發生 ANR 的真正原因。(在 錯誤報告可能屬於無害;可能有其他東西停滯不前 但由於 ANR 的時間不夠長,所以不會變得緩慢。
  • 超過一組堆疊追蹤 (VM TRACES JUST NOWVM TRACES AT LAST ANR) 可能存在。請務必查看 找到正確的部分

找出死結

由於執行緒卡住了,死結現象通常會以 ANR 的形式呈現。如果 系統伺服器發生死結時 監控程式最終會終止它 會使記錄中的項目類似: WATCHDOG KILLING SYSTEM PROCESS。從使用者的角度來看 會重新啟動,但嚴格來說這屬於執行階段重新啟動,而非 完全重新啟動。

  • 執行階段重新啟動時,系統伺服器會停止運作, 重新啟動;使用者看到裝置返回開機動畫時。
  • 重新啟動時,核心會異常終止。使用者會看到 裝置回到 Google 開機標誌。

如要找出死結,請查看 VM 追蹤記錄區段,尋找執行緒 A 的模式 等待執行緒 B 保留的項目,而這又正在等待系統等候 由執行緒 A 保留

活動

活動 應用程式元件,可提供使用者與執行動作互動的畫面 例如撥打電話號碼、拍照、傳送電子郵件等 報告的觀點 活動 具有單一焦點,使用者可自行操作,因此找出活動 當機率相當重要活動 (透過 ActivityManager) 因此,為特定活動尋找所有程序都會停止和開始 也有助於排解問題

查看聚焦活動

如要查看聚焦活動的歷史記錄,請搜尋 am_focused_activity

開始查看程序

如要查看程序啟動記錄,請搜尋 Start proc

判斷裝置是否閃爍

可判斷裝置是否 thrashing、 檢查 am_proc_died 和 很快就完成了 am_proc_start

記憶體

由於 Android 裝置通常具有有限的實體記憶體,因此要管理 因此至關重要錯誤報告內含數個指標 以及提供記憶體快照的轉儲狀態

找出低記憶體

記憶體不足可能會導致系統當機,因為這會終止部分程序無法使用 但會繼續啟動其他程序檢視 記憶體不足,請檢查 am_proc_died 濃度是否濃度偏低 二進位事件記錄中的 am_proc_start 個項目。

記憶體不足也會降低工作切換速度,進而減少傳回嘗試的情況 (因為 嘗試返回的工作就會終止)。如果啟動器 而使用者輕觸主畫面按鈕,記錄顯示 啟動器會重新載入其內容。

查看歷來指標

二進位事件記錄中的 am_low_memory 項目代表 上次快取程序已結束。之後,系統會開始終止服務。

查看輾轉現象指標

其他有關系統輾轉現象 (分頁、直接索回等) 包括 kswapdkworkermmcqd 正在使用 週期。(請注意,收集的錯誤報告可能會影響輾轉現象 指標)。

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

取得記憶體快照

記憶體快照是一個轉儲狀態,會列出執行 Java 和原生 程序 (詳情請參閱 檢視 整體記憶體配置)。請注意,快照僅會顯示 特定時間點的客群;系統可能表現得更好 (或甚至更糟) 然後繪製在快照前面

廣播

應用程式會產生廣播訊息,在目前的 或其他應用程式訂閱特定 訊息,讓他們能夠聽取及回應廣播訊息。 錯誤報告包含已傳送和未傳送廣播的相關資訊,例如 以及監聽特定廣播訊息的所有接收器

查看歷來廣播內容

過往廣播訊息是指已收到的內容,列於 由新到舊排序

「摘要」部分會顯示最近 300 項的總覽資訊 前景廣播和最近 300 次背景廣播訊息。

「detail」部分包含 最近 50 次的前景廣播和最近 50 次背景廣播訊息,以及 每個廣播訊息的接收器。具備以下特性的接收器:

  • BroadcastFilter 個項目在執行階段註冊並傳送 只能在已執行的程序上執行
  • 已透過資訊清單項目註冊 ResolveInfo 個項目。 如果符合下列條件,ActivityManager 會為每個 ResolveInfo 啟動程序 目前並未運作

查看進行中的廣播訊息

主動廣播是指尚未傳送的廣播訊息。這個數字中的 佇列表示系統發送廣播速度不夠快,無法跟上一樣。

查看廣播事件監聽器

如要查看監聽廣播的接收器清單,請檢查接收器 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) 記錄使用不同的時間基準,為記錄項目加上標記 。為了向其他 時間量表,請搜尋「suspend 結束」和「suspendEntry」訊息:

<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

核心記錄檔可能不會包含暫停期間的時間,因此, 同時登錄暫停進入和離開訊息之間的紀錄。 此外,核心記錄採用世界標準時間時區,因此必須根據使用者需求進行調整 時區。

找出錯誤報告時間

如想判斷錯誤報告的取得時間,請先查看系統記錄 (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 代表鍵盤保護完成。

錯誤報告也會納入與 Wake Lock 相關的統計資料;Wake Lock 是 應用程式開發人員,指出應用程式需要的裝置搭載 繼續保持。(如要進一步瞭解 Wake Lock,請參閱 PowerManager.WakeLockKeep 例如 CPU)。

匯總 Wake Lock 持續時間統計資料「只會」追蹤 那麼 Wake Lock 就其實是讓裝置保持喚醒狀態 不要加入螢幕開啟的時間。此外,如果 同時按住多個 Wake Lock,而 Wake Lock 的持續時間 分散在 Wake Lock 中

如需進一步瞭解如何以圖表呈現電源狀態,請使用 Battery Historian Google 開放原始碼工具:運用 Android 錯誤報告分析電池消費者 檔案。

套件

DUMP OF SERVICE package 區段包含應用程式版本 (以及 資訊)。

處理程序

錯誤報告包含開始和啟動等大量程序資料, 停止時間、執行階段長度、關聯服務、oom_adj 分數等 如要進一步瞭解 Android 如何管理程序,請參閱 程序 和 Threads

決定程序執行階段

procstats」區段提供時間長度的完整統計資料 個程序和相關服務都正在執行。快速、人類可讀 摘要, 搜尋「AGGREGATED OVER」以查看 最後三或 24 小時,再搜尋 Summary: 即可查看清單 程序、程序在不同優先順序中的執行時間長度,以及 RAM 用量,格式為 min-平均-max PSS/min-average-max 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) 和藍牙掃描功能