Fehlerberichte lesen

Fehler sind bei jeder Art von Entwicklung Realität – und Fehlerberichte sind ist entscheidend für die Identifizierung und Lösung von Problemen. Unterstützung aller Android-Versionen Fehlerberichte mit Android-Geräten Debug Bridge (ADB) Android-Version 4.2 und höher unterstützen ein Entwickler Option, Fehlerberichte zu erstellen und per E-Mail, Drive usw. zu teilen.

Android-Fehlerberichte enthalten dumpsys, dumpstate und logcat-Daten im TXT-Format für die einfache Suche nach bestimmten Inhalten suchen. In den folgenden Abschnitten werden die Komponenten des Fehlerberichts beschreibe häufige Probleme und gib hilfreiche Tipps und grep-Befehle um Logs zu finden, die mit diesen Fehlern in Verbindung stehen. Die meisten Abschnitte enthalten auch Beispiele für grep-Befehl und -Ausgabe und/oder dumpsys-Ausgabe.

Logcat

Das Log logcat ist ein stringbasierter Dump aller logcat Informationen. Der Teil system ist dem Framework vorbehalten. hat einen längeren Verlauf als main, die alles andere enthält. Jede Zeile beginnt normalerweise mit timestamp UID PID TID log-level, Allerdings ist UID möglicherweise nicht in älteren Android-Versionen aufgeführt.

Ereignisprotokoll aufrufen

Dieses Log enthält Stringdarstellungen von binär formatierten Lognachrichten. Es ist weniger laut als das logcat-Log, aber auch etwas schwerer zu lesen. Beim Ansehen von Ereignisprotokollen können Sie in diesem Abschnitt nach einer bestimmten Prozess-ID suchen (PID), um zu sehen, was ein Prozess getan hat. Das grundlegende Format lautet: timestamp PID TID log-level log-tag tag-values

Zu den Protokollebenen gehören:

  • V: ausführlich
  • D: Debuggen
  • I: 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 helfen dir, die Ursache zu ermitteln Anwendung Nicht reagieren (ANR) und Deadlock-Ereignisse.

Nicht reagierende Apps erkennen

Wenn eine Anwendung nicht innerhalb einer bestimmten Zeit antwortet, blockiert oder überlastet ist, bricht das System den Prozess ab und gibt den Stack aus /data/anr Um die Ursache eines ANR-Fehlers zu finden, grep für am_anr im binären Ereignisprotokoll.

Sie können auch „grep“ für ANR in im logcat-Log eingeben. Dort finden Sie weitere Informationen dazu, was die CPU zum Zeitpunkt des ANR-Fehlers genutzt hat.

Stacktraces finden

Es gibt häufig Stacktraces, die einem ANR-Fehler entsprechen. Achten Sie darauf, dass die Zeitstempel und PID in den VM-Traces mit dem ANR-Fehler übereinstimmen, den Sie untersuchen, den Hauptthread des Prozesses. Hinweise:

  • Der Hauptthread gibt nur Aufschluss darüber, was der Thread zum Zeitpunkt des ANR-Fehler, der nicht unbedingt der tatsächlichen Ursache des ANR-Fehlers entsprechen kann. (Der Stapel in ist der Fehlerbericht möglicherweise harmlos. kann es sein, dass ein anderes Problem – aber nicht sehr lange genug für einen ANR-Fehler –, bevor das Problem gelöst wird.)
  • Mehr als ein Satz von Stacktraces (VM TRACES JUST NOW und VM TRACES AT LAST ANR) möglicherweise vorhanden ist. Stellen Sie sicher, dass Sie die richtigen Abschnitt zu finden.

Deadlocks finden

