Modo Wakelock y doze

Según la documentación de Android Marshmallow cuando el sistema está en modo dormido, se ignora cualquier wakelock. Sin embargo, no tengo claro si un wakelock evita el modo dormido o no.

En función de algunas pruebas, utilizando un Nexus 5 con la última (?) Vista previa de Android 6.0 instalada:

  • Mantener un PARTIAL_WAKE_LOCK no es suficiente para bloquear el modo Doze; el dispositivo aún dormirá, aunque tenga WakeLock y esté intentando hacer un trabajo regular (por ejemplo, setExactAndAllowWhileIdle() para obtener el control cada minuto)

  • Mantener la pantalla encendida usando android:keepScreenOn (o el equivalente de Java), con la pantalla encendida, es suficiente para bloquear el modo Doze

  • Mantener la pantalla encendida usando android:keepScreenOn (o el equivalente de Java), con la pantalla apagada (el usuario presiona el botón POWER), no es suficiente para bloquear el modo Doze

IOW, reproductores de video y similares no deberían verse afectados mientras el usuario mira el video, aunque el reproductor no se mueva ni cargue. Sin embargo, si el usuario presiona el botón de ENCENDIDO, volverá a tener riesgo de Doze.

No he intentado utilizar FULL_WAKE_LOCK (esperaría un comportamiento idéntico al de android:keepScreenOn , pero estoy lejos de ser cierto).

Interesante

La aplicación de reloj propia de Google en Android 6.0 puede bloquear completamente el modo Doze:

  1. En la aplicación de reloj configura una alarma con un tiempo <60 minutos a partir de ahora
  2. Apaga el dispositivo
  3. En la consola set $ adb shell dumpsys battery unplug
  4. En la consola, configure $ adb shell dumpsys deviceidle step

El estado permanece como ‘Avanzado a: ACTIVO’

Si configura una alarma con un tiempo> 60 minutos a partir de ahora, funciona normalmente (el dispositivo puede pasar a estados inactivos). PERO una vez que la alarma está a <60 minutos de distancia, parece que el dispositivo se despierta silenciosamente de Doze inactivo, ya que el estado vuelve a 'ACTIVE' (en lugar de 'IDLE_MAINTENANCE').

¡Realmente me pregunto cómo están haciendo esto!

– EDITAR –

Parece que setAlarmClock() tiene este comportamiento por defecto. Esto podría ser útil para algunos casos de uso.

En respuesta a la discusión de comentarios anterior, esta no es una respuesta a la pregunta. Está destinado a aclarar el comportamiento de la aplicación en modo Doze en general. En mi aplicación de prueba, traté de obtener una posición de GPS cada 2 minutos, la intensidad de la señal del GPS era suficiente en todo momento.

Condiciones de prueba:

  • Nexus 9, Android M Preview, comstackción MPA44I
  • “ignorar optimizaciones” ENCENDIDO
  • setExactAndAllowWhileIdle () con intervalo de 2 minutos
  • cada operación tiene un tiempo de espera de 1 minuto para obtener una corrección de GPS y está rodeada por un wakelock parcial
  • los registros se escribieron en SQLiteOpenHelper.getWritableDatabase ()

Registro de prueba de GPS para el modo 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) 

Ahora que miré mis registros nuevamente, noté un comportamiento muy extraño: la misma prueba con “ignorar optimizaciones” OFF mostró resultados básicamente idénticos (como debería), PERO la mayoría de las veces el tiempo de espera no funcionaba como se esperaba, obtuve ‘milis activos’ en el rango de ~ 330000 (~ 5 veces el tiempo de espera) o incluso ~ 580000 (~ 10 veces el tiempo de espera) mientras está inactivo. Este extraño comportamiento no puedo explicarlo, pero parece mostrar que realmente hay algún efecto de la configuración de “ignorar optimizaciones” en el modo Doze.

Editar: El comportamiento ‘extraño’ descrito anteriormente ahora está documentado : solo con “ignorar optimizaciones” activado, puede mantener un wakelock parcial en el modo inactivo de Doze.

Por lo que he explorado, todos los lockings de activación (excepto los que tienen las aplicaciones con un servicio de primer plano actual) se descartan cuando comienza el sueño más profundo. El objective de dormitar es dejar que el sistema duerma cuando se establecen las “condiciones relevantes”. Así que sí, las cerraduras no son algo que les importe demasiado, supongo.

La forma en que lo veo JobScheduler es la manera de ir sobre la progtwigción, tareas en segundo plano, etc. en el futuro. Sin embargo, les quita el control a los desarrolladores, pero esa es la llamada que supongo que los chicos de Framework tomaron para la duración de la batería. Es más como ‘desencadenar y esperar que las cosas sucedan más o menos a tiempo’.

Viniendo a su caso de uso, JobScheduler tiene una callback onStopJob para saber cuándo se ha detenido la ejecución de su trabajo [por alguna razón, por ejemplo wifi se alteró] necesita tomar las medidas adecuadas, como reprogtwigr su trabajo para la siguiente ventana de mantenimiento. De los documentos:

Una repercusión inmediata es que el sistema dejará de tener un wakelock para ti.