Identifier les réveils créés par d'autres API

Plusieurs bibliothèques et API système peuvent acquérir des verrous de réveil attribuables à votre application. Il peut donc être difficile d'identifier un verrou de réveil dans votre application qui pourrait être à l'origine d'un problème. Si vous utilisez une API de manière abusive, votre application peut conserver un verrouillage de réveil trop longtemps, même si vous n'appelez pas directement les API de verrouillage de réveil.

Dans les scénarios où un verrouillage de réveil est acquis par d'autres API, vous devez éviter l'acquisition manuelle du verrouillage de réveil.

Ce document liste certains noms de verrouillage de réveil courants que vous pouvez voir lorsque vous utilisez les outils de débogage de verrouillage de réveil. Vous pouvez également voir ces noms dans un rapport vitals. Dans certains cas, le verrouillage de réveil peut avoir été créé par une bibliothèque ou une API système. Dans d'autres cas, il existe une raison pour laquelle l'outil obscurcit le nom du wakelock que vous utilisez dans l'application. Vous pouvez utiliser les outils de débogage pour identifier les wakelocks au comportement anormal, puis rechercher le nom du wakelock dans ce document pour identifier l'API qui peut être à l'origine du problème et comment le résoudre.

Ce document décrit les scénarios dans lesquels des verrous de réveil peuvent être créés. Dans chaque cas, même si le verrouillage de l'activation peut être créé par une autre bibliothèque ou API, le verrouillage est attribué à l'application qui a appelé cette API.

AlarmManager

AlarmManager acquiert des wake locks et les attribue à l'application appelante. AlarmManager acquiert le wake lock lorsque l'alarme se déclenche et le libère lorsque la méthode onReceive() de diffusion de l'alarme a fini de s'exécuter.

Noms des wakelocks

AlarmManager crée des verrous de réveil avec le nom *alarm*. (Les astérisques font partie du nom du verrouillage de réveil, ils ne représentent pas des caractères génériques.)

Recommandation

