App Standby — qué es, niveles de espera y principio de funcionamiento

Qué es App Standby

App Standby es un componente del sistema de gestión de energía de Android, introducido en Android 6.0 (API 23) y rediseñado significativamente en Android 9 (API 28). Su tarea es identificar qué aplicaciones usa el usuario raramente y restringir su actividad en segundo plano: solicitudes de red, sincronización, JobScheduler y AlarmManager. A diferencia de Doze, App Standby no depende del estado de la pantalla ni del movimiento del dispositivo.

El sistema clasifica las aplicaciones en cuatro buckets (niveles): Active, Working Set, Frequent y Rare. Cada nivel determina cuán fuertemente se restringe la actividad en segundo plano. Las transiciones entre niveles ocurren automáticamente según los patrones de uso de la aplicación: con qué frecuencia el usuario la abre, recibe notificaciones e interactúa con widgets.

App Standby funciona junto con Doze Mode pero no lo reemplaza. Mientras que Doze limita la actividad en segundo plano de todas las aplicaciones cuando el dispositivo está inactivo, App Standby restringe aplicaciones específicas independientemente del estado del dispositivo. Una aplicación en el nivel Rare tendrá restricciones incluso cuando el teléfono se use activamente, si el usuario no la ha abierto durante varios días.

Buckets en Android 9+

A partir de Android 9 (API 28), Google introdujo App Standby Buckets — una clasificación formal con valores numéricos. El sistema utiliza aprendizaje automático para predecir el próximo inicio de la aplicación. Si el modelo predice que la aplicación se abrirá en las próximas horas, recibe un bucket Active. Si la predicción indica un uso poco frecuente — se asigna Rare.

Cómo funciona App Standby

App Standby analiza varios factores para determinar el bucket: tiempo desde la última vez que el usuario abrió la aplicación, frecuencia de interacción (número de inicios por día/semana), recepción de notificaciones FCM, presencia de widgets activos en la pantalla de inicio y suscripción a AlarmManager. Cuanto más tiempo pasa sin usarse una aplicación, menor es su bucket y más estrictas las restricciones.

El servicio del sistema UsageStatsManager recopila estadísticas de uso de aplicaciones y las pasa a StandbyController — un componente del framework que calcula el bucket para cada aplicación. StandbyController también tiene en cuenta eventos del sistema: después de una actualización, el bucket de la aplicación se reinicia a Active durante unos días para que el usuario pueda evaluar las nuevas funciones.

Una característica importante: App Standby no mata el proceso de la aplicación, sino que limita sus capacidades en segundo plano. La aplicación sigue funcionando si el usuario interactúa con ella (bucket Active). En cuanto el usuario minimiza la aplicación y no vuelve a ella, el sistema comienza a contar el tiempo de inactividad y puede reducir el bucket a Working Set o Frequent.

Impacto de FCM en el bucket

Recibir un mensaje FCM de alta prioridad puede elevar temporalmente el bucket de la aplicación a Active. Esto le da a la aplicación la oportunidad de realizar una tarea (procesar el mensaje, sincronizar datos) sin restricciones. Sin embargo, después de completar el procesamiento, el bucket vuelve a su valor original. Google recomienda usar este mecanismo para entregar notificaciones importantes, no para mantener la aplicación activa.

Niveles de App Standby

App Standby utiliza cuatro niveles (buckets) para clasificar las aplicaciones. Cada nivel determina el tiempo de retraso para las tareas en segundo plano: cuanto menor es el nivel, mayor es el retraso. El sistema mueve automáticamente la aplicación entre niveles según las estadísticas de uso recopiladas en los últimos 7–14 días.

Active — aplicación activa

Active — una aplicación con la que el usuario ha interactuado recientemente (la ha iniciado, recibido una notificación o usado un widget). En este bucket no hay restricciones: JobScheduler se ejecuta inmediatamente, la red está disponible, AlarmManager funciona con precisión. La aplicación permanece en Active hasta que el usuario deje de interactuar con ella durante varias horas.

