Solución:
Basado en varios problemas informados en el WorkManager bugtracker, su documentación no es completamente precisa sobre el comportamiento exacto del WorkManager en tales casos extremos.
En ciertos dispositivos, las aplicaciones se detienen a la fuerza cuando la aplicación se borra del administrador de tareas, por lo que se espera esa parte. … fuente
Desafortunadamente, algunos dispositivos implementan la eliminación de la aplicación desde el menú reciente como una parada forzada. Stock Android no hace esto. Cuando una aplicación se detiene por la fuerza, no puede ejecutar trabajos, recibir alarmas o transmisiones, etc. Por lo tanto, desafortunadamente, no es factible para nosotros abordarlo: el problema radica en el sistema operativo y no hay solución. fuente
El único problema con el que nos hemos encontrado es el caso en el que algunos OEM chinos tratan el deslizamiento para descartar de Recientes como una parada forzada. Cuando eso suceda, WorkManager reprogramará todos los trabajos pendientes la próxima vez que se inicie la aplicación. Dado que se trata de una infracción de CDD, no hay mucho más que pueda hacer WorkManager dada su biblioteca cliente. fuente
Para agregar a esto, si el fabricante de un dispositivo ha decidido modificar el stock de Android para forzar la detención de la aplicación, WorkManager dejará de funcionar (al igual que JobScheduler, alarmas, receptores de transmisión, etc.). No hay forma de evitar esto. Algunos fabricantes de dispositivos hacen esto, desafortunadamente, por lo que en esos casos WorkManager dejará de funcionar hasta la próxima vez que se inicie la aplicación. fuente
Con pruebas intensas de un OneTimeWorkRequest (sin restricciones) en un Pixel 2 XL con stock de Android, el comportamiento es el siguiente:
-
Cierre del administrador de tareas:
- El trabajo continúa (después de un rato)
-
Reiniciar dispositivo (trabajo en ejecución):
- El trabajo continúa después de reiniciar
-
Información de la aplicación “Forzar detención”:
- El trabajo se detiene, solo continuará cuando la aplicación se inicie nuevamente
-
Reinicie el dispositivo (el trabajo fue “Forzado detenido”):
- El trabajo no continúa hasta que la aplicación se inicia de nuevo
Puede encontrar una lista completa de diferentes comportamientos OEM en dontkillmyapp.com. Parece que el equipo de Android también reconoce este problema y agregó una prueba para esto en su prueba CTS para Android Q.
Tengo entendido que una vez programado, siempre se ejecutará en segundo plano independientemente del ciclo de vida de la aplicación. ¿Está bien?
Si. Basado en la documentación
La tarea aún está garantizada para ejecutarse, incluso si se fuerza el cierre de la aplicación o se reinicia el dispositivo.
WorkManager elige la forma adecuada de ejecutar su tarea en función de factores como el nivel de API del dispositivo y el estado de la aplicación. Si WorkManager ejecuta una de sus tareas mientras la aplicación se está ejecutando, WorkManager puede ejecutar su tarea en un nuevo hilo en el proceso de su aplicación. Si su aplicación no se está ejecutando, WorkManager elige una forma adecuada de programar una tarea en segundo plano, según el nivel de API del dispositivo.
WorkManager puede usar JobScheduler, Firebase JobDispatcher o AlarmManager según el nivel de API. Respetará el Doze y considerará todas las demás restricciones antes de ejecutar el Trabajo. Puede esperar cierto retraso en el modo Doze, ya que podría esperar la ventana de mantenimiento.
Nota:
WorkManager está diseñado para tareas que requieren una garantía de que el sistema las ejecutará incluso si la aplicación se cierra, como cargar datos de la aplicación en un servidor. No está diseñado para el trabajo en segundo plano en proceso que se puede terminar de forma segura si el proceso de la aplicación desaparece; para situaciones como esa, recomendamos usar ThreadPools.