Lesen Sie Fehlerberichte

Fehler sind in jeder Art von Entwicklung eine Realität – und Fehlerberichte sind für die Identifizierung und Lösung von Problemen von entscheidender Bedeutung. Alle Android-Versionen unterstützen die Erfassung von Fehlerberichten mit Android Debug Bridge (adb) ; Android-Versionen 4.2 und höher unterstützen eine Entwickleroption zum Empfangen 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 detailliert beschrieben, häufige Probleme beschrieben und hilfreiche Tipps und grep Befehle zum Auffinden von Protokollen gegeben, die mit diesen Fehlern verknüpft 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 der Hauptteil , der alles andere enthält. Jede Zeile beginnt normalerweise mit timestamp UID PID TID log-level , obwohl die UID in älteren Android-Versionen möglicherweise nicht aufgeführt ist.

Sehen Sie sich das Ereignisprotokoll an

Dieses Protokoll enthält Zeichenfolgendarstellungen binär formatierter Protokollmeldungen. Es ist weniger laut als das logcat Protokoll, aber auch etwas schwerer 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 Grundformat ist: timestamp PID TID log-level log-tag tag-values .

Zu den Protokollebenen gehören:

  • 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

Mithilfe von Fehlerberichten können Sie ermitteln, was ANR-Fehler (Application Not Responding) und Deadlock-Ereignisse verursacht.

Identifizieren Sie nicht reagierende Apps

Wenn eine Anwendung nicht innerhalb einer bestimmten Zeit antwortet, normalerweise aufgrund eines blockierten oder ausgelasteten Hauptthreads, bricht das System den Prozess ab und speichert den Stapel in /data/anr . Um den Schuldigen hinter einer ANR zu ermitteln, 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 des ANR die CPU beanspruchte.

Finden Sie Stapelspuren

