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

Plusieurs bibliothèques et API système peuvent acquérir des wake locks attribuables à votre application. Il peut donc être difficile d'identifier un wake lock dans votre application qui pourrait causer un problème. Si vous faites un usage abusif d'une API, votre application peut maintenir un wake lock pendant trop longtemps, même si vous n'appelez pas directement les API de wake lock.

Ce document répertorie certains noms de wake lock courants que vous pouvez voir lorsque vous utilisez les outils de débogage du wake lock. 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 masque le nom du wakelock que vous utilisez dans l'application. Vous pouvez utiliser les outils de débogage pour identifier les wakelocks qui ne fonctionnent pas correctement, puis rechercher le nom du wakelock dans ce document pour identifier l'API à l'origine du problème et la résoudre.

Ce document présente les noms de wake lock suivants. Dans chaque cas, bien que le verrouillage de réveil puisse être créé par une autre bibliothèque ou API, le verrouillage est attribué à l'application qui a appelé cette API.

*alarm*

Ce wakelock est acquis par AlarmManager et attribué à l'application appelante. AlarmManager acquiert le wakelock lorsque l'alarme se déclenche et libère le verrouillage lorsque la méthode onReceive() de la diffusion de l'alarme a terminé son exécution.

Recommandation

Nous vous recommandons de suivre les bonnes 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 si nécessaire.
  • Réduisez l'utilisation des alarmes et évitez de réaliser un travail long dans la méthode onReceive().

AudioIn, AudioMix, etc.

Différents verrous de réveil dont les noms commencent par Audio sont acquis par les API multimédias lors de l'enregistrement ou de la lecture d'un contenu audio. Les wakelocks sont attribués à l'application appelante.

AudioIn est acquis lors de la capture AudioRecord en mode caméscope, lorsque le micro est actif. AudioMix est acquis lors de la lecture AudioTrack sur l'appareil. D'autres API multimédias peuvent acquérir des verrouillages de réveil avec d'autres noms commençant par Audio.

Recommandation

Nous vous recommandons de suivre les bonnes pratiques suivantes:

  • N'utilisez pas de noms de wakelock commençant par Audio.
  • Si vous utilisez les API multimédias, vous n'avez pas besoin d'acquérir directement des wake locks. Vous pouvez vous fier aux API pour qu'elles acquièrent 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.

GOOGLE_C2DM

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

Recommandation

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

  • Optimisez la fréquence d'envoi des notifications FCM.
  • N'utilisez pas de messages FCM à priorité élevée, sauf si le message doit être envoyé immédiatement.
  • Terminez la méthode onMessageReceived() le plus rapidement possible. Pour en savoir plus, consultez les conseils Firebase.

*job*/<package_name>/<package_and_job_name>

Ces verrous de réveil sont utilisés par les tâches JobScheduler 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 travailleurs.

"<package_name>" est le nom du package de votre application, et non le texte littéral <package name>. De même, "<package_and_job_name>" correspond au nom du package suivi du nom de la tâche. *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. Voici un exemple de nom de wakelock:

*job*/com.example.app/com.example.app.example.path.ExampleJobService

Recommandation

Effectuez un audit de 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.

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

Ces verrous de réveil sont utilisés par les travailleurs WorkManager 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 travailleurs.

"<package_name>" est le nom du package de votre application, et non le texte littéral <package name>. *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.

Recommandation

Effectuez un audit de 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.

NetworkLocationLocator, FusedLocation, *location*

Ces noms de wake lock sont utilisés par LocationManager et FusedLocationProviderClient pour acquérir et fournir l'emplacement de l'appareil. Les verrouillages de réveil sont attribués à l'application qui a appelé ces API.

Recommandation

Optimisez l'utilisation de la position. Par exemple, définissez des délais avant expiration, regroupez les requêtes de position ou utilisez des mises à jour de position passives.

_UNKNOWN

Si les outils de débogage pensent qu'un nom de wakelock contient des informations permettant d'identifier personnellement l'utilisateur, ils n'affichent pas le nom réel du wakelock. À la place, ils attribuent le nom _UNKNOWN au verrouillage de réveil. Par exemple, des outils peuvent le faire si le nom du verrouillage de réveil 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 wake lock nommé _UNKNOWN attribué à votre application, essayez d'identifier de quel wake lock il s'agit et attribuez-lui un autre nom.