Google a pris des mesures importantes pour aider les développeurs à créer des applications plus économes en énergie, car il sait que 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 wake locks pour réduire 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 régulièrement le seuil "Wakelock partiel excessif" dans Android Vitals peuvent avoir un impact tangible sur leur présence sur le Play Store, y compris des avertissements sur leur fiche Play Store et leur exclusion des surfaces de découverte telles que les recommandations.

Si votre application dépasse le seuil de comportement insatisfaisant, les utilisateurs pourront voir un avertissement sur votre fiche Play Store. 

Cette initiative a fait de l'efficacité de la batterie une métrique vitale principale, au même titre que les métriques de stabilité telles que les plantages et les erreurs ANR. Le "seuil de comportement insatisfaisant" est défini comme le fait de détenir 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. Une wake lock est exemptée s'il s'agit d'une wake lock détenue par le système qui offre des avantages clairs aux utilisateurs et qui ne peut pas être optimisée davantage, comme la lecture audio, l'accès à la position ou le transfert de données initié par l'utilisateur. Vous trouverez la définition complète des wakelocks excessifs dans la documentation Android Vitals.

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

Utiliser un service de premier plan ou des verrous de réveil partiels

Nous avons souvent constaté que les développeurs avaient du mal à comprendre la différence entre deux concepts lors de l'exécution en arrière-plan : les services de premier plan et les verrous de réveil partiels.

Un service de premier plan est une API de cycle de vie qui indique 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. Toutefois, il n'empêche pas automatiquement le processeur de se mettre en veille lorsque l'écran s'éteint. En revanche, un verrouillage partiel de l'écran est un mécanisme spécifiquement conçu pour maintenir le processeur en fonctionnement 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 verrouillage partiel de réveil 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 de wakelock si vous utilisez déjà une API qui maintient l'appareil en éveil. 

Consultez l'organigramme dans Choisir la bonne API pour que l'appareil reste activé pour bien comprendre l'outil à utiliser afin d'éviter d'acquérir un verrouillage de réveil dans les scénarios où ce 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 un nombre excessif de verrous de réveil détenus par un SDK tiers ou une API système agissant en son nom. Pour identifier et résoudre ces problèmes de verrouillage de réveil, nous vous recommandons de suivre les étapes suivantes :

• Vérifiez Android Vitals : recherchez le nom exact du wakelock incriminé dans le tableau de bord "Wakelocks partiels excessifs". Croisez ce nom avec les conseils de la section Identifier les wakelocks créés par d'autres API pour voir s'il a été créé par une bibliothèque Jetpack ou une API système connue. Si c'est le cas, vous devrez peut-être optimiser votre utilisation de l'API et consulter les conseils recommandés.
• Capturez une trace système : si le verrouillage de réveil ne peut pas être identifié facilement, reproduisez le problème de verrouillage de réveil en local à 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 wake locks 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 liste de cas d'utilisation spécifiques que nous avons examinés, ainsi que la méthode recommandée pour optimiser l'implémentation de votre verrouillage de réveil.

Importation ou téléchargement initiés par l'utilisateur

Exemples de cas d'utilisation : 

• Applications de streaming vidéo dans lesquelles l'utilisateur déclenche le téléchargement d'un fichier volumineux pour y accéder 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'accès désigné pour les tâches de transfert de données de longue durée lancées par l'utilisateur. Il est exempté des calculs excessifs de wake lock.

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

Exemples de cas d'utilisation : 

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

Comment réduire les wakelocks ?

• N'acquérez pas de wakelock manuel. Utilisez WorkManager configuré pour les tâches ponctuelles ou périodiques. WorkManager respecte l'état du système en regroupant les tâches par lots et en définissant 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 wake locks créés par WorkManager ou JobScheduler avec une utilisation élevée des wake locks, cela peut être dû à une mauvaise configuration de votre nœud de calcul qui ne se termine pas dans certains scénarios. Envisagez d'analyser les raisons de l'arrêt des nœuds de calcul, en particulier si vous constatez de nombreuses occurrences 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 de l'arrêt des nœuds de calcul, consultez notre documentation sur le débogage de vos nœuds de calcul. Pensez également à collecter et à analyser les traces système  pour comprendre quand les verrous de réveil sont acquis et libérés.
• Enfin, consultez notre étude de cas avec WHOOP. L'entreprise a pu identifier un problème de configuration de ses workers et réduire considérablement l'impact de ses wake locks.

