Leggi le segnalazioni di bug

I bug sono una realtà in qualsiasi tipo di sviluppo e le segnalazioni di bug sono fondamentali per identificare e risolvere i problemi. Tutte le versioni di Android supportano l'acquisizione di segnalazioni di bug con Android Debug Bridge (adb) ; Le versioni Android 4.2 e successive supportano un'opzione sviluppatore per la raccolta di segnalazioni di bug e la condivisione tramite e-mail, Drive, ecc.

Le segnalazioni di bug Android contengono dati dumpsys , dumpstate e logcat in formato testo (.txt), consentendoti di cercare facilmente contenuti specifici. Le sezioni seguenti descrivono in dettaglio i componenti della segnalazione di bug, descrivono problemi comuni e forniscono suggerimenti utili e comandi grep per trovare i log associati a tali bug. La maggior parte delle sezioni include anche esempi per il comando e l'output grep e/o l'output dumpsys .

Logcat

Il log logcat è un dump basato su stringhe di tutte le informazioni logcat . La parte system è riservata al framework e ha una storia più lunga di main che contiene tutto il resto. Ogni riga in genere inizia con timestamp UID PID TID log-level , sebbene l' UID potrebbe non essere elencato nelle versioni precedenti di Android.

Visualizza il registro eventi

Questo log contiene rappresentazioni di stringhe di messaggi di log in formato binario. È meno rumoroso del registro logcat ma anche un po' più difficile da leggere. Quando visualizzi i registri eventi, puoi cercare in questa sezione un ID processo specifico (PID) per vedere cosa ha fatto un processo. Il formato di base è: timestamp PID TID log-level log-tag tag-values .

I livelli di registro includono quanto segue:

  • V: prolisso
  • D: eseguire il debug
  • Io: informazioni
  • W: avvertimento
  • E: errore

Per altri tag utili del registro eventi, fare riferimento a /services/core/java/com/android/server/EventLogTags.logtags .

ANR e deadlock

Le segnalazioni di bug possono aiutarti a identificare la causa degli errori ANR (Applicazione che non risponde) e degli eventi di deadlock.

Identifica le app che non rispondono

Quando un'applicazione non risponde entro un certo tempo, solitamente a causa di un thread principale bloccato o occupato, il sistema interrompe il processo e scarica lo stack in /data/anr . Per scoprire il colpevole dietro un ANR, grep per am_anr nel registro eventi binario.

Puoi anche eseguire il grep per ANR in registro logcat , che contiene ulteriori informazioni su cosa stava utilizzando la CPU al momento dell'ANR.

Trova le tracce dello stack

