Leggere 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 la cattura di segnalazioni di bug con Android Debug Bridge (adb); le versioni di Android 4.2 e successive supportano un'opzione per gli sviluppatori per acquisire segnalazioni di bug e condividerle via email, Drive e così via.

I report di bug Android contengono dati dumpsys, dumpstate e logcat in formato di testo (.txt), che ti consentono di cercare facilmente contenuti specifici. Le sezioni seguenti descrivono in dettaglio i componenti dei report di bug, i problemi comuni e forniscono suggerimenti utili e comandi grep per trovare i log associati a questi bug. La maggior parte delle sezioni include anche esempi per il comando grep e l'output 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 cronologia più lunga rispetto a main, che contiene tutto il resto. In genere ogni riga inizia con timestamp UID PID TID log-level, anche se UID potrebbe non essere elencato nelle versioni precedenti di Android.

Visualizzare il log eventi

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

I livelli di log includono:

  • V: messaggio dettagliato
  • D: debug
  • I: informazioni
  • W: avviso
  • E: error

 

Per altri tag dei log eventi utili, consulta /services/core/java/com/android/server/EventLogTags.logtags.

ANR e deadlock

I report di bug possono aiutarti a identificare cosa causa gli errori L'applicazione non risponde (ANR) e gli eventi di deadlock.

Identificare le app che non rispondono

Quando un'applicazione non risponde entro un determinato periodo di tempo, in genere a causa di un flusso principale bloccato o occupato, il sistema interrompe il processo e esegue il dump dello stack in /data/anr. Per scoprire il responsabile di un ANR, cerca am_anr nel log degli eventi binari.

Puoi anche cercare ANR in nel log logcat, che contiene ulteriori informazioni su cosa stava utilizzando la CPU al momento dell'ANR.

Trovare le analisi dello stack

Spesso puoi trovare tracce dello stack corrispondenti a un ANR. Assicurati che il timestamp e il PID nelle tracce della VM corrispondano all'ANR che stai esaminando, quindi controlla il thread principale del processo. Ricorda:

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

Trovare deadlock

I deadlock spesso compaiono per la prima volta come ANR perché i thread si bloccano. Se il blocco si verifica nel server di sistema, il watchdog lo interromperà, generando una voce nel log 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 anziché di un vero riavvio.

  • In un riavvio in fase di esecuzione, il server di sistema si arresta e viene riavviato. L'utente vede il dispositivo tornare all'animazione all'avvio.
  • Durante un riavvio, il kernel ha avuto un arresto anomalo. L'utente vede il logo di avvio di Google sul dispositivo.

Per trovare i deadlock, controlla le sezioni delle tracce della VM per verificare la presenza di un pattern in cui il thread A è in attesa di qualcosa trattenuto dal thread B, che a sua volta è in attesa di qualcosa trattenuto dal thread A.

Attività

Un'attività è un componente dell'applicazione che fornisce una schermata con cui gli utenti interagiscono per eseguire un'azione, ad esempio comporre un numero, scattare una foto, inviare un'email e così via. Dal punto di vista dei report sui bug, un'attività è un'azione singola e mirata che un utente può eseguire, il che rende molto importante individuare l'attività attiva durante un arresto anomalo. Le attività (tramite ActivityManager) eseguono i processi, pertanto individuare tutte le interruzioni e le avviamenti dei processi per una determinata attività può anche contribuire alla risoluzione dei problemi.

Visualizzare le attività in primo piano

Per visualizzare una cronologia delle attività in primo piano, cerca am_focused_activity.

Visualizzazione del processo avviata

Per visualizzare la cronologia delle avviamenti dei processi, cerca Start proc.

Determinare se il dispositivo è in stato di thrashing

Per determinare se il dispositivo è in thrashing, controlla se si verifica un aumento anomalo dell'attività intorno a am_proc_died e am_proc_start in un breve lasso di tempo.

Memoria

Poiché i dispositivi Android hanno spesso una memoria fisica limitata, la gestione della memoria di accesso casuale (RAM) è fondamentale. I report di bug contengono diversi indicatori di bassa memoria, nonché un dumpstate che fornisce uno snapshot della memoria.

Identificare la scarsità di memoria

Una scarsa memoria può causare un aumento della latenza del sistema, poiché alcuni processi vengono interrotti per liberare memoria, ma continuano a essere avviati altri processi. Per visualizzare prove che confermano la scarsità di memoria, controlla la presenza di concentrazioni di voci am_proc_died e am_proc_start nel log eventi binario.

