Monitorare la qualità tecnica dell'app con Android vitals

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

• Soglie relative alle prestazioni scadenti
• 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 su Google Play scelte da te.
• Tendenza delle metriche nel tempo

Le metriche relative alla percentuale di ANR forniscono una panoramica della qualità della tua app. Queste metriche vengono calcolate tenendo conto del numero di utenti con errori ANR e normalizzandoli in base all'utilizzo dell'app. Sono riportate come percentuale di utenti attivi giornalieri, dove un utente attivo giornaliero viene definito come un utente che utilizza l'app in un singolo giorno su un singolo dispositivo. Se un utente utilizza la tua app su più dispositivi in un solo giorno, ogni dispositivo contribuirà al numero di utenti attivi per quel giorno. Se più utenti utilizzano lo stesso dispositivo in un solo giorno, viene conteggiato un singolo utente attivo.

Esistono tre metriche relative alla percentuale di ANR:

• Percentuale di errore ANR percepito dall'utente: la percentuale di utenti attivi giornalieri che hanno riscontrato almeno un errore ANR percepito dall'utente. Un errore ANR percepito dall'utente è un errore ANR che probabilmente è stato notato dall'utente. Attualmente vengono conteggiati solo gli errori ANR di tipo "timeout invio input". Questa metrica sarà sempre inferiore alla percentuale di ANR generale perché è normalizzata per utilizzo giornaliero, ma non conta tutti gli errori ANR.
  La percentuale di ANR percepiti dagli utenti è una metrica vitals essenziale, ovvero influisce sulla rilevabilità della tua app su Google Play. È importante perché gli errori ANR che conta si verificano sempre quando gli utenti interagiscono con l'app, causando così il maggior numero di interruzioni.
• Percentuale di ANR: la percentuale di utenti giornalieri che hanno riscontrato almeno un errore ANR. Questa metrica include gli errori ANR che non sono classificati come percepiti dall'utente, ma non possiamo garantire che non interessino gli utenti.
• Percentuale di ANR multipli: la percentuale di utenti giornalieri che hanno riscontrato almeno due errori ANR. Questa metrica consente di evidenziare loop di problemi.

Risolvere un problema

Gli errori ANR che contribuiscono alle metriche della percentuale di ANR vengono riportati nella pagina Arresti anomali e ANR. In questa pagina puoi filtrare gli errori ANR percepiti dagli utenti.

Il sito Android for Developers fornisce indicazioni su come diagnosticare e correggere gli ANR.

Le metriche relative alla percentuale di arresti anomali forniscono una panoramica della qualità della tua app. Queste metriche vengono calcolate tenendo conto del numero di utenti con arresti anomali e normalizzandoli in base all'utilizzo dell'app. Sono riportate come percentuale di utenti giornalieri, in cui un utente giornaliero viene definito come un utente che utilizza l'app in un singolo giorno su un singolo dispositivo. Se un utente ha più di un dispositivo, verrà conteggiato più di una volta. Ad esempio, se due utenti utilizzano l'app per due giorni su un dispositivo ciascuno, saranno generate quattro sessioni giornaliere.

Esistono tre metriche relative alla percentuale di arresti anomali:

• Percentuale di arresti anomali percepita dall'utente: la percentuale di utenti giornalieri che hanno riscontrato almeno un arresto anomalo percepito dall'utente. Un arresto anomalo percepito dall'utente è un arresto anomalo che probabilmente è stato notato dall'utente. Ad esempio, gli arresti anomali che si verificano quando la tua app mostra un'attività o è in esecuzione come servizio in primo piano. Questa metrica sarà sempre inferiore alla percentuale di arresti anomali generale perché è normalizzata per utilizzo giornaliero, ma non conta tutti gli arresti anomali.
  La percentuale di arresti anomali percepita dagli utenti è una metrica vitals essenziale, ovvero influisce sulla rilevabilità della tua app su Google Play. È importante perché gli arresti anomali che conta si verificano sempre quando gli utenti interagiscono con l'app, causando così il maggior numero di interruzioni. Per questo motivo, devi assicurarti che la tua app non superi la soglia relativa alle prestazioni scadenti per questa metrica.

• Percentuale di arresti anomali: la percentuale di utenti giornalieri che hanno riscontrato almeno un arresto anomalo. Questa metrica comprende gli arresti anomali che non sono classificati come percepiti dall'utente, ma non possiamo garantire che non interessino gli utenti.

• Percentuale di arresti anomali multipli: la percentuale di utenti giornalieri che hanno riscontrato almeno due arresti anomali. Questa metrica consente di evidenziare loop di problemi.

Risolvere un problema

Il sito Android for Developers fornisce indicazioni su come diagnosticare e correggere gli arresti anomali.

