Monitorare le prestazioni tecniche dell'app con Android vitals

Utilizzando Play Console, puoi visualizzare i dati per capire e migliorare l'utilizzo della batteria, la stabilità e il tempo di rendering dell'app.

I seguenti dati vengono raccolti dagli utenti che hanno attivato la condivisione automatica dei dati di utilizzo e diagnostica da un sottoinsieme di dispositivi Android e versioni del sistema operativo. Visita il Centro assistenza Account Google per ulteriori informazioni sulla modalità di attivazione della condivisione di dati da parte degli utenti Android.

Comprimi tutto Espandi tutto

Tipi di dati 

Utilizzo batteria
  • Wakeup eccessivi
  • Wakelock parziali bloccati
  • Wakelock parziali bloccati (in background)
  • Ricerche di reti Wi-Fi eccessive in background 
  • Utilizzo eccessivo della rete in background
Stabilità
  • Percentuale di ANR
  • Percentuale di ANR multipli
  • Percentuale di arresti anomali
  • Percentuale di arresti anomali multipli
Tempi di avvio dell'app
  • Avvio a freddo lento
  • Avvio a caldo (warm start) lento
  • Avvio a caldo (hot start) lento
Tempo di rendering
  • Frame lenti eccessivi
  • Frame bloccati eccessivi
Autorizzazioni
  • Rifiuti di autorizzazioni

Cercare e controllare i dati dell'app

L'intervallo di date indicato nella tua pagina di Android vitals include tutti i dati disponibili per la tua app e non può essere personalizzato. I dati Android vitals sono basati sul fuso orario del Pacifico (PT).

Importante: se non sono disponibili dati, l'app non dispone di punti dati sufficienti all'interno dei filtri specificati per identificare eventuali problemi associati. 

Per cercare e controllare i dati Android vitals dell'app:

  1. Apri Play Console.
  2. Seleziona un'app.
  3. Nel menu a sinistra, seleziona Qualità > Android vitals > Panoramica.
  4. Scegli come vuoi visualizzare i dati dell'app.
Esaminare la dashboard della panoramica e le pagine delle metriche dettagliate.

Metriche vitals essenziali

Nella parte superiore della pagina Panoramica puoi trovare dati relativi alle metriche vitals essenziali della tua app, ossia metriche relative alle prestazioni che possono incidere sulla visibilità e sul ranking della tua app su Google Play. Le metriche vitals essenziali includono:

  • Percentuale di ANR
  • Percentuale di arresti anomali
  • Wakelock parziali bloccati (in background)
  • Wakeup eccessivi

Se la tua app presenta problemi di prestazioni critici che richiedono la tua attenzione, comprese metriche che superano le soglie stabilite per i comportamenti dannosi e cambiamenti rilevanti nei dati sulle prestazioni (chiamati anomalie), puoi utilizzare questa pagina per identificare rapidamente le potenziali aree di miglioramento della tua app. Se vuoi ricevere notifiche via email quando vengono rilevati cambiamenti significativi nei cluster di ANR e arresti anomali o in Android vitals, visita Configurazione > Notifiche.

Importante: per un'esperienza utente ottimale, è necessario identificare e risolvere i problemi di tutte le app in modo da rimanere al di sotto delle soglie relative ai comportamenti dannosi.

Consultare tutte le metriche vitals

Nella parte centrale della pagina Panoramica puoi visualizzare dati relativi a tutte le metriche vitals, suddivisi per tipo di dati. Per filtrare la tabella, scegli il periodo di tempo e le dimensioni che vuoi visualizzare.

Per ogni metrica puoi esaminare la percentuale di sessioni dell'app interessate per i periodi di tempo corrente e precedente. Per confrontare le prestazioni della tua app con quelle di altre app su Google Play, puoi anche controllare la differenza tra la tua app e la mediana delle relative app peer.

Visualizzare metriche dettagliate

Per ulteriori dettagli su una metrica, seleziona Visualizza dettagli. Nella schermata successiva puoi controllare:

  • Anomalie rilevate nei dati sulle prestazioni
  • Soglie relative ai comportamenti dannosi
  • Benchmark di categoria
  • Confronti di benchmark dettagliati
    • Nella scheda di confronto tra app peer nella parte superiore della pagina, seleziona Modifica il gruppo di app peer per modificare un gruppo di app peer personalizzato. Dopo aver creato un gruppo di app peer personalizzato, puoi confrontare la tua app con altre app scelte da te su Google Play.
  • Metriche per elemento, dispositivo, versione di Android, benchmark o intervallo di tempo
    • Per visualizzare ulteriori dettagli, puoi espandere ogni riga nelle tabelle selezionando la freccia rivolta verso il basso sul lato destro.
