L'autonomie de la batterie est un aspect essentiel de l'expérience utilisateur, et les verrous de réveil jouent un rôle majeur. Les utilisez-vous de manière excessive ? Dans cet article de blog, nous allons explorer ce que sont les verrous de réveil, les bonnes pratiques pour les utiliser et comment mieux comprendre le comportement de votre propre application grâce à la métrique de la Play Console.

Utilisation excessive de wakelocks partiels dans Android Vitals

La Play Console surveille désormais la décharge de la batterie, en se concentrant sur l'utilisation excessive des wakelocks partiels comme indicateur clé de performance.

Cette fonctionnalité met en avant l'importance de l'efficacité de la batterie, en plus des indicateurs de stabilité des métriques principales existants (plantages et erreurs ANR excessifs perçus par les utilisateurs). Nous avons défini un seuil de comportement insatisfaisant pour les wakelocks excessifs. À partir du 1er mars 2026, si votre titre ne répond pas à ce seuil de qualité, nous pourrons l'exclure des surfaces de découverte mises en avant, comme les recommandations. Dans certains cas, nous pouvons afficher un avertissement sur votre fiche Play Store pour indiquer aux utilisateurs que votre application peut entraîner une décharge excessive de la batterie.

Avertissement concernant les wakelocks excessifs dans la vue d'ensemble Android Vitals

Pour les appareils mobiles, la métrique Android Vitals s'applique aux wakelocks non exemptés acquis lorsque l'écran est éteint et que l'application est en arrière-plan ou exécute un service de premier plan. Android Vitals considère que l'utilisation de wakelocks partiels est excessive si :

• Les verrous de réveil sont maintenus pendant au moins deux heures sur une période de 24 heures.
• Elle affecte plus de 5 % des sessions de votre application, en moyenne sur 28 jours.

Les wake locks créés par les API initiées par l'utilisateur audio, location et JobScheduler sont exemptés du calcul des wake locks.

Comprendre les wakelocks

Un wakelock est un mécanisme qui permet à une application de maintenir le processeur d'un appareil en fonctionnement, même lorsque l'utilisateur n'interagit pas activement avec lui. 

Un wakelock partiel maintient le processeur en fonctionnement même si l'écran est éteint, ce qui l'empêche de passer en mode veille à faible consommation d'énergie. Les wakelocks complets permettent de maintenir l'écran et le processeur allumés.

Il existe deux méthodes pour acquérir des verrous partiels de réveil :

• L'application acquiert et libère manuellement le verrouillage de réveil à l'aide des API PowerManager pour un cas d'utilisation spécifique. Il est souvent acquis en même temps qu'un service de premier plan, une API de cycle de vie de plate-forme destinée à une opération perceptible par l'utilisateur.
• Il est également possible que le wakelock soit acquis par une autre API et attribué à l'application en raison de l'utilisation de l'API. Pour en savoir plus, consultez la section sur les bonnes pratiques.

Bien que les verrous de réveil soient nécessaires pour des tâches telles que le téléchargement d'un fichier volumineux lancé par l'utilisateur, leur utilisation excessive ou inappropriée peut entraîner une décharge importante de la batterie. Nous avons constaté que certaines applications conservent des verrous de réveil pendant des heures ou ne les libèrent pas correctement, ce qui entraîne des plaintes d'utilisateurs concernant une décharge importante de la batterie, même lorsqu'ils n'interagissent pas avec l'application.

Bonnes pratiques d'utilisation des wakelocks

Avant de voir comment déboguer l'utilisation excessive de wake locks, assurez-vous de suivre les bonnes pratiques concernant les wake locks. 

Posez-vous ces quatre questions essentielles.

1. Avez-vous envisagé d'autres options de verrouillage de l'écran ?

Avant d'envisager d'acquérir un wakelock partiel manuel, suivez cet organigramme de décision :

Organigramme pour déterminer quand acquérir manuellement un verrouillage de réveil

1. L'écran doit-il rester allumé ?
   • Oui : consultez plutôt la documentation Garder l'écran allumé.
2. L'application exécute-t-elle un service de premier plan ?
   • Non : vous n'avez pas besoin d'acquérir manuellement un wakelock.
3. L'expérience utilisateur est-elle dégradée si l'appareil se met en veille ?
   • Non : par exemple, la mise à jour d'une notification après la sortie de veille de l'appareil ne nécessite pas de verrouillage de sortie de veille.
   • Oui : si la suspension de l'appareil doit absolument être évitée (par exemple, en cas de communication en cours avec un appareil externe), continuez.
4. Existe-t-il déjà une API qui maintient l'appareil activé pour vous ?
   • Vous pouvez utiliser la documentation Identifier les wakelocks créés par d'autres API pour identifier les scénarios dans lesquels des wakelocks sont créés par d'autres API, telles que LocationManager.
   • Si aucune API n'existe, passez à la dernière question.
