En Android móvil, la compatibilidad con múltiples usuarios les permite ejecutar en segundo plano (cuando otro usuario está activo) y en primer plano (también conocido como el usuario actual). Para conservar recursos cuando sea necesario, el sistema gestiona el cierre de usuarios. Siempre se requiere un usuario en primer plano .
A partir de Android 10, Android Automotive tiene una configuración predeterminada que permite que un máximo de tres 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 sin cabeza (Usuario 0) se ejecuta en segundo plano. Una vez que un Usuario pasa 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). - Fondo detenido y desbloqueado. Los usuarios se reinician durante el modo Garaje .
Los usuarios invitados son efímeros y sólo pueden ejecutarse en primer plano. Cuando una persona sale del Invitado, el Usuario Invitado se detiene y no puede ejecutarse en segundo plano.
Procesos de usuario en segundo plano
Cuando se produce el cambio del Usuario de primer plano a segundo plano (y viceversa), todas las actividades y servicios de primer plano para ese Usuario finalizan. Esto conduce a la paralización de todos los servicios vinculados a dichos servicios. Sin embargo, aún queda algo de limpieza. Los servicios persistentes de aplicaciones del sistema OEM y de origen continúan ejecutándose mientras el usuario (ahora en segundo plano) no esté detenido.
Los servicios persistentes son más problemáticos ya que están contenidos en un depósito de alta prioridad en el sistema de gestión de memoria insuficiente (OOM) de Android. Incluso si las aplicaciones para el usuario en primer plano requieren más memoria, esos procesos persistentes en segundo plano no finalizan. 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 sólo cuando una persona reinicia el automóvil y se detiene a los Usuarios en segundo plano.
Estado del usuario
Un usuario está en un estado detenido ( STATE_SHUTDOWN ) hasta que se inicia el usuario. Si se configura una credencial de usuario (como un PIN), el usuario de Android se ejecuta pero permanece bloqueado ( STATE_RUNNING_LOCKED ) hasta que una persona desbloquea la pantalla de bloqueo para ese usuario. Cuando se desbloquea al Usuario, su almacenamiento cifrado de credenciales se descifra y los directorios de datos para ese Usuario pasan a estar disponibles. Para el cambio de usuario típico, el usuario en segundo plano no se detiene y permanece ejecutándose 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 Garaje (por ejemplo, la descarga de actualizaciones de aplicaciones desde Google Play Store). Después de 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 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 persisten y sobreviven a través de 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 encendido. Sin embargo, una vez desbloqueado, y si el Usuario permanece en STATE_RUNNING_UNLOCKED , se pueden ejecutar trabajos para el Usuario.