Filtrare i dati per comportamenti dannosi

Nella parte superiore della pagina Panoramica, alcune metriche potrebbero essere contrassegnate da un'icona di errore rossa . Questo significa che il numero indicato è più elevato rispetto a quello di altre app: questo è noto anche come comportamento dannoso.

Seleziona Visualizza dettagli nella scheda con l'icona per controllare quali APK della tua app includono il comportamento dannoso.

Dettagli sulle metriche

Wakelock parziali bloccati e wakelock parziali bloccati (in background)

Nelle pagine Wakelock parziali bloccati e Wakelock parziali bloccati (in background) vengono indicati i wakelock parziali acquisiti dall'app tramite la classe PowerManager. Un wakelock parziale assicura che la CPU sia in esecuzione, ma consente la disattivazione della retroilluminazione dello schermo e della tastiera.

Dettagli sulla raccolta dei dati

  • Per motivi di privacy, i tag identificativi dei wakelock parziali sono anonimizzati.
  • I dati sui wakelock parziali vengono acquisiti quando il dispositivo non è in carica e lo schermo è spento.
  • I dati sui wakelock parziali bloccati (in background) vengono acquisiti solo quando l'app è in esecuzione in background.
  • Google calcola la durata massima del wakelock parziale per sessione di batteria in modo da mostrare quante sessioni sono state interessate da un wakelock prolungato. Ad esempio, se un utente attiva un wakelock di due ore, Google utilizzerà un valore massimo di wakelock di un'ora.
  • Per le app con il valore sharedUserId impostato nel file manifest, vedrai i dati solo se è installata al massimo un'app con lo stesso sharedUserId.

Dettagli relativi alle metriche vitals

  • Sessioni interessate: la percentuale di sessioni di batteria in cui gli utenti hanno riscontrato almeno un wakelock di oltre un'ora.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato durate di wakelock parziali superiori al valore indicato.
  • Soglia comportamenti dannosi: se la tua app presenta un tasso di occorrenza uguale o superiore a quello della soglia mostrata, significa che fa parte del 25% delle app con prestazioni peggiori tra le 1000 app migliori su Google Play (per numero di installazioni).

Risolvere un problema

Se la tua app ha un numero elevato di wakelock parziali bloccati, visita il sito Android Developers per scoprire le soluzioni consigliate.

Wakeup eccessivi

Nella pagina Wakeup eccessivi vengono mostrati i wakeup di Alarm Manager attivati dall'app. Troverai i dati dei wakeup per le classi ELAPSED_REALTIME_WAKEUP o RTC_WAKEUP.

Dettagli sulla raccolta dei dati

  • Per motivi di privacy, i tag di identificazione dei wakeup vengono anonimizzati.
  • I wakeup vengono acquisiti quando il dispositivo non è in carica.
  • Per fornire una metrica normalizzata, il numero di wakeup è confrontato con il tempo per cui il dispositivo usa la batteria. Google calcola il numero di wakeup per utente per ora in modo da mostrare il numero di utenti interessati da una percentuale elevata di wakeup.
  • Per le app con il valore sharedUserId impostato nel file manifest, vedrai i dati solo se è installata al massimo un'app con lo stesso sharedUserId.

Dettagli relativi alle metriche vitals

  • Sessioni interessate: la percentuale di sessioni di batteria in cui gli utenti hanno riscontrato più di 10 wakeup all'ora. Una sessione di batteria è l'aggregazione di tutti i rapporti sulla batteria ricevuti entro un determinato periodo di 24 ore. In Android 10, un rapporto sulla batteria fa riferimento all'intervallo tra due ricariche della batteria da meno del 20% a sopra l'80% o di qualsiasi valore inferiore al 100%. In Android 11 e versioni successive, un rapporto sulla batteria fa riferimento a un periodo fisso di 24 ore. Google raccoglie i dati solo quando il dispositivo è scollegato dal caricabatterie.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato in un'ora wakeup superiori al valore indicato.
  • Soglia comportamenti dannosi: se la tua app presenta un tasso di occorrenza uguale o superiore a quello della soglia mostrata, significa che fa parte del 25% delle app con prestazioni peggiori tra le 1000 app migliori su Google Play (per numero di installazioni).

Risolvere un problema

Se la tua app presenta wakeup frequenti, visita il sito Android Developers per scoprire le soluzioni consigliate.

Ricerche di reti Wi-Fi eccessive (in background)

La pagina delle ricerche di reti Wi-Fi eccessive (in background) mostra quando le ricerche di reti Wi-Fi determinano un elevato utilizzo della batteria. 

