Contrôler la qualité technique de votre application avec Android Vitals

Pour en savoir plus sur une métrique, sélectionnez Afficher les détails () à côté de la métrique concernée. Sur l'écran qui s'affiche, vous pouvez consulter les éléments suivants :

• Seuils de comportement insatisfaisant
• Données de référence par catégorie
• Analyses comparatives détaillées
  • Vers le haut de la page, dans la fiche de comparaison des applications similaires, sélectionnez Modifier le groupe d'applications similaires pour modifier un groupe d'applications similaires personnalisé. Une fois ce groupe créé, vous pouvez comparer votre application à d'autres applications de votre choix sur Google Play.
• Évolution des métriques au fil du temps

Les métriques sur le taux d'erreurs ANR offrent un aperçu de la qualité de votre application. Ces métriques sont calculées en normalisant le nombre d'utilisateurs ayant subi des erreurs ANR en fonction de l'utilisation de votre application. Elles sont exprimées en pourcentage d'utilisateurs actifs par jour. Un utilisateur actif par jour est défini comme une personne qui utilise l'application lors d'une même journée et sur un même appareil. Si un utilisateur se sert de votre application sur plusieurs appareils au cours d'une même journée, chaque appareil sera comptabilisé dans le nombre d'utilisateurs actifs pour ce jour-là. Si plusieurs personnes utilisent le même appareil au cours d'une même journée, un seul utilisateur actif est comptabilisé.

Il existe trois métriques sur le taux d'erreurs ANR :

• Taux d'erreurs ANR perçues par l'utilisateur : pourcentage d'utilisateurs actifs par jour qui ont subi au moins une erreur ANR perçue par l'utilisateur. Une erreur ANR perçue par l'utilisateur est une erreur ANR qui a probablement été remarquée par l'utilisateur. Actuellement, seules les erreurs ANR de type "Délai d'envoi des entrées dépassé" sont comptabilisées. Cette métrique sera toujours inférieure à votre taux d'erreurs ANR global, car elle est normalisée en fonction de l'utilisation quotidienne, mais ne comptabilise pas toutes les erreurs ANR.
  Le taux d'erreurs ANR repérées par l'utilisateur est une statistique principale Android Vitals. Il affecte donc la visibilité de votre application sur Google Play. Cette métrique est importante, car les erreurs ANR comptabilisées se produisent toujours lorsque l'utilisateur interagit avec l'application, ce qui entraîne le plus de perturbations.
• Taux d'erreurs ANR : pourcentage de vos utilisateurs quotidiens ayant subi au moins une erreur ANR. Cette métrique inclut les erreurs ANR non classées comme perçues par l'utilisateur, mais nous ne pouvons pas garantir qu'elles n'affectent pas les utilisateurs.
• Taux d'erreurs ANR multiples : pourcentage de vos utilisateurs quotidiens ayant subi au moins deux erreurs ANR. Cette métrique permet de mettre en évidence les boucles problématiques.

Résoudre un problème

Les erreurs ANR qui contribuent à vos métriques sur le taux d'erreurs ANR sont indiquées sur la page Plantages et ANR. Vous pouvez y filtrer les erreurs ANR perçues par l'utilisateur.

Le site des développeurs Android fournit des conseils sur le diagnostic et la résolution des erreurs ANR.

Les métriques sur le taux de plantages offrent un aperçu de la qualité de votre application. Ces métriques sont calculées en normalisant le nombre d'utilisateurs ayant subi des plantages en fonction de l'utilisation de votre application. Elles sont exprimées en pourcentage d'utilisateurs quotidiens. Un utilisateur quotidien est défini comme une personne qui utilise l'application lors d'une même journée et sur un même appareil. Si un utilisateur possède plusieurs appareils, il est comptabilisé plusieurs fois. Par exemple, si deux personnes utilisent l'application pendant deux jours, chacune sur un seul appareil, quatre sessions quotidiennes seront comptabilisées.

Il existe trois métriques sur le taux de plantages :

• Taux de plantages perçus par l'utilisateur : pourcentage d'utilisateurs quotidiens qui ont subi au moins un plantage perçu par l'utilisateur. Un plantage repéré par l'utilisateur est un plantage qui a probablement été remarqué par l'utilisateur. Il peut s'agir, par exemple, de plantages qui se produisent lorsque votre application affiche une activité ou s'exécute en tant que service de premier plan. Cette métrique sera toujours inférieure à votre taux de plantages global, car elle est normalisée en fonction de l'utilisation quotidienne, mais ne comptabilise pas tous les plantages.
  Le taux de plantages repérés par l'utilisateur est une statistique principale Android Vitals. Il affecte donc la visibilité de votre application sur Google Play. Cette métrique est importante, car les plantages comptabilisés se produisent toujours lorsque l'utilisateur interagit avec l'application, ce qui entraîne le plus de perturbations. C'est pourquoi vous devez vous assurer que votre application ne dépasse pas le seuil de comportement insatisfaisant pour cette métrique.