Oftmals findet man Stack-Traces, die einem ANR entsprechen. Stellen Sie sicher, dass der Zeitstempel und die PID auf 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 getan hat, was möglicherweise mit der wahren Ursache der ANR übereinstimmt oder auch nicht. (Der Stapel im Fehlerbericht ist möglicherweise unschuldig; etwas anderes könnte schon lange 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.

Finden Sie Deadlocks

Deadlocks erscheinen oft zuerst als ANRs, weil Threads stecken bleiben. Wenn der Deadlock den Systemserver trifft, beendet ihn der Watchdog schließlich, was zu einem Eintrag im Protokoll führt, der dem folgenden ähnelt: WATCHDOG KILLING SYSTEM PROCESS . Aus Benutzersicht wird das Gerät neu gestartet, obwohl es sich technisch gesehen eher um einen Laufzeitneustart als um einen echten Neustart handelt.

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

Um Deadlocks zu finden, überprüfen Sie die VM-Ablaufverfolgungsabschnitte auf ein 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 Benutzer interagieren können, um beispielsweise eine Nummer zu wählen, ein Foto aufzunehmen, eine E-Mail zu senden usw. Aus der Sicht eines Fehlerberichts ist eine Aktivität eine einzelne, fokussierte Sache, die ein Benutzer tun kann Daher ist es sehr wichtig, die Aktivität zu lokalisieren, die während eines Absturzes im Fokus stand. Aktivitäten (über ActivityManager) führen Prozesse aus. Daher kann die Lokalisierung aller Prozessstopps und -starts für eine bestimmte Aktivität auch bei der Fehlerbehebung hilfreich sein.

Sehen Sie sich fokussierte Aktivitäten an

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

Der Ansichtsprozess beginnt

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

Stellen Sie fest, ob das Gerät ausfällt

Um festzustellen, ob das Gerät überlastet ist, überprüfen Sie, ob in kurzer Zeit ein ungewöhnlicher Anstieg der Aktivität um am_proc_died und am_proc_start auftritt.

Erinnerung

Da Android-Geräte häufig über einen 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 einen Speicher-Snapshot bereitstellt.

Identifizieren Sie wenig Speicher

Wenig Arbeitsspeicher kann dazu führen, dass das System überlastet wird, da einige Prozesse beendet werden, um Arbeitsspeicher freizugeben, andere Prozesse jedoch weiterhin gestartet werden. Um bestätigende Beweise für wenig Arbeitsspeicher anzuzeigen, prüfen Sie, ob im binären Ereignisprotokoll eine Konzentration der Einträge am_proc_died “ und „ am_proc_start vorhanden ist.

Wenig Arbeitsspeicher kann auch den Aufgabenwechsel verlangsamen und Rückkehrversuche vereiteln (weil die Aufgabe, zu der der Benutzer zurückkehren wollte, abgebrochen wurde). Wenn der Launcher beendet wurde, startet er neu, wenn der Benutzer die Home-Taste berührt, und Protokolle zeigen, dass der Launcher seinen Inhalt neu lädt.

Historische Indikatoren anzeigen

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

Sehen Sie sich Thrashing-Indikatoren an

Weitere Indikatoren für Systemüberlastung (Paging, direkte Wiederherstellung usw.) sind die Verbrauchszyklen kswapd , kworker und mmcqd . (Bedenken Sie, dass der gesammelte Fehlerbericht Thrashing-Indikatoren beeinflussen kann.)

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

Machen Sie einen Erinnerungs-Schnappschuss

Der Speicher-Snapshot ist ein Dumpstate, der laufende Java- und native Prozesse auflistet (Einzelheiten finden Sie unter Anzeigen der gesamten Speicherzuordnungen ). Beachten Sie, dass der Schnappschuss nur den Zustand zu einem bestimmten Zeitpunkt wiedergibt; Möglicherweise war das System 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. Rundfunkempfänger abonnieren bestimmte Nachrichten (über Filter) und können so eine Sendung sowohl abhören als auch darauf reagieren. Fehlerberichte enthalten Informationen über gesendete und nicht gesendete Broadcasts sowie eine Übersicht über alle Empfänger, die eine bestimmte Broadcast hören.

Sehen Sie sich historische Sendungen an

Als historische Sendungen werden bereits gesendete Sendungen bezeichnet, die in umgekehrter chronologischer Reihenfolge aufgeführt sind.

Der Zusammenfassungsbereich ist eine Übersicht über die letzten 300 Vordergrundübertragungen und die letzten 300 Hintergrundübertragungen.

Der Detailbereich enthält vollständige Informationen zu den letzten 50 Vordergrundsendungen und den 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 , sofern diese noch nicht ausgeführt wird.

Aktive Sendungen anzeigen

Aktive Sendungen sind solche, die noch gesendet werden müssen. Eine große Anzahl in der Warteschlange bedeutet, dass das System die Broadcasts nicht schnell genug versenden kann, um mitzuhalten.

Rundfunkhörer anzeigen

Um eine Liste der Empfänger anzuzeigen, die auf eine Übertragung warten, überprüfen Sie die Receiver-Resolver-Tabelle in der dumpsys activity broadcasts . Im folgenden Beispiel werden alle Empfänger angezeigt, die auf USER_PRESENT warten.

Überwachen Sie Konflikte

Die Protokollierung von Monitorkonflikten kann manchmal auf einen tatsächlichen Monitorkonflikt hinweisen, weist jedoch meistens darauf hin, dass das System so ausgelastet ist, dass alles langsamer geworden ist. Möglicherweise werden von ART protokollierte Langzeitüberwachungsereignisse 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]

Hintergrundzusammenstellung

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

Die Kompilierung kann im Hintergrund erfolgen, wenn Updates für den Google Play Store heruntergeladen werden. In diesem Fall werden Nachrichten von 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 wird die Protokollierung von finsky oder installd nicht angezeigt.

Erzählung

Um die Beschreibung eines Problems zu erstellen (wie es begann, was passiert ist, wie das System reagiert hat), ist eine solide Zeitleiste der Ereignisse erforderlich. Sie können die Informationen im Fehlerbericht verwenden, um Zeitleisten über mehrere Protokolle hinweg zu synchronisieren und den genauen Zeitstempel des Fehlerberichts zu ermitteln.

Zeitleisten synchronisieren

Ein Fehlerbericht spiegelt mehrere parallele Zeitleisten wider: Systemprotokoll, Ereignisprotokoll, Kernel-Protokoll und mehrere spezielle Zeitleisten für Broadcasts, Batteriestatistiken usw. Leider werden Zeitleisten oft auf unterschiedlichen Zeitbasen gemeldet.