Dettagli sulla raccolta dei dati

I dati sulla ricerca di reti Wi-Fi vengono raccolti quando il dispositivo non è in carica e l'app è in background.

Dettagli relativi alle metriche vitals

  • Sessioni interessate: la percentuale di sessioni di batteria in cui gli utenti hanno riscontrato più di 4 ricerche di reti Wi-Fi all'ora.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato un numero di ricerche orarie di reti Wi-Fi in background superiore al valore indicato.

Risolvere un problema

Se la tua app esegue un numero elevato di ricerche di reti Wi-Fi in background, visita il sito Android Developers per scoprire le soluzioni consigliate. 

Utilizzo eccessivo della rete

Nella pagina Utilizzo eccessivo della rete viene indicato quando una grande quantità di dati di rete è associata a un servizio in background. Quando l'utilizzo della rete mobile avviene in background, i tuoi utenti non hanno facile accesso ai controlli per interrompere il trasferimento dei dati. 

Dettagli sulla raccolta dei dati

I dati sull'utilizzo della rete mobile vengono acquisiti quando il dispositivo non è in carica e l'app è in background.

Dettagli relativi alle metriche vitals

  • Sessioni interessate: la percentuale di sessioni di batteria in cui gli utenti hanno riscontrato più di 50 MB di utilizzo giornaliero della rete in background.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato un maggiore utilizzo giornaliero della rete in background rispetto al valore indicato.

Risolvere un problema

Se la tua app presenta un utilizzo elevato della rete in background, visita il sito Android Developers per scoprire le soluzioni consigliate.

Percentuale di ANR e percentuale di ANR multipli

Comprendere i dati dell'app

Nelle pagine Percentuale di ANR e Percentuale di ANR multipli troverai dati simili a quelli mostrati nella pagina ANR e arresti anomali dell'app. Nella pagina di Android vitals, i dati ANR sono associati ai dati sull'utilizzo al fine di creare una metrica normalizzata.

Dettagli sulla percentuale di ANR

  • Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato almeno un errore ANR. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
  • Sessioni senza ANR. la percentuale di sessioni giornaliere in cui gli utenti non hanno riscontrato alcun errore ANR. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • Soglia comportamenti dannosi: se la tua app presenta un tasso di occorrenza uguale o superiore a quello della soglia mostrata, significa che fa parte del 25% delle app con prestazioni peggiori tra le 1000 app migliori su Google Play (per numero di installazioni).

Dettagli sulla percentuale di ANR multipli

  • Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato almeno due errori ANR. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
  • Sessioni non interessate: percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato al massimo un ANR. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.

Risolvere un problema

Se la tua app ha un numero elevato di errori ANR, visita il sito Android Developers per scoprire le soluzioni consigliate.

Percentuale di arresti anomali e percentuale di arresti anomali multipli

Comprendere i dati dell'app

Nelle pagine Percentuale di arresti anomali e Percentuale di arresti anomali multipli troverai dati simili a quelli mostrati nella pagina ANR e arresti anomali dell'app. Nella pagina di Android vitals, i dati relativi agli arresti anomali sono associati ai dati sull'utilizzo al fine di creare una metrica normalizzata.

Dettagli sulla percentuale di arresti anomali

  • Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato almeno un arresto anomalo. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
  • Sessioni senza arresti anomali: la percentuale di sessioni giornaliere in cui gli utenti non hanno riscontrato alcun arresto anomalo. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • Soglia comportamenti dannosi: se la tua app presenta un tasso di occorrenza uguale o superiore a quello della soglia mostrata, significa che fa parte del 25% delle app con prestazioni peggiori tra le 1000 app migliori su Google Play (per numero di installazioni).

Dettagli sulla percentuale di arresti anomali multipli

  • Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato almeno due arresti anomali. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
  • Sessioni non interessate: percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato al massimo un arresto anomalo. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.

Risolvere un problema

Se la tua app ha un numero elevato di arresti anomali, visita il sito Android Developers per scoprire le soluzioni consigliate.

Frame lenti eccessivi

Comprendere i dati dell'app

Nella pagina Frame lenti eccessivi troverai dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato un tempo di rendering superiore a 16 ms per oltre il 50% dei frame. Le interazioni degli utenti con la tua app dovrebbero avvenire a 60 frame al secondo senza frame interrotti o in ritardo.

Dettagli sulla raccolta dei dati

Google raccoglie il tempo di rendering di ciascun frame mostrato dall'app quando utilizzi il framework del toolkit dell'interfaccia utente, non quando viene usato direttamente OpenGL.

Dati visualizzati nella dashboard

