El sistema prioriza las solicitudes de recursos de las apps según el estado del dispositivo, el estado de la app y el intervalo de App Standby.
El sistema Android puede aplicar límites de recursos de dos maneras diferentes. Una forma de optimizar el uso de recursos es aplazar la ejecución del trabajo hasta que el dispositivo salga de un estado de bajo consumo, como el modo de Descanso. Por ejemplo, las tareas normales y las alarmas inexactas se aplazan para que se ejecuten después de que el dispositivo salga del modo de suspensión.
Otra forma es reducir la cantidad de veces que la app puede activar el dispositivo y realizar tareas, según el bucket de modo de espera actual de la app. El sistema puede reducir la frecuencia (la frecuencia con la que la app activa el dispositivo) y la duración total (la cantidad de tiempo que el dispositivo permanece activo). Por ejemplo, si la app está en el bucket de espera poco frecuente, puede ejecutar trabajos programados durante un período total de 10 minutos en un período continuo de 24 horas.
Ten en cuenta que WorkManager usa JobScheduler para programar tareas cuando la app no es visible y, por lo tanto, los trabajadores se ven afectados por los límites de recursos de trabajo.
Para comprender mejor las restricciones, lee lo siguiente:
- Límites de recursos según el estado del dispositivo
- Límites de recursos según el estado de la app
- Límites de recursos basados en el intervalo de App Standby
Ten en cuenta que el estado del dispositivo y el estado de la app pueden anular los límites del bucket de modo de espera de la app. Por ejemplo, si el dispositivo se está cargando, el sistema permite que las apps del bucket de App Standby poco frecuente ejecuten trabajos por más de 10 minutos en un período continuo de 24 horas.
Se produjeron cambios de comportamiento que también afectaron los límites de recursos. Consulta Cambios en el comportamiento de Android que afectan los límites de recursos para obtener más información.
Límites de recursos según el estado del dispositivo
El sistema también puede eximir o aplicar límites de recursos según el estado del dispositivo. Por ejemplo, un dispositivo en el estado charging tiene acceso sin restricciones a los recursos, independientemente del bucket de modo de espera de la app.
Estado del dispositivo |
Empleos |
Alarmas |
Acceso a la red |
Envío de mensajes a través de la nube de Firebase |
Cargando |
Sin límites de ejecución, excepto para el bucket de espera restringido |
No hay límites de ejecución para todos los buckets en espera y los estados de proceso, excepto si el usuario restringe manualmente la batería de la app. |
Sin restricciones |
Sin restricciones |
Pantalla encendida |
Los límites de ejecución se aplican según el bucket en espera |
Los límites de ejecución se aplican según el proceso de la app y el bucket en espera. |
El acceso depende del bucket en espera o del estado del proceso de la app |
Sin restricciones |
Pantalla apagada y modo de suspensión activo |
Los límites de ejecución se aplican según el bucket en espera, y la ejecución se aplaza al período de mantenimiento de Doze. |
Los límites de ejecución se aplican según el bucket en espera. Alarmas regulares: Se difieren al período de mantenimiento de Doze Alarmas inactivas: Límite de 7 por hora |
Se restringe durante el modo Doze |
Prioridad alta: Sin límites de ejecución Prioridad normal: Se difiere al período de mantenimiento de Doze |
Límites de recursos según el estado de la app
El sistema aplica o no los límites de recursos del bucket en espera de la app según la importancia del proceso de la app. Consulta ActivityManager.RunningAppProcessInfo.importance para comprender los diferentes niveles de importancia del proceso.
El usuario del dispositivo también puede anular de forma manual las optimizaciones de administración de energía de la app, lo que anula los límites del bucket de App Standby.
Estado de la app |
Empleos |
Alarmas |
Red |
El proceso de la app es visible o está en primer plano |
Sin límites de ejecución |
Sin límites de frecuencia |
Sin restricciones |
El proceso de la app está ejecutando un servicio en primer plano |
Los límites de ejecución se aplican según el bucket en espera*** |
Los límites de frecuencia se aplican según el bucket de reserva |
Sin restricciones |
El usuario restringe manualmente la batería de la app |
La ejecución está restringida |
La ejecución está restringida |
El acceso depende del comportamiento del bucket en espera |
El usuario quita manualmente las restricciones de batería de la app |
El límite de ejecución es generoso*** |
Sin límites de ejecución |
Sin restricciones, a menos que el dispositivo esté en modo de ahorro de datos |
*** El comportamiento de la cuota de ejecución de los trabajos cambió en Android 16. Antes de Android 16, no había un límite de ejecución cuando la app ejecutaba un servicio en primer plano o el usuario no restringía la batería de la app.
Límites de recursos según el intervalo de App Standby
Nota: Los valores de esta tabla no son una garantía de las duraciones de ejecución, ya que otras condiciones del dispositivo o cambios en el bucket pueden afectar las restricciones de recursos. Los valores también están sujetos a cambios en futuras versiones de Android.
Los trabajos regulares, los trabajos acelerados, las alarmas y el acceso a la red se pueden limitar según el bucket de App Standby. Comprende cómo los buckets de modo de espera de la app afectan a tu app con estas limitaciones aproximadas de administración de energía como guía. Para obtener un rendimiento óptimo, sigue las prácticas recomendadas de modo de espera de la app y optimiza el uso de batería para las APIs de programación de tareas.
Ten en cuenta que, a partir de Android 13, el bucket de App Standby ya no determina la cantidad de FCM de alta prioridad que puede usar una app.
Intervalo de App Standby |
Trabajos habituales* |
Trabajos acelerados** |
Alarmas |
Red |
Activas: |
Hasta 20 minutos en un período continuo de 60 minutos*** |
Hasta 30 minutos en un período continuo de 24 horas*** |
Sin límites de ejecución |
Sin restricciones |
Conjunto de tareas: |
Hasta 10 minutos en un período continuo de 4 horas |
Hasta 15 minutos en un período continuo de 24 horas |
Límite de 10 por hora |
Sin restricciones |
Frecuentes: |
Hasta 10 minutos en un período continuo de 12 horas |
Hasta 10 minutos en un período continuo de 24 horas |
Límite de 2 por hora |
Sin restricciones |
Poco frecuentes: |
Hasta 10 minutos en un período continuo de 24 horas |
Hasta 10 minutos en un período continuo de 24 horas |
Límite de 1 por hora |
Inhabilitado |
Restringido: |
Una vez al día durante hasta 10 minutos |
Hasta 5 minutos en un período continuo de 24 horas |
Una alarma por día, ya sea una alarma exacta o una alarma inexacta |
Inhabilitado |
* Los trabajos normales describen trabajos que no usan marcas setUserInitiated(true) ni setExpedited(true) en JobScheduler ni trabajadores acelerados en WorkManager.
** Los trabajos acelerados tienen un límite de ejecución independiente de los trabajos normales y se pueden configurar en WorkManager para que sigan ejecutándose con los límites de ejecución de trabajos normales una vez que se agoten los límites acelerados.
*** El comportamiento de la cuota de ejecución de los trabajos cambió en Android 16. Antes de Android 16, no había un límite de ejecución cuando la app estaba en el bucket de modo de espera activo.
Cambios de comportamiento de Android que afectan los límites de recursos
Las siguientes actualizaciones de Android realizaron cambios en los límites de recursos de las apps.
Android 16
Cambio en el comportamiento de las optimizaciones de cuota de JobScheduler
Android ajustó la cuota del tiempo de ejecución de la ejecución de trabajos normal y acelerada según los siguientes factores:
- En qué bucket de App Standby se encuentra la app
- Si la tarea comienza a ejecutarse mientras la app está en un estado superior
- Si la tarea se ejecuta mientras se ejecuta un servicio en primer plano
Android 13
Cambio en el comportamiento de las cuotas de Firebase Cloud Messaging (FCM) de alta prioridad
- Los intervalos de App Standby ya no determinan la cantidad de FCM de alta prioridad que puede usar una app.
- El sistema ahora cambia a una prioridad inferior los mensajes de prioridad alta si detecta que una app envía de forma coherente mensajes de prioridad alta que no generan notificaciones.
- Para conocer los lineamientos actuales sobre los mensajes de prioridad alta, consulta la documentación de firebase sobre cómo establecer y administrar la prioridad de los mensajes.
Android 9
Se presenta la función de Intervalos de App Standby
Android 9 presenta una característica nueva de administración de batería: App Standby Buckets. Esta función ayuda al sistema a priorizar las solicitudes de recursos que hacen las apps según el momento y la frecuencia en que estas se usan. En función de los patrones de uso, se coloca cada una de las apps en uno de los cinco buckets de prioridad. El sistema limita los recursos del dispositivo que están disponibles para cada app según el bucket en el que estas se encuentran.