Surveiller la qualité technique de votre application avec Android Vitals

Utilisez Android Vitals pour vous aider à comprendre et à améliorer la stabilité, les performances et l'utilisation de la pile de votre application, et plus.

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

Vous pouvez utiliser Android Vitals de deux façons : par Play Console et par l'API Play Developer Reporting.

L'API fournit un accès programmatique à Android Vitals pour les développeurs qui veulent intégrer les données Android Vitals à d'autres ensembles de données ou les intégrer à leurs flux de travail. Pour en savoir plus à propos de l'utilisation d'une API pour accéder à Android Vitals, accédez à la page de l'API Google Play Developer Reporting.

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

  1. Ouvrez Play Console.
  2. Sélectionnez une application.
  3. Dans le menu de gauche, sélectionnez Qualité > Android Vitals > Aperçu.
  4. Choisissez la plage de données que vous souhaitez afficher à l'aide du sélecteur de période dans la partie supérieure droite de l'écran.

Important : Si aucune donnée n'est proposée, cela signifie que votre application ne dispose pas de suffisamment de points de données selon les filtres précisés pour déterminer d'éventuels problèmes.

Surveiller les données essentielles de votre application

En haut de la page Aperçu, vous pouvez consulter les données essentielles sur votre application. Ce sont les mesures techniques les plus importantes, et celles-ci ont une incidence sur la découvrabilité de votre application sur Google Play. Les données essentielles comprennent :

Google Play définit des seuils de comportement insatisfaisant sur ces mesures. Si votre application dépasse ces seuils, elle sera probablement moins repérable sur Google Play. Dans certains cas, une mise en garde peut s'afficher sur la fiche Google Play Store de votre application afin de définir les attentes des utilisateurs.

Vous pouvez utiliser la section « Problèmes critiques » pour cerner rapidement les domaines dans lesquels votre application peut être améliorée. Il existe deux types de problèmes critiques :

  • Comportements insatisfaisants : des mesures qui dépassent les seuils de comportement insatisfaisant
  • Anomalies : des changements importants relevés dans les données (par exemple une forte augmentation du taux d'erreurs ANR perçues par les utilisateurs)

Pour recevoir des notifications par courriel, accédez à Configurer > Notifications ou cliquez sur Gérer les notifications dans le coin de la section « Données essentielles » (Qualité > Android Vitals > Aperçu). Notez que les notifications ne sont actuellement proposées que pour les anomalies.

Parcourir toutes les données essentielles

Près du centre de la page Aperçu, vous pouvez afficher toutes les données essentielles par aspect de la qualité.

Dans le tableau, vous pouvez examiner vos mesures pour les périodes actuelles et précédentes. Vous pouvez également voir comment votre application se compare à d'autres applications sur Google Play.

Afficher les mesures détaillées

Pour afficher plus de détails sur une mesure particulière, sélectionnez Afficher les détails () à côté de celle-ci. À l'écran suivant, vous pouvez examiner :

  • les seuils de comportement insatisfaisant;
  • les références de la catégorie;
  • les comparaisons détaillées des références;
    • Dans la partie supérieure de la page, dans la carte de comparaison de l'application similaire, sélectionnez Modifier le groupe d'applications similaires pour modifier un groupe d'applications similaires personnalisé. Après avoir créé un groupe d'applications similaires personnalisé, vous pouvez comparer votre application avec d'autres de votre choix sur Google Play.
  • la tendance de la mesure au fil du temps.
Analyser les données avec des dimensions

Pour vous aider à organiser, à segmenter et à analyser vos données, vos mesures sont réparties selon un certain nombre de dimensions différentes. Toutes les mesures sont réparties comme suit :

  • Artefact : la version de votre application sur laquelle le problème s'est produit.
  • Version d'Android (trousse SDK) : la version du système d'exploitation Android installée sur l'appareil de l'utilisateur
  • Facteur de forme : le type d'appareil sur lequel l'application a été exécutée (par exemple, téléphone, tablette, téléviseur, accessoire connecté)
  • Modèle d'appareil : une description générale de l'appareil, composée d'une marque unique et d'un identifiant d'appareil, par exemple « Google oriole »; un même modèle d'appareil peut avoir des variantes avec des versions d'Android, une mémoire vive, un espace de stockage ou un système sur puce (SoC) différents.
  • Pays ou région : la position signalée par l'appareil de l'utilisateur au moment du problème.

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

Certaines mesures comportent d'autres répartitions :

  • Nom du verrou de réveil : les balises qui ont été configurées par programmation dans votre application au moyen de l'API PowerManager.
  • Nom du réveil : les balises qui ont été configurées par programmation dans votre application au moyen de l'API AlarmManager.
  • Nom de l'activité ANR : le nom entièrement qualifié de la classe d'activité dans laquelle l'erreur ANR s'est produite (si proposé).
  • Type d'erreur ANR : le moment où l'erreur ANR s'est produite, par exemple lors de l'exécution d'un service (si proposé).

Vous pouvez afficher plus de détails lorsqu'ils sont accessibles (par exemple les grappes du plantage ou de l'erreur ANR associées à cette répartition) en sélectionnant Afficher les détails () à côté de l'élément.