La scarsa memoria può anche rallentare il passaggio da un'attività all'altra e sventare i tentativi di ritorno (poiché la task a cui l'utente stava tentando di tornare è stata interrotta). Se il programma di avvio è stato terminato, si riavvia quando l'utente tocca il tasto Home e i log mostrano che il programma di avvio ricarica i contenuti.

Visualizzare gli indicatori storici

La voce am_low_memory nel log eventi binario indica che l'ultimo processo memorizzato nella cache è stato interrotto. Dopodiché, il sistema inizia a terminare i servizi.

Visualizzare gli indicatori di thrashing

Altri indicatori di thrashing del sistema (paginazione, recupero diretto e così via) includono i cicli di consumo di kswapd, kworker e mmcqd. Tieni presente che il report di bug raccolto può influire sugli indicatori di thrashing.

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

Scatta un'istantanea della memoria

Lo snapshot della memoria è un dumpstate che elenca i processi Java e nativi in esecuzione (per maggiori dettagli, consulta Visualizzazione delle allocazioni di memoria complessive). Tieni presente che lo snapshot fornisce solo lo stato in un determinato momento; il sistema potrebbe essere stato in condizioni migliori (o peggiori) prima dello snapshot.

Trasmissione

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

Visualizzare le trasmissioni storiche

Le trasmissioni storiche sono quelle che sono già state inviate, elencate in ordine cronologico inverso.

La sezione Riepilogo è una panoramica delle ultime 300 trasmissioni in primo piano e delle ultime 300 trasmissioni in background.

La sezione dettagli contiene informazioni complete sulle ultime 50 trasmissioni in primo piano e sulle ultime 50 trasmissioni in background, nonché sui ricevitori di ogni trasmissione. Destinatari che dispongono di:

  • L'elemento BroadcastFilter viene registrato in fase di esecuzione e inviato solo ai processi già in esecuzione.
  • La voce ResolveInfo viene registrata tramite le voci manifest. ActivityManager avvia il processo per ogni ResolveInfo se non è già in esecuzione.

Visualizza le trasmissioni attive

Le trasmissioni attive sono quelle che devono ancora essere inviate. Un numero elevato nella fila indica che il sistema non riesce a inviare le trasmissioni abbastanza velocemente per stare al passo.

Visualizzare gli ascoltatori delle trasmissioni

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

Monitorare la contesa

A volte la registrazione delle contese del monitor può indicare una contesa effettiva del monitor, ma il più delle volte indica che il sistema è così carico che tutto ha rallentato. Potresti vedere eventi di monitoraggio lunghi registrati da ART nel log di sistema o di eventi.

Nel log 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 log 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 in background

La compilazione può essere costosa e caricare il dispositivo.

La compilazione potrebbe avvenire in background durante il download degli aggiornamenti del 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 i log finsky o installd.

Presentazione narrativa

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

Sincronizzare le tempistiche

Un report di bug riflette più sequenze temporali parallele: log di sistema, log eventi, log del kernel e più sequenze temporali specializzate per trasmissioni, statistiche della batteria e così via. Purtroppo, le sequenze temporali vengono spesso registrate utilizzando basi di tempo diverse.

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

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 log eventi segnala:

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

I log del kernel (dmesg) utilizzano una base di tempo diversa, con il tagging degli elementi del log con i secondi dal completamento del bootloader. Per registrare questa scala temporale ad altre, cerca i messaggi suspend exit e 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

Poiché i log del kernel potrebbero non includere il tempo in stato di sospensione, devi registrare il log tra i messaggi di entrata e di uscita della sospensione. Inoltre, i log del kernel utilizzano il fuso orario UTC e devono essere aggiustati in base al fuso orario dell'utente.

Identifica la data e l'ora della segnalazione di bug

Per determinare quando è stata generata una segnalazione di bug, controlla innanzitutto il log di sistema (Logcat) per dumpstate: begin:

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

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

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

Procedi a ritroso per correlare i due eventi, tenendo presente le limitazioni riportate in Sincronizzare le cronologie. Anche se accade molto dopo l'avvio della segnalazione di bug, la maggior parte delle attività non è molto utile poiché l'atto di generare la segnalazione di bug carica notevolmente il sistema.

Potenza

Il log eventi contiene lo stato di alimentazione dello schermo, dove 0 indica lo schermo spento, 1 lo schermo acceso e 2 la tastiera protetta.

Le segnalazioni di bug contengono anche statistiche sui blocchi di attivazione, un meccanismo utilizzato dagli sviluppatori di applicazioni per indicare che la loro applicazione deve mantenere acceso il dispositivo. Per informazioni dettagliate sui wakelock, consulta PowerManager.WakeLock e Mantieni attiva la CPU.

Le statistiche aggregate sulla durata del blocco risveglio monitorano solo il tempo in cui un blocco risveglio è effettivamente responsabile del mantenimento del dispositivo attivo e non includono il tempo con lo schermo acceso. Inoltre, se vengono attivati contemporaneamente più wakelock, la durata del wakelock viene distribuita tra questi.

Per ulteriore assistenza per la visualizzazione dello stato dell'alimentazione, utilizza Battery Historian, uno strumento open source di Google per analizzare i consumatori di batteria utilizzando i file bugreport di Android.

Pacchetti

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

Processi

I report di bug contengono una grande quantità di dati relativi ai processi, tra cui ora di inizio e di interruzione, durata del runtime, servizi associati, punteggio oom_adj e così via. Per informazioni dettagliate su come Android gestisce i processi, consulta Processi e thread.

Determina il tempo di esecuzione del processo

La sezione procstats contiene statistiche complete sul tempo di esecuzione dei processi e dei servizi associati. Per un riepilogo rapido e leggibile, cerca AGGREGATED OVER per visualizzare i dati delle ultime tre o 24 ore, quindi cerca Summary: per visualizzare l'elenco dei processi, il tempo di esecuzione di questi processi a varie priorità e il loro utilizzo della RAM 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 un'istantanea della memoria, ma include informazioni aggiuntive su cosa sta causando l'esecuzione del processo. Nell'esempio riportato di seguito, 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

Per identificare le applicazioni che eseguono ricerche Bluetooth Low Energy (BLE) eccessive:

  • Trovare i messaggi di log per BluetoothLeScanner: 
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
  • Individua il PID nei messaggi di log. 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 i dati per le ricerche BLE e associa queste attività all'applicazione di invio. Per maggiori dettagli, vedi Scansioni Bluetooth e Low Energy (LE).