Working Set y Frequent

Working Set — la aplicación se usa regularmente (varias veces a la semana). Retraso de tareas en segundo plano hasta 2 horas. Frequent — la aplicación se usa varias veces al mes. Retraso hasta 4 horas. En ambos niveles, la red solo está disponible en ventanas de mantenimiento, y AlarmManager puede retrasarse. JobScheduler ejecuta tareas en la ventana más cercana.

Rare — poco usado

Rare — el nivel más estricto, asignado a aplicaciones que el usuario no ha abierto durante más de 30 días. El retraso de tareas en segundo plano alcanza las 24 horas. La red está completamente bloqueada fuera de las ventanas de mantenimiento, AlarmManager solo se activa con setAndAllowWhileIdle() con un límite de 1 vez cada 9 minutos. Las notificaciones FCM de alta prioridad aún se entregan pero no pueden elevar el bucket.

Restricciones en App Standby

App Standby impone restricciones en varias categorías de operaciones en segundo plano. A diferencia de Doze, las restricciones de App Standby se aplican independientemente del estado de la pantalla y del cargador. El desarrollador debe diseñar la aplicación teniendo en cuenta estas restricciones, especialmente si el público objetivo usa la aplicación de forma irregular.

JobScheduler y WorkManager

JobScheduler — la API principal afectada por App Standby. Dependiendo del bucket, el retraso en la ejecución de tareas varía de 2 a 24 horas. WorkManager, que utiliza JobScheduler internamente (en API 23+), también está sujeto a estos retrasos. Para tareas críticas en el tiempo, use Expedited Work, que inicia un Foreground Service internamente y no se ve afectado por el bucket.

Restricciones de red

Las aplicaciones en los buckets Working Set, Frequent y Rare no pueden realizar solicitudes de red arbitrarias en cualquier momento. El sistema solo permite el acceso a la red durante las ventanas de mantenimiento, que están sincronizadas con Doze. Para enviar datos críticos, use FCM de alta prioridad con sincronización posterior en la ventana de mantenimiento.

AlarmManager

AlarmManager en App Standby sigue las mismas reglas que en Doze: las alarmas exactas (setExact()) se difieren, y setAndAllowWhileIdle() está limitado a 1 activación cada 9 minutos. Para el bucket Rare, el retraso puede alcanzar las 24 horas, lo que hace que AlarmManager no sea adecuado para la programación precisa de tareas en aplicaciones poco usadas.

• JobScheduler — las tareas se difieren de 2 a 24 horas según el bucket
• Red — acceso solo en ventanas de mantenimiento para Working Set e inferiores
• AlarmManager — las alarmas exactas se difieren; setAndAllowWhileIdle — 1/9 min
• SyncManager — la sincronización de cuentas se retrasa hasta la ventana de mantenimiento
• Widget updates — la frecuencia de actualización de widgets puede reducirse

Cómo obtener una excepción

Se puede obtener una excepción de App Standby de dos maneras: a través de la configuración de batería del usuario (lista blanca manual) o mediante el Intent del sistema ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Sin embargo, Google regula estrictamente el acceso a las excepciones — las aplicaciones sin una razón válida corren el riesgo de ser rechazadas en Google Play.

El usuario puede desactivar manualmente las restricciones para una aplicación específica a través de Configuración → Aplicaciones → [Aplicación] → Batería → Optimización → No optimizar. Esto elimina completamente las restricciones de App Standby y Doze para la aplicación seleccionada. El desarrollador puede mostrar al usuario instrucciones o un diálogo del sistema, pero no puede agregar forzosamente una aplicación a las excepciones.

Foreground Service con una notificación obtiene automáticamente una excepción temporal de App Standby. Mientras el servicio se ejecuta y muestra una notificación, la aplicación se traslada al bucket Active independientemente de su nivel real. Después de que el servicio se detiene, el bucket vuelve a su valor original. Esta es la forma más fiable de garantizar el trabajo en segundo plano sin solicitar excepciones del sistema.

