Fehlerberichte lesen

Fehler sind in jeder Art von Entwicklung unvermeidlich. Fehlerberichte sind entscheidend, um Probleme zu erkennen und zu beheben. Alle Android-Versionen unterstützen das Erstellen von Fehlerberichten mit Android Debug Bridge (ADB). Android-Versionen 4.2 und höher unterstützen eine Entwickleroption zum Erstellen von Fehlerberichten und zum Teilen per E-Mail, Drive usw.

Android-Fehlerberichte enthalten dumpsys-, dumpstate- und logcat-Daten im Textformat (.txt), sodass Sie problemlos nach bestimmten Inhalten suchen können. In den folgenden Abschnitten werden die Komponenten von Fehlerberichten beschrieben, häufige Probleme erläutert und hilfreiche Tipps und grep-Befehle zum Auffinden von Logs im Zusammenhang mit diesen Fehlern gegeben. Die meisten Abschnitte enthalten auch Beispiele für grep-Befehle und ‑Ausgaben und/oder dumpsys-Ausgaben.

Logcat

Das logcat-Log ist ein String-basierter Dump aller logcat-Informationen. Der Teil system ist für das Framework reserviert und hat eine längere Historie als main, das alle anderen Daten enthält. Jede Zeile beginnt in der Regel mit timestamp UID PID TID log-level. In älteren Android-Versionen wird UID möglicherweise nicht aufgeführt.

Ereignisprotokoll ansehen

Dieses Log enthält Stringdarstellungen von binär formatierten Log-Nachrichten. Es ist weniger unübersichtlich als das logcat-Log, aber auch etwas schwieriger zu lesen. Wenn Sie Ereignisprotokolle ansehen, können Sie in diesem Abschnitt nach einer bestimmten Prozess-ID (PID) suchen, um zu sehen, was ein Prozess ausgeführt hat. Das grundlegende Format ist: timestamp PID TID log-level log-tag tag-values.

Folgende Logebenen sind möglich:

  • V: ausführlich
  • D: Debugging
  • I: Information
  • W: Warnung
  • E: Fehler

 

Andere nützliche Event-Log-Tags finden Sie unter /services/core/java/com/android/server/EventLogTags.logtags.

ANRs und Deadlocks

Mithilfe von Fehlerberichten können Sie herausfinden, was „App antwortet nicht“-Fehler (ANR) und Deadlock-Ereignisse verursacht.

Nicht reagierende Apps identifizieren

Wenn eine Anwendung innerhalb eines bestimmten Zeitraums nicht reagiert, was in der Regel auf einen blockierten oder ausgelasteten Hauptthread zurückzuführen ist, beendet das System den Prozess und speichert den Stack in /data/anr. Um den Verursacher eines ANR-Fehlers zu ermitteln, suchen Sie im binären Ereignislog nach am_anr.

Sie können auch im logcat-Log nach ANR in suchen, das weitere Informationen dazu enthält, was zum Zeitpunkt des ANR die CPU verwendet hat.

Stacktraces finden

Häufig finden Sie Stacktraces, die einem ANR-Fehler entsprechen. Achten Sie darauf, dass der Zeitstempel und die PID in den VM-Traces mit dem ANR übereinstimmen, den Sie untersuchen. Prüfen Sie dann den Hauptthread des Prozesses. Hinweise:

  • Der Hauptthread gibt nur an, was der Thread zum Zeitpunkt des ANR-Fehlers ausgeführt hat. Das muss nicht der tatsächliche Grund für den ANR-Fehler sein. Der Stack im Fehlerbericht ist möglicherweise unschuldig. Etwas anderes ist möglicherweise lange Zeit hängengeblieben, aber nicht lange genug, um einen ANR-Fehler auszulösen, bevor es sich wieder gelöst hat.
  • Es können mehrere Gruppen von Stacktraces (VM TRACES JUST NOW und VM TRACES AT LAST ANR) vorhanden sein. Achten Sie darauf, dass Sie den richtigen Bereich aufrufen.

Deadlocks finden

