Restricciones para el inicio del servicio en primer plano

Nos encantaría saber qué opinas de estas restricciones. Realiza una breve encuesta para contarnos lo que piensas. En particular, queremos conocer los casos de uso de tu app que se verán afectados por este cambio.

Las apps orientadas a Android 12 ya no pueden iniciar servicios en primer plano mientras se ejecutan en segundo plano, excepto en algunos casos especiales. Si una app intenta iniciar un servicio en primer plano mientras se ejecuta en segundo plano y el servicio en primer plano no cumple con uno de los casos excepcionales, el sistema lanza una IllegalStateException.

Alternativa recomendada a los servicios en primer plano: WorkManager

Si este cambio afecta a tu app, te recomendamos que comiences a usar WorkManager. Cuando se publique la versión beta de Android 12, WorkManager se convertirá en la solución recomendada para iniciar tareas en segundo plano con mayor prioridad.

WorkManager 2.7.0-alpha01 incluye compatibilidad con trabajos acelerados, que es un nuevo tipo de trabajo en Android 12. En Android 12 y versiones anteriores, esta versión de WorkManager usa servicios en primer plano para proporcionar retrocompatibilidad.

Para ver un ejemplo completo de cómo WorkManager 2.7.0-alpha01 usa trabajos acelerados, consulta WorkManagerSample en GitHub.

Trabajos acelerados

Los trabajos acelerados, que son nuevos en Android 12, permiten que las apps ejecuten tareas importantes, al tiempo que le otorgan al sistema un mejor control sobre el acceso a los recursos. Estos trabajos tienen un conjunto de características en algún lugar entre un servicio en primer plano y un trabajo de JobScheduler:

• No se ven afectados por algunas de las restricciones de administración de energía del sistema, como el Ahorro de batería y Descanso.
• El sistema las ejecuta de inmediato, siempre que la carga de trabajo actual del sistema permita hacerlo.

Los trabajos acelerados pueden postergarse

El sistema intenta ejecutar un trabajo acelerado determinado lo antes posible una vez que se invoca. Sin embargo, como sucede con otros tipos de trabajos, el sistema podría diferir el inicio de nuevos trabajos acelerados si hay demasiados trabajos en ejecución o si se están agotando los recursos del sistema.

En particular, el sistema aplaza la ejecución de trabajos acelerados cuando se produce al menos una de las siguientes condiciones:

• La carga del sistema es demasiado alta.
• Se superó el límite de cuota para trabajos acelerados. Los trabajos acelerados usan un sistema de cuotas basado en los buckets de App Standby y limitan el tiempo máximo de ejecución en un período de tiempo progresivo. Las cuotas que se usan para trabajos acelerados son más restrictivas que las que se usan para otros tipos de trabajos en segundo plano.

Actualizaciones de WorkManager

A partir de WorkManager 2.7.0-alpha01, tu app puede llamar a setExpedited() para declarar que se debe acelerar un Worker. Esta nueva API usa trabajos acelerados cuando se ejecuta en Android 12, y la API usa servicios en primer plano en versiones anteriores de Android.

Con el fin de alentar a los desarrolladores a realizar solicitudes de trabajos acelerados en sus apps de manera premeditada y respaldar mejor la capacidad para extender el tiempo en que una tarea puede ejecutarse, ya no están disponibles los métodos CoroutineWorker.setForeground() y ListenableWorker.setForegroundAsync(). En particular, en los dispositivos que ejecutan Android 12, cuando se intenta llamar a ListenableWorker.setForegroundAsync(), el resultado es IllegalStateException. Recomendamos a los desarrolladores usar setExpedited() en su lugar.

Casos en los que se permite el inicio de servicios en primer plano desde el segundo plano

En las siguientes situaciones, tu app puede iniciar servicios en primer plano incluso mientras se ejecuta en segundo plano:

• La app viene de un estado visible para el usuario, como una actividad.
• Tu app recibe un mensaje de prioridad alta mediante Firebase Cloud Messaging.
• El usuario realiza una acción en un elemento de la IU relacionado con tu app. Por ejemplo, puede interactuar con un cuadro de ayuda, una notificación, un widget o una actividad.
• Tu app recibe un evento relacionado con el geovallado o el reconocimiento de actividad.
• Después de que el dispositivo se reinicia y recibe la acción de intent ACTION_BOOT_COMPLETED en un receptor de emisión.
• Apps que tienen permisos o funciones del sistema específicos, como propietarios del dispositivo y propietarios de perfiles.
• Tu app usa el administrador de dispositivo complementario.

• Tu app solicitó el permiso REQUEST_IGNORE_BATTERY_OPTIMIZATIONS y envió al usuario a una página de configuración en la que el usuario inhabilitó las optimizaciones de batería para la app.

  Para enviar a los usuarios a la página Optimización de batería en la configuración del sistema, invoca un intent que contenga la acción del intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. En esa página, después de que los usuarios desactiven la optimización de la batería para tu app, el sistema mostrará el diálogo que aparece en la figura 1.

• Tu app cumple con alguna de las condiciones descritas como excepciones sobre restricciones para iniciar actividades en segundo plano, salvo que la app tenga una actividad en la pila de actividades de una tarea existente.