Quando selezioni una riga, puoi notare che i dati sono suddivisi in percentili.

  • Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato un tempo di rendering superiore a 16 ms per oltre il 50% dei frame. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • 90º/99º percentile: il tempo di rendering è stato inferiore al valore indicato per il 90%/99% del totale dei frame raccolti. Questi valori sono basati su tutti i frame raccolti.

Quando fai clic su una voce nella tabella, viene visualizzato il grafico "Distribuzione del tempo di rendering dell'interfaccia utente". Quando esamini il grafico, devi assicurarti che il tempo indicato per la maggior parte dei frame dell'app sia pari o inferiore a 16 ms.

I dati sotto il grafico danno un'idea delle prestazioni del rendering dell'app e potrebbero aiutarti a individuare la causa principale di eventuali problemi relativi al tempo di rendering. Ad esempio, se la percentuale "Latenza input elevata" è alta, dovresti esaminare il codice dell'app che gestisce l'input utente. Per ulteriori informazioni su queste metriche, vai al test delle prestazioni dell'UI.

  • Eventi Vsync persi: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi Vsync persi, diviso per il numero di frame.
  • Latenza input elevata: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi di input che hanno richiesto più di 24 ms, diviso per il numero di frame.
  • Thread interfaccia utente lento: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui sono stati necessari più di 8 ms per completare il thread dell'interfaccia utente, diviso per il numero di frame.
  • Comandi draw lenti: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui l'invio alla GPU dei comandi draw ha richiesto più di 12 ms, diviso per il numero di frame.
  • Caricamenti bitmap lenti: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui sono stati necessari più di 3,2 ms per caricare la bitmap nella GPU, diviso per il numero di frame.

Risolvere un problema

Se la tua app ha un numero elevato di frame con un tempo di rendering superiore a 16 ms, visita il sito Android Developers per scoprire le soluzioni consigliate.

Frame bloccati eccessivi

Nella pagina Frame bloccati eccessivi troverai dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato un tempo di rendering superiore a 700 ms per oltre lo 0,1% dei frame. Le interazioni degli utenti con la tua app dovrebbero avvenire a 60 frame al secondo senza frame interrotti o in ritardo.

Dettagli sulla raccolta dei dati

Google raccoglie il tempo di rendering di ciascun frame mostrato dall'app quando utilizzi il framework del toolkit dell'interfaccia utente, non quando viene usato direttamente OpenGL.

Dati visualizzati nella dashboard

Quando espandi la riga di una dimensione, puoi notare che i dati sono suddivisi in percentili.

  • Sessioni interessate: la percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato un tempo di rendering superiore a 700 ms per oltre lo 0,1% dei frame. Con "sessione giornaliera" si intende una giornata in cui è stata usata l'app. Ad esempio, se due utenti utilizzano l'app per due giorni, saranno generate quattro sessioni giornaliere.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • 90º/99º percentile: il tempo di rendering è stato inferiore al valore indicato per il 90%/99% del totale dei frame raccolti. Questi valori sono basati su tutti i frame raccolti.

Quando fai clic su una voce nella tabella, troverai il grafico della "Distribuzione del tempo di rendering dell'interfaccia utente". Quando esamini il grafico, dovrai assicurarti che la maggior parte dei frame dell'app sia sotto i 700 ms.

I dati sotto il grafico danno un'idea delle prestazioni di rendering dell'app e potrebbero aiutarti a individuare la causa principale di eventuali problemi relativi al tempo di rendering. Ad esempio, se la percentuale di "latenza input elevata" è alta, dovresti esaminare il codice dell' app che gestisce l'input utente. Per ulteriori informazioni su queste metriche, vai al test delle prestazioni dell'UI.

  • Eventi Vsync persi: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi Vsync persi, diviso per il numero di frame.
  • Latenza input elevata: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di eventi di input che hanno richiesto più di 24 ms, diviso per il numero di frame.
  • Thread interfaccia utente lento: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui sono stati necessari più di 8 ms per completare il thread dell'interfaccia utente, diviso per il numero di frame.
  • Comandi draw lenti: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui l'invio alla GPU dei comandi draw ha richiesto più di 12 ms, diviso per il numero di frame.
  • Caricamenti bitmap lenti: per tutti i frame il cui rendering ha richiesto più di 16 ms, il numero di volte per cui sono stati necessari più di 3,2 ms per caricare la bitmap nella GPU, diviso per il numero di frame.

Risolvere un problema

Se la tua app ha un elevato numero di frame con un tempo di rendering superiore a 700 ms, visita il sito Android Developers per scoprire le soluzioni consigliate.