Deadlocks werden oft zuerst als ANR-Fehler angezeigt, weil Threads hängen bleiben. Wenn wenn der Deadlock den Systemserver erreicht und der Watchdog es schließlich beendet. Dies führt zu einem Eintrag im Log, der ungefähr so aussieht: WATCHDOG KILLING SYSTEM PROCESS Aus der Perspektive der Nutzenden das Gerät neu startet. Technisch gesehen ist dies jedoch ein Neustart der Laufzeit und kein echten Neustart.

  • Bei einem Neustart der Laufzeit stürzt der Systemserver ab und wird neu gestartet; sieht der Nutzer, dass das Gerät zur Startanimation zurückkehrt.
  • Bei einem Neustart ist der Kernel abgestürzt. sieht der Nutzer Gerät wieder zum Google Boot-Logo zurück.

Suchen Sie in den Abschnitten zu VM-Traces nach einem Muster von Thread A, um Deadlocks zu finden Warten auf etwas, das von Thread B gehalten wird, der wiederum auf etwas wartet die von Thread A geführt wird.

Aktivitäten

Eine Aktivität ist eine Anwendungskomponente, die einen Bildschirm bereitstellt, mit dem Nutzende interagieren können. z. B. eine Nummer wählen, ein Foto aufnehmen, eine E-Mail senden usw. die Berichtsperspektive, ein Aktivität eine einzelne, fokussierte Aufgabe ist, die Nutzende tun können, wodurch das Auffinden der Aktivität, im Fokus war, sehr wichtig. Aktivitäten (über ActivityManager) Prozesse ausführen, sodass die Suche nach allen Prozessen für eine bestimmte Aktivität beendet und gestartet wird. bei der Fehlerbehebung helfen.

Fokussierte Aktivitäten ansehen

Wenn du den Verlauf der fokussierten Aktivitäten sehen möchtest, suche nach am_focused_activity

Start des Aufrufvorgangs

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

Prüfen, ob das Gerät reagiert

Um zu ermitteln, ob das Gerät Prügeln, Achte auf einen ungewöhnlichen Anstieg der Aktivität um am_proc_died und am_proc_start kurz warten.

Arbeitsspeicher

Da der physische Arbeitsspeicher bei Android-Geräten oft begrenzt ist, Random-Access Memory (RAM) ist entscheidend. Fehlerberichte enthalten mehrere Indikatoren sowie einen Dumpstate, der einen Snapshot des Arbeitsspeichers liefert.

Wenig Arbeitsspeicher erkennen

Zu wenig Arbeitsspeicher kann dazu führen, dass das System rast, da einige Prozesse beendet werden, startet aber weiterhin andere Prozesse. Um die stichhaltigen Belege für Arbeitsspeicher niedrig, überprüfe die Konzentrationen von am_proc_died und am_proc_start-Einträge im binären Ereignisprotokoll.

Außerdem kann zu wenig Arbeitsspeicher das Wechseln von Aufgaben verlangsamt werden und die Aufgabe, zu der der Nutzer zurückkehren wollte, beendet wurde). Wenn der Launcher wird es neu gestartet, wenn der Nutzer die Startbildschirmtaste berührt und die Protokolle den den Inhalt des Launchers neu geladen.

Bisherige Indikatoren anzeigen

Der Eintrag am_low_memory im binären Ereignisprotokoll gibt an, der letzte im Cache gespeicherte Prozess abgestürzt ist. Danach beginnt das System, Dienste zu beenden.

Anzeigen von Seitenladeanzeigen

Andere Indikatoren für System-Pging (Pging, direkte Reaktivierung usw.) sind kswapd, kworker und mmcqd verbrauchen Zyklen. (Vergiss nicht, dass der Fehlerbericht, den du erhältst, das Thrashing beeinflussen kann. Indikatoren enthalten.)

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

Arbeitsspeicher-Snapshot abrufen

Der Arbeitsspeicher-Snapshot ist ein Dumpstate, der die ausgeführten Java- und nativen Instanzen auflistet. (Details finden Sie in den Ansicht Arbeitsspeicherzuweisungen insgesamt). Beachten Sie, dass der Snapshot nur den Status zu einem bestimmten Zeitpunkt Das System war möglicherweise in einem besseren (oder schlechteren) vor dem Snapshot einfügen.

Übertragungen