Cuándo solicitar una excepción

Solicitar una lista blanca solo tiene sentido para aplicaciones con funcionalidad crítica en segundo plano: navegación en tiempo real, monitoreo de salud, llamadas VoIP, protección del dispositivo. Para la mayoría de las aplicaciones, es suficiente usar Foreground Service o WorkManager. Google Play puede rechazar la publicación si la aplicación solicita una excepción sin una necesidad evidente.

// Solicitar excepción de App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Comprobar estado actual
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Pruebas de App Standby

Probar App Standby a través de ADB permite asignar forzosamente cualquier bucket a una aplicación y verificar su comportamiento. Esto es críticamente importante para aplicaciones que dependen de la sincronización en segundo plano, notificaciones o actualizaciones periódicas. Las pruebas deben realizarse en un dispositivo físico o emulador con Android 9+.

Para establecer forzosamente un bucket, use el comando adb shell am set-standby-bucket [package] [bucket], donde bucket puede ser: active, working_set, frequent o rare. Para ver el bucket actual — adb shell am get-standby-bucket [package]. El sistema también permite simular la inactividad prolongada de la aplicación mediante el comando adb shell dumpsys usagestats.

# Establecer bucket Rare para la aplicación
$ adb shell am set-standby-bucket com.example.app rare

# Ver bucket actual
$ adb shell am get-standby-bucket com.example.app

# Restablecer todos los buckets a Active
$ adb shell dumpsys usagestats clear

# Ver todos los buckets del sistema
$ adb shell dumpsys usagestats

Qué comprobar

Después de establecer el bucket en Rare, compruebe: si la tarea de WorkManager se ejecuta en 24 horas, si AlarmManager se activa, si las notificaciones FCM se entregan y si Foreground Service funciona sin restricciones. WorkManager con política de Expedited Work debe ejecutarse inmediatamente incluso en el bucket Rare, ya que usa Foreground Service. Las tareas normales de WorkManager se diferirán según el bucket.

Mejores prácticas

Desarrollar una aplicación resistente a App Standby requiere un enfoque consciente de las tareas en segundo plano. El principio principal: no asumir que la aplicación está siempre en el bucket Active. Diseñe el trabajo en segundo plano para que se ejecute correctamente con los retrasos característicos de los buckets Frequent y Rare.

Use WorkManager con Expedited Work

Expedited Work (WorkManager 2.7+) inicia un Foreground Service internamente, lo que da a la tarea una ejecución inmediata independientemente del bucket. Esta es la opción óptima para tareas que no pueden retrasarse: enviar un mensaje, sincronizar después de un pago, procesar una llamada entrante. Las tareas normales de WorkManager se ejecutan en ventanas de mantenimiento según el bucket.

FCM para reactivación

Use mensajes FCM de alta prioridad para despertar una aplicación de App Standby. Cuando la aplicación recibe dicho mensaje, su bucket se eleva temporalmente a Active, permitiéndole realizar tareas necesarias (sincronizar, actualizar datos). Después de completar el procesamiento, el bucket vuelve a su nivel original.

Evite la retención constante en memoria

No intente eludir App Standby con servicios en segundo plano persistentes, WakeLock o mensajes FCM periódicos. Google combate activamente estas prácticas — la aplicación puede ser marcada como de alto consumo y restringida aún más estrictamente. Use WorkManager para tareas periódicas y Foreground Service solo cuando la tarea sea realmente visible para el usuario.

• WorkManager — API preferida; Expedited Work ejecuta tareas sin retraso
• FCM de alta prioridad — eleva temporalmente el bucket a Active para procesar mensajes
• No eluda App Standby — esto provoca el bloqueo de la aplicación por el sistema
• Foreground Service — traslada temporalmente la aplicación a Active mientras se ejecuta
• Pruebe la aplicación en los buckets Rare y Frequent mediante ADB antes de cada lanzamiento