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

Utilisation excessive des 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é des performances.

Cette fonctionnalité renforce 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 l'utilisateur. Nous avons défini un seuil de comportement insatisfaisant pour les wakelocks excessifs. À partir du 1er mars 2026, si votre titre ne respecte pas ce seuil de qualité, nous pourrons l'exclure des surfaces de découverte importantes, telles que les recommandations. Dans certains cas, nous pourrons 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 des wakelocks partiels est excessive si :

• les wakelocks sont conservés pendant au moins deux heures sur une période de 24 heures ;
• cela affecte plus de 5 % des sessions de votre application, en moyenne sur 28 jours.

Les wakelocks créés par les API initiées par l'utilisateur pour l'audio, la localisation et JobScheduler sont exemptés du calcul des wakelocks.

Comprendre les wakelocks

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

Un wakelock partiel maintient le processeur en cours d'exécution même si l'écran est éteint, ce qui empêche le processeur de passer à un état de "suspension" à faible consommation d'énergie. Un wakelock complet maintient l'écran et le processeur en cours d'exécution.

Il existe deux méthodes d'acquisition des wakelocks partiels :

• L'application acquiert et libère manuellement le wakelock à l'aide des API PowerManager pour un cas d'utilisation spécifique. Souvent, il est 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.
• Le wakelock est 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 wakelocks soient nécessaires pour des tâches telles que le téléchargement d'un fichier volumineux initié par l'utilisateur, leur utilisation excessive ou inappropriée peut entraîner une décharge importante de la batterie. Nous avons constaté que des applications conservaient des wakelocks pendant des heures ou ne les libéraient pas correctement, ce qui a entraîné des plaintes d'utilisateurs concernant une décharge importante de la batterie, même lorsqu'ils n'interagissaient pas avec l'application.

Bonnes pratiques pour l'utilisation des wakelocks

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

Réfléchissez à ces quatre questions essentielles.

1. Avez-vous envisagé d'autres options de wakelock ?

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

Organigramme pour décider quand acquérir manuellement un wakelock

1. L'écran doit-il rester allumé ?
   • Oui : consultez plutôt la documentation sur le maintien de 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 affecté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 wakelock.
   • Oui : si vous devez absolument empêcher l'appareil de se mettre en veille, comme lors d'une communication continue avec un appareil externe, continuez.
4. Existe-t-il déjà une API qui maintient l'appareil en veille à votre place ?
   • Vous pouvez consulter 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 autre solution, vous devez acquérir manuellement un wakelock.

2. Nommez-vous correctement le wakelock ?

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

• Ne laissez aucune information personnelle identifiable (IPI) dans le nom, comme des adresses e-mail. Si des IPI sont détectées, le wakelock est enregistré en tant que _UNKNOWN, ce qui entrave le débogage.
• Ne nommez pas votre wakelock par programmation à l'aide de noms de classes ou de méthodes, car ils 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 balises de wakelock. La même balise doit être utilisée chaque fois que le wakelock 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 wakelock, cela peut entraîner une décharge importante de la batterie. 

Par exemple, si une exception non interceptée est générée lors du traitement de processingWork(), l'appel release() peut ne jamais avoir lieu. Vous pouvez 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'expiration au wakelock pour vous assurer qu'il est libéré après une période spécifique, ce qui l'empêche d'être conservé 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 sortie de veille ?

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

• WorkManager : augmentez l'intervalle périodique dans les PeriodicWorkRequests.
• SensorManager : utilisez 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 traitement par lot de la position 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 des 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 détails sur les noms de wakelocks non exemptés associés à votre application, en indiquant les sessions et les durées concernées. N'oubliez pas d'utiliser la documentation pour déterminer si le nom du wakelock est conservé par l'application ou par une autre API.

Le tableau de bord Android Vitals sur les wakelocks partiels excessifs a été fait défiler jusqu'à la section des détails pour afficher les balises de wakelocks excessifs.

Déboguer les wakelocks excessifs conservés par les nœuds de calcul/tâches

Vous pouvez identifier les wakelocks conservés par les nœuds de calcul avec ce nom de wakelock :

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

La liste complète des variantes de noms de wakelocks conservés par les nœuds de calcul est disponible dans la documentation. Pour déboguer ces wakelocks, vous pouvez utiliser Background Task Inspector pour déboguer localement ou utiliser getStopReason pour déboguer les problèmes sur le terrain. 

Background Task Inspector d'Android Studio

Capture d'écran de Background Task Inspector, qui a pu identifier un nœud de calcul "WeatherSyncWorker" qui a fréquemment retenté et échoué.

Pour le débogage local des problèmes WorkManager, utilisez cet outil sur un émulateur ou un appareil connecté (niveau d'API 26 ou supérieur). Il affiche une liste des nœuds de calcul et de leurs états (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 nœuds de calcul. 

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

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

WorkManager getStopReason

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

Cette API permet d'enregistrer la raison pour laquelle un nœud de calcul s'est arrêté (par exemple, STOP_REASON_TIMEOUT, STOP_REASON_QUOTA), en identifiant les problèmes tels que les délais d'attente fréquents dus à l'épuisement de la durée d'exécution.

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 wakelocks conservés manuellement ou des API conservant le wakelock, nous vous recommandons d'utiliser la collecte de traces système pour le débogage.

Collecte de traces système

Une trace système  est un outil de débogage puissant qui capture un enregistrement détaillé de l'activité du système sur une période donnée, fournissant des informations sur l'état du processeur, l'activité des threads, l'activité du réseau et les métriques liées à la batterie, telles que la durée des tâches et l'utilisation des wakelocks.

Vous pouvez capturer une trace système à l'aide de plusieurs méthodes :

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

Activez la catégorie Atrace "power:PowerManagement" dans l'interface utilisateur de Perfetto sous l'onglet "Android apps & svcs". 

Quelle que soit la méthode choisie, il est essentiel de vous assurer que vous collectez la catégorie Atrace "power:PowerManagement" pour permettre l'affichage des pistes d'état de l'appareil. 

Inspection de l'interface utilisateur de Perfetto et analyse SQL

Les traces système peuvent être ouvertes et inspectées dans l'interface utilisateur de Perfetto. Lorsque vous ouvrez la trace, vous voyez une visualisation de différents processus sur une chronologie. Les pistes sur lesquelles nous allons nous concentrer dans ce guide sont celles qui se trouvent sous "Device State" (État de l'appareil).

Épinglez les pistes sous "Device State" (État de l'appareil), telles que "Top app" (Application principale), "Screen state" (État de l'écran), "Long Wake locks" (Wakelocks longs) et "Jobs" (Tâches), pour identifier visuellement les tranches de wakelocks de longue durée.

Chaque bloc répertorie le nom de l'événement, son heure de début et son heure de fin. Dans Perfetto, cela s'appelle 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 wakelocks triés par durée, ce qui permet d'identifier les principaux contributeurs à une utilisation excessive.

Voici un exemple de requête qui additionne toutes les balises de wakelock qui se sont produites dans la trace système, triées 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 plus de contrôle sur les points de déclenchement de début et de fin pour 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 de ProfilingManager pour connaître les étapes à suivre pour implémenter la collecte de traces système sur le terrain, y compris comment capturer une trace par programmation, analyser les données de profilage et utiliser les commandes de débogage locales.

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

Conclusion

La métrique de wakelock partiel excessif dans Android Vitals n'est 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. L'utilisation d'API alternatives, le respect des bonnes pratiques concernant les wakelocks et l'utilisation d'outils de débogage puissants tels que Background Task Inspector, les traces système et ProfilingManager sont essentiels pour assurer le succès de votre application sur Google Play.