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.
- Gestionnaire d'alarmes (AlarmManager)
- Audio et multimédia
- Bluetooth
- Capteurs de l'appareil
- Firebase Cloud Messaging (FCM)
- JobScheduler
- Localisation
- WorkManager
_UNKNOWN
: affiché par les outils de débogage si le nom du verrouillage de réveil semble utiliser des informations permettant d'identifier personnellement l'utilisateur.
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 unmaxReportLatencyUs
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
- Mettez à niveau votre version de WorkManager pour rendre les tags de verrouillage de réveil plus détaillés sur Android 16 ou version ultérieure.
- 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 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.