Application des règles de qualité technique concernant la batterie : comment optimiser les cas d'utilisation courants des wakelocks

Google a pris des mesures importantes pour aider les développeurs à créer des applications plus économes en énergie, car la décharge excessive de la batterie est une préoccupation majeure pour les utilisateurs d'Android. Le 1er mars 2026, le Google Play Store a commencé à déployer les traitements de qualité technique des wakelocks pour améliorer la décharge de la batterie. Ce traitement sera déployé progressivement dans les applications concernées au cours des prochaines semaines. Les applications qui dépassent systématiquement le seuil "Trop de wakelocks partiels" dans Android Vitals peuvent avoir un impact tangible sur leur présence dans le Play Store, y compris des avertissements sur leur fiche Play Store et une exclusion des surfaces de découverte telles que les recommandations.

Les utilisateurs peuvent voir un avertissement sur votre fiche Play Store si votre application dépasse le seuil de comportement insatisfaisant. 

Cette initiative a élevé l'efficacité de la batterie au rang de métrique vitale de base, aux côtés des métriques de stabilité telles que les plantages et les erreurs ANR. Le "seuil de comportement insatisfaisant" est défini comme le maintien d'un wakelock partiel non exempté pendant au moins deux heures en moyenne lorsque l'écran est éteint dans plus de 5% des sessions utilisateur au cours des 28 derniers jours. Un wakelock est exempté s'il s'agit d'un wakelock détenu par le système qui offre des avantages clairs à l'utilisateur et qui ne peut pas être optimisé davantage, comme la lecture audio, l'accès à la position ou le transfert de données déclenché par l'utilisateur. Vous pouvez consulter la définition complète des wakelocks excessifs dans notre documentation Android Vitals.

Dans le cadre de notre initiative visant à améliorer l'autonomie de la batterie dans l'écosystème Android, nous avons analysé des milliers d'applications et leur utilisation des wakelocks partiels. Bien que les wakelocks soient parfois nécessaires, nous constatons souvent que les applications les maintiennent de manière inefficace ou inutile, alors que des solutions plus efficaces existent. Cet article de blog abordera les scénarios les plus courants dans lesquels des wakelocks excessifs se produisent, ainsi que nos recommandations pour optimiser les wakelocks.Nous avons déjà constaté des résultats mesurables chez des partenaires tels que WHOOP, qui ont utilisé ces recommandations pour optimiser leur comportement en arrière-plan.

Utiliser un service de premier plan ou des wakelocks partiels

Nous avons souvent vu des développeurs avoir du mal à comprendre la différence entre deux concepts lors de l'exécution en arrière-plan : le service de premier plan et les wakelocks partiels.

Un service de premier plan est une API de cycle de vie qui signale au système qu'une application effectue un travail perceptible par l'utilisateur et ne doit pas être arrêtée pour récupérer de la mémoire, mais elle n'empêche pas automatiquement le processeur de se mettre en veille lorsque l'écran s'éteint. En revanche, un wakelock partiel est un mécanisme spécialement conçu pour maintenir le processeur en cours d'exécution même lorsque l'écran est éteint. 

Bien qu'un service de premier plan soit souvent nécessaire pour poursuivre une action de l'utilisateur, une acquisition manuelle d'un wakelock partiel n'est nécessaire qu'en association avec un service de premier plan pendant la durée de l'activité du processeur. De plus, vous n'avez pas besoin d'utiliser un wakelock si vous utilisez déjà une API qui maintient l'appareil activé. 

Reportez-vous à l'organigramme de la section Choisir la bonne API pour maintenir l'appareil activé afin de bien comprendre l'outil à utiliser pour éviter d'acquérir un wakelock dans les scénarios où il n'est pas nécessaire.

Bibliothèques tierces acquérant des wakelocks

Il est courant qu'une application découvre qu'elle est signalée pour des wakelocks excessifs détenus par un SDK tiers ou une API système agissant en son nom. Pour identifier et résoudre ces wakelocks, nous vous recommandons de procéder comme suit :

• Vérifiez Android Vitals : recherchez le nom exact du wakelock problématique dans le tableau de bord des wakelocks partiels excessifs. Comparez ce nom avec les instructions Identifier les wakelocks créés par d'autres API pour voir s'il a été créé par une API système connue ou une bibliothèque Jetpack. Si c'est le cas, vous devrez peut-être optimiser votre utilisation de l'API et vous pourrez vous reporter aux instructions recommandées.
• Capturez une trace système : si le wakelock ne peut pas être facilement identifié, reproduisez le problème de wakelock localement à l'aide d'une trace système et inspectez-le avec l'interface utilisateur Perfetto. Pour en savoir plus, consultez la section __Déboguer d'autres types de wakelocks excessifs__ de cet article de blog.
• Évaluez les alternatives : si une bibliothèque tierce inefficace est responsable et ne peut pas être configurée pour respecter l'autonomie de la batterie, envisagez de communiquer le problème aux propriétaires du SDK, de trouver un autre SDK ou de créer la fonctionnalité en interne.

