Fehlerberichte lesen

Fehler sind eine Realität in jeder Art von Entwicklung – und Fehlerberichte sind entscheidend für die Identifizierung und Lösung von Problemen. Alle Versionen von Android unterstützen das Erfassen von Fehlerberichten mit Android Debug Bridge (adb) ; Android-Versionen 4.2 und höher unterstützen eine Entwickleroption zum Entgegennehmen von Fehlerberichten und Teilen per E-Mail, Drive usw.

Android-Fehlerberichte enthalten dumpsys -, dumpstate - und logcat -Daten im Textformat (.txt), sodass Sie einfach nach bestimmten Inhalten suchen können. Die folgenden Abschnitte beschreiben Komponenten von Fehlerberichten, beschreiben allgemeine Probleme und geben hilfreiche Tipps und grep Befehle zum Auffinden von Protokollen, die mit diesen Fehlern verbunden sind. Die meisten Abschnitte enthalten auch Beispiele für den Befehl und die Ausgabe von grep und/oder die Ausgabe dumpsys .

Logcat

Das logcat -Protokoll ist ein stringbasierter Dump aller logcat -Informationen. Der Systemteil ist für das Framework reserviert und hat eine längere Historie als main , der alles andere enthält. Jede Zeile beginnt normalerweise mit dem timestamp UID PID TID log-level , obwohl die UID in älteren Android-Versionen möglicherweise nicht aufgeführt ist.

Anzeigen des Ereignisprotokolls

Dieses Protokoll enthält Zeichenfolgendarstellungen von Protokollmeldungen im Binärformat. Es ist weniger laut als das logcat Protokoll, aber auch etwas schwieriger zu lesen. Beim Anzeigen von Ereignisprotokollen können Sie diesen Abschnitt nach einer bestimmten Prozess-ID (PID) durchsuchen, um zu sehen, was ein Prozess getan hat. Das grundlegende Format ist: timestamp PID TID log-level log-tag tag-values .

Protokollebenen umfassen Folgendes:

  • V: ausführlich
  • D: debuggen
  • Ich: Informationen
  • W: Warnung
  • E: Fehler

Weitere nützliche Ereignisprotokoll-Tags finden Sie unter /services/core/java/com/android/server/EventLogTags.logtags .

ANRs und Deadlocks

Fehlerberichte können Ihnen dabei helfen, die Ursache von ANR-Fehlern (Application Not Responding) und Deadlock-Ereignissen zu identifizieren.

Identifizieren von nicht reagierenden Apps

Wenn eine Anwendung nicht innerhalb einer bestimmten Zeit antwortet, normalerweise aufgrund eines blockierten oder ausgelasteten Haupt-Threads, beendet das System den Prozess und gibt den Stapel nach /data/anr . Um den Schuldigen hinter einem ANR zu entdecken, suchen Sie im binären Ereignisprotokoll nach am_anr .

Sie können auch im logcat Protokoll nach ANR in suchen, das weitere Informationen darüber enthält, was zum Zeitpunkt der ANR CPU verwendet hat.

Stack-Traces finden

Sie können häufig Stacktraces finden, die einem ANR entsprechen. Stellen Sie sicher, dass der Zeitstempel und die PID in den VM-Traces mit der ANR übereinstimmen, die Sie untersuchen, und überprüfen Sie dann den Hauptthread des Prozesses. Merken Sie sich:

  • Der Hauptthread sagt Ihnen nur, was der Thread zum Zeitpunkt der ANR tat, was der wahren Ursache der ANR entsprechen kann oder nicht. (Der Stapel im Fehlerbericht kann unschuldig sein; etwas anderes könnte lange Zeit hängen geblieben sein – aber nicht lange genug für ANR – bevor es sich gelöst hat.)
  • Möglicherweise ist mehr als ein Satz von Stack-Traces ( VM TRACES JUST NOW und VM TRACES AT LAST ANR ) vorhanden. Stellen Sie sicher, dass Sie den richtigen Abschnitt anzeigen.

Blockaden finden

Deadlocks erscheinen oft zuerst als ANRs, weil Threads stecken bleiben. Wenn der Deadlock den Systemserver trifft, beendet der Watchdog ihn schließlich, was zu einem Eintrag im Protokoll ähnlich dem folgenden führt: WATCHDOG KILLING SYSTEM PROCESS . Aus Benutzersicht wird das Gerät neu gestartet, obwohl dies technisch eher ein Runtime-Neustart als ein echter Neustart ist.

  • Bei einem Runtime -Neustart stirbt der Systemserver und wird neu gestartet; Der Benutzer sieht, wie das Gerät zur Boot-Animation zurückkehrt.
  • Bei einem Neustart ist der Kernel abgestürzt; Der Benutzer sieht, dass das Gerät zum Google-Boot-Logo zurückkehrt.

