Doze Mode: esencia, fases y mecanismo de ahorro de energía

Qué es Doze Mode

Doze Mode es un mecanismo integrado de ahorro de energía de Android que se activa cuando el dispositivo no está conectado a un cargador, la pantalla está apagada y el usuario no ha interactuado con el dispositivo durante un tiempo determinado. El objetivo de Doze es minimizar la actividad en segundo plano de las aplicaciones para maximizar la duración de la batería en modo de espera. El sistema aplaza JobScheduler, la sincronización de cuentas, AlarmManager y las solicitudes de red.

El modo se introdujo en Android 6.0 Marshmallow (API 23) y se mejoró significativamente en versiones posteriores. Android 7.0 Nougat introdujo una segunda fase (Light Doze) que se activa cuando el dispositivo está en movimiento. Android 8.0 añadió restricciones adicionales a los servicios en segundo plano que funcionan junto con Doze. En Android 12+, Doze se integró con un sistema de gestión de batería actualizado que analiza el comportamiento del usuario.

Es importante entender: Doze Mode no desactiva completamente las aplicaciones. Las pone en un estado con tareas aplazadas, pero no mata los procesos. Un Foreground Service con notificación sigue funcionando, las notificaciones push de alta prioridad (FCM high-priority) se entregan y las alarmas se disparan según lo programado. Doze solo afecta las operaciones en segundo plano que el usuario no ve ni espera en ese momento.

Condiciones de activación

Doze Mode se activa cuando se cumplen todas las condiciones: la pantalla ha estado apagada durante más de 30 minutos (primera activación), el dispositivo está inmóvil (usando el acelerómetro) y no está conectado a un cargador. Si el usuario recoge el teléfono o conecta un cargador, Doze se desactiva inmediatamente. En Android 7+, Light Doze se activa después de solo 5 minutos de inactividad, incluso cuando el dispositivo está en movimiento.

Cómo funciona Doze Mode

Doze Mode gestiona la actividad en segundo plano a través del servicio del sistema DeviceIdleController, que analiza el estado de los sensores, la pantalla y el cargador. Cuando se cumplen todas las condiciones de activación, el sistema pone las aplicaciones en modo de espera, agrupando sus solicitudes en ventanas de mantenimiento. Dentro de estas ventanas, todas las tareas aplazadas — llamadas de red, sincronización, AlarmManager — se ejecutan en lote.

El PowerManager del sistema controla qué aplicaciones pueden salir de Doze. Las notificaciones push de alta prioridad (FCM high-priority) pueden activar el dispositivo para entregar un mensaje. El sistema también ignora Doze para las aplicaciones añadidas por el usuario a la lista blanca de optimización de batería. Todas las demás aplicaciones deben esperar la siguiente ventana de mantenimiento.

La duración de las ventanas de mantenimiento en Deep Doze aumenta exponencialmente: la primera ventana después de 1 hora, la segunda después de 2 horas, la tercera después de 4 horas, y así sucesivamente hasta un intervalo máximo de 12 horas. Esto significa que cuanto más tiempo esté el dispositivo en Doze, menos frecuentemente las aplicaciones pueden ejecutar tareas en segundo plano — ahorrando batería de la manera más agresiva posible.

Impacto en las solicitudes de red

En Doze Mode, todas las solicitudes de red se suspenden hasta que se abre una ventana de mantenimiento. Las únicas excepciones son los mensajes FCM de alta prioridad (con la etiqueta “high_priority” en el payload) y las señales de AlarmManager con las banderas setAndAllowWhileIdle() o setExactAndAllowWhileIdle(). Las llamadas de red normales a través de Retrofit, OkHttp o Volley no se ejecutarán hasta que se abra una ventana.

Fases de Doze Mode

Doze Mode consta de dos fases: Light Doze (sueño ligero) y Deep Doze (sueño profundo). Cada fase impone sus propias restricciones y tiene diferentes umbrales de activación. Comprender la diferencia entre las fases es crítico para un desarrollador que diseña tareas en segundo plano resistentes al modo de ahorro de energía.

Light Doze (sueño ligero)