Scénarios courants de wakelocks

Vous trouverez ci-dessous une présentation de certains cas d'utilisation spécifiques que nous avons examinés, ainsi que la méthode recommandée pour optimiser l'implémentation de vos wakelocks.

Importation ou téléchargement déclenché par l'utilisateur

Exemples d'utilisation :

• Applications de streaming vidéo dans lesquelles l'utilisateur déclenche le téléchargement d'un fichier volumineux pour un accès hors connexion.
• Applications de sauvegarde de contenus multimédias dans lesquelles l'utilisateur déclenche l'importation de ses photos récentes via une invite de notification.

Comment réduire les wakelocks : 

• N'acquérez pas de wakelock manuel. Utilisez plutôt l'API User-Initiated Data Transfer (UIDT). Il s'agit du chemin désigné pour les tâches de transfert de données de longue durée lancées par l'utilisateur, et il est exempté des calculs de wakelocks excessifs.

Synchronisations en arrière-plan ponctuelles ou périodiques

Exemples d'utilisation :

• Une application effectue des synchronisations périodiques en arrière-plan pour récupérer des données pour un accès hors connexion. 
• Applications de podomètre qui récupèrent périodiquement le nombre de pas.

Comment réduire les wakelocks :

• N'acquérez pas de wakelock manuel. Utilisez WorkManager configuré pour un travail ponctuel ou périodique. WorkManager respecte l'état du système en regroupant les tâches et dispose d'un intervalle périodique minimal (15 minutes), ce qui est généralement suffisant pour les mises à jour en arrière-plan. 
• Si vous identifiez des wakelocks créés par WorkManager ou JobScheduler avec une utilisation élevée des wakelocks, cela peut être dû au fait que vous avez mal configuré votre worker pour qu'il ne se termine pas dans certains scénarios. Envisagez d'analyser les raisons d'arrêt du worker, en particulier si vous constatez une fréquence élevée de STOP_REASON_TIMEOUT. 

workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

• En plus d'enregistrer les raisons d'arrêt du worker, consultez notre documentation sur le débogage de vos workers. Envisagez également de collecter et d'analyser des traces système pour comprendre quand les wakelocks sont acquis et libérés.
• Enfin, consultez notre étude de cas avec WHOOP, qui a pu découvrir un problème de configuration de ses workers et réduire considérablement l’impact de ses wakelocks.

Communication Bluetooth

Exemples d'utilisation :

• L'application de l'appareil associé invite l'utilisateur à associer son appareil externe Bluetooth.
• L'application de l'appareil associé écoute les événements matériels sur un appareil externe et les modifications visibles par l'utilisateur dans la notification.
• L'utilisateur de l'application de l'appareil associé lance un transfert de fichiers entre l'appareil mobile et l'appareil Bluetooth.
• L'application de l'appareil associé effectue des mises à jour occasionnelles du micrologiciel sur un appareil externe via Bluetooth.

Comment réduire les wakelocks :

• Utilisez l'association d'appareils associés pour associer des appareils Bluetooth afin d'éviter d'acquérir un wakelock manuel lors de l'association Bluetooth. 
• Consultez les instructions ____Communiquer en arrière-plan pour comprendre comment effectuer une communication Bluetooth en arrière-plan. 
• L'utilisation de WorkManager est souvent suffisante s'il n'y a pas d'impact sur l'utilisateur en cas de communication retardée. Si un wakelock manuel est jugé nécessaire, ne le maintenez que pendant la durée de l'activité Bluetooth ou du traitement des données d'activité.

Localisation

Exemples d'utilisation :

• Applications de fitness qui mettent en cache les données de localisation pour une importation ultérieure, par exemple pour tracer des itinéraires de course.
• Applications de livraison de nourriture qui extraient des données de localisation à haute fréquence pour mettre à jour la progression de la livraison dans une notification ou une interface utilisateur de widget.

Comment réduire les wakelocks :