Spesso puoi trovare analisi dello stack che corrispondono a un ANR. Assicurati che il timestamp e il PID sulle tracce della VM corrispondano all'ANR che stai esaminando, quindi controlla il thread principale del processo. Tieni a mente:

  • Il thread principale ti dice solo cosa stava facendo il thread al momento dell'ANR, che può corrispondere o meno alla vera causa dell'ANR. (Lo stack nella segnalazione di bug potrebbe essere innocuo; qualcos'altro potrebbe essere rimasto bloccato per molto tempo, ma non abbastanza a lungo per ANR, prima di sbloccarsi.)
  • Potrebbero esistere più set di analisi dello stack ( VM TRACES JUST NOW e VM TRACES AT LAST ANR ). Assicurati di visualizzare la sezione corretta.

Trova situazioni di stallo

I deadlock spesso vengono visualizzati inizialmente come ANR perché i thread si bloccano. Se il deadlock colpisce il server di sistema, il watchdog alla fine lo ucciderà, portando a una voce nel registro simile a: WATCHDOG KILLING SYSTEM PROCESS . Dal punto di vista dell'utente, il dispositivo si riavvia, anche se tecnicamente si tratta di un riavvio di runtime piuttosto che di un vero riavvio.

  • In un riavvio del runtime , il server di sistema muore e viene riavviato; l'utente vede il dispositivo tornare all'animazione di avvio.
  • In un riavvio , il kernel si è bloccato; l'utente vede il dispositivo tornare al logo di avvio di Google.

Per trovare deadlock, controlla le sezioni delle tracce della VM per uno schema del thread A in attesa di qualcosa tenuto dal thread B, che a sua volta è in attesa di qualcosa tenuto dal thread A.

Attività

Un'attività è un componente dell'applicazione che fornisce uno schermo con cui gli utenti interagiscono per fare qualcosa come comporre un numero, scattare una foto, inviare un'e-mail, ecc. Dal punto di vista della segnalazione di bug, un'attività è una singola cosa mirata che un utente può fare , il che rende molto importante individuare l'attività messa a fuoco durante un incidente. Le attività (tramite ActivityManager) eseguono processi, quindi anche l'individuazione di tutti gli arresti e gli inizi dei processi per una determinata attività può aiutare nella risoluzione dei problemi.

Visualizza attività mirate

Per visualizzare una cronologia delle attività mirate, cerca am_focused_activity .

Viene avviato il processo di visualizzazione

Per visualizzare una cronologia degli avvii dei processi, cercare Start proc .

Determina se il dispositivo sta tremando

Per determinare se il dispositivo è in difficoltà , verificare la presenza di un aumento anomalo dell'attività intorno am_proc_died e am_proc_start in un breve lasso di tempo.

Memoria

Poiché i dispositivi Android spesso hanno una memoria fisica limitata, la gestione della memoria ad accesso casuale (RAM) è fondamentale. Le segnalazioni di bug contengono diversi indicatori di memoria insufficiente nonché uno stato di dump che fornisce un'istantanea della memoria.

Identificare la memoria insufficiente

La memoria insufficiente può causare il blocco del sistema poiché interrompe alcuni processi per liberare memoria ma continua ad avviare altri processi. Per visualizzare prove corroboranti di memoria insufficiente, verificare la presenza di concentrazioni di voci am_proc_died e am_proc_start nel registro eventi binario.

La memoria insufficiente può anche rallentare il cambio di attività e ostacolare i tentativi di restituzione (perché l'attività a cui l'utente stava tentando di tornare è stata interrotta). Se il launcher è stato interrotto, si riavvia quando l'utente tocca il pulsante Home e i log mostrano che il launcher ricarica il suo contenuto.

Visualizza gli indicatori storici

La voce am_low_memory nel registro eventi binario indica che l'ultimo processo memorizzato nella cache è terminato. Successivamente, il sistema inizia a uccidere i servizi.

Visualizza gli indicatori di thrashing

Altri indicatori di thrashing del sistema (paging, recupero diretto, ecc.) includono i cicli di consumo kswapd , kworker e mmcqd . (Tieni presente che la segnalazione di bug raccolta può influenzare gli indicatori di thrashing.)

I registri ANR possono fornire un'istantanea della memoria simile.

Ottieni un'istantanea della memoria

L'istantanea della memoria è uno stato di dump che elenca i processi Java e nativi in ​​esecuzione (per i dettagli, fare riferimento a Visualizzazione delle allocazioni di memoria complessive ). Tieni presente che l'istantanea fornisce solo lo stato in un momento specifico nel tempo; il sistema avrebbe potuto essere in condizioni migliori (o peggiori) prima dello snapshot.

Trasmissioni

Le applicazioni generano trasmissioni per inviare eventi all'interno dell'applicazione corrente o a un'altra applicazione. I ricevitori broadcast si iscrivono a messaggi specifici (tramite filtri), consentendo loro sia di ascoltare che di rispondere a una trasmissione. Le segnalazioni di bug contengono informazioni sulle trasmissioni inviate e non inviate, nonché un dumpsys di tutti i ricevitori che ascoltano una trasmissione specifica.

Visualizza le trasmissioni storiche

Le trasmissioni storiche sono quelle già trasmesse, elencate in ordine cronologico inverso.

La sezione di riepilogo è una panoramica delle ultime 300 trasmissioni in primo piano e delle ultime 300 trasmissioni in sottofondo.

La sezione dei dettagli contiene informazioni complete sulle ultime 50 trasmissioni in primo piano e sulle ultime 50 trasmissioni in sottofondo, nonché sui ricevitori per ciascuna trasmissione. Ricevitori che hanno:

  • Le voci BroadcastFilter vengono registrate in fase di esecuzione e vengono inviate solo ai processi già in esecuzione.
  • Le voci ResolveInfo vengono registrate tramite voci manifest. L'ActivityManager avvia il processo per ciascun ResolveInfo se non è già in esecuzione.

Visualizza le trasmissioni attive

Le trasmissioni attive sono quelle che devono ancora essere inviate. Un numero elevato in coda indica che il sistema non è in grado di inviare le trasmissioni abbastanza velocemente per tenere il passo.

Visualizza gli ascoltatori delle trasmissioni

Per visualizzare un elenco di ricevitori in ascolto per una trasmissione, controllare la tabella dei risolutori dei ricevitori nelle dumpsys activity broadcasts . L'esempio seguente mostra tutti i ricevitori in ascolto per USER_PRESENT .

Monitorare il conflitto

La registrazione dei conflitti tra monitor a volte può indicare un conflitto effettivo tra i monitor, ma molto spesso indica che il sistema è così carico che tutto è rallentato. Potresti visualizzare eventi di monitoraggio lunghi registrati da ART nel sistema o nel registro eventi.

Nel registro di sistema:

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

Nel registro eventi:

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]