Conseil : Vous pouvez basculer entre les mesures d'une même catégorie à l'aide du commutateur en haut de l'écran, de même que filtrer la page.

Types et mesures de données

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

Les données sont collectées auprès d'utilisateurs qui ont accepté de partager automatiquement des données d'utilisation et de diagnostics à partir d'un sous-ensemble d'appareils Android et de versions du système d'exploitation. Pour en savoir plus sur les façons dont les utilisateurs Android choisissent de partager des données, consultez le centre d'aide des comptes.

Android Vitals est mise à jour quotidiennement. Parfois, les données pour les appareils dotés d'Android 10+ peuvent arriver plus tôt que les données pour les appareils dotés d'une version antérieure à Android 10. Si c'est le cas, vous verrez les données des appareils dotés d'Android 10+ accessibles uniquement pour les jours où elles le sont.

Remarque : Les mesures Android Vitals excluent les problèmes techniques qui surviennent sur des modèles d'appareils non certifiés ou sur des versions de votre application qui n'ont pas été installées par l'intermédiaire de Google Play.

Tout réduire Tout développer

Stabilité

Mesures du taux d'erreurs ANR

Les mesures du taux d'erreurs ANR fournissent un aperçu de la qualité de votre application. Ces mesures sont calculées en prenant votre nombre d'utilisateurs ayant rencontré des erreurs ANR et en normalisant ceux-ci en fonction de l'utilisation de votre application. Ils sont représentés sous forme de pourcentage d'utilisateurs actifs quotidiens, soit les utilisateurs qui interagissent avec l'application au cours d'une journée donnée sur un appareil donné. Si un utilisateur utilise votre application sur plusieurs appareils au cours d'une même journée, chaque appareil contribuera au nombre d'utilisateurs actifs pour cette journée. Si plusieurs utilisateurs utilisent le même appareil au cours d'une même journée, cela compte comme un seul utilisateur actif.

Il existe trois mesures de taux d'erreurs ANR :

  • Taux d'erreurs ANR perçues par les utilisateurs : le pourcentage de vos utilisateurs actifs quotidiens qui ont rencontré au moins une erreur ANR perceptible. Une erreur ANR perçue par l'utilisateur est une erreur ANR susceptible d'avoir été remarquée par un utilisateur. Actuellement, seules les erreurs ANR de type « délai d'acheminement des entrées expiré » sont comptées. Cette mesure sera toujours inférieure à votre taux d'erreurs ANR global parce qu'elle est normalisée par l'utilisation quotidienne, mais ne compte pas toutes les erreurs ANR.
    Le taux d'erreurs ANR perçues par les utilisateurs est une donnée essentielle, ce qui signifie qu'il a une incidence sur la découvrabilité de votre application sur Google Play. Il revêt son importance du fait que les erreurs ANR qu'il compte se produisent toujours lorsque l'utilisateur interagit avec l'application, causant ainsi les dérangements les plus notables.
  • Taux d'erreurs ANR : le pourcentage de vos utilisateurs quotidiens qui ont rencontré au moins une erreur ANR; cette mesure inclut les erreurs ANR qui ne sont pas classées comme perçues par les utilisateurs, mais nous ne pouvons pas garantir que celles-ci ne les affectent pas.
  • Taux d'erreurs ANR multiples : le pourcentage de vos utilisateurs quotidiens qui ont rencontré au moins deux erreurs ANR; cette mesure aide à mettre en évidence les boucles de problèmes.

