Leggi le segnalazioni di bug

I bug si concretizzano in qualsiasi tipo di sviluppo e le segnalazioni di bug sono indispensabili per identificare e risolvere i problemi. Tutte le versioni di Android sono supportate acquisizione di segnalazioni di bug con Android Debug Bridge (adb); Le versioni Android 4.2 e successive supportano un Sviluppatore Opzione per la creazione di segnalazioni di bug e la condivisione via email, Drive e così via.

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

logcat

Il log logcat è un dump basato su stringhe di tutti i valori logcat informazioni. La parte relativa al sistema è riservata al framework e ha una cronologia più lunga di main, che contiene tutto il resto. Ogni riga in genere 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 in formato stringa dei messaggi di log in formato binario. it è meno rumoroso rispetto al log di logcat, ma è anche un po' più difficile da leggere. Quando visualizzi i log eventi, puoi cercare un ID processo specifico in questa sezione (PID) per vedere lo stato di un processo. Il formato di base è: timestamp PID TID log-level log-tag tag-values.

I livelli di log includono:

  • V: dettagliato
  • D: debug
  • I: Informazioni
  • W: avviso
  • E: errore

 

Per altri utili tag dei log eventi, fai riferimento /services/core/java/com/android/server/EventLogTag.logtags.

ANR e deadlock

Le segnalazioni di bug possono aiutarti a identificare la causa Applicazione Errori ANR (Non risponde) ed eventi di deadlock.

Identificare le app che non rispondono

Quando una richiesta non risponde entro un certo periodo di tempo, di solito a causa di un il thread principale bloccato o occupato, il sistema termina il processo ed esegue il dump dello stack /data/anr. Per scoprire il colpevole di un errore ANR, grep per am_anr nel log eventi binario.

Puoi anche eseguire il comando grep per ANR in nel log logcat, che contiene ulteriori informazioni sulla funzionalità che utilizzava la CPU al momento dell'errore ANR.

Trova analisi dello stack

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

  • Il thread principale ti dice solo cosa stava facendo il thread al momento della ANR, che può o meno corrispondere alla vera causa dell'errore ANR. (lo stack la segnalazione di bug potrebbe essere innocente; è possibile che qualcos'altro sia rimasto bloccato a lungo ma non abbastanza a lungo prima di riuscire a risolvere il problema.)
  • Più di un set di analisi dello stack (VM TRACES JUST NOW e VM TRACES AT LAST ANR). Assicurati di visualizzare il sezione corretta.

Trova deadlock

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à, generando una voce nel log simile a: WATCHDOG KILLING SYSTEM PROCESS. Dal punto di vista dell'utente, dispositivo, anche se tecnicamente si tratta di un riavvio in fase di runtime è vero riavvio.

  • In un riavvio di runtime, il server di sistema muore e viene riavviato; l'utente vede il dispositivo tornare all'animazione di avvio.
  • Durante un riavvio, il kernel si è arrestato in modo anomalo. l'utente vede il dispositivo torna al logo di avvio di Google.

Per trovare i deadlock, controlla nelle sezioni delle tracce della VM un pattern del thread A in attesa di qualcosa tenuto dal thread B, che a sua volta attende qualcosa del thread A.

Attività

Un'attività è un componente dell'applicazione che fornisce una schermata con cui gli utenti interagiscono ad esempio comporre un numero, scattare una foto, inviare un'email e così via. punto di vista del report, attività è una singola attività che un utente può svolgere e che consente di individuare l'attività che era a fuoco durante un incidente molto importante. Attività (tramite ActivityManager) eseguire processi, quindi la localizzazione di tutti i processi si arresta e inizia per una determinata attività aiutano anche a risolvere i problemi.

Visualizza attività selezionate

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

Inizio procedura di visualizzazione

Per visualizzare una cronologia degli avvii di processo, cerca Start proc.

Determina se il dispositivo sta eseguendo il thrashing

Per determinare se il dispositivo è thrashing, controlla se si è verificato un aumento anomalo dell'attività intorno alle ore am_proc_died e am_proc_start in breve tempo.