Um Deadlocks zu finden, überprüfen Sie die VM-Traces-Abschnitte auf ein Muster von Thread A, der auf etwas wartet, das von Thread B gehalten wird, der wiederum auf etwas wartet, das von Thread A gehalten wird.

Aktivitäten

Eine Aktivität ist eine Anwendungskomponente, die einen Bildschirm bereitstellt, mit dem Benutzer interagieren, um beispielsweise eine Nummer zu wählen, ein Foto aufzunehmen, eine E-Mail zu senden usw. Aus der Perspektive eines Fehlerberichts ist eine Aktivität eine einzelne, fokussierte Sache, die ein Benutzer tun kann , was das Auffinden der Aktivität, die während eines Absturzes im Fokus stand, sehr wichtig macht. Aktivitäten (über ActivityManager) führen Prozesse aus, sodass das Auffinden aller Prozessstopps und -starts für eine bestimmte Aktivität auch bei der Fehlerbehebung hilfreich sein kann.

Fokussierte Aktivitäten anzeigen

Um einen Verlauf fokussierter Aktivitäten anzuzeigen, suchen Sie nach am_focused_activity .

Der Anzeigevorgang beginnt

Um einen Verlauf der Prozessstarts anzuzeigen, suchen Sie nach Start proc .

Ruckelt das Gerät?

Um festzustellen, ob das Gerät thrasht , überprüfen Sie in kurzer Zeit, ob die Aktivität um am_proc_died und am_proc_start herum anormal zugenommen hat.

Erinnerung

Da Android-Geräte oft über begrenzten physischen Speicher verfügen, ist die Verwaltung des Arbeitsspeichers (RAM) von entscheidender Bedeutung. Fehlerberichte enthalten mehrere Indikatoren für wenig Arbeitsspeicher sowie einen Dumpstate, der eine Momentaufnahme des Arbeitsspeichers bereitstellt.

Identifizieren von niedrigem Gedächtnis

Wenig Speicher kann dazu führen, dass das System zusammenbricht, da einige Prozesse beendet werden, um Speicher freizugeben, andere Prozesse jedoch weiterhin gestartet werden. Um bestätigende Beweise für wenig Arbeitsspeicher anzuzeigen, suchen Sie nach Konzentrationen von am_proc_died und am_proc_start Einträgen im binären Ereignisprotokoll.

Wenig Arbeitsspeicher kann auch das Wechseln von Aufgaben verlangsamen und Rückkehrversuche vereiteln (weil die Aufgabe, zu der der Benutzer zurückkehren wollte, abgebrochen wurde). Wenn der Launcher beendet wurde, wird er neu gestartet, wenn der Benutzer die Home-Schaltfläche berührt, und Protokolle zeigen, dass der Launcher seinen Inhalt neu lädt.

Anzeigen historischer Indikatoren

Der Eintrag am_low_memory im binären Ereignisprotokoll zeigt an, dass der letzte zwischengespeicherte Prozess gestorben ist. Danach beginnt das System, Dienste zu beenden.

Anzeigen von Thrashing-Indikatoren

Andere Indikatoren für Systemüberlastung (Paging, direkte Rückforderung usw.) sind kswapd , kworker und mmcqd verbrauchende Zyklen. (Denken Sie daran, dass der gesammelte Fehlerbericht die Thrashing-Indikatoren beeinflussen kann.)

ANR-Protokolle können einen ähnlichen Speicher-Snapshot liefern.

Einen Erinnerungs-Schnappschuss bekommen

Der Speicher-Snapshot ist ein Dumpstate, der ausgeführte Java- und native Prozesse auflistet (Einzelheiten finden Sie unter Anzeigen der Gesamtspeicherzuweisungen ). Denken Sie daran, dass der Schnappschuss nur den Zustand zu einem bestimmten Zeitpunkt wiedergibt; Das System war möglicherweise vor dem Snapshot in einem besseren (oder schlechteren) Zustand.

Sendungen

Anwendungen generieren Broadcasts, um Ereignisse innerhalb der aktuellen Anwendung oder an eine andere Anwendung zu senden. Broadcast-Empfänger abonnieren bestimmte Nachrichten (über Filter), sodass sie einen Broadcast sowohl abhören als auch darauf reagieren können. Fehlerberichte enthalten Informationen über gesendete und nicht gesendete Sendungen sowie ein Dumpsys aller Empfänger, die eine bestimmte Sendung hören.