Light Doze se activa después de 5–30 minutos de inactividad del dispositivo (pantalla apagada, sin movimiento). En esta fase, las solicitudes de red y la sincronización se suspenden, pero AlarmManager y JobScheduler continúan funcionando con pequeños retrasos. Las aplicaciones pueden salir de Light Doze al recibir una notificación push o al conectarse a un cargador. Light Doze no requiere inmovilidad total — el dispositivo puede estar en movimiento.

Deep Doze (sueño profundo)

Deep Doze ocurre después de 60–90 minutos de inactividad con el dispositivo inmóvil (el acelerómetro no detecta movimiento). En Deep Doze, el sistema es significativamente más agresivo al aplazar tareas: las ventanas de mantenimiento se abren con menos frecuencia (con un intervalo que aumenta exponencialmente), AlarmManager solo se dispara con las banderas setAndAllowWhileIdle() y WakeLock no funciona de manera habitual. Las aplicaciones que no están en la lista blanca se ven casi completamente privadas de actividad en segundo plano.

Restricciones en Doze Mode

Doze Mode impone varias categorías de restricciones que un desarrollador debe considerar al diseñar una aplicación. Ignorar estas restricciones lleva a que las tareas en segundo plano no se ejecuten y el usuario vea un comportamiento incorrecto de la aplicación — actualizaciones faltantes, mensajes no enviados, sincronización incompleta.

Restricciones de red

Todas las solicitudes de red se bloquean hasta que se abre una ventana de mantenimiento. Esto aplica a llamadas HTTP, conexiones WebSocket y descargas de archivos. La excepción son los mensajes FCM de alta prioridad, que pasan por un canal separado de Google Play Services independiente de Doze. Para la sincronización de datos críticos, se recomienda usar WorkManager con la política NetworkType.CONNECTED.

Restricciones de AlarmManager

AlarmManager en Deep Doze aplaza todas las alarmas excepto las creadas con los métodos setAndAllowWhileIdle() y setExactAndAllowWhileIdle(). Sin embargo, incluso estos métodos tienen una limitación — no más de 1 activación cada 9 minutos por aplicación. Las alarmas exactas con setExact() en Deep Doze no garantizan la activación en el momento especificado.

Restricciones de WakeLock

WakeLock se comporta de manera inusual en Doze Mode: el sistema no mantiene el bloqueo de activación para aplicaciones fuera de la lista blanca. Incluso si una aplicación ha adquirido correctamente un PARTIAL_WAKE_LOCK, cuando comienza Deep Doze, el sistema puede liberarlo forzosamente. La única forma de garantizar la ejecución de tareas en Doze es usar un Foreground Service con una notificación.

• Red — todas las solicitudes aplazadas hasta la ventana de mantenimiento, excepto FCM high-priority
• AlarmManager — alarmas exactas aplazadas; setAndAllowWhileIdle — no más de 1/9 min
• WakeLock — liberado forzosamente para aplicaciones fuera de la lista blanca
• JobScheduler — tareas agrupadas en ventanas de mantenimiento con intervalo exponencial
• Sincronización — Account SyncManager suspendido hasta salir de Doze

Lista blanca y excepciones

La lista blanca de Doze es una lista de aplicaciones a las que el sistema permite actividad en segundo plano en modo de ahorro de energía con restricciones mínimas. El usuario puede añadir aplicaciones manualmente a la lista a través de Configuración → Batería → Optimización de batería. Las aplicaciones del sistema, los lanzadores y Google Play Services están en la lista blanca por defecto.

Un desarrollador puede solicitar ser añadido a la lista blanca mediante un diálogo del sistema con el Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Esto requiere el permiso REQUEST_IGNORE_BATTERY_OPTIMIZATIONS en el manifiesto. Sin embargo, Google no recomienda solicitar una excepción sin una razón válida — las aplicaciones que abusan de esta capacidad corren el riesgo de ser rechazadas al publicarse en Google Play.

Sin la lista blanca, una aplicación puede usar FCM de alta prioridad para activar el dispositivo desde Doze. Cada uno de estos mensajes le da a la aplicación una ventana corta (10–30 segundos) para ejecutar una tarea. Para operaciones más largas, la aplicación debe iniciar un Foreground Service, que continúa trabajando dentro de las ventanas de mantenimiento de Doze. Google también proporciona un mecanismo de exención para ciertos tipos de aplicaciones: navegación, médicas, mensajería.

Cómo verificar el estado de la lista blanca