Memoria

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

Identificare i dati sulla memoria insufficiente

Se la memoria è insufficiente, il sistema potrebbe essere sottoposto a thrash, mentre distrugge alcuni processi per liberare ma continua ad avviare altri processi. Per visualizzare prove a sostegno di memoria insufficiente, controlla le concentrazioni di am_proc_died e am_proc_start voci nel log degli eventi binari.

Poca memoria può anche rallentare il cambio di attività e impedire i tentativi di ritorno (perché l'attività a cui l'utente stava cercando di tornare è stata interrotta). Se l'Avvio app era terminato, si riavvia quando l'utente tocca il pulsante Home e i log mostrano Avvio app ricarica i suoi contenuti.

Visualizza indicatori storici

La voce am_low_memory nel log degli eventi binari indica la l'ultimo processo memorizzato nella cache è terminato. Dopodiché, il sistema inizia a terminare i servizi.

Visualizza indicatori thrashing

Altri indicatori di thrashing del sistema (paging, recupero diretto e così via) includono: Utilizzo di kswapd, kworker e mmcqd ciclico. Ricorda che la segnalazione di bug può influire sugli attacchi indicatori).

I log degli errori ANR possono fornire uno snapshot della memoria simile.

Ottieni uno snapshot della memoria

Lo snapshot della memoria è un dumpstate che elenca Java e applicazioni native (per i dettagli, fai riferimento Visualizzazione Allocazioni complessive della memoria). Tieni presente che lo snapshot fornisce solo lo stato in un momento specifico; il sistema potrebbe essere migliorato (o peggiorato) prima dello snapshot.

Trasmissione

Le applicazioni generano trasmissioni per inviare eventi entro l'attuale applicazione o a un'altra applicazione. I ricevitori si abbonano a specifici messaggi (tramite filtri), che consentono loro di ascoltare e rispondere a un annuncio. Le segnalazioni di bug contengono informazioni su trasmissioni inviate e trasmissioni non inviate, come e un dumpsys di tutti i ricevitori che ascoltano una trasmissione specifica.

Visualizzare le trasmissioni storiche

Le trasmissioni storiche sono quelle già inviate, elencate nella inverso.

La sezione summary offre una panoramica degli ultimi 300 le trasmissioni in primo piano e le ultime 300 trasmissioni in background.

La sezione dei dettagli contiene informazioni complete per il le ultime 50 trasmissioni in primo piano e le ultime 50 trasmissioni in background, nonché ricevitore per ogni trasmissione. Ricevitori che hanno:

  • BroadcastFilter voce è stata registrata in fase di runtime e viene inviata solo ai processi già in esecuzione.
  • La voce ResolveInfo è stata registrata tramite voci manifest. La ActivityManager avvia il processo per ogni ResolveInfo, se è non è già in esecuzione.

Visualizza trasmissioni attive

Gli annunci attivi sono quelli che devono essere ancora inviati. Un numero elevato di significa che il sistema non è in grado di inviare le trasmissioni abbastanza velocemente per stare al passo.

Visualizza listener di trasmissione

Per visualizzare un elenco di ricevitori in ascolto di un annuncio, seleziona la casella Ricevitore Tabella resolver in dumpsys activity broadcasts. Le seguenti l'esempio mostra tutti i ricevitori in ascolto di USER_PRESENT.

Monitora contesa

Il logging dei conflitti del monitoraggio a volte può indicare un conflitto effettivo del monitoraggio, ma il più delle volte indica che il sistema è talmente caricato che tutto è rallentato. Potresti vedere lunghi eventi di monitoraggio registrati da ART nel log di sistema o degli 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 di sfondi

La compilazione può essere costosa e caricare il dispositivo.

La compilazione potrebbe avvenire in background quando sono presenti gli aggiornamenti del Google Play Store download. In questo caso, i messaggi dall'app Google Play Store (finsky) e installd sono visualizzati prima di dex2oat messaggi.