Nella pagina Tempi di avvio, puoi trovare informazioni dettagliate relative a quando la tua app si avvia lentamente dagli stati di sistema a freddo, tiepido e a caldo. Il tempo di avvio misura il tempo che intercorre tra l'avvio dell'app da parte dell'utente e il momento in cui appaiono sullo schermo i primi frame. È anche noto come "tempo di attesa per la prima schermata".

Dopo questo tempo, la tua app potrebbe non essere ancora pronta per l'interazione da parte dell'utente, ad esempio se sono previste schermate di caricamento aggiuntive.

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): a partire da 2 secondi
  • Avvio a caldo (hot): a partire da 1 secondo
• Numero di sessioni: numero approssimativo di sessioni registrate.
• 90º/99º percentile: il 10/1% di sessioni giornaliere durante le quali 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 for Developers per scoprire le soluzioni consigliate.

Perché è importante

Tramite i dati sulle sessioni lente puoi capire l'andamento della frequenza frame del tuo gioco, che incide sulla fluidità del gioco percepita dagli utenti.

Comprendere i dati dell'app

Nella pagina Sessioni lente troverai dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato più del 25% dei frame più lenti di 30 FPS o 20 FPS, a seconda del benchmark selezionato. Puoi anche vedere la distribuzione delle sessioni per frequenza frame del tuo gioco. (La frequenza frame a livello di sessione viene misurata al 75° percentile, il che significa che il 75% dei frame raggiunge almeno questa frequenza frame.)

La maggior parte dei giochi su Google Play dovrebbe avere un obiettivo minimo di 30 FPS. Ciò fornisce un'esperienza ragionevole agli utenti, indipendentemente dal tipo di gioco, anche se alcuni preferiscono almeno 60 FPS, in particolare sui dispositivi di fascia alta. Monitora la metrica della percentuale di sessioni lente (30 FPS) per raggiungere questo obiettivo. Tieni presente che questa metrica include solo sessioni in cui a oltre il 25% dei frame mancano 30 FPS, quindi ha una certa tolleranza per la variabilità della frequenza frame.

Sebbene la frequenza di 30 FPS offra un'esperienza ragionevole, in alcuni casi potrebbe essere necessario ridurre la frequenza frame al di sotto o potrebbero essere utili per giocare su telefoni che non supportano la frequenza di 30 FPS. In questi scenari, almeno il 75% dei frame in una sessione dovrebbe comunque raggiungere 20 FPS o più. Monitora la metrica della percentuale di sessioni lente (20 FPS) per assicurarti di raggiungere questo livello.

Android vitals registra le sessioni lente (30 FPS e 20 FPS) per ogni dispositivo così come per tutti i dispositivi e le sessioni. Utilizza la metrica complessiva per comprendere l'esperienza utente complessiva, ma fai attenzione anche alle prestazioni per dispositivo. A tempo debito, Google Play inizierà ad indirizzerà gli utenti lontano dai giochi che non possono raggiungere i 20 FPS sul telefono.

Vitals inizia a monitorare la frequenza frame solo dopo che il gioco è stato in esecuzione per 1 minuto.

Dettagli sulla raccolta dei dati

La metrica relativa alle sessioni lente viene calcolata con i dati raccolti da SurfaceFlinger. Più concretamente, la frequenza frame di una sessione viene stimata in base al tempo che intercorre fra i frame tracciati sulle piattaforme di proprietà dell'app e include i frame il cui rendering è stato eseguito con OpenGL, Vulkan e il toolkit per la UI di Android. Al momento questa metrica è disponibile soltanto per i giochi.

I dati sulla frequenza frame relativi alle sessioni lente vengono raccolti per i dispositivi con Android 9 e versioni successive.

Visualizzazione nella dashboard

• Frequenza frame aggregata: l'andamento della frequenza frame del tuo gioco sui dispositivi con Android 9 o versioni successive, calcolato al 75° percentile. Ciò significa che il 75% delle sessioni ha registrato almeno questa frequenza frame il 75% delle volte.
• Percentuale di sessioni lente nel tempo: una serie temporale che mostra la percentuale di sessioni ritenute lente.
• Distribuzione della frequenza frame: istogramma che mostra la frequenza frame al 75° percentile di tutte le sessioni. Ciò significa che il 75% dei frame in una sessione è stato più veloce della frequenza frame utilizzata per il bucket della sessione.

Risolvere un problema

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

Comprendere i dati dell'app

Nella pagina Frame lenti eccessivi, troverai i dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato che oltre il 50% dei frame non ha raggiunto in tempo la scadenza di rendering del dispositivo. Le interazioni degli utenti con la tua app dovrebbero avvenire a 60 frame al secondo senza alcun frame interrotto o in ritardo.

Dettagli sulla raccolta dei dati

Google acquisisce il tempo di rendering di ciascun frame mostrato dall'app quando utilizzi il framework del toolkit dell'UI. I frame visualizzati utilizzando direttamente OpenGL o Vulkan non vengono acquisiti.