Deadlocks treten oft zuerst als ANRs auf, weil Threads hängen bleiben. Wenn der Deadlock den Systemserver betrifft, wird er vom Watchdog beendet. Das führt zu einem Eintrag im Log, der so aussieht: WATCHDOG KILLING SYSTEM PROCESS. Aus Nutzersicht wird das Gerät neu gestartet. Technisch gesehen handelt es sich jedoch um einen Neustart der Laufzeitumgebung und nicht um einen echten Neustart.

  • Bei einem Laufzeitneustart wird der Systemserver beendet und neu gestartet. Der Nutzer sieht, dass das Gerät zur Startanimation zurückkehrt.
  • Bei einem Neustart ist der Kernel abgestürzt. Der Nutzer sieht, dass das Gerät zum Google-Bootlogo zurückkehrt.

Suchen Sie in den VM-Traces nach einem Muster, bei dem Thread A 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 Nutzer interagieren, um beispielsweise eine Nummer zu wählen, ein Foto aufzunehmen oder eine E‑Mail zu senden. Aus der Sicht eines Fehlerberichts ist eine Aktivität eine einzelne, fokussierte Aufgabe, die ein Nutzer ausführen kann. Daher ist es sehr wichtig, die Aktivität zu finden, die während eines Absturzes im Fokus stand. Aktivitäten (über ActivityManager) führen Prozesse aus. Wenn Sie alle Prozessstopps und -starts für eine bestimmte Aktivität finden, kann das auch bei der Fehlerbehebung helfen.

Fokusaktivitäten ansehen

Wenn Sie sich einen Verlauf der fokussierten Aktivitäten ansehen möchten, suchen Sie nach am_focused_activity.

Prozessstarts ansehen

Wenn Sie sich den Verlauf der Prozessstarts ansehen möchten, suchen Sie nach Start proc.

Feststellen, ob das Gerät überlastet ist

Wenn Sie feststellen möchten, ob das Gerät Thrashing ausführt, suchen Sie nach einer ungewöhnlichen Zunahme der Aktivität um am_proc_died und am_proc_start innerhalb kurzer Zeit.

Arbeitsspeicher

Da Android-Geräte oft nur über begrenzten physischen Arbeitsspeicher verfügen, ist die Verwaltung des Arbeitsspeichers (RAM) von entscheidender Bedeutung. Fehlerberichte enthalten mehrere Hinweise auf wenig Arbeitsspeicher sowie einen Dumpstate, der einen Arbeitsspeicher-Snapshot liefert.

Geringen Arbeitsspeicher ermitteln

Bei wenig Arbeitsspeicher kann es zu einem Thrashing des Systems kommen, da einige Prozesse beendet werden, um Arbeitsspeicher freizugeben, aber weiterhin andere Prozesse gestartet werden. Um Beweise für einen geringen Arbeitsspeicher zu sehen, suchen Sie im binären Ereignisprotokoll nach Konzentrationen von am_proc_died- und am_proc_start-Einträgen.

Ein geringer Arbeitsspeicher kann auch das Wechseln von Aufgaben verlangsamen und Rückkehrversuche verhindern, da die Aufgabe, zu der der Nutzer zurückkehren wollte, beendet wurde. Wenn der Launcher beendet wurde, wird er neu gestartet, wenn der Nutzer die Startbildschirmtaste berührt. Die Protokolle zeigen, dass der Launcher seine Inhalte neu lädt.

Verlaufsindikatoren ansehen

Der Eintrag am_low_memory im binären Ereignislog gibt an, dass der letzte im Cache gespeicherte Prozess beendet wurde. Danach beginnt das System, Dienste zu beenden.

Thrashing-Indikatoren ansehen

Weitere Indikatoren für System-Thrashing (Paging, Direct Reclaim usw.) sind kswapd, kworker und mmcqd, die Zyklen verbrauchen. Beachten Sie, dass die erfassten Bugreports die Indikatoren für das Thrashing beeinflussen können.

ANR-Logs können einen ähnlichen Memory-Snapshot liefern.

Erinnerungs-Snapshot abrufen