Tempi di avvio dell'app

Nella pagina Tempi di avvio dell'app puoi trovare informazioni dettagliate relative a quando la tua app si avvia lentamente dagli stati di sistema freddo, caldo con app in memoria (warm) e caldo (hot).

Dettagli sulla raccolta dei dati

  • I tempi di avvio vengono registrati soltanto quando un utente attiva un'attività.
    • Esempio: per quanto riguarda le app per tastiera, il tempo di avvio corrisponde al tempo di avvio dell'app complementare.
  • Se un'app viene avviata più volte nell'arco di una giornata dallo stesso stato di sistema, viene registrato il tempo di avvio massimo della giornata.
  • I tempi di avvio vengono monitorati al completamento del caricamento del primo frame dell'app, anche se non si tratta di una schermata con cui interagiscono gli utenti.
    • Esempio: se un'app si avvia con una schermata iniziale, il tempo di avvio corrisponde al tempo necessario per mostrare la schermata iniziale.

Dettagli relativi alle metriche vitals

  • Sessioni interessate: la percentuale di sessioni durante le quali gli utenti hanno riscontrato un tempo di avvio lento per ogni relativo stato di sistema:
    • Avvio a freddo lento: a partire da 5 secondi.
    • Avvio a caldo (warm start) lento: a partire da 2 secondi.
    • Avvio a caldo (hot start) lento: a partire da 1 secondo.
  • Numero di sessioni: il numero approssimativo di sessioni registrate.
  • 90º/99º percentile: 10%/1% di sessioni giornaliere in cui gli utenti hanno riscontrato tempi di avvio lenti dell'app.

Risolvere un problema

Se la tua app ha un numero elevato di tempi di avvio lenti, visita il sito Android Developers per scoprire le soluzioni consigliate.

Rifiuti di autorizzazioni

Nella pagina Rifiuti di autorizzazioni puoi trovare informazioni dettagliate sulla percentuale di sessioni di autorizzazione giornaliere durante le quali gli utenti hanno negato le autorizzazioni. Con "sessione di autorizzazione giornaliera" si intende una giornata in cui la tua app ha richiesto almeno un'autorizzazione all'utente.

Dettagli sulla raccolta dei dati

I dati relativi ai rifiuti di autorizzazioni vengono raccolti quando gli utenti rispondono alle richieste di autorizzazioni all'interno della tua app.

Dettagli relativi alle metriche vitals

  • Autorizzazioni rifiutate: la percentuale di sessioni di autorizzazione giornaliere durante le quali gli utenti hanno negato le autorizzazioni.
  • Non chiedere più: la percentuale di sessioni di autorizzazione giornaliere durante le quali gli utenti hanno negato le autorizzazioni selezionando l'opzione Non chiedere più.
  • Sessioni totali: il numero approssimativo di sessioni registrate.

Risolvere un problema

Se la tua app ha un numero elevato di rifiuti di autorizzazioni, visita il sito degli Sviluppatori Android per scoprire le soluzioni consigliate.

Analizzare i dati con le dimensioni

Per semplificare l'organizzazione, la segmentazione e l'analisi dei tuoi dati, tutti i dati dell'app vengono suddivisi in base alle seguenti dimensioni:

  • Elemento: la versione dell'app.
  • Versione di Android (SDK): la versione del sistema operativo Android segnalata dal dispositivo dell'utente.
  • Tipo di dispositivo: il tipo di dispositivo utilizzato per eseguire l'app (ad es. telefono, tablet, TV, indossabile).
  • Modello dispositivo: il nome commerciale del dispositivo dell'utente e il nome del dispositivo (ad es. Google Nexus 7/Flo).
  • Nome wakelock: i tag che sono stati impostati in modo programmatico durante l'uso dell'API PowerManager nella tua app.
  • Nome wakeup: i tag che sono stati impostati in modo programmatico durante l'uso dell'API AlarmManager nella tua app.
  • Nome attività ANR: il nome completo della classe di attività in cui si è verificato l'errore ANR (se disponibile).
  • Tipo di ANR: quando si è verificato l'errore ANR (ad esempio durante l'esecuzione di un servizio), se disponibile.

Contenuti correlati

Scopri le best practice per l'utilizzo di Android vitals per migliorare le prestazioni e la stabilità della tua app.

È stato utile?
Come possiamo migliorare l'articolo?

Hai bisogno di ulteriore assistenza?

Accedi per scoprire altre opzioni di assistenza che ti consentiranno di risolvere rapidamente il tuo problema

Ricerca
Cancella ricerca
Chiudi ricerca
App Google
Menu principale
Cerca nel Centro assistenza
true
92637
false