Résoudre un problème

Les erreurs ANR qui contribuent à vos mesures de taux d'erreurs ANR sont indiquées sur la page Plantages et applications qui ne répondent pas. Vous pouvez filtrer les erreurs ANR perçues par les utilisateurs sur cette page.

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

Mesures du taux de plantages

Les mesures du taux de plantages fournissent un aperçu de la qualité de votre application. Ces mesures sont calculées en prenant votre nombre d'utilisateurs ayant rencontré des plantages et en normalisant ceux-ci en fonction de l'utilisation de votre application. Ils sont représentés sous forme de pourcentage d'utilisateurs quotidiens, soit les utilisateurs qui interagissent avec l'application au cours d'une journée donnée sur un appareil donné. Un utilisateur interagissant avec plus d'un appareil sera compté plus d'une fois. Par exemple, si deux utilisateurs utilisent l'application pendant deux jours sur un seul appareil chacun, cela produira quatre sessions quotidiennes.

Il existe trois mesures du taux de plantages :

  • Taux de plantages perçus par les utilisateurs : le pourcentage de vos utilisateurs quotidiens qui ont rencontré au moins un plantage perceptible. Un plantage perçu par l'utilisateur est un plantage susceptible d'avoir été remarqué par l'utilisateur. Par exemple, les plantages qui se produisent lorsque votre application affiche une activité ou s'exécute en tant que service en avant-plan. Cette mesure sera toujours inférieure à votre taux de plantages global parce qu'elle est normalisée par l'utilisation quotidienne, mais ne compte pas tous les plantages.
    Le taux de plantages perçus par les utilisateurs est une donnée essentielle, ce qui signifie qu'il a une incidence sur la découvrabilité de votre application sur Google Play. Il revêt son importance du fait que les plantages qu'il compte se produisent toujours lorsque l'utilisateur interagit avec l'application, causant ainsi les dérangements les plus notables. C'est pourquoi vous devez vous assurer que votre application ne dépasse pas le seuil de comportement insatisfaisant pour cette mesure.
  • Taux de plantages : le pourcentage de vos utilisateurs quotidiens qui ont rencontré au moins un plantage; cette mesure inclut les plantages qui ne sont pas classés comme perçus par les utilisateurs, mais nous ne pouvons pas garantir que ceux-ci ne les affectent pas.

  • Taux de plantages multiples : le pourcentage de vos utilisateurs quotidiens qui ont rencontré au moins deux plantages; cette mesure aide à mettre en évidence les boucles de problèmes.

Résoudre un problème

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

Temps de démarrage et de chargement

Durée de démarrage (délai d'affichage initial)

Sur la page Durée de démarrage, vous pourrez consulter les détails sur le démarrage lent de votre application à partir des états de système froid, tiède et chaud. La durée de démarrage mesure le temps qui s'écoule entre le moment où un utilisateur lance votre application et celui où les premières images s'affichent à l'écran. Ce délai est également connu sous le nom de « délai d'affichage initial ».

Il se peut que votre application ne soit pas prête pour que l'utilisateur commence à interagir avec elle après ce délai, par exemple si votre application comporte des écrans de chargement supplémentaires.

Détails de la collecte de données

  • Les durées de démarrage sont uniquement enregistrées lorsqu'un utilisateur déclenche une activité.
    • Exemple : Pour les applications pour le clavier, la durée de démarrage est égale à la durée de démarrage de l'application compagnon.
  • Si une application démarre plusieurs fois le même jour à partir du même état de système, la durée de démarrage maximale de la journée sera enregistrée.
  • Les durées de démarrage sont suivies lorsque la première image de l'application est complètement chargée, même si ce n'est pas un écran avec lequel les utilisateurs interagissent.
    • Exemple : Si une application démarre avec un écran de démarrage, la durée de démarrage est égale au temps nécessaire pour afficher l'écran de démarrage.

Détails importants

  • Sessions concernées : le pourcentage des sessions où les utilisateurs ont constaté une durée de démarrage lent pour chaque état de système respectif :
    • Démarrage à froid lent : 5 secondes ou plus
    • Démarrage tiède lent : 2 secondes ou plus
    • Démarrage à chaud lent : 1 seconde ou plus
  • Nombre de sessions : le nombre approximatif de sessions enregistrées.
  • 90ᵉ/99ᵉ centile : 10 %/1 % des sessions quotidiennes où les utilisateurs ont constaté une durée de démarrage lent pour votre application.

Résoudre un problème

Si votre application connaît un nombre élevé de durées de démarrage lent de l'application, accédez au site pour développeurs Android afin de consulter les solutions recommandées.

Rendu

Tous les rendus

Taux de sessions lentes (30 i/s ou 20 i/s) [jeux uniquement]

Pourquoi c'est important

Utilisez la page Sessions lentes pour mieux comprendre les performances de fréquence d'images de votre jeu, qui influencent la manière dont les utilisateurs perçoivent la fluidité de celui-ci.

Comprendre les données de votre application

Sur la page Sessions lentes, vous verrez des détails sur le pourcentage de sessions quotidiennes pendant lesquelles les utilisateurs ont rencontré plus de 25 % d'images s'exécutant à moins de 30 i/s ou 20 i/s, selon la référence que vous sélectionnez. Vous pouvez également y consulter la répartition des sessions par fréquence d'images pour votre jeu. (La fréquence d'images pour la session est mesurée au 75ᵉ centile, ce qui signifie que 75 % des images atteignent au moins cette fréquence.)