Anzeigen von historischen Sendungen

Historische Sendungen sind bereits gesendete Sendungen in umgekehrter chronologischer Reihenfolge.

Der Zusammenfassungsabschnitt ist eine Übersicht der letzten 300 Vordergrundübertragungen und der letzten 300 Hintergrundübertragungen.

Der Detailbereich enthält vollständige Informationen für die letzten 50 Vordergrundsendungen und die letzten 50 Hintergrundsendungen sowie die Empfänger für jede Sendung. Empfänger mit:

  • BroadcastFilter -Einträge werden zur Laufzeit registriert und nur an bereits laufende Prozesse gesendet.
  • ResolveInfo Einträge werden über Manifesteinträge registriert. Der ActivityManager startet den Prozess für jede ResolveInfo , falls er nicht bereits läuft.

Anzeigen aktiver Übertragungen

Aktive Broadcasts sind diejenigen, die noch gesendet werden müssen. Eine große Anzahl in der Warteschlange bedeutet, dass das System die Rundsendungen nicht schnell genug versenden kann, um Schritt zu halten.

Broadcast-Zuhörer anzeigen

Um eine Liste der Empfänger anzuzeigen, die auf einen Broadcast warten, überprüfen Sie die Receiver-Resolver-Tabelle in der dumpsys activity broadcasts . Das folgende Beispiel zeigt alle Empfänger, die auf USER_PRESENT .

Konflikte überwachen

Die Protokollierung von Monitorkonflikten kann manchmal auf tatsächliche Monitorkonflikte hinweisen, zeigt jedoch meistens an, dass das System so ausgelastet ist, dass sich alles verlangsamt hat. Möglicherweise sehen Sie lange Überwachungsereignisse, die von ART im System- oder Ereignisprotokoll protokolliert wurden.

Im Systemlog:

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

Im Ereignisprotokoll:

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]

Hintergrundzusammenstellung

Das Kompilieren kann teuer sein und das Gerät belasten.

Die Kompilierung kann im Hintergrund erfolgen, wenn Google Play Store-Updates heruntergeladen werden. In diesem Fall erscheinen Nachrichten von der Google Play Store App ( finsky ) und installd vor dex2oat Nachrichten.

Die Kompilierung kann auch im Hintergrund erfolgen, wenn eine Anwendung eine noch nicht kompilierte dex-Datei lädt. In diesem Fall sehen Sie keine finsky oder installd Protokollierung.

Narrativ

Die Beschreibung eines Problems (wie es begann, was passierte, wie das System reagierte) erfordert eine solide Zeitachse der Ereignisse. Sie können die Informationen im Fehlerbericht verwenden, um Zeitachsen über mehrere Protokolle hinweg zu synchronisieren und den genauen Zeitstempel des Fehlerberichts zu bestimmen.

Synchronisieren von Zeitleisten

Ein Fehlerbericht spiegelt mehrere parallele Zeitlinien wider: Systemprotokoll, Ereignisprotokoll, Kernelprotokoll und mehrere spezialisierte Zeitlinien für Broadcasts, Batteriestatistiken usw. Leider werden Zeitlinien oft mit unterschiedlichen Zeitbasen gemeldet.

Die System- und Ereignisprotokoll-Zeitstempel befinden sich in derselben Zeitzone wie der Benutzer (wie die meisten anderen Zeitstempel auch). Wenn der Benutzer beispielsweise auf die Home-Schaltfläche tippt, meldet das Systemprotokoll Folgendes:

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

Für dieselbe Aktion meldet das Ereignisprotokoll Folgendes:

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

Kernel-Protokolle ( dmesg ) verwenden eine andere Zeitbasis und kennzeichnen Protokollelemente mit Sekunden seit Abschluss des Bootloaders. Um diese Zeitskala mit anderen Zeitskalen zu registrieren, suchen Sie nach Nachrichten zum Aussetzen des Ausgangs und zum Aussetzen des Eingangs :

<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

Da Kernel-Protokolle möglicherweise keine Zeit im Suspend-Zustand enthalten, sollten Sie das Protokoll stückweise zwischen den Suspend-Eintritts- und Austrittsmeldungen registrieren. Darüber hinaus verwenden Kernelprotokolle die UTC-Zeitzone und müssen an die Benutzerzeitzone angepasst werden.

Identifizieren der Fehlerberichtszeit

Um festzustellen, wann ein Fehlerbericht erstellt wurde, überprüfen Sie zuerst das Systemprotokoll (Logcat) auf den dumpstate: begin :

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