Anwendungen generieren Broadcasts, um Ereignisse innerhalb des aktuellen oder einer anderen Anwendung. Übertragungsempfänger abonnieren bestimmte Nachrichten (über Filter), sodass sie Nachrichten anzuhören und darauf antworten können. Fehlerberichte enthalten Informationen über gesendete und nicht gesendete Broadcasts, wie sowie eine Dumpsys aller Empfänger, die eine bestimmte Nachricht hören.

Frühere Übertragungen ansehen

Historische Übertragungen sind solche, die bereits gesendet wurden, aufgelistet in in umgekehrter chronologischer Reihenfolge.

Der Bereich summary gibt einen Überblick über die letzten 300 Broadcasts im Vordergrund und die letzten 300 Broadcasts im Hintergrund.

Der Abschnitt detail enthält umfassende Informationen zu den die letzten 50 Übertragungen im Vordergrund und die letzten 50 Übertragungen im Hintergrund sowie an die Empfänger für jede Übertragung. Empfänger mit

  • Der BroadcastFilter-Eintrag ist zur Laufzeit registriert und wird gesendet bereits laufenden Prozessen.
  • Der ResolveInfo-Eintrag wird über Manifesteinträge registriert. Die ActivityManager startet den Prozess für jeden ResolveInfo, falls noch nicht geschaltet wird.

Aktive Übertragungen ansehen

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

Broadcast-Hörer ansehen

Wenn du eine Liste der Empfänger aufrufen möchtest, die auf eine Nachricht warten, aktiviere das Kästchen neben „Empfänger“ Resolver-Tabelle in dumpsys activity broadcasts. Die folgenden Das Beispiel zeigt alle Empfänger, die auf USER_PRESENT warten.

Konflikte beobachten

Das Monitoring-Konflikt-Logging kann manchmal auf einen tatsächlichen Monitorkonflikt hinweisen, bedeutet aber meistens, dass das System so ausgelastet ist, dass sich alles verlangsamt hat. Möglicherweise sehen Sie lange Monitorereignisse, die von ART im System- oder Ereignisprotokoll protokolliert wurden.

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

Kompilierung kann teuer sein und das Gerät laden.

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

Die Kompilierung kann auch im Hintergrund erfolgen, während eine Anwendung geladen wird eine DEX-Datei, die noch nicht kompiliert wurde. In diesem Fall werden keine finsky- oder installd-Logging

Erzählung

Die Erzählung eines Problems erstellen (wie es begann, was passiert ist, wie es System reagiert) einen soliden Zeitplan für die Ereignisse erfordert. Sie können die Informationen im Fehlerbericht zur Synchronisierung von Zeitplänen über mehrere Protokolle und um den genauen Zeitstempel des Fehlerberichts zu ermitteln.

Zeitachsen synchronisieren

Ein Fehlerbericht enthält mehrere parallele Zeitpläne: Systemprotokoll, Ereignisprotokoll, Kernel-Protokoll und mehrere spezialisierte Zeitleisten für Broadcasts, Akku-Statistiken, usw. Leider werden Zeitpläne häufig auf einer anderen Zeitbasis angegeben.

Die Zeitstempel des System- und Ereignisprotokolls befinden sich in derselben Zeitzone wie der Nutzer (wie sind die meisten anderen Zeitstempel). Wenn Nutzende beispielsweise auf die Startbildschirmtaste tippen, Systemprotokollberichte:

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 enthält 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-Logs (dmesg) verwenden eine andere Zeitbasis und taggen Log-Elemente mit Sekunden seit der Ausführung des Bootloaders. Um diese Zeitachse bei anderen Timescales, suchen Sie nach Nachrichten zum Ausstieg aussetzen und Eintritt sperren:

<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 während des Anhaltens möglicherweise keine Zeit enthalten, sollten Sie Registrieren Sie das Protokoll stückweise zwischen den Ein- und Ausstiegsmeldungen. Außerdem verwenden Kernel-Logs die UTC-Zeitzone und müssen an den Nutzer angepasst werden Zeitzone.