Der Memory-Snapshot ist ein Dumpstate, in dem laufende Java- und native Prozesse aufgeführt sind. Weitere Informationen finden Sie unter Gesamte Speicherzuweisungen ansehen. Der Snapshot gibt nur den Zustand zu einem bestimmten Zeitpunkt an. Das System war möglicherweise vor dem Snapshot in einem besseren oder schlechteren Zustand.

Übertragungen

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 Broadcasts empfangen und darauf reagieren können. Fehlerberichte enthalten Informationen zu gesendeten und nicht gesendeten Broadcasts sowie einen Dumpsys aller Empfänger, die auf einen bestimmten Broadcast warten.

Frühere Übertragungen ansehen

Vergangene Übertragungen sind Übertragungen, die bereits gesendet wurden. Sie werden in umgekehrt chronologischer Reihenfolge aufgeführt.

Der Bereich Zusammenfassung enthält eine Übersicht über die letzten 300 Vordergrund- und Hintergrundübertragungen.

Der Abschnitt Detail enthält vollständige Informationen zu den letzten 50 Vordergrund- und Hintergrundübertragungen sowie die Empfänger für jede Übertragung. 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 jedes ResolveInfo, sofern er noch nicht ausgeführt wird.

Aktive Übertragungen ansehen

Aktive Broadcasts sind solche, die noch nicht gesendet wurden. Eine große Zahl in der Warteschlange bedeutet, dass das System die Broadcasts nicht schnell genug senden kann.

Zuhörer von Übertragungen ansehen

Eine Liste der Empfänger, die auf einen Broadcast warten, finden Sie in der Receiver Resolver Table in der dumpsys activity broadcasts. Im folgenden Beispiel werden alle Empfänger angezeigt, die auf USER_PRESENT warten.

Konflikte überwachen

Die Protokollierung von Monitor-Konflikten kann manchmal auf tatsächliche Monitor-Konflikte hinweisen, meistens aber darauf, dass das System so überlastet ist, dass alles verlangsamt wurde. Möglicherweise werden lange Monitor-Ereignisse, die von ART protokolliert wurden, im System- oder Ereignisprotokoll angezeigt.

Im Systemprotokoll:

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]

Kompilierung im Hintergrund

Die Kompilierung kann teuer sein und das Gerät belasten.

Die Kompilierung kann im Hintergrund erfolgen, während Updates für den Google Play Store heruntergeladen werden. In diesem Fall werden Nachrichten aus der Google Play Store App (finsky) und installd vor dex2oat-Nachrichten angezeigt.

Die Kompilierung kann auch im Hintergrund erfolgen, wenn eine Anwendung eine DEX-Datei lädt, die noch nicht kompiliert wurde. In diesem Fall werden keine finsky- oder installd-Logs angezeigt.

Hintergrundinformationen

Um die Geschichte eines Problems zu erzählen (wie es begann, was passiert ist, wie das System reagiert hat), ist eine solide Zeitachse der Ereignisse erforderlich. Mithilfe der Informationen im Fehlerbericht können Sie Zeitachsen in mehreren Logs synchronisieren und den genauen Zeitstempel des Fehlerberichts ermitteln.

Zeitachsen synchronisieren

Ein Fehlerbericht enthält mehrere parallele Zeitachsen: Systemprotokoll, Ereignisprotokoll, Kernel-Protokoll und mehrere spezielle Zeitachsen für Broadcasts, Akkustatistiken usw. Leider werden Zeitachsen oft mit unterschiedlichen Zeitbasen gemeldet.

Die Zeitstempel im System- und Ereignisprotokoll sind in derselben Zeitzone wie der Nutzer (wie die meisten anderen Zeitstempel auch). Wenn ein Nutzer beispielsweise auf die Schaltfläche „Zuhause“ tippt, wird im Systemlog Folgendes gemeldet:

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 wird im Ereignisprotokoll Folgendes angezeigt:

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

Kernel-Logs (dmesg) verwenden eine andere Zeitbasis und kennzeichnen Logeinträge mit Sekunden seit Abschluss des Bootloaders. Wenn Sie diesen Zeitraum für andere Zeiträume registrieren möchten, suchen Sie nach Nachrichten vom Typ suspend exit und 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