La plupart des jeux sur Google Play devraient viser 30 i/s ou plus. Cela offre une expérience raisonnable aux utilisateurs, quel que soit le type de jeu auquel ils jouent (bien que certains utilisateurs préféreront au moins 60 i/s, en particulier sur les appareils haut de gamme). Surveillez la mesure du taux de sessions lentes (30 i/s) pour vous assurer que vous atteignez ce seuil. Gardez à l'esprit que cette mesure n'inclut que les sessions où plus de 25 % d'images n'atteignent pas 30 i/s; elle a donc une certaine tolérance pour la variabilité de la fréquence d'images.

Bien que 30 i/s offre une expérience raisonnable, il peut y avoir des moments ou des types de jeux pour lesquels il est logique de réduire la fréquence d'images en dessous de cela, ou les utilisateurs peuvent vouloir jouer à votre jeu sur des téléphones qui ne prennent pas en charge 30 i/s. Dans ces scénarios, au moins 75 % des images d'une session doivent encore atteindre 20 i/s ou plus. Surveillez la mesure du taux de sessions lentes (20 i/s) pour vous assurer que vous respectez ce seuil.

Android Vitals signale les sessions lentes (30 i/s) et les sessions lentes (20 i/s) pour chaque appareil ainsi que sur tous les appareils et toutes les sessions. Utilisez la mesure globale pour comprendre votre expérience utilisateur globale, mais faites également attention à la performance par appareil. En temps voulu, Play fera en sorte que les utilisateurs ne voient pas les titres des jeux qui ne peuvent pas atteindre 20 i/s sur leur téléphone.

Vitals ne commence à surveiller la fréquence d'images qu'après que votre jeu a fonctionné pendant une minute.

Détails de la collecte de données

Le calcul de la mesure Sessions lentes est fondé sur les données collectées à partir de 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, et elle inclut les images rendues par OpenGL, Vulkan, ainsi que la trousse d'outils pour IU Android. Cette mesure prend en charge uniquement les jeux à l'heure actuelle.

Les données de fréquence d'images qui alimentent Sessions lentes sont collectées sur les appareils exécutant Android 9 et les versions ultérieures.

Affichage du tableau de bord

  • Fréquence d'images représentative : les performances de fréquence d'images de votre jeu sur les appareils sous Android 9 ou une version ultérieure. Elles sont calculées au 75ᵉ centile, ce qui signifie que 75 % des sessions atteignent cette fréquence d'images ou plus rapide 75 % du temps.
  • Taux de sessions lentes au fil du temps : une série temporelle qui indique le pourcentage de sessions considérées comme lentes.
  • Répartition de la fréquence d'images : un histogramme qui montre la fréquence d'images au 75ᵉ centile pour l'ensemble des sessions, ce qui signifie que 75 % des images d'une session étaient plus rapides que la fréquence d'images utilisée pour compartimenter la session.

Résoudre un problème

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

Rendu de la trousse d'outils pour IU Android

Nombre excessif d'images lentes [applications uniquement]