5. Si vous avez répondu à toutes ces questions et déterminé qu'il n'existe aucune alternative, vous devez procéder à l'acquisition manuelle d'un wakelock.

2. Avez-vous correctement nommé le wake lock ?

Lorsque vous acquérez manuellement des verrous de réveil, il est important de les nommer correctement pour le débogage :

• N'indiquez aucune information permettant d'identifier personnellement l'utilisateur dans le nom, comme une adresse e-mail. Si des informations permettant d'identifier personnellement l'utilisateur sont détectées, le verrouillage de l'activation est enregistré en tant que _UNKNOWN, ce qui entrave le débogage.
• Ne nommez pas votre verrouillage de réveil par programmation à l'aide de noms de classes ou de méthodes, car ceux-ci peuvent être obscurcis par des outils tels que Proguard. Utilisez plutôt une chaîne codée en dur.
• N'ajoutez pas de compteurs ni d'identifiants uniques aux identificateurs de wakelock. La même balise doit être utilisée chaque fois que le verrouillage de réveil s'exécute pour permettre au système d'agréger l'utilisation par nom, ce qui facilite la détection des comportements anormaux.

3. Le wakelock acquis est-il toujours libéré ?

Si vous acquérez un wakelock manuellement, assurez-vous que la libération du wakelock s'exécute toujours. Si vous ne libérez pas un verrouillage de réveil, la batterie peut se décharger considérablement. 

Par exemple, si une exception non interceptée est levée lors de processingWork(), l'appel release() peut ne jamais se produire. Vous pouvez plutôt utiliser un bloc try-finally pour garantir la libération du wakelock, même en cas d'exception.

Vous pouvez également ajouter un délai d'inactivité au wakelock pour vous assurer qu'il se libère après une période spécifique, ce qui l'empêche d'être maintenu indéfiniment.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. Pouvez-vous réduire la fréquence de réveil ?

Pour les requêtes de données périodiques, il est essentiel de réduire la fréquence à laquelle votre application réactive l'appareil pour optimiser l'autonomie de la batterie. Voici quelques exemples de réduction de la fréquence de réveil :

• WorkManager : augmentez l'intervalle périodique dans les PeriodicWorkRequest.
• SensorManager : exploitez le traitement par lot en spécifiant maxReportLatencyMs lors de l'enregistrement de l'écouteur.
• Fused Location Provider :
  • Réduisez la fréquence de récupération de la position en utilisant getLastLocation pour la position mise en cache la plus récente.
  • Utilisez setPriority(PRIORITY_PASSIVE) pour une méthode de mise à jour moins gourmande en batterie.
  • Vous pouvez également utiliser le mécanisme de regroupement des positions en définissant un intervalle de mise à jour minimal avec setMinUpdateIntervalMillis.

Pour en savoir plus, consultez la documentation sur les bonnes pratiques concernant les wakelocks.

Déboguer l'utilisation excessive de wakelocks

Même avec les meilleures intentions, une utilisation excessive des wakelocks peut se produire. Si votre application est signalée dans la Play Console, voici comment la déboguer :

Identification initiale avec la Play Console

Le tableau de bord Android Vitals sur les wakelocks partiels excessifs fournit des informations détaillées sur les noms de wakelocks non exemptés associés à votre application, en indiquant les sessions et les durées concernées. Rappel d'utiliser la documentation pour vous aider à identifier si le nom du wakelock est détenu par l'application ou par une autre API.

Tableau de bord Android Vitals "Trop de wakelocks partiels" avec la section "Répartitions" affichée pour voir les tags de wakelocks excessifs.

Déboguer les wake locks excessifs détenus par les workers/jobs

Vous pouvez identifier les wakelocks détenus par le Worker avec ce nom de wakelock :

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

La liste complète des variantes de noms de verrouillage de réveil détenus par le Worker est disponible dans la documentation. Pour déboguer ces verrous de réveil, vous pouvez utiliser Background Task Inspector pour déboguer localement ou utiliser getStopReason pour déboguer les problèmes sur le terrain. 

Inspecteur des tâches en arrière-plan d'Android Studio

Capture d'écran de Background Task Inspector, où un worker "WeatherSyncWorker" a été identifié comme ayant fréquemment effectué des nouvelles tentatives et échoué.

