Dans la version mobile d'Android, la prise en charge de plusieurs utilisateurs permet aux utilisateurs d'exécuter dans en arrière-plan (lorsqu'un autre utilisateur est actif) et au premier plan (également appelé l'utilisateur actuel). Pour économiser des ressources lorsque cela est approprié, le système gère l'arrêt des utilisateurs. Un utilisateur de premier plan est toujours requis.
À partir d'Android 10, Android Automotive dispose
configuration permettant d'autoriser seulement trois utilisateurs à la fois à s'exécuter
(config_multiuserMaxRunningUsers). Par conséquent, en plus du modèle headless,
utilisateur système (utilisateur 0), un seul utilisateur de premier plan et un utilisateur d'arrière-plan peuvent être configurés.
- En général, l'utilisateur actuel s'exécute au premier plan.
et l'utilisateur système headless (utilisateur 0) s'exécute en arrière-plan. Lorsqu'un utilisateur est
déplacé en arrière-plan, l'utilisateur est arrêté, mais pas verrouillé. Lorsque le nombre maximal d'utilisateurs est atteint, l'utilisateur en arrière-plan le moins récemment utilisé est arrêté et verrouillé (
config_multiuserDelayUserDataLocking). - Les utilisateurs en arrière-plan arrêtés et déverrouillés sont redémarrés pendant le mode Garage.
Les utilisateurs invités sont éphémères et ne peuvent s'exécuter qu'au premier plan. Lorsqu'une personne quitte l'invité, l'utilisateur invité est arrêté et ne peut pas s'exécuter en arrière-plan.
Processus utilisateur en arrière-plan
Lorsqu'un utilisateur passe du premier plan à l'arrière-plan (et inversement), toutes les activités et tous les services de premier plan de cet utilisateur sont arrêtés. Cela permet d'arrêter tous les services liés à ces services. Toutefois, il reste encore des éléments à nettoyer. Les services persistants des applications système first party et OEM continuent de s'exécuter tant que l'utilisateur (maintenant en arrière-plan) n'est pas arrêté.
Les services persistants sont plus problématiques, car ils sont contenus dans un bucket de priorité élevée dans le système de gestion de la mémoire insuffisante (OOM) d'Android. Même si les applications pour l'utilisateur de premier plan nécessitent plus de mémoire, ces processus en arrière-plan persistants ne sont pas arrêtés. Par conséquent, du point de vue de l'utilisateur au premier plan, les services persistants réservent définitivement une certaine quantité de mémoire, qui n'est restituée que lorsqu'une personne redémarre la voiture et que tous les utilisateurs en arrière-plan sont arrêtés.
État des utilisateurs
Un utilisateur est à l'état "Arrêté" (STATE_SHUTDOWN) jusqu'à ce qu'il
est lancé. Si des identifiants utilisateur (tels qu'un code) sont définis, l'utilisateur Android s'exécute, mais
reste verrouillé (STATE_RUNNING_LOCKED) jusqu'à ce qu'une personne déverrouille l'écran de verrouillage.
pour cet utilisateur. Lorsque l'utilisateur est déverrouillé, son stockage chiffré par identifiants est déchiffré et les répertoires de données de cet utilisateur deviennent disponibles. Pour un changement
d’utilisateur typique,
l'utilisateur en arrière-plan n'est pas arrêté, et reste en cours d'exécution et déverrouillé.
(STATE_RUNNING_UNLOCKED), une fois déverrouillé.
Mode Garage, JobScheduler et mises à jour des applications pour les utilisateurs
La technique recommandée pour les applications Automotive afin de mettre à jour les données consiste à utiliser JobScheduler pour planifier l'exécution de tâches lorsqu'un appareil est inactif, via le mode Garage (par exemple, en téléchargeant les mises à jour d'applications depuis Google Play). Une fois que les applications ont enregistré des offres d'emploi auprès de JobScheduler et
JobSchedulerService,
les jobs sont exécutés lorsque cela est possible.
CarService envoie un signal à JobSchedulerService pour déclencher les tâches définies pour s'exécuter lorsque l'appareil Automotive est inactif via le mode Garage. Pour que JobSchedulerService exécute des tâches pour un utilisateur en arrière-plan, cela
l'utilisateur doit avoir l'état STATE_RUNNING_UNLOCKED. Les tâches mises en file d'attente dans JobSchedulerService sont conservées et survivent aux cycles d'alimentation.
JobScheduler ne peut pas exécuter de tâches pour un utilisateur spécifique si celui-ci n'a jamais été déverrouillé après un cycle d'alimentation. Toutefois, lorsque l'utilisateur est déverrouillé et qu'il reste dans
STATE_RUNNING_UNLOCKED, les jobs de l'utilisateur peuvent être exécutés.