Comprendre les données de votre application

Sur la page Images excessivement lentes, vous trouverez des détails sur le pourcentage de sessions quotidiennes pendant lesquelles les utilisateurs ont constaté plus de 50 % d'images qui n'ont pas respecté le délai de rendu cible de l'appareil. Les interactions d'utilisateur avec votre application devraient s'exécuter à la vitesse de 60 images/seconde, sans images perdues ni retardées.

Détails de la collecte de données

Google collecte la durée de rendu de chaque image de votre application lors de l'utilisation de la trousse d'outils pour l'IU. Les images rendues directement au moyen d'OpenGL ou de Vulkan ne sont pas collectées.

Affichage du tableau de bord

Lorsque vous sélectionnerez une ligne, la répartition des données s'affichera en centiles.

  • Sessions concernées : le pourcentage des sessions quotidiennes où les utilisateurs ont constaté plus de 50 % d'images avec une durée de rendu supérieure à 16 ms. Une session quotidienne fait référence à une journée au cours de laquelle votre application a été utilisée. Par exemple, si deux utilisateurs se servent de l'application pendant deux jours, cela créera quatre sessions quotidiennes.
  • Nombre de sessions : le nombre approximatif de sessions enregistrées.
  • 90ᵉ/99ᵉ centile : la durée de rendu de 90 %/99 % du nombre total d'images était inférieure au nombre indiqué. Ces chiffres reposent sur toutes les images collectées.

Si vous cliquez sur une entrée du tableau, le graphique « Répartition de la durée de rendu de l'IU » s'affichera. Lorsque vous examinerez le graphique, vous souhaiterez vous assurer que la durée de rendu de la majorité des images de votre application est inférieure à 16 ms.

Les données affichées sous le graphique rapportent la performance de rendu de l'application et peuvent vous permettre de trouver la cause principale des problèmes relatifs à la durée de rendu. Par exemple, si votre pourcentage « Latence d'entrée élevée » est élevé, vous souhaiterez examiner le code de votre application qui gère les entrées de l'utilisateur. Pour en savoir plus sur ces mesures, accédez à la rubrique relative aux tests de performance de l'IU.

  • Événements Vsync manqués : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre d'événements Vsync manqués, divisé par le nombre d'images.
  • Latence d'entrée élevée : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre d'événements d'entrée ayant pris plus de 24 ms, divisé par le nombre d'images.
  • Fil de l'interface utilisateur lent : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre de fils de l'interface utilisateur ayant pris plus de 8 ms pour s'exécuter complètement, divisé par le nombre d'images.
  • Commandes de dessin lentes : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre de fois où l'envoi des commandes de dessin au processeur graphique a pris plus de 12 ms, divisé par le nombre d'images.
  • Téléversements lents de la table de bits : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre de téléversements de la matrice de bits sur le processeur graphique ayant pris plus de 3,2 ms, divisé par le nombre d'images.

Résoudre un problème

Si votre application présente un nombre d'images élevé à une durée de rendu supérieure à 16 ms, accédez au site pour développeurs Android afin de consulter les solutions recommandées.

Nombre excessif d'images figées [applications uniquement]

Comprendre les données de votre application

Sur la page Images excessivement lentes, vous trouverez des détails sur le pourcentage de sessions quotidiennes pendant lesquelles les utilisateurs ont constaté plus de 50 % d'images qui n'ont pas respecté le délai de rendu cible de l'appareil. Les interactions d'utilisateur avec votre application devraient s'exécuter à la vitesse de 60 images/seconde, sans images perdues ni retardées.

Détails de la collecte de données

Google collecte la durée de rendu de chaque image de votre application lors de l'utilisation de la trousse d'outils pour l'IU. Les images rendues directement au moyen d'OpenGL ou de Vulkan ne sont pas collectées.

Affichage du tableau de bord

Lorsque vous sélectionnerez une ligne, la répartition des données s'affichera en centiles.

  • Sessions concernées : le pourcentage des sessions quotidiennes où les utilisateurs ont constaté plus de 50 % d'images avec une durée de rendu supérieure à 16 ms. Une session quotidienne fait référence à une journée au cours de laquelle votre application a été utilisée. Par exemple, si deux utilisateurs se servent de l'application pendant deux jours, cela créera quatre sessions quotidiennes.
  • Nombre de sessions : le nombre approximatif de sessions enregistrées.
  • 90ᵉ/99ᵉ centile : la durée de rendu de 90 %/99 % du nombre total d'images était inférieure au nombre indiqué. Ces chiffres reposent sur toutes les images collectées.