Nous vous recommandons de suivre les pratiques suivantes pour optimiser le comportement des alarmes :

  • Utilisez AlarmManager pour optimiser la fréquence de planification des alarmes.
  • N'utilisez le type d'alarme RTC_WAKEUP (qui réveille l'appareil) que lorsque cela est nécessaire.
  • Réduisez l'utilisation des alarmes et évitez d'effectuer des tâches longues dans la méthode onReceive().

Audio et multimédia

Les API multimédias peuvent acquérir des verrous de réveil lors de l'enregistrement ou de la lecture audio. Les wake locks sont attribués à l'application appelante.

Noms des wakelocks

Les API Media acquièrent des wakelocks avec différents noms commençant par Audio :

  • AudioBitPerfect : utilisé pour la lecture audio USB sans perte.
  • AudioDirectOut : utilisé pour la lecture audio sans perte sur un téléviseur ou un appareil spécial.
  • AudioDup : utilisé pour la lecture des notifications lorsqu'un appareil est connecté via Bluetooth ou USB.
  • AudioIn : utilisé pour la capture audio en mode caméscope lorsque le micro est actif.
  • AudioMix : utilisé pour la lecture audio sur un appareil commun.
  • AudioOffload : utilisé pour la lecture de musique uniquement à long terme, pour les applications compatibles avec ce mode.
  • AudioSpatial : utilisé pour la lecture de films ou de musique multicanaux sur les appareils compatibles avec le son spatialisé.
  • AudioUnknown : à utiliser lorsque les autres situations ne s'appliquent pas.
  • MmapCapture : utilisé pour la capture audio à faible latence.
  • MmapPlayback : utilisé pour la lecture à faible latence, par exemple pour les jeux ou les applications audio professionnelles.

Recommandation

Nous vous recommandons de suivre les pratiques suivantes :

  • N'utilisez pas de noms de wakelock commençant par Audio.
  • Si vous utilisez les API Media, vous n'avez pas besoin d'acquérir directement des verrous de réveil. Vous pouvez vous appuyer sur les API pour acquérir les verrous de réveil nécessaires.
  • Lorsque vous utilisez des API multimédias, mettez fin à la session multimédia lorsque vous n'en avez plus besoin.

Bluetooth

Les API Bluetooth de la plate-forme ne contiennent aucun verrouillage de réveil attribuable à l'application lors des actions Bluetooth. Pour vérifier que le transfert Bluetooth s'effectue en arrière-plan, planifiez une tâche à l'aide de WorkManager.

Recommandation

  • Utilisez l'association d'appareils associés pour associer des appareils Bluetooth afin d'éviter d'acquérir un verrouillage de réveil manuel lors de l'association Bluetooth.
  • Consultez les conseils sur la communication en arrière-plan pour comprendre comment effectuer la communication Bluetooth en arrière-plan.
  • Si un verrouillage de réveil manuel est jugé nécessaire, ne le maintenez que pendant la durée de l'action Bluetooth.

Capteurs de l'appareil

Il existe plusieurs méthodes pour suivre les données des capteurs de l'appareil, telles que le nombre de pas, ou les données de l'accéléromètre ou du gyroscope.

Sur Wear OS, utilisez les Services Santé Wear pour récupérer les données de l'appareil, telles que l'altitude, la fréquence cardiaque et la distance parcourue.

Si les données sont collectées par d'autres applications, vous pouvez utiliser Santé Connect combiné à WorkManager pour les récupérer.

Pour des scénarios tels que le suivi du delta de pas ou de la distance parcourue, vous pouvez utiliser l'API Recording sur mobile combinée à WorkManager pour récupérer les données.

Dans certains cas, il peut être nécessaire d'utiliser SensorManager pour effectuer un suivi personnalisé des capteurs de l'appareil. SensorManager n'acquiert pas de verrouillage de réveil au nom de l'application, sauf si le capteur est un capteur de réveil, qui peut être identifié à l'aide de l'API isWakeUpSensor.

Recommandation

L'utilisation de capteurs pour enregistrer des données à des taux d'échantillonnage élevés peut décharger considérablement la batterie. Voici quelques recommandations pour réduire la décharge de la batterie et l'utilisation du verrouillage de réveil :

  • Si vous souhaitez suivre le nombre de pas ou la distance parcourue, utilisez l'API Recording pour enregistrer les données de manière économe en batterie.
  • Pour le suivi passif des capteurs sur Wear OS, utilisez Wear Health Services afin d'optimiser l'utilisation de la batterie.
  • Réduisez la fréquence de votre capteur à moins de 200 Hz.
  • Lorsque vous enregistrez un capteur avec SensorManager, définissez un maxReportLatencyUs de plus de 30 secondes pour utiliser la logique de traitement par lot des capteurs et réduire le nombre d'interruptions reçues par l'application.
  • Évitez de maintenir un long verrouillage de réveil pendant toute la durée du suivi des capteurs. Planifiez plutôt des alarmes à l'aide de AlarmManager pour interroger les données des capteurs toutes les 30 secondes ou plus.

Firebase Cloud Message (FCM)

Un verrouillage de réveil est acquis lors de la diffusion d'un message Firebase Cloud Messaging (FCM) à l'application. Le verrouillage de réveil est libéré une fois que la méthode onMessageReceived() de diffusion FCM a terminé son exécution.

Noms des wakelocks

Un verrouillage de réveil est acquis avec le nom GOOGLE_C2DM.

Recommandation

Nous vous recommandons de suivre les pratiques suivantes pour optimiser le comportement de FCM :

  • Optimisez la fréquence d'envoi des messages FCM.
  • N'utilisez pas FCM à priorité élevée, sauf si le message doit réellement être remis immédiatement.
  • Faites en sorte que la méthode onMessageReceived() se termine le plus rapidement possible. Pour en savoir plus, consultez les conseils Firebase.

JobScheduler

Les tâches JobScheduler acquièrent des wakelocks lorsqu'elles exécutent des tâches en arrière-plan. Les wake locks sont attribués à l'application qui a créé les workers.

Noms des wakelocks

Les noms des wake locks acquis par JobScheduler dépendent de la version du système Android sur laquelle ils s'exécutent et de l'objectif du job.

Les éléments entourés de crochets sont des variables. Par exemple, "<package_name>" est le nom du package de votre application, et non le texte littéral <package name>. Toutefois, *job* est la séquence de caractères *job*, avec des astérisques. Les astérisques ne sont pas utilisés comme caractères génériques.

Android 15 ou version antérieure

Les tâches lancées par l'utilisateur créent des verrous de réveil dont les noms suivent ce modèle :

*job*u/@<name_space>@/<package_name>/<classname>

D'autres tâches utilisent ce modèle :

*job*/@<name_space>@/<package_name>/<classname>
Android 16 ou version ultérieure

Les tâches lancées par l'utilisateur créent des wake locks dont le nom suit ce modèle :

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Les tâches accélérées utilisent ce modèle :

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

Les jobs réguliers utilisent ce modèle :

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
Exemple

Supposons qu'il existe un job accéléré avec l'espace de noms backup et le tag de trace started. Le nom du package est com.example.app et la classe qui a créé le job est com.backup.BackupFileService.

Sur les appareils équipés d'Android 15 ou version antérieure, le verrouillage de réveil est nommé comme suit :

*job*/@backup@/com.example.app/com.backup.BackupFileService

Sur les appareils équipés d'Android 16 ou version ultérieure, le nom du wake lock est le suivant :

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

Recommandation

Auditez votre utilisation des tâches JobScheduler. En particulier, suivez nos conseils pour optimiser l'utilisation de la batterie pour les API de planification des tâches.

Position

LocationManager et FusedLocationProviderClient utilisent des verrous de réveil pour obtenir et fournir la position de l'appareil. Les wake locks sont attribués à l'application qui a appelé ces API.

Noms des wakelocks

Les services de localisation utilisent les noms suivants :

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

Recommandation

  • Optimisez l'utilisation de la localisation. Par exemple, définissez des délais d'attente, regroupez les demandes de localisation ou utilisez des mises à jour de position passives.
  • Si vous utilisez les API de localisation, vous n'avez pas besoin d'acquérir directement des wake locks. Vous pouvez vous appuyer sur les API pour acquérir les wake locks nécessaires.

WorkManager

Les workers WorkManager acquièrent des wake locks lorsqu'ils exécutent des tâches en arrière-plan. Les wake locks sont attribués à l'application qui a créé les workers.

Noms des wakelocks

Les noms de verrouillage de réveil acquis par WorkManager dépendent de la version du système Android sur laquelle ils s'exécutent.

Android 15 ou version antérieure

Les tâches WorkManager créent des verrous de réveil dont les noms suivent ce modèle :

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 ou version ultérieure

Les tâches accélérées créent des verrous de réveil dont les noms suivent ce modèle :

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

Les tâches régulières suivent ce modèle :

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

Par défaut, <trace_tag> est le nom du nœud de calcul.

Exemple

Supposons qu'il existe un nœud de calcul accéléré nommé BackupFileWorker. Le nom du package est com.example.app.

Sur les appareils équipés d'Android 15 ou version antérieure, le verrouillage de réveil est nommé comme suit :

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Sur les appareils équipés d'Android 16 ou version ultérieure et utilisant WorkManager 2.10.0+, le nom du wake lock serait le suivant :

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Recommandation

_UNKNOWN

Si les outils de débogage estiment qu'un nom de wakelock contient des informations permettant d'identifier personnellement l'utilisateur, ils n'affichent pas le nom du wakelock. Au lieu de cela, ils attribuent le libellé _UNKNOWN au wake lock. Par exemple, les outils peuvent le faire si le nom du wake-lock contient une adresse e-mail.

Recommandation

Suivez les bonnes pratiques d'attribution de noms aux wakelocks et évitez d'utiliser des informations permettant d'identifier personnellement l'utilisateur dans le nom du wakelock. Si vous trouvez un verrouillage de réveil nommé _UNKNOWN attribué à votre application, essayez d'identifier de quel verrouillage de réveil il s'agit et donnez-lui un autre nom.