En Android móvil, la compatibilidad con varios usuarios permite que los usuarios se ejecuten en segundo plano (cuando otro usuario está activo) y en primer plano (también conocido como el usuario actual). Para conservar los recursos cuando corresponda, el sistema gestiona el cierre de usuarios. Siempre se requiere un usuario de primer plano .
A partir de Android 10, Android Automotive tiene una configuración predeterminada que permite que un máximo de tres (3) usuarios se ejecuten a la vez ( config_multiuserMaxRunningUsers ). Por lo tanto, además del Usuario del sistema sin cabeza (Usuario 0), solo se puede configurar un Usuario en primer plano y un Usuario en segundo plano.
- En circunstancias típicas, el Usuario actual se ejecuta en primer plano y el usuario del sistema autónomo (Usuario 0) se ejecuta en segundo plano. Una vez que un usuario se mueve al fondo, el usuario se detiene pero no se bloquea. Cuando se alcanza el número máximo de usuarios, el usuario en segundo plano utilizado menos recientemente se detiene y bloquea (
config_multiuserDelayUserDataLocking). - Los usuarios en segundo plano detenidos y desbloqueados se reinician durante el modo de garaje .
Los usuarios invitados son efímeros y solo pueden ejecutarse en primer plano. Cuando una persona sale de Invitado, el Usuario invitado se detiene y no puede ejecutarse en segundo plano.
Procesos de usuario en segundo plano
Cuando el Usuario cambia de primer plano a segundo plano (y viceversa), todas las actividades y servicios de primer plano para ese Usuario finalizan. Esto conduce a la detención de todos los servicios vinculados a esos servicios. Sin embargo, queda algo de limpieza. Los servicios persistentes de aplicaciones de sistema originales y OEM continúan ejecutándose mientras el Usuario (ahora en segundo plano) no se detenga.
Los servicios persistentes son más problemáticos ya que estos servicios están contenidos en un depósito de alta prioridad en el sistema de administración de falta de memoria (OOM) de Android. Incluso si las aplicaciones para el usuario en primer plano requieren más memoria, esos procesos persistentes en segundo plano no finalizarán. Como resultado, desde el punto de vista del Usuario en primer plano, los Servicios persistentes extraen permanentemente cierta cantidad de memoria y esa memoria se devuelve solo cuando una persona reinicia el automóvil y se detiene cualquier Usuario en segundo plano.
Estado de usuario
Un usuario está en un estado detenido ( STATE_SHUTDOWN ) hasta que se inicia el usuario. Si se establece una credencial de usuario (como un PIN), el usuario de Android se ejecutará pero permanecerá bloqueado ( STATE_RUNNING_LOCKED ) hasta que una persona desbloquee la pantalla de bloqueo para ese usuario. Una vez que se desbloquee al usuario, se descifrará su almacenamiento cifrado de credenciales y los directorios de datos para ese usuario estarán disponibles. Para el cambio de usuario típico, el usuario de fondo no se detiene y permanece en ejecución y desbloqueado ( STATE_RUNNING_UNLOCKED ), una vez desbloqueado.
Modo garaje, JobScheduler y actualizaciones de aplicaciones para usuarios
La técnica recomendada para que las aplicaciones automotrices actualicen datos es usar JobScheduler para programar trabajos para que se ejecuten cuando un dispositivo está en estado inactivo, a través del modo de garaje (por ejemplo, la descarga de actualizaciones de aplicaciones desde Google Play Store). Una vez que las aplicaciones registran trabajos con JobScheduler y JobSchedulerService, los trabajos se ejecutan cuando es posible.
CarService envía una señal a JobSchedulerService para activar trabajos configurados para ejecutarse cuando el dispositivo automotriz está inactivo a través del modo de garaje. Para que JobSchedulerService ejecute trabajos para usuarios en segundo plano, ese usuario debe estar en el estado STATE_RUNNING_UNLOCKED . Los trabajos en cola en JobSchedulerService se conservan y sobreviven a través de los ciclos de energía.
JobScheduler no puede ejecutar trabajos para un usuario específico si el usuario nunca se desbloqueó después de un ciclo de energía. Sin embargo, una vez desbloqueado, y si el usuario permanece en STATE_RUNNING_UNLOCKED , se pueden ejecutar trabajos para el usuario.