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

Nouveaux insights sur les problèmes de qualité des applications et nouvelles recommandations

À partir de septembre 2024, vous pourrez trouver de nouveaux insights et de nouvelles recommandations sur les pages Android Vitals – Vue d'ensemble et Plantages et ANR de la Play Console pour vous aider à hiérarchiser les problèmes de qualité.

Pour le moment, vous trouverez des problèmes de compatibilité, des comportements insatisfaisants et des recommandations concernant l'expérience utilisateur. Nous continuerons de détecter et d'identifier davantage de problèmes de qualité, et de fournir davantage de recommandations au cours de l'année à venir.

Utilisez Android Vitals pour mieux comprendre et améliorer la stabilité et les performances de votre application, l'utilisation de la batterie et plus encore.

Choisir comment accéder aux données de votre application

Vous pouvez utiliser Android Vitals de deux façons : via la Play Console ou via l'API Play Developer Reporting.

L'API fournit un accès programmatique à Android Vitals pour les développeurs qui souhaitent intégrer des données Android Vitals à d'autres ensembles de données ou les inclure dans leurs workflows. Pour en savoir plus sur l'accès à Android Vitals via une API, consultez la page de l'API Google Play Developer Reporting.

Pour rechercher et examiner les données Android Vitals de votre application dans la Play Console :

1. Ouvrez la Play Console, puis accédez à la page Android Vitals – Vue d'ensemble (Qualité > Android Vitals > Vue d'ensemble).
2. Choisissez la période à afficher à l'aide du sélecteur de dates en haut à droite.

Important : Si aucune donnée n'est disponible, votre application ne possède pas suffisamment de points de données dans les filtres spécifiés pour identifier les éventuels problèmes.

Surveiller les statistiques principales Android Vitals pour votre application

En haut de la page Android Vitals – Vue d'ensemble, vous pouvez consulter des données sur les statistiques principales Android Vitals pour votre application. Il s'agit des métriques techniques les plus importantes qui affectent la visibilité de votre application sur Google Play. Les statistiques principales Android Vitals comprennent les éléments suivants :

• Taux d'erreurs ANR perçues par l'utilisateur
• Taux de plantages perçus par l'utilisateur

Google Play définit des seuils de comportement insatisfaisant pour ces métriques. Si votre application dépasse ces seuils, elle risque d'être moins visible sur Google Play. Dans certains cas, un avertissement peut s'afficher sur la fiche Play Store de votre application afin de répondre aux attentes des utilisateurs.

La section "Problèmes critiques" permet d'identifier rapidement les points à améliorer pour votre application. Il existe deux types de problèmes critiques :

• Comportements insatisfaisants : métriques dépassant les seuils de comportement insatisfaisant
• Anomalies : variations importantes des données (par exemple, une forte hausse du taux d'erreurs ANR perçues par l'utilisateur)

Pour recevoir des notifications par e-mail, accédez à Configuration >Notifications ou cliquez sur Gérer les notifications dans l'angle de la section "Statistiques principales Android Vitals" (Qualité >Android Vitals >Vue d'ensemble). Notez que les notifications ne sont actuellement disponibles que pour les anomalies.

Parcourir toutes les statistiques Android Vitals

Vers le milieu de la page Android Vitals – Vue d'ensemble, vous pouvez consulter les données sur toutes les statistiques Android Vitals concernant la qualité de votre application.

Dans le tableau, vous pouvez consulter vos métriques pour la période actuelle et les précédentes. Vous pouvez également comparer votre application à d'autres sur Google Play.

Afficher les métriques détaillées

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

Analyser les données à l'aide de dimensions

Pour vous aider à organiser, à segmenter et à analyser vos données, vos métriques sont réparties selon différentes dimensions. Toutes les métriques présentent les répartitions suivantes :

• Artefact : version de votre application sur laquelle le problème est survenu.
• Version d'Android (SDK) : version de l'OS Android installée sur l'appareil de l'utilisateur.
• Facteur de forme : type d'appareil utilisé pour exécuter l'application (par exemple, téléphone, tablette, téléviseur, accessoire connecté).
• Modèle de l'appareil : description détaillée de l'appareil, indiquant la marque et l'identifiant de l'appareil, par exemple "Google oriole". Un même modèle peut avoir des variantes avec différentes versions d'Android ou configurations matérielles (mémoire RAM, espace de stockage ou SoC).
• Pays/Région : position indiquée par l'appareil de l'utilisateur au moment où le problème est survenu.