Da Kernel-Logs möglicherweise keine Zeitangabe enthalten, wenn das Gerät im Ruhezustand ist, sollten Sie das Log zwischen den Nachrichten zum Eintreten und Beenden des Ruhezustands stückweise registrieren. Außerdem wird in Kernel-Logs die UTC-Zeitzone verwendet. Diese muss an die Zeitzone des Nutzers angepasst werden.

Zeitpunkt des Fehlerberichts ermitteln

Um festzustellen, wann ein Fehlerbericht erstellt wurde, suchen Sie zuerst im Systemlog (Logcat) nach dumpstate: begin:

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

Prüfen Sie als Nächstes die Zeitstempel im Kernel-Log (dmesg) für die Starting service 'bugreport'-Meldung:

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

Gehen Sie rückwärts vor, um die beiden Ereignisse in Beziehung zu setzen. Beachten Sie dabei die Einschränkungen, die unter Zeitachsen synchronisieren aufgeführt sind. Nach dem Starten des Fehlerberichts passiert viel, aber die meisten Aktivitäten sind nicht sehr nützlich, da das Erstellen des Fehlerberichts das System erheblich belastet.

Leistung

Das Ereignisprotokoll enthält den Status der Displaystromversorgung. Dabei steht 0 für „Display aus“, 1 für „Display an“ und 2 für „Keyguard abgeschlossen“.

Fehlerberichte enthalten auch Statistiken zu Wake Locks. Das ist ein Mechanismus, mit dem App-Entwickler angeben, dass ihre App das Gerät eingeschaltet lassen muss. Weitere Informationen zu Wakelocks finden Sie unter PowerManager.WakeLock und CPU aktiv halten.

Die aggregierten Statistiken zur Dauer von Wakelocks erfassen nur die Zeit, in der ein Wakelock tatsächlich dafür verantwortlich ist, dass das Gerät aktiv bleibt, und nicht die Zeit, in der der Bildschirm eingeschaltet ist. Wenn mehrere Wakelocks gleichzeitig gehalten werden, wird die Wakelock-Dauer auf diese Wakelocks verteilt.

Battery Historian ist ein Open-Source-Tool von Google, mit dem Sie den Akkuverbrauch anhand von Android-Fehlerberichtsdateien analysieren können.

Pakete

Der Bereich 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, Laufzeit, zugehörige Dienste, oom_adj-Punktzahl usw. Weitere Informationen dazu, wie Android Prozesse verwaltet, finden Sie unter Prozesse und Threads.

Prozesslaufzeit bestimmen

Der Abschnitt procstats enthält vollständige Statistiken zur Laufzeit von Prozessen und zugehörigen Diensten. Eine kurze, für Menschen lesbare Zusammenfassung erhalten Sie, wenn Sie nach AGGREGATED OVER suchen, um Daten aus den letzten drei oder 24 Stunden aufzurufen. Suchen Sie dann nach Summary:, um die Liste der Prozesse, die Dauer der Ausführung dieser Prozesse mit verschiedenen Prioritäten und die RAM-Nutzung im Format „min–durchschnittlich–max PSS/min–durchschnittlich–max USS“ aufzurufen.

Gründe für die Ausführung eines Prozesses

Im Bereich dumpsys activity processes werden alle derzeit laufenden Prozesse nach oom_adj-Wert sortiert aufgeführt. Android gibt die Wichtigkeit eines Prozesses an, indem dem Prozess ein oom_adj-Wert zugewiesen wird, der von ActivityManager dynamisch aktualisiert werden kann. Die Ausgabe ähnelt der eines Speichersnapshots, enthält aber zusätzliche Informationen dazu, was den Prozess auslöst. Im folgenden Beispiel geben 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

So ermitteln Sie, welche Apps übermäßig viele Bluetooth Low Energy-Scans (BLE) durchführen:

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

    In diesem Beispiel lautet der Paketname com.badapp.

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

Hinweis: Bei Geräten mit Android 7.0 werden Daten für BLE-Scans erhoben und diese Aktivitäten werden der initiierenden Anwendung zugeordnet. Weitere Informationen finden Sie unter Low Energy (LE) und Bluetooth-Scans.