android android-6.0-marshmallow

android - Wakelock y modo dormita



android-6.0-marshmallow (4)

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

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 GPS cada 2 minutos, la intensidad de la señal GPS fue suficiente en todo momento.

Condiciones de prueba:

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

Registro de prueba de GPS para 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 volví a mirar mis registros, 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 funcionó como se esperaba, obtuve ''millis activo'' en el rango de ~ 330000 (~ 5 veces el tiempo de espera) o incluso ~ 580000 (~ 10 veces el tiempo de espera) mientras está inactivo. Este comportamiento extraño 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 está ahora documented : solo con "ignorar optimizaciones" activado, puede mantener un wakelock parcial en modo inactivo Doze.

Por lo que he explorado, todos los bloqueos de activación (excepto los que tienen las aplicaciones con un servicio actual en primer plano) se eliminan cuando comienza el sueño más profundo. El objetivo principal es dejar que el sistema duerma cuando se establezcan las ''condiciones relevantes''. Entonces, sí, los bloqueos no es algo que les importe demasiado, supongo.

La forma en que lo veo JobScheduler es la forma de programar, realizar tareas en segundo plano, etc. en el futuro. Sin embargo, les quita algo de 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 ''disparar y esperar que las cosas sucedan más o menos a tiempo''.

En cuanto a su caso de uso, JobScheduler tiene una devolución de llamada onStopJob para saber cuándo se detuvo la ejecución de su trabajo [por cualquier motivo, digamos que se activó el wifi], debe tomar las medidas adecuadas, como reprogramar su trabajo para la próxima ventana de mantenimiento. De los documentos:

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

Según algunas pruebas, utilizando un Nexus 5 con la vista previa final (?) De Android 6.0 instalado:

  • Mantener un PARTIAL_WAKE_LOCK es insuficiente para bloquear el modo Doze: el dispositivo seguirá dormitando, 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 con android:keepScreenOn (o el equivalente de Java), con la pantalla apagada (el usuario presiona el botón de ENCENDIDO), no es suficiente para bloquear el modo Doze

IOW, los reproductores de video y similares no deberían verse afectados mientras el usuario mira el video, aunque el reproductor no se esté moviendo o cargando. Sin embargo, si el usuario presiona el botón de ENCENDIDO, volverá a correr el riesgo de Doze.

No he intentado usar FULL_WAKE_LOCK (esperaría un comportamiento idéntico al de android:keepScreenOn , pero no estoy seguro).

Interesante

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

  1. En la aplicación de reloj, configure una alarma con un tiempo <60 minutos a partir de ahora
  2. Apaga el dispositivo
  3. En la consola, configure $ adb shell dumpsys batería desconecte
  4. En la consola establezca $ adb shell dumpsys deviceidle paso

El estado permanece como ''Pasado a: ACTIVO''

Si configura una alarma con un tiempo> 60 minutos a partir de ahora, funciona normalmente (el dispositivo puede entrar en estado inactivo). PERO una vez que la alarma está a menos de 60 minutos, parece que el dispositivo se despierta silenciosamente desde Doze inactivo, ya que el estado devuelve ''ACTIVO'' nuevamente (en lugar de ''IDLE_MAINTENANCE'').

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

- EDITAR -

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