Compilazione dello sfondo

La compilazione può essere costosa e caricare il dispositivo.

La compilazione potrebbe avvenire in background durante il download degli aggiornamenti di Google Play Store. In questo caso, i messaggi dell'app Google Play Store ( finsky ) e installd vengono visualizzati prima dei messaggi dex2oat .

La compilazione potrebbe avvenire anche in background quando un'applicazione carica un file dex che non è stato ancora compilato. In questo caso, non vedrai la registrazione finsky o installd .

Narrativa

Stabilire la narrazione di un problema (come è iniziato, cosa è successo, come ha reagito il sistema) richiede una solida cronologia degli eventi. Puoi utilizzare le informazioni nella segnalazione di bug per sincronizzare le sequenze temporali su più registri e determinare il timestamp esatto della segnalazione di bug.

Sincronizza le sequenze temporali

Una segnalazione di bug riflette più sequenze temporali parallele: registro di sistema, registro eventi, registro del kernel e più sequenze temporali specializzate per trasmissioni, statistiche della batteria, ecc. Sfortunatamente, le sequenze temporali vengono spesso riportate utilizzando basi temporali diverse.

I timestamp del registro eventi e del sistema si trovano nello stesso fuso orario dell'utente (come la maggior parte degli altri timestamp). Ad esempio, quando l'utente tocca il pulsante Home, il registro di sistema riporta:

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

Per la stessa azione, il registro eventi riporta:

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

I registri del kernel ( dmesg ) utilizzano una base temporale diversa, contrassegnando gli elementi del registro con i secondi dal completamento del bootloader. Per registrare questa scala temporale su altre scale temporali, cercare i messaggi di uscita di sospensione e di entrata di sospensione :

<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

Poiché i log del kernel potrebbero non includere il tempo durante la sospensione, è necessario registrare il log a pezzi tra i messaggi di ingresso e di uscita della sospensione. Inoltre, i log del kernel utilizzano il fuso orario UTC e devono essere adattati al fuso orario dell'utente.

Identificare l'ora della segnalazione di bug

Per determinare quando è stata effettuata una segnalazione di bug, controllare prima il registro di sistema (Logcat) per lo dumpstate: begin :

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