La compilazione potrebbe avvenire anche in background durante il caricamento di un'applicazione un file dex che non è stato ancora compilato. In questo caso, non vedrai Logging di finsky o installd.

Testo narrativo

Definire la narrazione di un problema (come è iniziato, cosa è successo, come il sistema ha reagito) richiede una cronologia degli eventi affidabile. Puoi utilizzare lo informazioni nella segnalazione di bug per sincronizzare le cronologie tra più log determinare il timestamp esatto della segnalazione di bug.

Sincronizzare le cronologie

Una segnalazione di bug riflette più tempistiche parallele: log di sistema, log eventi, log del kernel e varie sequenze temporali specializzate per trasmissioni, statistiche sulla batteria, e così via. Purtroppo, spesso le tempistiche sono diverse.

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

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, i report dei log eventi:

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 temporale diversa ed eseguono il tagging degli elementi di log secondi dal completamento del bootloader. Per registrare questo intervallo di tempo ad altri scala temporale, cerca i messaggi di sospensione uscita e sospendi voce:

<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, registrare il log tra i messaggi di entrata e uscita di sospensione. Inoltre, i log del kernel utilizzano il fuso orario UTC e devono essere modificati in base all'utente fuso orario.

Identifica data e ora segnalazione bug

Per determinare quando è stata creata 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'...

Lavora a ritroso per correlare i due eventi, tenendo presenti le avvertenze menzionata in Sincronizzazione delle sequenze temporali. Anche se le risorse che accade dopo l'inizio della segnalazione di bug, la maggior parte delle attività non è molto utile l'esecuzione della segnalazione di bug carica il sistema in modo sostanziale.

Potenza

Il registro eventi contiene lo stato di alimentazione dello schermo, dove 0 indica lo schermo spento, 1 indica e lo schermo 2 è per il controllo della tastiera.

Le segnalazioni di bug contengono anche statistiche sui wakelock, un meccanismo utilizzato agli sviluppatori di applicazioni di indicare che la loro applicazione deve disporre del e rimanere acceso. Per maggiori dettagli sui wakelock, consulta PowerManager.WakeLock e Keep attiva la CPU.)

Le statistiche aggregate sulla durata dei wakelock tracciano solo i volta che un wakelock è responsabile di mantenere attivo il dispositivo non includere il tempo con lo schermo acceso. Inoltre, se vengono mantenuti contemporaneamente più wakelock, la durata del wakelock è distribuiti tra i wakelock.

Per ulteriore assistenza per visualizzare lo stato di alimentazione, usa Batteria storica, un Strumento open source di Google per analizzare i consumatori di batteria utilizzando una segnalazione di bug su Android .

Pacchetti

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

Processi

Le segnalazioni di bug contengono una quantità enorme di dati per i processi, tra cui ora di interruzione, durata del runtime, servizi associati, punteggio oom_adj e così via. Per maggiori dettagli su come Android gestisce i processi, consulta Processi e Thread.

Determina il runtime del processo

La sezione procstats contiene statistiche complete sul tempo processi e i servizi associati siano in esecuzione. Per una guida rapida e leggibile riepilogo, cerca AGGREGATED OVER per visualizzare i dati ultime tre o 24 ore, quindi cerca Summary: per visualizzare l'elenco di processi, per quanto tempo tali processi sono stati eseguiti in base alle varie priorità e Utilizzo della RAM formattato come min-media-max PSS/min-average-max USS.

Motivi per cui un processo è in esecuzione

La sezione dumpsys activity processes elenca tutti i dati attualmente di processi 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 ulteriori informazioni su ciò che 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 il suo NetworkLocationService.

Scansioni

Segui questi passaggi per identificare le applicazioni con un rendimento eccessivo Scansioni BLE (Bluetooth Low Energy):

  • Trova 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 di 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 il responsabile applicazione: https://play.google.com/store/apps/details?id=com.badapp.

Nota: per i dispositivi con Android 7.0, il raccoglie dati per le scansioni BLE e associa queste attività con l'applicazione iniziale. Per maggiori dettagli, vedi Bassa energia (LE) e scansioni Bluetooth.