Si vous cliquez sur une entrée du tableau, le graphique « Répartition de la durée de rendu de l'IU » s'affichera. Lorsque vous examinerez le graphique, vous souhaiterez vous assurer que la durée de rendu de la majorité des images de votre application est inférieure à 16 ms.

Les données affichées sous le graphique rapportent la performance de rendu de l'application et peuvent vous permettre de trouver la cause principale des problèmes relatifs à la durée de rendu. Par exemple, si votre pourcentage « Latence d'entrée élevée » est élevé, vous souhaiterez examiner le code de votre application qui gère les entrées de l'utilisateur. Pour en savoir plus sur ces mesures, accédez à la rubrique relative aux tests de performance de l'IU.

  • Événements Vsync manqués : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre d'événements Vsync manqués, divisé par le nombre d'images.
  • Latence d'entrée élevée : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre d'événements d'entrée ayant pris plus de 24 ms, divisé par le nombre d'images.
  • Fil de l'interface utilisateur lent : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre de fils de l'interface utilisateur ayant pris plus de 8 ms pour s'exécuter complètement, divisé par le nombre d'images.
  • Commandes de dessin lentes : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre de fois où l'envoi des commandes de dessin au processeur graphique a pris plus de 12 ms, divisé par le nombre d'images.
  • Téléversements lents de la table de bits : le nombre d'images dont le rendu nécessite plus de 16 ms, multiplié par le nombre de téléversements de la matrice de bits sur le processeur graphique ayant pris plus de 3,2 ms, divisé par le nombre d'images.

Résoudre un problème

Si votre application présente un nombre d'images élevé à une durée de rendu supérieure à 16 ms, accédez au site pour développeurs Android afin de consulter les solutions recommandées.

Utilisation de la pile

Verrous de réveil bloqués et verrous de réveil partiels bloqués (en arrière-plan)

Les pages Verrous de réveil partiels bloqués et Verrous de réveil partiels bloqués (en arrière-plan) indiquent les verrous de réveil partiels acquis par votre application dans la classe PowerManager. Un verrou de réveil partiel assure que le processeur fonctionne, mais que la désactivation du rétroéclairage de l'écran et du clavier sera permise.

Détails de la collecte de données

  • Pour des raisons de confidentialité, les étiquettes d'identification des verrous de réveil partiels sont anonymes.
  • Les données relatives aux verrous de réveil partiels sont collectées lorsque l'appareil n'est pas en charge et que l'écran est éteint.
  • Les données relatives aux verrous de réveil partiels bloqués (en arrière-plan) ne sont collectées que lorsque l'application fonctionne en arrière-plan.
  • Google calcule la durée maximale des verrous de réveil partiels par session de pile pour indiquer le nombre de sessions concernées par un long verrou de réveil. Par exemple, si un utilisateur déclenche des verrous de réveil d'une durée de deux heures, Google utilisera une valeur maximale de verrou de réveil d'une durée d'une heure.
  • Pour les applications qui définissent la valeur sharedUserId dans le fichier de configuration : les données s'afficheront uniquement si un maximum d'une seule application comportant la même valeur sharedUserId est installée.