Communication Bluetooth

Exemples de cas 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 changements visibles par l'utilisateur dans la notification.
• L'utilisateur de l'application de l'appareil associé lance un transfert de fichier entre l'appareil mobile et l'appareil Bluetooth.
• L'application de l'appareil associé effectue des mises à jour occasionnelles du micrologiciel d'un appareil externe via Bluetooth.

Comment réduire les wakelocks ?

• Utilisez l'association d'appareils associés pour associer des appareils Bluetooth et éviter d'acquérir un verrouillage manuel de l'activation pendant l'association Bluetooth. 
• Consultez les consignes  Communiquer en arrière-plan pour savoir comment communiquer par Bluetooth en arrière-plan. 
• L'utilisation de WorkManager est souvent suffisante si la communication différée n'a aucune incidence sur les utilisateurs. Si un verrouillage de réveil 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 de cas d'utilisation : 

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

Comment réduire les wakelocks ?

• Consultez nos conseils pour optimiser l'utilisation des lieux. Envisagez d'implémenter des délais d'attente, d'utiliser le traitement par lot des requêtes de localisation ou d'utiliser des mises à jour de position passives pour garantir l'efficacité de la batterie.
• Lorsque vous demandez des mises à jour de la position à 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 wakelock partiel excessif.
• Évitez d'acquérir un verrouillage de réveil 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 de cas d'utilisation : 

• Applications de podomètre qui collectent passivement le nombre de pas ou la distance parcourue. 
• Applications de sécurité qui surveillent les capteurs de l'appareil pour détecter les 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'UI. La surveillance des capteurs à haute fréquence peut décharger fortement 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, utilisez l'API Recording au lieu de SensorManager. Vous pouvez également utiliser Santé Connect pour accéder à l'historique et aux données agrégées du nombre de pas de l'appareil afin de capturer les données de manière économe en batterie.
• Si vous enregistrez un capteur avec SensorManager, spécifiez une valeur maxReportLatencyUs de 30 secondes ou plus pour tirer parti du regroupement des capteurs afin de minimiser la fréquence des interruptions du processeur. Lorsque l'appareil est réactivé par un autre déclencheur, tel qu'une interaction utilisateur, une récupération de position ou une tâche planifiée, le système envoie immédiatement les données de capteur 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 d'événements. En utilisant les lectures de capteurs sur le bref wakelock que le système détient pour les mises à jour de localisation, vous évitez d'avoir besoin d'un wakelock pour maintenir le processeur en éveil. Utilisez un worker ou un verrouillage de réveil de courte durée pour gérer l'importation et le traitement de ces données combinées.

Messagerie à distance

Exemples de cas d'utilisation : 

• Applications associées de surveillance vidéo ou audio qui doivent surveiller les événements se produisant 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 pour ordinateur.

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 nœud de calcul 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 socket, un verrouillage de réveil n'est pas nécessaire pour écouter les interruptions d'événements. Lorsque des paquets de données arrivent au niveau de la radio Wi-Fi ou cellulaire, le matériel radio déclenche une interruption matérielle sous la forme d'un verrouillage de réveil du noyau. Vous pouvez ensuite choisir de planifier un nœud de calcul ou d'acquérir un verrouillage de réveil 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 verrouillage de réveil que lorsque les paquets ont été remis 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 position, la surveillance des capteurs et la communication réseau, les développeurs peuvent s'efforcer de réduire l'utilisation inutile des wake locks. 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 Android Vitals sur les wakelocks. 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 conseils dans notre enquête sur les commentaires concernant la documentation.