web-dev-qa-db-fra.com

Mode wakelock et assoupi

Selon la documentation d'Android Marshmallow lorsque le système est en mode veille, tout wakelock est ignoré. Cependant, ce n'est pas clair pour moi si un wakelock empêche ou non le mode assoupi.

androidandroid-6.0-marshmallow
13
greywolf82

Sur la base de certains tests, en utilisant un Nexus 5 avec l'aperçu final (?) D'Android 6.0 installé:

  • Tenir un PARTIAL_WAKE_LOCK est insuffisant pour bloquer le mode Doze - le périphérique somnole quand même, même si vous avez la WakeLock et essayez de faire un travail régulier (par exemple, setExactAndAllowWhileIdle() pour avoir le contrôle toutes les minutes)

  • Garder l'écran allumé en utilisant Android:keepScreenOn (ou l'équivalent Java), avec l'écran allumé, est suffisant pour bloquer le mode Doze

  • Maintenir l'écran en utilisant Android:keepScreenOn (ou l'équivalent Java), avec l'écran éteint (l'utilisateur appuie sur le bouton d'alimentation), est insuffisant pour bloquer le mode assoupi

IOW, les lecteurs vidéo et autres ne doivent pas être affectés lorsque l'utilisateur regarde la vidéo, même si le lecteur ne bouge pas ou ne charge pas. Cependant, si l'utilisateur appuie sur le bouton POWER, le risque de somnolence est de nouveau présent.

Je n'ai pas essayé d'utiliser FULL_WAKE_LOCK (j'attendrais un comportement identique à Android:keepScreenOn, mais je suis loin d'être certain).

13
CommonsWare

Intéressant

La propre application d'horloge de Google dans Android 6.0 est capable de bloquer complètement le mode Doze:

  1. Dans l'application Horloge, définissez une alarme avec un délai inférieur à 60 minutes.
  2. Éteindre l'appareil
  3. Dans la console, définissez $ adb Shell dumpsys battery unplug
  4. Dans la console, définissez $ adb Shell dumpsys deviceidle step

L'Etat reste en 'Pas à Pas: ACTIVE'

Si vous définissez une alarme dans un délai supérieur à 60 minutes, le système fonctionne normalement (le périphérique peut passer en mode veille). MAIS une fois l’alarme signalée <60 minutes, il semble que l’appareil se réveille silencieusement de Doze en veille, car l’état revient à «ACTIVE» (au lieu de «IDLE_MAINTENANCE»).

Je me demande vraiment comment ils font ça!

- MODIFIER -

Il semble que setAlarmClock() ait ce comportement par défaut. Cela pourrait être utile dans certains cas d'utilisation.

10
sec_aw

En réponse au commentaire ci-dessus, il ne s'agit pas d'une réponse à la question. Il s'agit de clarifier le comportement de l'application en mode Doze en général. Dans mon application de test, j'ai essayé d'obtenir un GPS. position toutes les 2 minutes, la force du signal GPS était suffisante à tout moment.

Conditions de test:

  • Nexus 9, Aperçu M Android, Construire MPA44I
  • "ignorer les optimisations" ON
  • setExactAndAllowWhileIdle () avec un intervalle de 2 minutes
  • chaque opération a un délai d'une minute pour obtenir un point GPS et est entourée d'un wakelock partiel
  • les journaux ont été écrits dans SQLiteOpenHelper.getWritableDatabase ()

Journal de test GPS pour le mode Doze:

1   2015-09-04 - 12:14  GPS ok (device left stationary unplugged)
2   2015-09-04 - 12:16  GPS ok
3   2015-09-04 - 12:18  GPS ok
4   2015-09-04 - 12:20  GPS ok
5   2015-09-04 - 12:22  GPS ok
6   2015-09-04 - 12:24  GPS ok
7   2015-09-04 - 12:26  GPS ok
8   2015-09-04 - 12:28  GPS ok
9   2015-09-04 - 12:30  GPS ok
10  2015-09-04 - 12:32  GPS ok
11  2015-09-04 - 12:34  GPS ok
...
31  2015-09-04 - 13:14  GPS ok
32  2015-09-04 - 13:16  GPS ok
33  2015-09-04 - 13:18  GPS ok
34  2015-09-04 - 13:20  GPS ok
35  2015-09-04 - 13:22  GPS ok
36  2015-09-04 - 13:24  GPS ok
37  2015-09-04 - 13:26  GPS ok (entering Doze mode some time after)
38  2015-09-04 - 13:42  GPS failed, active millis: 60174 (idle)
39  2015-09-04 - 13:57  GPS failed, active millis: 60128 (idle)
40  2015-09-04 - 14:12  GPS failed, active millis: 60122 (idle)
41  2015-09-04 - 14:16  GPS ok (idle maintenance)
42  2015-09-04 - 14:18  GPS ok (idle maintenance)
43  2015-09-04 - 14:20  GPS ok (idle maintenance)
44  2015-09-04 - 14:22  GPS ok (idle maintenance)
45  2015-09-04 - 14:38  GPS failed, active millis: 60143 (idle)
46  2015-09-04 - 14:53  GPS failed, active millis: 60122 (idle)
47  2015-09-04 - 15:08  GPS failed, active millis: 60068 (idle)
48  2015-09-04 - 15:23  GPS failed, active millis: 60138 (idle)
49  2015-09-04 - 15:38  GPS failed, active millis: 60140 (idle)
50  2015-09-04 - 15:53  GPS failed, active millis: 60131 (idle)
51  2015-09-04 - 16:08  GPS failed, active millis: 60185 (idle)
52  2015-09-04 - 16:12  GPS ok (ending Doze mode - power button on)

Maintenant que j’ai regardé à nouveau mes journaux, j’ai remarqué un comportement très étrange: Le même test avec "ignorer les optimisations" donnait des résultats pratiquement identiques (comme il se doit), MAIS la plupart du temps, le délai d’attente ne fonctionnait pas. comme prévu, j'ai eu «actif millis» dans la plage de ~ 330000 (~ 5 fois le délai d'expiration) ou même ~ 580000 (~ 10 fois le délai d'expiration) en veille. Ce comportement étrange que je ne peux pas expliquer, mais il semble montrer qu'il y a en fait IS effet du réglage "ignorer les optimisations" en mode Doze.

Edit: Le comportement "étrange" décrit ci-dessus est juste maintenant documenté : Uniquement si "ignorer les optimisations" est activé, vous pouvez maintenir un wakelock partiel en mode veille Doze.

4
sec_aw

Pour autant que j'ai exploré, tous les verrous de réveil (à l'exception de ceux détenus par les applications avec un service de premier plan actuel) sont supprimés lorsque l'assoupissement plus profond commence. Le but de la somnolence est de laisser le système dormir lorsque les «conditions pertinentes» sont définies. Donc, oui, je pense que les verrous ne sont pas une chose dont ils se soucient trop.

La façon dont je vois JobScheduler est la voie à suivre pour la planification, les tâches en arrière-plan, etc. Prend un peu de contrôle sur les développeurs, mais c’est là l’appel, je suppose, les gars du framework ont ​​pris toute leur vie Cela ressemble plus à «déclencher et espérer que les choses se passeront plus ou moins à temps».

En ce qui concerne votre cas d'utilisation, JobScheduler a un onStopJob callback pour savoir quand l'exécution de votre travail s'est arrêtée [pour une raison quelconque - disons que le wifi a été activé], vous devez prendre les mesures appropriées, telles que le replanification de votre travail. pour la prochaine fenêtre de maintenance. De la docs: 

Une conséquence immédiate est que le système cessera de vous organiser un wakelock.

0
Rajat Sharma