Comment gérer les WakeLocks (orphelins) ?

Comment puis-je savoir si je suis affecté ?

C'est probablement la première question que se posent ceux qui ne sont pas familiers avec ce sujet. Avec Gingerbread (Android 2.3) et les versions ultérieures, vous disposez d'un service à bord qui vous aide à y voir clair : les statistiques sur la batterie. Bien que les fabricants aient tendance à le placer à différents endroits, on le trouve principalement dans les rubriques suivantes Paramètres → À propos du téléphone → Batterie ou similaire, et affiche une liste des applications ayant le plus utilisé votre batterie. Au-dessus de cette liste se trouve un petit graphique. Touchez-le, et vous verrez apparaître un écran similaire à celui-ci :

Capture d'écran des statistiques de la batterie sous Android 2.3

J'ai choisi une capture d'écran de l'un de mes appareils qui illustre le problème. En regardant les deux barres bleues inférieures ("Aktiv" = L'appareil est resté éveillé (actif), "Bildschirm an" = "Écran allumé"), la barre bleue la plus à droite sur "Aktiv" indique un WakeLock : Le dispositif a été maintenu actif malgré le fait que l'écran était éteint. Nous pouvons donc être pratiquement sûrs d'avoir un WakeLock, mais nous ne pouvons pas dire qui l'a provoqué.

Si votre appareil ne propose pas cet écran (ou les barres en bas) : Je viens de découvrir, par exemple, le LG Optimus 4X fonctionnant sous Android 4.0.3 a supprimé ces barres), vous pouvez les trouver en utilisant par exemple Moniteur de batterie GSam :

Informations similaires provenant de Moniteur de batterie GSam -- Ici, les "barres bleues" mentionnées sont jaunes/oranges.

Qu'est-ce qui a causé le WakeLock ?

Malheureusement, il est impossible de répondre à cette question en utilisant des applications préinstallées (à l'exception, peut-être, de certaines ROM personnalisées). Mais il existe des outils qui le peuvent. Le candidat le plus connu pour cela est BetterBatteryStats et nous montre la cause dans son wakelocks partiels section :

Captures d'écran de BetterBatteryStats

Dans le premier exemple 2 (extrait de la page playstore de l'application), l'événement à l'origine de la plupart des WakeLocks était un événement souhaité : Nous ne voulons pas que la lecture soit arrêtée pendant que nous écoutons de la musique. Donc le deuxième exemple 3 (tirée d'un cas réel sur l'un de mes appareils) pourrait s'avérer meilleure : les 3 événements les plus élevés sont causés par la même application, qui avait besoin du WakeLock pour maintenir le service push IMAP actif.

Pour une alternative à BetterBatteryStats , consultez le Détecteur Wakelock application mentionnée dans Réponse d'UzumApps -- qui semble plus facile à manier, surtout pour les non-techniciens :

Détecteur Wakelock -- Cliquez sur l'image pour l'agrandir. (Source : Google Play )

Que peut-on faire ?

Si le cas est aussi clair que dans le deuxième exemple de la section précédente, l'action est tout à fait évidente - du moins dans mon cas : Je n'ai pas besoin d'être informé immédiatement lorsqu'un courrier arrive ; un délai de 30min est absolument acceptable. Je suis donc allé dans l'application de messagerie, j'ai désactivé IMAP Push (voir aussi : Push Email ), et est passé à un intervalle de sondage de 30 minutes. Les WakeLocks n'ont pas entièrement disparu, mais ont diminué de façon significative - la durée de vie de la batterie s'est améliorée de façon notable.

Il y a aussi le cas mentionné dans la question elle-même : Une application qui se comporte mal ne libère pas son WakeLock. Confrontez le développeur avec vos découvertes et demandez une correction. S'il s'exécute : problème résolu. Dans le cas contraire : Il y a presque toujours une application alternative disponible.

Et si c'était le système Android lui-même ?

Oui, parfois ça ressemble à ça : 98% ou plus consommés par un service Android. Oh, si c'est 98%, dans la plupart des cas, le candidat s'appelle LocationManagerService . Le méchant nous espionne ? Pas nécessairement. Dans ce cas particulier, le "méchant" cité n'est même pas coupable - du moins pas directement. Il s'agit ici d'une autre application qui demande trop fréquemment la localisation actuelle. Il y a un excellent article sur Setera.org à ce sujet : Détermination de l'usure de la batterie du service LocationManagerService d'Android . Pour résumer, il utilise l'interface d'Android. dumpsys (qui nécessite une racine !) pour vider l'état du système, et vous permet d'examiner les écouteurs établis pour le LocationManagerService. Un examen plus approfondi de leur configuration montre lesquels sont constamment en train de "marteler" le service pour obtenir des informations de localisation (certains le font en permanence, c'est-à-dire sans interruption). Comme l'ID de l'application est répertorié, et à un autre endroit dans la décharge, même avec le nom technique de l'application, vous pouvez toujours l'identifier et prendre les mesures appropriées.

Et qu'en est-il des OVNIs ?

Malheureusement, il en existe : Des applications qui ont enregistré un WakeLock -- et qui sont sorties sans le libérer. Ce qui reste, ce sont des *Unused F***ing Obsoletes* -- des WakeLocks retenus pour aucune utilisation. Il n'y a donc aucun moyen de ramener simplement l'application au premier plan et de la reconfigurer, ou de lui faire libérer ses WakeLocks.

Ici, la seule solution que je connaisse est un redémarrage - et j'aimerais avoir une meilleure solution. Bien sûr, si vous connaissez l'application coupable, les étapes la concernant sont les mêmes que ci-dessus : informer le développeur, obtenir une correction -- ou remplacer l'application. Mais pour ce qui est de se débarrasser du actuel WakeLock ? Peut-être que quelqu'un d'autre peut fournir une meilleure alternative au redémarrage ?

Y a-t-il des lectures complémentaires recommandées ?

Bien sûr. Un pour l'instant, je pourrais en ajouter d'autres plus tard :

• [GUIDE] Wakelocks Définition et comment les éviter (XDA Developers, mars 2013)