Conseil : Pour des répartitions selon certains aspects du matériel ou des logiciels de l'appareil (par exemple, le modèle ou la version d'Android), vous pouvez cliquer sur le symbole () à côté de l'élément concerné dans le tableau.

Certaines métriques présentent des répartitions supplémentaires :

• Nom du wakelock : balises définies de manière automatisée lors de l'utilisation de l'API PowerManager dans votre application
• Nom du wakeup : balises définies de manière automatisée lors de l'utilisation de l'API AlarmManager dans votre application
• Nom de l'activité ANR : nom complet de la classe d'activité dans laquelle l'erreur ANR s'est produite (si disponible)
• Type d'ANR : lorsque l'erreur ANR s'est produite (par exemple, pendant l'exécution d'un service) (si disponible)

Lorsque des détails supplémentaires sont disponibles (par exemple, les clusters de plantages ou d'erreurs ANR associés à cette répartition), vous pouvez les afficher en sélectionnant Afficher les détails () à côté de l'élément.

Conseil : Vous pouvez passer d'une métrique à l'autre dans une même catégorie à l'aide du bouton situé en haut de l'écran, puis filtrer la page.

Types de données et métriques

Les données Android Vitals sont disponibles pour les 90 derniers jours dans la Play Console, et pendant trois ans dans l'API Play Developer Reporting.

Les données sont recueillies sur un sous-groupe d'appareils et de versions Android pour lesquels les utilisateurs ont accepté de partager automatiquement les données d'utilisation et de diagnostic. Pour en savoir plus sur la manière dont les utilisateurs Android activent le partage de données, accédez au Centre d'aide des comptes.

Les statistiques Android Vitals sont mises à jour quotidiennement. Les données concernant les appareils équipés d'Android 10 ou version ultérieure peuvent arriver avant celles concernant les appareils équipés de versions antérieures à Android 10. Dans ce cas, vous ne verrez les données pour Android 10 et versions ultérieures que pour les jours où elles sont disponibles.

Remarque : Les métriques Android Vitals excluent les problèmes techniques survenant sur des modèles d'appareils non certifiés ou sur des versions de votre application qui n'ont pas été installées via Google Play.

Tout réduire Tout développer

Stabilité

Métriques sur le taux d'erreurs ANR

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.

Métriques sur le taux de plantages

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.

Temps de démarrage et de chargement

Temps de démarrage (temps d'affichage initial)

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.

Affichage

Affichage dans son intégralité

Taux de session lente (30 FPS ou 20 FPS) [jeux uniquement]

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.

Rendu du kit UI Android

Nombre excessif d'images affichées trop lentement [applications uniquement]

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.

Nombre excessif de cadres figés [applications uniquement]

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.

Utilisation de la batterie

Wakelocks figés et wakelocks partiels figés (en arrière-plan)

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.

Nombre excessif de wakeups

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.

Nombre excessif de recherches de réseaux Wi-Fi (en arrière-plan)

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.

Utilisation excessive du réseau (en arrière-plan)

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.

Autorisations

Refus d'autorisation

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.

Seuils de comportement insatisfaisant pour les statistiques principales Android Vitals

Google Play a défini des seuils de comportement insatisfaisant pour les statistiques principales Android Vitals de votre application.

Si votre application dépasse un seuil de comportement insatisfaisant, elle risque d'être moins visible sur Google Play. Si votre application présente un comportement insatisfaisant sur certains modèles d'appareils, Google Play redirige les utilisateurs de ces appareils vers des applications qui leur conviennent davantage. Dans certains cas, un avertissement peut s'afficher sur la fiche Play Store de votre application afin de répondre aux attentes des utilisateurs et de leur proposer des alternatives avec une meilleure qualité technique.

Google Play prend généralement en compte les données des 28 derniers jours pour évaluer la qualité de votre application, mais peut agir plus tôt en cas de pic.

Tout réduire Tout développer

Stabilité

Seuils de taux d'erreurs ANR perçues par l'utilisateur

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 (Version > Portée et appareils > Vue d'ensemble).

Seuils de taux de plantages perçus par l'utilisateur

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 (Version > Portée et appareils > Vue d'ensemble).

Contenu associé

Découvrez les bonnes pratiques pour utiliser Android Vitals afin d'améliorer les performances et la stabilité de votre application.