• Taux de plantages : pourcentage d'utilisateurs quotidiens qui ont subi au moins un plantage. Cette métrique inclut les plantages non classés comme perçus par l'utilisateur, mais nous ne pouvons pas garantir qu'ils n'affectent pas les utilisateurs.

• Taux de plantages multiples : pourcentage d'utilisateurs quotidiens qui ont subi au moins deux plantages. Cette métrique permet de mettre en évidence les boucles problématiques.

Résoudre un problème

Le site des développeurs Android fournit des conseils sur le diagnostic et la résolution des plantages.

Sur la page Temps de démarrage, vous pouvez consulter des informations sur les sessions au cours desquelles votre application a démarré lentement à partir des états système suivants : démarrage à froid, redémarrage à chaud et démarrage à chaud. Le temps de démarrage correspond au temps qui s'écoule entre le moment où un utilisateur lance votre application et l'instant où les premières images apparaissent à l'écran. Également appelé "temps d'affichage initial".

Il se peut que l'utilisateur ne puisse pas commencer à se servir de votre appli dès la fin de ce délai, par exemple si votre appli contient des écrans de chargement supplémentaires.

Informations concernant la collecte des données

• Les temps de démarrage ne sont enregistrés que lorsqu'un utilisateur déclenche une activité.
  • Exemple : Pour les applications de clavier, le temps de démarrage est égal au temps de démarrage de l'application associée.
• Si une application démarre plusieurs fois le même jour à partir du même état système, le temps de démarrage enregistré est le temps maximal de ce jour.
• Les temps de démarrage sont mesurés jusqu'au chargement complet du premier cadre de l'application, même si aucune interactivité n'est possible.
  • Exemple : Si une application s'ouvre sur un écran de démarrage, le temps de démarrage équivaut au temps nécessaire pour afficher cet écran.

Informations sur les statistiques Android Vitals

• Sessions concernées : pourcentage de sessions au cours desquelles les utilisateurs ont constaté un temps de démarrage lent pour chaque état système respectif :
  • Démarrage à froid lent : 5 secondes ou plus
  • Redémarrage à chaud lent : 2 secondes ou plus
  • Démarrage à chaud lent : 1 seconde ou plus
• Nombre de sessions : nombre approximatif de sessions enregistrées.
• 90e/99e centile : 10 %/1 % des sessions quotidiennes au cours desquelles les utilisateurs ont constaté un temps de démarrage lent de votre application.

Résoudre un problème

Si votre application présente un nombre élevé de temps de démarrage lents, accédez au site des développeurs Android pour consulter les solutions recommandées.

Pourquoi est-ce important ?

Les sessions lentes vous permettent de comprendre les performances de votre jeu liées à la fréquence d'images, qui ont un impact sur sa fluidité.

Analyser les données de votre application