Successivamente, controlla i timestamp del log del kernel ( dmesg ) per il messaggio Starting service 'bugreport' :

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

Lavora all'indietro per correlare i due eventi, tenendo presente le avvertenze menzionate in Sincronizzazione delle sequenze temporali . Anche se succedono molte cose dopo l'avvio della segnalazione di bug, la maggior parte delle attività non è molto utile poiché l'atto di ricevere la segnalazione di bug carica sostanzialmente il sistema.

Energia

Il registro eventi contiene lo stato di alimentazione dello schermo, dove 0 indica lo schermo spento, 1 indica lo schermo acceso e 2 indica lo blocco tastiera eseguito.

Le segnalazioni di bug contengono anche statistiche sui wakelock, un meccanismo utilizzato dagli sviluppatori di applicazioni per indicare che la loro applicazione deve mantenere il dispositivo acceso. (Per dettagli sui wakelock, fare riferimento a PowerManager.WakeLock e Mantieni la CPU accesa .)

Le statistiche aggregate sulla durata del wakelock tengono traccia solo del tempo in cui un wakelock è effettivamente responsabile di mantenere il dispositivo attivo e non includono il tempo trascorso con lo schermo acceso. Inoltre, se vengono mantenuti più wakelock contemporaneamente, la durata del wakelock viene distribuita tra tali wakelock.

Per ulteriore assistenza nella visualizzazione dello stato di alimentazione, utilizza Battery Historian , uno strumento open source di Google per analizzare i consumi della batteria utilizzando i file di segnalazione di bug Android.

Pacchetti

La sezione DUMP OF SERVICE package contiene le versioni dell'applicazione (e altre informazioni utili).

Processi

Le segnalazioni di bug contengono un'enorme quantità di dati per i processi, inclusi ora di inizio e fine, durata del runtime, servizi associati, punteggio oom_adj , ecc. Per dettagli su come Android gestisce i processi, fare riferimento a Processi e thread .

Determinare il tempo di esecuzione del processo

La sezione procstats contiene statistiche complete sulla durata dell'esecuzione dei processi e dei servizi associati. Per un riepilogo rapido e leggibile dall'uomo, cerca AGGREGATED OVER per visualizzare i dati delle ultime tre o 24 ore, quindi cerca Summary: per visualizzare l'elenco dei processi, per quanto tempo tali processi sono stati eseguiti a varie priorità e la loro RAM utilizzo formattato come min-media-max PSS/min-media-max USS.

Motivi per cui un processo è in esecuzione

La sezione dumpsys activity processes elenca tutti i processi attualmente in esecuzione ordinati in base al punteggio oom_adj (Android indica l'importanza del processo assegnando al processo un valore oom_adj , che può essere aggiornato dinamicamente da ActivityManager). L'output è simile a quello di uno snapshot della memoria ma include informazioni aggiuntive su ciò che sta causando l'esecuzione del processo. Nell'esempio seguente, le voci in grassetto indicano che il processo gms.persistent è in esecuzione con priorità vis (visibile) perché il processo di sistema è associato al suo NetworkLocationService .

Scansioni

Utilizzare i passaggi seguenti per identificare le applicazioni che eseguono scansioni Bluetooth Low Energy (BLE) eccessive:

  • Trova i messaggi di registro per BluetoothLeScanner :
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • Individuare il PID nei messaggi di registro. In questo esempio, "24840" e "24851" sono PID (ID processo) e TID (ID thread).
  • Individua l'applicazione associata al PID:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    In questo esempio, il nome del pacchetto è com.badapp .

  • Cerca il nome del pacchetto su Google Play per identificare l'applicazione responsabile: https://play.google.com/store/apps/details?id=com.badapp .

Nota : per i dispositivi con Android 7.0, il sistema raccoglie dati per le scansioni BLE e associa queste attività all'applicazione che le ha avviate. Per i dettagli, vedere Scansioni Low Energy (LE) e Bluetooth .