Détails importants

  • Sessions concernées : le pourcentage des sessions de pile où les utilisateurs ont constaté au moins un verrou de réveil de plus d'une heure.
  • Nombre de sessions : le nombre approximatif de sessions enregistrées.
  • 90ᵉ/99ᵉ centile : 10 %/1 % des sessions quotidiennes où les utilisateurs ont constaté des durées de verrou de réveil partiel supérieures au nombre indiqué.
  • Seuil de comportement insatisfaisant : si votre application affiche un taux d'occurrence égal ou supérieur au seuil indiqué, elle figure dans les 25 % d'applications les moins performantes parmi les 1 000 applications principales sur Google Play (selon le nombre d'installations).

Résoudre un problème

Si votre application connaît un nombre élevé de verrous de réveil partiels bloqués, accédez au site pour développeurs Android pour consulter les solutions recommandées.

Réveils excessifs

La page Réveils excessifs indique les réveils d'Alarm Manager déclenchés par votre application. Les données de réveil s'afficheront pour les catégories ELAPSED_REALTIME_WAKEUP ou RTC_WAKEUP.

Détails de la collecte de données

  • Pour des raisons de confidentialité, les étiquettes d'identification des réveils sont anonymes.
  • Les réveils sont collectés lorsque l'appareil n'est pas en charge.
  • Pour fournir une mesure normalisée, le nombre de réveils est comparé à la durée pendant laquelle l'appareil est branché sur la pile. Google calcule le nombre de réveils par utilisateur et par heure de pile pour indiquer le nombre d'utilisateurs concernés par un taux de réveils élevé.
  • Pour les applications qui définissent la valeur sharedUserId dans le fichier de configuration : les données s'afficheront uniquement si un maximum d'une seule application comportant la même valeur sharedUserId est installée.

Détails importants

  • Sessions concernées : le pourcentage des sessions de pile où les utilisateurs ont constaté plus de 10 réveils par heure. Une session de pile est l'agrégation de tous les rapports de pile reçus au cours d'une période de 24 heures. Sur Android 10, un rapport de pile fait référence à l'intervalle entre deux recharges d'une pile, soit d'une valeur inférieure à 20 % jusqu'à plus de 80 %, soit de toute valeur jusqu'à 100 %. Sur Android 11 ou une version ultérieure, un rapport de pile fait référence à une période fixe de 24 heures. Les données sont uniquement collectées lorsque l'appareil n'est pas en charge.
  • Nombre de sessions : le nombre approximatif de sessions enregistrées.
  • 90ᵉ/99ᵉ centile : 10 %/1 % des sessions quotidiennes où les utilisateurs ont constaté un nombre de réveils par heure supérieur à la valeur indiquée.
  • Seuil de comportement insatisfaisant : si votre application affiche un taux d'occurrence égal ou supérieur au seuil indiqué, elle figure dans les 25 % d'applications les moins performantes parmi les 1 000 applications principales sur Google Play (selon le nombre d'installations).

Résoudre un problème

Si votre application connaît des réveils fréquents, accédez au site pour 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 que les recherches de réseaux Wi-Fi entraînent une utilisation élevée de la pile.

Détails de la collecte de données

Les données sur les recherches de réseaux Wi-Fi sont collectées lorsque l'appareil ne charge pas et que l'application est en arrière-plan.

Détails importants

  • Sessions concernées : le pourcentage des sessions de pile où les utilisateurs ont constaté plus de quatre recherches de réseaux Wi-Fi par heure.
  • Nombre de sessions : le nombre approximatif de sessions enregistrées.
  • 90ᵉ/99ᵉ centile : 10 %/1 % des sessions quotidiennes où les utilisateurs ont constaté plus de recherches de réseaux Wi-Fi en arrière-plan par heure que le nombre affiché.

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 pour 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 qu'une grande quantité de données réseau est associée à un service en arrière-plan. Lorsque l'utilisation du réseau cellulaire se produit en arrière-plan, vos utilisateurs n'ont pas facilement accès aux commandes pour arrêter le transfert de données.

Détails de la collecte de données

Les données sur l'utilisation du réseau cellulaire sont collectées lorsque l'appareil ne charge pas et que l'application est en arrière-plan.

Détails importants

  • Sessions concernées : le pourcentage des sessions de pile où les utilisateurs ont constaté plus de 50 Mo d'utilisation du réseau en arrière-plan par jour.
  • Nombre de sessions : le nombre approximatif de sessions enregistrées.
  • 90ᵉ/99ᵉ centile : 10 %/1 % des sessions quotidiennes où les utilisateurs ont constaté une plus grande utilisation quotidienne du réseau en arrière-plan que le nombre indiqué.

Résoudre un problème

Si votre application utilise beaucoup le réseau en arrière-plan, consultez le site pour développeurs Android afin de connaître les solutions recommandées.

Autorisations

Refus d'autorisation

Dans la page Refus d'autorisation, vous pouvez afficher des détails sur le pourcentage des autorisations relatives aux sessions quotidiennes au cours desquelles les utilisateurs refusent des autorisations. Une autorisation relative à la session quotidienne fait référence à une journée au cours de laquelle votre application a demandé au moins une autorisation à son utilisateur.

Détails de la collecte de données

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

Détails importants

  • Refus : le pourcentage des autorisations relatives à la session quotidienne au cours desquelles les utilisateurs ont refusé des autorisations.
  • Ne plus jamais demander : le pourcentage des autorisations relatives à la session quotidienne au cours desquelles les utilisateurs ont refusé des autorisations en sélectionnant Ne plus jamais demander.
  • Nombre total de sessions : le nombre approximatif de sessions enregistrées.

Résoudre un problème

Si votre application connaît un nombre élevé de refus d'autorisations, accédez au site pour développeurs Android pour consulter les solutions recommandées.

Seuils de comportement insatisfaisant pour les données essentielles

Google Play a défini des seuils de comportement insatisfaisant pour les données essentielles de votre application.

Si votre application dépasse un seuil de comportement insatisfaisant, elle sera probablement moins repérable sur Google Play. Si votre application présente un comportement insatisfaisant sur des modèles d'appareils particuliers, Google Play fera en sorte que les utilisateurs de ces appareils ne voient pas les titres en question, et dirigera les utilisateurs vers d'autres titres mieux adaptés à leurs appareils. Dans certains cas, une mise en garde peut s'afficher sur la fiche Google Play Store de votre application afin de définir les attentes des utilisateurs et d'offrir une option vers d'autres applications de qualité technique supérieure.

En règle générale, Google Play prend en compte les 28 derniers jours de données lors de l'évaluation de la qualité de votre application, mais peut agir plus tôt en cas de hausse.

Tout réduire Tout développer

Stabilité

Seuils de taux d'ANR perçues par les utilisateurs

Google Play a défini des seuils de comportement insatisfaisant pour le taux d'erreurs ANR perçues par les utilisateurs.

  • Comportement insatisfaisant dans l'ensemble : au moins 0,47 % des utilisateurs actifs quotidiens rencontrent au moins une erreur ANR perceptible dans l'ensemble des modèles d'appareils.

  • Comportement insatisfaisant lié à un appareil particulier : au moins 8 % des utilisateurs actifs quotidiens rencontrent au moins une erreur ANR perceptible sur un modèle d'appareil en particulier.

Pour améliorer votre taux d'erreurs ANR, corrigez les grappes d'erreurs ANR sous-jacentes indiquées sur la page Plantages et applications qui ne répondent pas. Plus le nombre d'utilisateurs affectés est élevé, plus la grappe contribue à votre taux d'ANR.

Si des aspects particuliers du matériel ou du logiciel de l'appareil sont susceptibles de contribuer à votre taux d'ANR, Android Vitals vous en informera. Vous pouvez également explorer vous-même les associations sur la page Aperçu de la portée et des appareils (Version > Portée et appareils > Aperçu).

Seuils de taux de plantages perçus par les utilisateurs

Google Play a défini des seuils de comportement insatisfaisant pour le taux de plantages perçus par les utilisateurs.

  • Comportement insatisfaisant dans l'ensemble : au moins 1,09 % des utilisateurs quotidiens rencontrent au moins un plantage perceptible dans l'ensemble des modèles d'appareils.

  • Comportement insatisfaisant lié à un appareil particulier : au moins 8 % des utilisateurs quotidiens rencontrent au moins un plantage perceptible sur un modèle d'appareil en particulier.

Pour améliorer votre taux de plantages, corrigez les grappes de plantages sous-jacentes indiquées sur la page Plantages et applications qui ne répondent pas. Plus le nombre d'utilisateurs affectés est élevé, plus la grappe contribue à votre taux de plantages.

Si des aspects particuliers du matériel ou du logiciel de l'appareil sont susceptibles de contribuer à votre taux de plantages, Android Vitals vous en informera. Vous pouvez également explorer vous-même les associations sur la page Aperçu de la portée et des appareils (Version > Portée et appareils > Aperçu).

Contenu connexe

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

Cela a-t-il été utile?

Comment pouvons-nous améliorer cette page?

Besoin d'aide supplémentaire?

Essayez les étapes suivantes :

Rechercher
Effacer les termes de recherche
Fermer le champ de recherche
Applications Google
Menu principal
12073795584096280998
true
Rechercher dans le Centre d'aide
true
true
true
true
true
92637
false
false