Dans Android mobile, la prise en charge de plusieurs utilisateurs permet aux utilisateurs de s'exécuter en arrière-plan (lorsqu'un autre utilisateur est actif) et au premier plan (également appelé utilisateur actuel). Pour conserver les ressources le cas échéant, le système gère l'arrêt des utilisateurs. Un utilisateur de premier plan est toujours requis .
À partir d'Android 10, Android Automotive a une configuration par défaut permettant à un maximum de trois utilisateurs de s'exécuter à la fois ( config_multiuserMaxRunningUsers ). Par conséquent, en plus de l'utilisateur du système sans tête (utilisateur 0), un seul utilisateur de premier plan et un utilisateur d'arrière-plan peuvent être configurés.
- Dans des circonstances typiques, l'utilisateur actuel s'exécute au premier plan et l'utilisateur du système sans tête (utilisateur 0) s'exécute en arrière-plan. Une fois qu'un utilisateur est déplacé en arrière-plan, il est arrêté mais pas verrouillé. Lorsque le nombre maximum 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 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
Lorsque l'utilisateur passe du premier plan à l'arrière-plan (et vice versa), toutes les activités et services de premier plan pour cet utilisateur prennent fin. Cela conduit à l'arrêt de tous les services liés à ces services. Il reste cependant du nettoyage à faire. Les services persistants des applications système propriétaires 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 ces services sont contenus dans un compartiment haute priorité dans le système de gestion des mémoires insuffisantes (MOO) d'Android. Même si les applications destinées à l'utilisateur de premier plan nécessitent plus de mémoire, ces processus persistants en arrière-plan ne sont pas interrompus. En conséquence, du point de vue de l'utilisateur de premier plan, les services persistants effacent en permanence une certaine quantité de mémoire et cette mémoire n'est restituée que lorsqu'une personne redémarre la voiture et que tous les utilisateurs d'arrière-plan sont arrêtés.
État de l'utilisateur
Un utilisateur est dans un état arrêté ( STATE_SHUTDOWN ) jusqu'à ce qu'il soit démarré. Si un identifiant utilisateur (tel qu'un code PIN) est défini, l'utilisateur Android s'exécute mais reste verrouillé ( STATE_RUNNING_LOCKED ) jusqu'à ce qu'une personne déverrouille l'écran de verrouillage de cet utilisateur. Lorsque l'utilisateur est déverrouillé, le stockage crypté de ses 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 de l'application pour les utilisateurs
La technique recommandée pour que les applications automobiles mettent à jour les données consiste à utiliser JobScheduler pour planifier l'exécution des tâches lorsqu'un appareil est en état d'inactivité, via le mode Garage (par exemple, le téléchargement de mises à jour d'applications depuis le Google Play Store). Une fois que les applications ont enregistré les 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 configurées pour s'exécuter lorsque l'appareil automobile est inactif via le mode Garage. Pour que JobSchedulerService exécute des tâches pour les utilisateurs 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 à travers les cycles d'alimentation.
JobScheduler ne peut pas exécuter de tâches pour un utilisateur spécifique si l'utilisateur n'a jamais été déverrouillé après un cycle d'alimentation. Cependant, une fois déverrouillé, et si l'utilisateur reste dans STATE_RUNNING_UNLOCKED , les tâches pour l'utilisateur peuvent être exécutées.