Zeitpunkt des Fehlerberichts ermitteln

Um herauszufinden, wann ein Fehlerbericht erstellt wurde, sehen Sie zuerst im Systemprotokoll (Logcat) nach für dumpstate: begin:

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

Prüfen Sie als Nächstes die Zeitstempel des Kernel-Logs (dmesg) für 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 Einschränkungen. wie unter Zeitachsen synchronisieren erwähnt. Es gibt zwar viel nachdem der Fehlerbericht erstellt wurde, sind die meisten Aktivitäten Durch das Erstellen des Fehlerberichts wird das System wesentlich geladen.

Stromversorgung

Das Ereignisprotokoll enthält den Ein/Aus-Status des Bildschirms, wobei 0 bedeutet, dass der Bildschirm ausgeschaltet ist, und 1 bedeutet, dass der Bildschirm ausgeschaltet ist. Bildschirm ein und 2 bedeutet, dass Keyguard fertig ist.

Fehlerberichte enthalten auch Statistiken zu Wakelocks, einem Mechanismus, der von App-Entwickler angeben, dass ihre App über das Gerät verfügen muss, bleiben Sie auf dem Laufenden. Weitere Informationen zu Wakelocks finden Sie unter PowerManager.WakeLock und Google Notizen die CPU eingeschaltet.)

Die aggregierte Statistik zur Wakelock-Dauer erfasst nur die Wann ein Wakelock das Gerät wach hält keine Zeit bei eingeschaltetem Bildschirm enthalten. Wenn außerdem mehrere Wakelocks gleichzeitig gehalten werden, beträgt die Wakelock-Dauer die auf diese Wakelocks verteilt sind.

Wenn Sie weitere Hilfe bei der Visualisierung des Energiestatus benötigen, verwenden Sie Battery Historian, Open-Source-Tool von Google zur Analyse von Akkuverbrauchern anhand des Android-Fehlerberichts Dateien.

Pakete

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

Prozesse

Fehlerberichte enthalten eine große Menge an Daten für Prozesse, darunter Start- und Haltestellenzeit, Laufzeitdauer, zugehörige Dienste, oom_adj-Wert usw. Weitere Informationen dazu, wie unter Android Prozesse verwaltet werden, finden Sie unter Prozesse und Threads.

Prozesslaufzeit bestimmen

Der Abschnitt procstats enthält eine vollständige Statistik dazu, wie lange Prozesse und die zugehörigen Dienste ausgeführt wurden. Für eine schnelle, visuell lesbare suchen Sie nach AGGREGATED OVER, um Daten aus der die letzten 3 oder 24 Stunden und suche dann nach Summary:, um die Liste zu sehen wie lange diese Prozesse mit verschiedenen Prioritäten gelaufen sind, und RAM-Nutzung formatiert als min-average-max PSS/min-average-max USS.

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

Im Abschnitt dumpsys activity processes werden alle derzeit laufende Prozesse sortiert nach oom_adj (Android zeigt an, Prozesswichtigkeit, indem Sie dem Prozess einen oom_adj-Wert zuweisen, der kann vom ActivityManager dynamisch aktualisiert werden. Die Ausgabe ähnelt der von einen Speicher-Snapshot, enthält aber zusätzliche Informationen zur Ausführung des Prozesses. Im Beispiel unten Die fettgedruckten Einträge geben an, dass der Prozess gms.persistent ausgeführt wird mit Priorität vis (sichtbar), da der Systemprozess Es ist NetworkLocationService.

Scans

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

  • Logeinträge für BluetoothLeScanner suchen: 
    $ 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 Logeinträgen. In diesem Beispiel: „24840“ und „24851“ sind 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, Anwendung: https://play.google.com/store/apps/details?id=com.badapp.

Hinweis: Auf Geräten mit Android 7.0 Das System erfasst Daten für BLE-Scans und verknüpft diese Aktivitäten. mit der initiierenden Anwendung. Weitere Informationen finden Sie unter Niedriger Energiebedarf und Bluetooth-Scans.