Sur la page "Sessions lentes", vous pourrez voir des informations détaillées correspondant au pourcentage de sessions quotidiennes pendant lesquelles les utilisateurs ont subi un affichage lent de plus de 25 % des images (moins de 30 FPS ou 20 FPS, en fonction du benchmark que vous sélectionnez). Vous pouvez également consulter la distribution des sessions par fréquence d'images de votre jeu. La fréquence d'images au niveau de la session est mesurée au 75e centile (75 % des images atteignent au moins cette fréquence d'images).

La plupart des jeux sur Google Play doivent assurer au moins 30 FPS. Cela garantit une expérience utilisateur raisonnable, quel que soit le type de jeu (même si certains utilisateurs préfèrent disposer d'au moins 60 FPS, en particulier sur les appareils haut de gamme). Surveillez la métrique "Taux de session lente (30 FPS)" pour être certain d'atteindre cet objectif. N'oubliez pas que cette métrique ne comprend que les sessions pour lesquelles plus de 25 % des images n'atteignent pas 30 FPS. Elle offre donc une certaine tolérance à la variabilité de la fréquence d'images.

Même si un affichage 30 FPS procure une expérience raisonnable, il peut être utile de diminuer la fréquence d'images dans certains cas ou avec certains jeux, ou lorsque l'utilisateur souhaite jouer sur un téléphone non compatible avec une fréquence de 30 FPS. Dans ces scénarios, au moins 75 % des images d'une session doivent toujours atteindre 20 FPS ou plus. Surveillez la métrique "Taux de session lente (20 FPS)" pour être certain d'atteindre cet objectif.

Android Vitals signale les sessions lentes (30 FPS) et les sessions lentes (20 FPS) de chaque appareil, ainsi que pour tous les appareils et toutes les sessions. Utilisez la métrique globale pour analyser l'expérience utilisateur globale. Soyez également attentif aux performances par appareil. À terme, Play évitera de proposer aux utilisateurs des jeux qui ne peuvent pas atteindre 20 FPS sur leur téléphone.

Android Vitals ne surveille la fréquence d'images que si votre jeu s'exécute plus d'une minute.

Informations concernant la collecte des données

La métrique "Sessions lentes" est calculée à partir des données collectées depuis SurfaceFlinger. Plus concrètement, la fréquence d'images d'une session est estimée en fonction du temps entre les images dessinées sur les surfaces appartenant à l'application. Elle inclut les images affichées par OpenGL, Vulkan et le kit UI Android. Cette métrique n'est actuellement disponible que pour les jeux.

Les données de fréquence d'images des sessions lentes sont collectées pour les appareils équipés d'Android 9 ou version ultérieure.

Affichage du tableau de bord

• Fréquence d'images représentative : performances de votre jeu liées à la fréquence d'images sur les appareils équipés d'Android 9 ou version ultérieure, calculées au 75e centile. Cela signifie que 75 % des sessions présentaient au moins cette fréquence d'images dans 75 % des cas.
• Taux de session lent au fil du temps : série temporelle indiquant le pourcentage de sessions considérées comme lentes.
• Distribution de la fréquence d'images : histogramme affichant la fréquence d'images au 75e centile pour les sessions. Cela signifie que 75 % des images d'une session étaient plus rapides que la fréquence d'images utilisée pour segmenter la session.

Résoudre un problème

Si votre application présente un grand nombre de sessions lentes, accédez au site pour les développeurs Android pour consulter les solutions recommandées.

Analyser les données de votre application

Sur la page "Nombre excessif d'images affichées trop lentement", vous pouvez voir des informations détaillées correspondant au pourcentage de sessions quotidiennes pendant lesquelles les utilisateurs ont subi un affichage lent de plus de 50 % des images. Les interactions des utilisateurs avec votre application doivent s'exécuter à 60 images par seconde sans perte ni retard d'affichage des images.

Informations concernant la collecte des données

Google collecte le délai d'affichage de chaque image chargée par votre application avec le kit UI. Les données n'incluent pas les images affichées directement avec OpenGL ou Vulkan.

Affichage du tableau de bord

Lorsque vous sélectionnez une ligne, les données affichées sont réparties en centiles.

• Sessions concernées : pourcentage de sessions quotidiennes au cours desquelles les utilisateurs ont subi un affichage lent de plus de 50 % des images (plus de 16 ms). Une "session quotidienne" désigne une journée au cours de laquelle votre application a été utilisée. Par exemple, si deux personnes utilisent l'application pendant deux jours, quatre sessions quotidiennes seront comptabilisées.
• Nombre de sessions : nombre approximatif de sessions enregistrées.
• 90e/99e centile : 90 %/99 % du nombre total d'images présentaient un délai d'affichage inférieur à la valeur indiquée. Ces chiffres sont basés sur le nombre total d'images recueillies.

En cliquant sur une entrée dans le tableau, vous pourrez voir le graphique "Distribution du temps d'affichage de l'interface utilisateur". Vérifiez que la majorité des images de votre application présentées dans le graphique s'affichent en 16 ms ou moins.

Les données sous le graphique indiquent les performances de l'application et peuvent vous aider à déterminer la cause des problèmes d'affichage. Par exemple, s'il y a un fort pourcentage de "Latence de saisie élevée", vérifiez le code de votre application qui gère les entrées utilisateur. Pour en savoir plus sur ces métriques, accédez à la page sur le test des performances de l'interface utilisateur.

• Événements Vsync manqués : pour toutes les images chargées en plus de 16 ms, nombre d'événements Vsync manqués, divisé par le nombre d'images.
• Latence de saisie élevée : pour toutes les images chargées en plus de 16 ms, nombre d'événements de saisie ayant pris plus de 24 ms, divisé par le nombre d'images.
• Thread UI lent : pour toutes les images chargées en plus de 16 ms, nombre de fois où le thread UI s'est chargé en plus de 8 ms, divisé par le nombre d'images.
• Commandes de dessin lentes : pour toutes les images chargées en plus de 16 ms, nombre de fois où l'envoi de commandes de dessin au GPU a pris plus de 12 ms, divisé par le nombre d'images.
• Importations lentes de bitmap : pour toutes les images chargées en plus de 16 ms, nombre de fois où l'importation du bitmap sur le GPU a pris plus de 3,2 ms, divisé par le nombre d'images.

Résoudre un problème

Si votre application présente un grand nombre d'images dont le délai d'affichage est supérieur à 16 ms, accédez au site des développeurs Android pour consulter les solutions recommandées.

Analyser les données de votre application

Sur la page "Nombre excessif d'images affichées trop lentement", vous pouvez voir des informations détaillées correspondant au pourcentage de sessions quotidiennes pendant lesquelles les utilisateurs ont subi un affichage lent de plus de 50 % des images. Les interactions des utilisateurs avec votre application doivent s'exécuter à 60 images par seconde sans perte ni retard d'affichage des images.

Informations concernant la collecte des données

Google collecte le délai d'affichage de chaque image chargée par votre application avec le kit UI. Les données n'incluent pas les images affichées directement avec OpenGL ou Vulkan.

Affichage du tableau de bord

Lorsque vous sélectionnez une ligne, les données affichées sont réparties en centiles.

• Sessions concernées : pourcentage de sessions quotidiennes au cours desquelles les utilisateurs ont subi un affichage lent de plus de 50 % des images (plus de 16 ms). Une "session quotidienne" désigne une journée au cours de laquelle votre application a été utilisée. Par exemple, si deux personnes utilisent l'application pendant deux jours, quatre sessions quotidiennes seront comptabilisées.
• Nombre de sessions : nombre approximatif de sessions enregistrées.
• 90e/99e centile : 90 %/99 % du nombre total d'images présentaient un délai d'affichage inférieur à la valeur indiquée. Ces chiffres sont basés sur le nombre total d'images recueillies.

En cliquant sur une entrée dans le tableau, vous pourrez voir le graphique "Distribution du temps d'affichage de l'interface utilisateur". Vérifiez que la majorité des images de votre application présentées dans le graphique s'affichent en 16 ms ou moins.

Les données sous le graphique indiquent les performances de l'application et peuvent vous aider à déterminer la cause des problèmes d'affichage. Par exemple, s'il y a un fort pourcentage de "Latence de saisie élevée", vérifiez le code de votre application qui gère les entrées utilisateur. Pour en savoir plus sur ces métriques, accédez à la page sur le test des performances de l'interface utilisateur.

• Événements Vsync manqués : pour toutes les images chargées en plus de 16 ms, nombre d'événements Vsync manqués, divisé par le nombre d'images.
• Latence de saisie élevée : pour toutes les images chargées en plus de 16 ms, nombre d'événements de saisie ayant pris plus de 24 ms, divisé par le nombre d'images.
• Thread UI lent : pour toutes les images chargées en plus de 16 ms, nombre de fois où le thread UI s'est chargé en plus de 8 ms, divisé par le nombre d'images.
• Commandes de dessin lentes : pour toutes les images chargées en plus de 16 ms, nombre de fois où l'envoi de commandes de dessin au GPU a pris plus de 12 ms, divisé par le nombre d'images.
• Importations lentes de bitmap : pour toutes les images chargées en plus de 16 ms, nombre de fois où l'importation du bitmap sur le GPU a pris plus de 3,2 ms, divisé par le nombre d'images.

Résoudre un problème

Si votre application présente un grand nombre d'images dont le délai d'affichage est supérieur à 16 ms, accédez au site des développeurs Android pour consulter les solutions recommandées.

Les pages Wakelocks partiels figés et Wakelocks partiels figés (en arrière-plan) affichent les wakelocks partiels acquis par votre application via la classe PowerManager. Les wakelocks partiels permettent d'assurer l'exécution du processeur, mais l'écran et le rétroéclairage du clavier peuvent être désactivés.

Informations concernant la collecte des données

• Pour des raisons de confidentialité, les balises d'identification des wakelocks partiels sont anonymes.
• Les données sur les wakelocks partiels sont recueillies lorsque l'appareil n'est pas en charge et que l'écran est éteint.
• Les données de wakelocks partiels figés (en arrière-plan) ne sont collectées que lorsque l'application est exécutée en arrière-plan.
• Google calcule la durée maximale des wakelocks partiels par session de batterie pour indiquer le nombre de sessions concernées par un wakelock prolongé. Par exemple, si un utilisateur déclenche un wakelock de deux heures, Google utilisera une valeur maximale de wakelock d'une heure.
• Pour les applications qui définissent sharedUserId dans le fichier manifeste : les données s'affichent uniquement si une seule application est installée avec le même sharedUserId.

Informations sur les statistiques Android Vitals

• Sessions concernées : pourcentage de sessions de batterie pendant lesquelles les utilisateurs ont subi au moins un wakelock de plus d'une heure.
• Nombre de sessions : nombre approximatif de sessions enregistrées.
• 90e/99e centile : 10 %/1 % des sessions quotidiennes au cours desquelles les utilisateurs ont subi des wakelocks partiels d'une durée supérieure à la valeur indiquée.
• Seuil de comportement insatisfaisant : si votre application présente un taux d'occurrence supérieur ou égal au seuil indiqué, elle fait partie des 25 % d'applications les moins performantes parmi les 1 000 applications principales sur Google Play (en nombre d'installations).

Résoudre un problème

Si votre application génère un grand nombre de wakelocks partiels figés, accédez au site des développeurs Android pour consulter les solutions recommandées.

La page Nombre excessif de wakeups indique le nombre de wakeups d'AlarmManager déclenchés par votre application. Vous pouvez consulter les données des wakeups pour les classes ELAPSED_REALTIME_WAKEUP ou RTC_WAKEUP.

Informations concernant la collecte des données

• Pour des raisons de confidentialité, les balises d'identification des wakeups sont rendues anonymes.
• Les données des wakeups sont collectées lorsque l'appareil n'est pas en charge.
• Pour que vous obteniez une statistique normalisée, le nombre de wakeups est comparé au temps de fonctionnement sur batterie de l'appareil. Google calcule le nombre de wakeups par utilisateur et par heure, afin d'indiquer le nombre d'utilisateurs concernés par un taux de wakeups important.
• Pour les applications qui définissent sharedUserId dans le fichier manifeste : les données s'affichent uniquement si une seule application est installée avec le même sharedUserId.

Informations sur les statistiques Android Vitals

• Sessions concernées : pourcentage de sessions de batterie pendant lesquelles les utilisateurs ont subi plus de 10 wakeups par heure. Une session de batterie regroupe tous les rapports sur la batterie reçus sur une période de 24 heures. Dans Android 10, un rapport sur la batterie couvre l'intervalle entre deux recharges de batterie : lorsque le niveau de batterie avant la recharge est inférieur à 20 % et atteint plus de 80 % après la recharge, ou lorsque le niveau de batterie atteint 100 % après la recharge, indépendamment de son niveau initial. Dans Android 11 et versions ultérieures, un rapport sur la batterie couvre une période fixe de 24 heures. Google recueille les données uniquement lorsque l'appareil n'est pas en charge.
• Nombre de sessions : nombre approximatif de sessions enregistrées.
• 90e/99e centile : 10 %/1 % des sessions quotidiennes au cours desquelles les utilisateurs ont subi un nombre de wakeups par heure supérieur à la valeur indiquée.
• Seuil de comportement insatisfaisant : si votre application présente un taux d'occurrence supérieur ou égal au seuil indiqué, elle fait partie des 25 % d'applications les moins performantes parmi les 1 000 applications principales sur Google Play (en nombre d'installations).

Résoudre un problème

Si votre application présente des wakeups fréquents, accédez au site des développeurs Android pour consulter les solutions recommandées.

La page Nombre excessif de recherches de réseaux Wi-Fi (en arrière-plan) indique quand les recherches de réseaux Wi-Fi sollicitent beaucoup la batterie.

Informations concernant la collecte des données

Les données relatives aux recherches de réseaux Wi-Fi sont recueillies lorsque l'appareil n'est pas en charge et que l'application est en arrière-plan.

Informations sur les statistiques Android Vitals

• Sessions concernées : pourcentage de sessions de batterie pendant lesquelles les utilisateurs ont subi plus de quatre recherches de réseaux Wi-Fi par heure.
• Nombre de sessions : nombre approximatif de sessions enregistrées.
• 90e/99e centile : 10 %/1 % des sessions quotidiennes au cours desquelles les utilisateurs ont subi un nombre de recherches de réseaux Wi-Fi en arrière-plan par heure supérieur au nombre indiqué.

Résoudre un problème

Si votre application présente un nombre élevé de recherches de réseaux Wi-Fi en arrière-plan, accédez au site des développeurs Android pour consulter les solutions recommandées.

La page Utilisation excessive du réseau indique quand un grand nombre de données du réseau sont associées à un service d'arrière-plan. Lorsque l'utilisation du réseau mobile s'effectue en arrière-plan, les utilisateurs ne peuvent pas accéder facilement aux commandes pour arrêter le transfert de données.

Informations concernant la collecte des données

Les données relatives à l'utilisation du réseau mobile sont recueillies lorsque l'appareil n'est pas en charge et que l'application est exécutée en arrière-plan.

Informations sur les statistiques Android Vitals

• Sessions concernées : pourcentage de sessions de batterie au cours desquelles les utilisateurs ont subi une utilisation du réseau en arrière-plan supérieure à 50 Mo par jour.
• Nombre de sessions : nombre approximatif de sessions enregistrées.
• 90e/99e centile : 10 %/1 % des sessions quotidiennes au cours desquelles les utilisateurs ont subi chaque jour une utilisation du réseau en arrière-plan supérieure au nombre indiqué.

Résoudre un problème

Si votre application présente une utilisation élevée du réseau en arrière-plan, accédez au site des développeurs Android pour consulter les solutions recommandées.

Sur la page Refus d'autorisation, vous pouvez consulter des informations sur le pourcentage de sessions quotidiennes avec demande d'autorisation au cours desquelles les utilisateurs ont refusé des autorisations. Une session quotidienne avec demande d'autorisation désigne une journée au cours de laquelle votre application demande au moins une autorisation à l'utilisateur.

Informations concernant la collecte des données

Les données sur les refus d'autorisation sont collectées lorsque les utilisateurs répondent aux demandes d'autorisation dans votre application.

Informations sur les statistiques Android Vitals

• Refus : pourcentage de sessions d'autorisations quotidiennes au cours desquelles les utilisateurs ont refusé des autorisations.
• Ne plus demander : pourcentage de sessions d'autorisation quotidiennes au cours desquelles les utilisateurs ont refusé des autorisations en sélectionnant "Ne plus demander".
• Nombre total de sessions : nombre approximatif de sessions enregistrées.

Résoudre un problème

Si votre application présente un nombre élevé de refus d'autorisation, accédez au site des développeurs Android pour consulter les solutions recommandées.

Google Play a défini des seuils de comportement insatisfaisant pour le taux d'erreurs ANR perçues par l'utilisateur :

• Comportement insatisfaisant en général : au moins 0,47 % des utilisateurs actifs par jour subissent une erreur ANR perçue par l'utilisateur sur tous les modèles d'appareils.

• Comportement insatisfaisant par appareil : au moins 8 % des utilisateurs actifs par jour subissent une erreur ANR perçue par l'utilisateur sur un même modèle d'appareil.

Pour améliorer votre taux d'erreurs ANR, corrigez les clusters d'erreurs ANR sous-jacents signalés sur la page Plantages et ANR. Plus le nombre d'utilisateurs concernés est élevé, plus un cluster contribue au taux d'erreurs ANR.

Si certains aspects du matériel ou des logiciels de l'appareil sont susceptibles de contribuer à votre taux d'erreurs ANR, Android Vitals vous en informera. Vous pouvez également explorer les associations vous-même sur la page Présentation de la fonctionnalité Portée et appareils (Surveiller et améliorer > Portée et appareils > Vue d'ensemble).

Google Play a défini des seuils de comportement insatisfaisant pour le taux de plantages repérés par l'utilisateur :

• Comportement insatisfaisant en général : au moins 1,09 % des utilisateurs quotidiens subissent un plantage perçu par l'utilisateur sur tous les modèles d'appareils.

• Comportement insatisfaisant par appareil : au moins 8 % des utilisateurs quotidiens subissent un plantage perçu par l'utilisateur sur un même modèle d'appareil.

Pour améliorer votre taux de plantages, corrigez les clusters de plantages sous-jacents signalés sur la page Plantages et ANR . Plus le nombre d'utilisateurs concernés est élevé, plus un cluster contribue au taux de plantages.

Si certains aspects du matériel ou des logiciels de l'appareil sont susceptibles de contribuer à votre taux de plantages, Android Vitals vous en informera. Vous pouvez également explorer les associations vous-même sur la page Présentation de la fonctionnalité Portée et appareils (Surveiller et améliorer > Portée et appareils > Vue d'ensemble).