Visualizzazione 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: 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 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 "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 dell'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 di disegno 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 di disegno ha richiesto più di 12 ms, diviso per il numero di frame.
• Caricamenti bitmap lenti: per tutti i frame il cui rendering ha superato i 16 ms, il numero di volte in cui sono stati necessari oltre 3,2 ms per caricare la bitmap nella GPU, diviso il numero di frame.

Risolvere un problema

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

Comprendere i dati dell'app

Nella pagina Frame lenti eccessivi, troverai i dettagli sulla percentuale di sessioni giornaliere in cui gli utenti hanno riscontrato che oltre il 50% dei frame non ha raggiunto in tempo la scadenza di rendering del dispositivo. Le interazioni degli utenti con la tua app dovrebbero avvenire a 60 frame al secondo senza alcun frame interrotto o in ritardo.

Dettagli sulla raccolta dei dati

Google acquisisce il tempo di rendering di ciascun frame mostrato dall'app quando utilizzi il framework del toolkit dell'UI. I frame visualizzati utilizzando direttamente OpenGL o Vulkan non vengono acquisiti.

Visualizzazione 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: 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 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 "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 dell'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 di disegno 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 di disegno ha richiesto più di 12 ms, diviso per il numero di frame.
• Caricamenti bitmap lenti: per tutti i frame il cui rendering ha superato i 16 ms, il numero di volte in cui sono stati necessari oltre 3,2 ms per caricare la bitmap nella GPU, diviso il numero di frame.

Risolvere un problema

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

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: percentuale di sessioni di batteria in cui gli utenti hanno riscontrato almeno un wakelock di oltre un'ora.
• Numero di sessioni: 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 relativa alle prestazioni scadenti: 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 for Developers per scoprire le soluzioni consigliate.

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 report sulla batteria fa riferimento all'intervallo tra due ricariche da meno del 20% al di sopra dell'80% o di qualsiasi valore inferiore al 100%. In Android 11 e versioni successive, un report 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: 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 relativa alle prestazioni scadenti: 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 for Developers per scoprire le soluzioni consigliate.

La pagina di ricerche di reti Wi-Fi eccessive (in background) mostra quando le ricerche di reti Wi-Fi generano 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: 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 ha un elevato numero di ricerche di reti Wi-Fi in background, visita il sito degli Sviluppatori Android per scoprire le soluzioni consigliate.

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 un accesso rapido ai controlli per fermare 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: 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 ha un elevato utilizzo della rete in background, visita il sito Android for Developers per scoprire le soluzioni consigliate.

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: percentuale di sessioni di autorizzazione giornaliere durante le quali gli utenti non hanno concesso 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 Android for Developers per scoprire le soluzioni consigliate.

Google Play ha definito soglie relative alle prestazioni scadenti in base alla percentuale di errore ANR percepito dall'utente:

• Prestazioni scadenti generali: almeno lo 0,47% degli utenti attivi giornalieri ha riscontrato un errore ANR percepito dall'utente su tutti i modelli di dispositivi.

• Prestazioni scadenti del dispositivo: almeno l'8% degli utenti attivi giornalieri ha riscontrato un errore ANR percepito dall'utente su un singolo modello di dispositivo.

Per migliorare la percentuale di ANR, correggi i cluster di ANR sottostanti segnalati nella pagina Arresti anomali e ANR. Maggiore è il numero di utenti interessati, più il cluster contribuirà alla percentuale di ANR.

Se aspetti specifici dell'hardware o del software del dispositivo potrebbero contribuire alla percentuale di ANR, Android vitals ti invierà una notifica. Puoi anche esplorare le associazioni autonomamente nella pagina Panoramica relativa a Copertura e dispositivi (Release > Copertura e dispositivi > Panoramica).

Google Play ha definito soglie relative alle prestazioni scadenti in base alla percentuale di arresti anomali percepita dall'utente:

• Prestazioni scadenti generali: almeno l'1,09% degli utenti giornalieri ha riscontrato un arresto anomalo percepito dall'utente su tutti i modelli di dispositivo.

• Prestazioni scadenti del dispositivo: almeno l'8% degli utenti giornalieri ha riscontrato un arresto anomalo percepito dall'utente su un singolo modello di dispositivo.

Per migliorare la percentuale di arresti anomali, correggi i cluster di arresti anomali sottostanti segnalati nella pagina Arresti anomali e ANR. Maggiore è il numero di utenti interessati, più il cluster contribuirà alla percentuale di arresti anomali.

Se aspetti specifici dell'hardware o del software del dispositivo possono contribuire alla percentuale di arresti anomali, Android vitals ti invierà una notifica. Puoi anche esplorare le associazioni autonomamente nella pagina Panoramica relativa a Copertura e dispositivi (Release > Copertura e dispositivi > Panoramica).