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.

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 Android 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 les alarmes RTC_WAKEUP (qui réveillent 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 Media 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 l'audio multicanal de films ou de musique 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 wake locks. Vous pouvez vous appuyer sur les API pour acquérir les wake locks nécessaires.
  • Lorsque vous utilisez des API multimédias, mettez fin à la session multimédia lorsque vous n'en avez plus besoin.

Firebase Cloud Message (FCM)

GCM acquiert un verrouillage de réveil 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 fini de s'exécuter.

Noms des wakelocks

GCM acquiert un wakelock nommé 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 lors de l'exécution de tâches en arrière-plan. Les verrous de réveil 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>" correspond au nom du package de votre application, et non au 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 verrous de réveil 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 verrouillage de réveil 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.

WorkManager

Les workers WorkManager acquièrent des wake locks lorsqu'ils exécutent des tâches en arrière-plan. Les verrous de réveil 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 wake locks 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 le nom suit 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 worker.

Exemple

Supposons qu'il existe un nœud de calcul de rendu 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, le nom du verrouillage de réveil est le suivant :

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

Recommandation

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

_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 verrouillage de réveil. 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.