Para verificar si una aplicación está en la lista blanca de optimización de batería, se usa el método powerManager.isIgnoringBatteryOptimizations(). Si el método devuelve false, la aplicación está sujeta a todas las restricciones de Doze. Si devuelve true, la aplicación puede usar Wakelock, AlarmManager y red sin restricciones incluso en Deep Doze. Sin embargo, abusar de este privilegio llevará a malas reseñas de los usuarios.

Pruebas de Doze Mode

Probar el comportamiento de la aplicación en Doze Mode es un paso obligatorio del desarrollo, ya que Doze puede interrumpir las funciones en segundo plano. Android proporciona herramientas de línea de comandos a través de ADB para forzar la transición del dispositivo a Light Doze y Deep Doze. Las pruebas deben realizarse en un dispositivo físico o emulador con Android 6.0+.

Para entrar en Light Doze, se usa el comando adb shell dumpsys deviceidle step light. Para Deep Doze — adb shell dumpsys deviceidle step deep. El comando adb shell dumpsys deviceidle force-idle deep transiciona inmediatamente el dispositivo a Deep Doze sin esperar el tiempo de espera estándar. Después de las pruebas, se sale de Doze con el comando adb shell dumpsys deviceidle unforce.

# Forzar entrada en Light Doze
$ adb shell dumpsys deviceidle step light

# Forzar entrada en Deep Doze
$ adb shell dumpsys deviceidle step deep

# Forzar Deep Doze inmediatamente
$ adb shell dumpsys deviceidle force-idle deep

# Salir de Doze
$ adb shell dumpsys deviceidle unforce

# Ver estado de Doze
$ adb shell dumpsys deviceidle

Verificación del funcionamiento de la aplicación

Después de la transición a Doze Mode, verifique si las solicitudes de red funcionan (deberían estar aplazadas), si AlarmManager se activa, si los mensajes FCM se entregan y si las tareas de WorkManager se ejecutan correctamente. WorkManager continúa funcionando en Doze: sus tareas se ejecutan en las ventanas de mantenimiento. Sin embargo, si una tarea requiere ejecución inmediata, especifique setExpedited() o use un Foreground Service.

Mejores prácticas para Doze Mode

Desarrollar una aplicación resistente a Doze Mode requiere repensar el enfoque de las tareas en segundo plano. Google recomienda diseñar la aplicación para que funcione correctamente bajo cualquier restricción de Doze, sin depender de la ejecución inmediata de operaciones en segundo plano. El principio fundamental es usar WorkManager para todas las tareas en segundo plano que puedan aplazarse.

Use WorkManager

WorkManager es la API recomendada por Google para tareas en segundo plano porque se adapta automáticamente a Doze. WorkManager usa JobScheduler (API 23+) o AlarmManager + BroadcastReceiver en versiones antiguas. Las tareas de WorkManager se ejecutan en la ventana de mantenimiento más cercana de Doze, o inmediatamente si es necesario a través de Expedited Work (Foreground Service bajo el capó).

Foreground Service para tareas críticas

Si una tarea no puede aplazarse (reproducción de medios, navegación, VoIP), use un Foreground Service con una notificación obligatoria. Un Foreground Service recibe una exención de Doze: puede mantener un WakeLock y ejecutar solicitudes de red. Sin embargo, incluso un Foreground Service está sujeto a las políticas de ventanas de mantenimiento de Deep Doze para algunos tipos de tareas — por ejemplo, dataSync.

FCM de alta prioridad para notificaciones

Para entregar mensajes que requieren atención inmediata (llamada entrante, notificación urgente), use mensajes FCM de alta prioridad. Dichos mensajes activan el dispositivo desde Doze y le dan a la aplicación una ventana corta para procesarlos. No use alta prioridad para notificaciones regulares — esto causará un drenaje rápido de la batería y puede considerarse una violación de la política de Google Play.

• WorkManager — API preferida para todas las tareas en segundo plano aplazables
• Foreground Service — para tareas críticas con una notificación visible
• FCM de alta prioridad — para entregar mensajes urgentes con activación del dispositivo
• No solicite la lista blanca sin necesidad crítica — empeora la experiencia del usuario
• Pruebe la aplicación en Light y Deep Doze a través de ADB antes del lanzamiento