Pour déboguer localement les problèmes liés à WorkManager, utilisez cet outil sur un émulateur ou un appareil connecté (niveau d'API 26 ou supérieur). Il affiche une liste des workers et de leur état (terminé, en cours d'exécution, en file d'attente), ce qui vous permet d'inspecter les détails et de comprendre les chaînes de workers. 

Par exemple, il peut révéler si un nœud de calcul échoue ou effectue de nouvelles tentatives fréquemment en raison de limitations du système. 

Pour en savoir plus, consultez la documentation sur Background Task Inspector.

WorkManager getStopReason

Pour déboguer sur le terrain les nœuds de calcul avec des verrous de réveil excessifs, utilisez WorkInfo.getStopReason() sur WorkManager 2.9.0 ou version ultérieure, ou JobParameters.getStopReason() pour JobScheduler, disponible sur le SDK 31 ou version ultérieure. 

Cette API permet d'enregistrer la raison pour laquelle un worker s'est arrêté (par exemple, STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), ce qui permet d'identifier les problèmes tels que les délais d'attente fréquents dus à une durée d'exécution épuisée.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

Pour en savoir plus, consultez Optimiser l'utilisation de la batterie pour les API de planification des tâches.

Déboguer d'autres types de wakelocks excessifs

Pour les scénarios plus complexes impliquant des verrous de réveil manuels ou des API détenant le verrou de réveil, nous vous recommandons d'utiliser la collecte de trace système pour le débogage.

Collecte de traces système

Une trace système  est un outil de débogage puissant qui enregistre en détail l'activité du système sur une période donnée. Elle fournit des informations sur l'état du processeur, l'activité des threads, l'activité réseau et les métriques liées à la batterie, comme la durée des tâches et l'utilisation des wake locks.

Vous pouvez capturer une trace système de plusieurs façons :

• Utiliser l'outil de ligne de commande de trace système
• Utiliser le Profileur de processeur Android Studio
• Utiliser l'interface utilisateur Perfetto
• Enregistrez une trace manuellement sur l'appareil directement à partir des options pour les développeurs. 

Activez la catégorie Atrace "power:PowerManagement" dans l'interface utilisateur Perfetto, sous l'onglet "Android apps & svcs" (Applications et services Android).  

Quelle que soit la méthode choisie, il est essentiel de vous assurer de collecter la catégorie Atrace "power:PowerManagement" pour pouvoir afficher les pistes d'état de l'appareil. 

Inspection de l'UI Perfetto et analyse SQL

Vous pouvez ouvrir et inspecter les traces système dans l'interface utilisateur de Perfetto. Lorsque vous ouvrez la trace, vous voyez une visualisation de différents processus sur une timeline. Dans ce guide, nous nous concentrerons sur les pistes sous "État de l'appareil".

Épinglez les pistes sous "État de l'appareil", telles que "Application principale", "État de l'écran", "Verrouillages de réveil longs" et "Jobs", pour identifier visuellement les tranches de verrouillage de réveil de longue durée.

Chaque bloc indique le nom de l'événement, ainsi que ses dates de début et de fin. Dans Perfetto, on appelle cela une tranche.

Pour une analyse évolutive de plusieurs traces, vous pouvez utiliser l'analyse SQL de Perfetto. Une requête SQL peut trouver tous les verrous de réveil triés par durée, ce qui permet d'identifier les principaux contributeurs à une utilisation excessive.

Voici un exemple de requête qui additionne tous les tags de verrouillage de réveil qui se sont produits dans la trace système, classés par durée totale :

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

Utiliser ProfilingManager pour la collecte de traces sur le terrain

Pour les problèmes difficiles à reproduire, ProfilingManager (ajouté dans le SDK 35) est une API programmatique qui permet aux développeurs de collecter des traces système sur le terrain avec des déclencheurs de début et de fin. Il offre un meilleur contrôle sur les points de déclenchement de début et de fin de la collecte de profils, et applique une limitation du débit au niveau du système pour éviter tout impact sur les performances de l'appareil. 

Consultez la documentation ProfilingManager pour découvrir comment implémenter la collecte de trace système sur le terrain, y compris comment capturer une trace de manière programmatique, analyser les données de profilage et utiliser les commandes de débogage local.

Les traces système collectées à l'aide de ProfilingManager ressemblent à celles collectées manuellement, mais les processus système et les autres processus d'application sont masqués dans la trace.

Conclusion

La métrique "Nombre de wakelocks partiels excessifs" dans Android Vitals ne représente qu'une petite partie de notre engagement continu à aider les développeurs à réduire la décharge de la batterie et à améliorer la qualité des applications. 

En comprenant et en implémentant correctement les wakelocks, vous pouvez optimiser considérablement les performances de la batterie de votre application. Pour assurer le succès de votre application sur Google Play, il est essentiel d'exploiter des API alternatives, de respecter les bonnes pratiques concernant les wakelocks et d'utiliser des outils de débogage puissants tels que Background Task Inspector, les traces système et ProfilingManager.