Überprüfen Sie als Nächstes die Zeitstempel des Kernel-Protokolls ( dmesg ) auf die Nachricht Starting service 'bugreport' :

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

Gehen Sie rückwärts vor, um die beiden Ereignisse zu korrelieren, und beachten Sie dabei die unter Synchronisieren von Zeitachsen erwähnten Vorbehalte. Während nach der Erstellung des Fehlerberichts viel passiert, sind die meisten Aktivitäten nicht sehr nützlich, da das Aufnehmen des Fehlerberichts das System erheblich belastet.

Leistung

Das Ereignisprotokoll enthält den Stromstatus des Bildschirms, wobei 0 für Bildschirm aus, 1 für Bildschirm an und 2 für „Tastensperre beendet“ steht.

Fehlerberichte enthalten auch Statistiken über Wakelocks, einen Mechanismus, der von Anwendungsentwicklern verwendet wird, um anzuzeigen, dass ihre Anwendung das Gerät eingeschaltet lassen muss. (Einzelheiten zu Wakelocks finden Sie unter PowerManager.WakeLock und Keep the CPU on .)

Die aggregierte Wakelock-Dauerstatistik verfolgt nur die Zeit, die ein Wakelock tatsächlich dafür verantwortlich ist, das Gerät wach zu halten, und enthält keine Zeit mit eingeschaltetem Bildschirm. Wenn außerdem mehrere Wakelocks gleichzeitig gehalten werden, wird die Wakelock-Dauer auf diese Wakelocks verteilt.

Wenn Sie weitere Hilfe beim Visualisieren des Energiestatus benötigen, verwenden Sie Battery Historian , ein Open-Source-Tool von Google zum Analysieren von Batterieverbrauchern mithilfe von Android-Fehlerberichtsdateien.

Pakete

Der DUMP OF SERVICE package enthält Anwendungsversionen (und andere nützliche Informationen).

Prozesse

Fehlerberichte enthalten eine große Menge an Daten für Prozesse, einschließlich Start- und Stoppzeit, Laufzeitlänge, zugehörige Dienste, oom_adj Score usw. Einzelheiten dazu, wie Android Prozesse verwaltet, finden Sie unter Prozesse und Threads .

Ermittlung der Prozesslaufzeit

Der Abschnitt procstats enthält vollständige Statistiken darüber, wie lange Prozesse und zugehörige Dienste ausgeführt wurden. Suchen Sie für eine schnelle, für Menschen lesbare Zusammenfassung nach AGGREGATED OVER , um Daten der letzten drei oder 24 Stunden anzuzeigen, und suchen Sie dann nach Summary: :, um die Liste der Prozesse anzuzeigen, wie lange diese Prozesse mit verschiedenen Prioritäten ausgeführt wurden, und deren RAM Nutzung formatiert als Min-Durchschnitt-Maximum PSS/Min-Durchschnitt-Maximum USS.

Warum läuft ein Prozess?

Der Abschnitt dumpsys activity processes listet alle derzeit laufenden Prozesse auf, geordnet nach oom_adj Score (Android zeigt die Wichtigkeit des Prozesses an, indem es dem Prozess einen oom_adj -Wert zuweist, der von ActivityManager dynamisch aktualisiert werden kann). Die Ausgabe ähnelt der eines Speicherabbilds , enthält jedoch zusätzliche Informationen darüber, wodurch der Prozess ausgeführt wird. Im folgenden Beispiel zeigen die fettgedruckten Einträge an, dass der Prozess gms.persistent mit der Priorität vis (sichtbar) ausgeführt wird, da der Systemprozess an seinen NetworkLocationService gebunden ist.

Scans

Verwenden Sie die folgenden Schritte, um Anwendungen zu identifizieren, die übermäßige Bluetooth Low Energy (BLE)-Scans durchführen:

  • Protokollmeldungen für BluetoothLeScanner finden:
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
  • Suchen Sie die PID in den Protokollmeldungen. In diesem Beispiel sind „24840“ und „24851“ PID (Prozess-ID) und TID (Thread-ID).
  • Suchen Sie die mit der PID verknüpfte Anwendung:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}

    In diesem Beispiel lautet der Paketname com.badapp .

  • Schlagen Sie den Paketnamen bei Google Play nach, um die verantwortliche Anwendung zu identifizieren: https://play.google.com/store/apps/details?id=com.badapp .

Hinweis : Bei Geräten mit Android 7.0 sammelt das System Daten für BLE-Scans und verknüpft diese Aktivitäten mit der initiierenden Anwendung. Einzelheiten finden Sie unter Niedrigenergie- (LE) und Bluetooth-Scans .