Sur Android mobile, la prise en charge de plusieurs utilisateurs permet aux utilisateurs d'exécuter des tâches en arrière-plan (lorsque qu'un autre utilisateur est actif) et au premier plan (également appelé 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 est configuré par défaut pour n'autoriser l'exécution d'un maximum de trois utilisateurs seulement à la fois (config_multiuserMaxRunningUsers). Par conséquent, en plus de l'utilisateur système headless (utilisateur 0), un seul utilisateur au premier plan et un seul utilisateur en arrière-plan peuvent être configurés.
- Dans des circonstances normales, l'utilisateur actuel s'exécute au premier plan et l'utilisateur système sans tête (utilisateur 0) s'exécute en arrière-plan. Lorsqu'un utilisateur est déplacé en arrière-plan, il 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 en mode Garage.
Les utilisateurs invités sont éphémères et ne peuvent s'exécuter qu'au premier plan. Lorsqu'une personne quitte le mode 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 arrête tous les services liés à ces services. Toutefois, il reste encore quelques nettoyages à effectuer. 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 allouent définitivement une certaine quantité de mémoire, et cette mémoire n'est renvoyé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 dans un état arrêté (STATE_SHUTDOWN) jusqu'à ce qu'il soit démarré. 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é.
Mises à jour du mode Garage, de JobScheduler et 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 tâches avec JobScheduler et JobSchedulerService, les tâches sont exécutées 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, cet utilisateur doit être dans 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 s'il reste dans STATE_RUNNING_UNLOCKED, des tâches peuvent être exécutées pour lui.