Die Zeitstempel des Systems und des Ereignisprotokolls liegen in derselben Zeitzone wie der Benutzer (wie auch die meisten anderen Zeitstempel). 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 in anderen Zeitskalen zu registrieren, suchen Sie nach den Nachrichten „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-Protokolle möglicherweise keine Zeit im Suspend-Modus enthalten, sollten Sie das Protokoll stückweise zwischen den Suspend-Einstiegs- und Exit-Meldungen registrieren. Darüber hinaus verwenden Kernel-Protokolle die UTC-Zeitzone und müssen an die Benutzerzeitzone angepasst werden.

Identifizieren Sie die Fehlerberichtszeit

Um festzustellen, wann ein Fehlerbericht erstellt wurde, überprüfen Sie zunächst 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 Meldung Starting service 'bugreport' :

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

Arbeiten Sie rückwärts, um die beiden Ereignisse zu korrelieren, und beachten Sie dabei die im Abschnitt Zeitleisten synchronisieren genannten Vorbehalte. Obwohl nach der Initiierung des Fehlerberichts eine Menge passiert, sind die meisten Aktivitäten nicht sehr nützlich, da die Erstellung des Fehlerberichts das System erheblich belastet.

Leistung

Das Ereignisprotokoll enthält den Betriebsstatus des Bildschirms, wobei 0 für ausgeschalteten Bildschirm, 1 für eingeschalteten Bildschirm und 2 für aktivierte Tastensperre steht.

Fehlerberichte enthalten auch Statistiken zu Wake-Locks, einem Mechanismus, den Anwendungsentwickler verwenden, um anzugeben, dass ihre Anwendung das Gerät eingeschaltet lassen muss. (Ausführliche Informationen zu Wake-Locks finden Sie unter PowerManager.WakeLock und Keep the CPU on .)

Die aggregierten Statistiken zur Wake-Lock-Dauer verfolgen nur die Zeit, die ein Wake-Lock tatsächlich dafür verantwortlich ist, das Gerät wach zu halten, und berücksichtigen nicht die Zeit, in der der Bildschirm eingeschaltet ist. Wenn außerdem mehrere Wakelocks gleichzeitig gehalten werden, wird die Dauer des Wakelocks auf diese Wakelocks verteilt.

Wenn Sie weitere Hilfe bei der Visualisierung des Energiestatus benötigen, verwenden Sie Battery Historian , ein Open-Source-Tool von Google zur Analyse 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 Datenmenge für Prozesse, einschließlich Start- und Stoppzeit, Laufzeitlänge, zugehörige Dienste, oom_adj Score usw. Einzelheiten zur Verwaltung von Prozessen durch Android finden Sie unter Prozesse und Threads .

Prozesslaufzeit ermitteln

Der Abschnitt procstats enthält vollständige Statistiken darüber, wie lange Prozesse und zugehörige Dienste ausgeführt wurden. Für eine schnelle, für Menschen lesbare Zusammenfassung suchen Sie 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 wie viel RAM sie haben Nutzung im Format „Min.-Durchschnitt-Max. PSS/Min.-Durchschnitt-Max. USS“.

Gründe, warum ein Prozess ausgeführt wird

Im Abschnitt dumpsys activity processes werden alle aktuell ausgeführten Prozesse aufgelistet, sortiert nach oom_adj Score (Android zeigt die Prozesswichtigkeit an, indem es dem Prozess einen oom_adj Wert zuweist, der von ActivityManager dynamisch aktualisiert werden kann). Die Ausgabe ähnelt der eines Speicher-Snapshots , enthält jedoch zusätzliche Informationen darüber, was die Ausführung des Prozesses verursacht. Im folgenden Beispiel zeigen die fett gedruckten Einträge an, dass der gms.persistent Prozess mit vis -Priorität (sichtbar) ausgeführt wird, da der Systemprozess an seinen NetworkLocationService gebunden ist.

Scannt

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

  • Suchen Sie nach Protokollnachrichten 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 die PID in den Protokollnachrichten. 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 .

  • Suchen Sie bei Google Play nach dem Paketnamen, 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 ordnet diese Aktivitäten der initiierenden Anwendung zu. Einzelheiten finden Sie unter Low Energy (LE) und Bluetooth-Scans .