• Consultez nos instructions pour optimiser l'utilisation de la localisation. Envisagez d'implémenter des délais d'inactivité, d'utiliser le traitement par lots des requêtes de localisation ou d'utiliser des mises à jour passives de la localisation pour garantir l'efficacité de la batterie.
• Lorsque vous demandez des mises à jour de la localisation à l'aide des API FusedLocationProvider ou LocationManager, le système déclenche automatiquement un réveil de l'appareil lors du rappel de l'événement de localisation. Ce wakelock bref et géré par le système est exempté des calculs de wakelocks partiels excessifs.
• Évitez d'acquérir un wakelock continu distinct pour la mise en cache des données de localisation, car cela est redondant. Au lieu de cela, conservez les événements de localisation en mémoire ou dans le stockage local, et utilisez WorkManager pour les traiter à intervalles réguliers.

override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

Surveillance des capteurs à haute fréquence

Exemples d'utilisation :

• Applications de podomètre qui collectent passivement les pas ou la distance parcourue. 
• Applications de sécurité qui surveillent les capteurs de l'appareil pour détecter des changements rapides en temps réel, afin de fournir des fonctionnalités telles que la détection des accidents ou des chutes.

Comment réduire les wakelocks :

• Si vous utilisez SensorManager, réduisez l'utilisation à des intervalles périodiques et uniquement lorsque l'utilisateur a explicitement accordé l'accès via une interaction avec l'interface utilisateur. La surveillance des capteurs à haute fréquence peut décharger considérablement la batterie en raison du nombre de réveils et de traitements du processeur.
• Si vous suivez le nombre de pas ou la distance parcourue, plutôt que d'utiliser SensorManager, utilisez l'API Recording ou envisagez d'utiliser Health Connect pour accéder aux nombres de pas historiques et agrégés de l'appareil afin de capturer les données de manière économe en énergie.
• Si vous enregistrez un capteur avec SensorManager, spécifiez un maxReportLatencyUs de 30 secondes ou plus pour utiliser le traitement par lots des capteurs afin de minimiser la fréquence des interruptions du processeur. Lorsque l'appareil est ensuite réactivé par un autre déclencheur, tel qu'une interaction de l'utilisateur, une récupération de la position ou un job planifié, le système envoie immédiatement les données des capteurs mises en cache.

val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

• Si votre application nécessite à la fois des données de localisation et des données de capteur, synchronisez leur récupération et leur traitement. En ajoutant des lectures de capteur au bref wakelock que le système conserve pour les mises à jour de la localisation, vous évitez d'avoir besoin d'un wakelock pour maintenir le processeur activé. Utilisez un worker ou un wakelock de courte durée pour gérer l'importation et le traitement de ces données combinées.

Messagerie à distance

Exemples d'utilisation :

• Applications compagnons de surveillance vidéo ou audio qui doivent surveiller les événements qui se produisent sur un appareil externe connecté à l'aide d'un réseau local.
• Applications de messagerie qui maintiennent une connexion de socket réseau avec la variante de bureau.

Comment réduire les wakelocks :

• Si les événements réseau peuvent être traités côté serveur, utilisez FCM pour recevoir des informations sur le client. Vous pouvez choisir de planifier un worker accéléré si un traitement supplémentaire des données FCM est nécessaire. 
• Si les événements doivent être traités côté client via une connexion de socket, un wakelock n'est pas nécessaire pour écouter les interruptions d'événements. Lorsque des paquets de données arrivent sur la radio Wi-Fi ou cellulaire, le matériel radio déclenche une interruption matérielle sous la forme d'un wakelock de noyau. Vous pouvez ensuite choisir de planifier un worker ou d'acquérir un wakelock pour traiter les données.
• Par exemple, si vous utilisez ktor-network pour écouter les paquets de données sur un socket réseau, vous ne devez acquérir un wakelock que lorsque les paquets ont été livrés au client et doivent être traités.

val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

Résumé

En adoptant ces solutions recommandées pour les cas d'utilisation courants tels que les synchronisations en arrière-plan, le suivi de la localisation, la surveillance des capteurs et la communication réseau, les développeurs peuvent réduire l'utilisation inutile des wakelocks. Pour en savoir plus, consultez notre autre article de blog technique ou regardez notre vidéo technique sur la découverte et le débogage des wakelocks : Optimiser la batterie de votre application à l'aide de la métrique de wakelock Android Vitals. Consultez également notre documentation mise à jour sur les wakelocks. Pour nous aider à continuer d'améliorer nos ressources techniques, veuillez nous faire part de vos commentaires supplémentaires sur nos instructions dans notre enquête de commentaires sur la documentation.