In mobile Android, support for multiple users enables users to run in the background (when another user is active) and in the foreground (also known as the current user). To conserve resources when appropriate, the system manages the shutting down of users. One foreground user is always required.
Starting with Android 10, Android Automotive has a default
configuration of allowing a maximum of three users only to run at a time
(config_multiuserMaxRunningUsers). Therefore, in addition to the headless
system user (User 0), only one foreground user and one background user can be configured.
- In typical circumstances, the current user runs in the foreground
and the headless system user (User 0) runs in the background. When a user is
moved to the background, the user is stopped but not locked. When the maximum
number of users is met, the least recently used background user is stopped and
locked (
config_multiuserDelayUserDataLocking). - Stopped and unlocked background users are restarted during Garage Mode.
Guest users are ephemeral and can run only in the foreground. When a person switches out of guest, the guest user is stopped and can't run in the background.
Background user processes
When a user is switched from foreground to background (and vice versa), all activities and foreground services for that user are terminated. This stops all services bound from those services. However, some clean up remains. Persistent services from first-party and OEM system apps continue to run for as long as the (now background) user isn't stopped.
Persistent services are more problematic, as these services are contained in a high-priority bucket in Android's Out of Memory (OOM) management system. Even if apps for the foreground user require more memory, those persistent background processes aren't terminated. As a result, from the foreground user's point of view, the persistent services permanently carve out some amount of memory and that memory is returned only when a person reboots the car and any background users are stopped.
User state
A user is in a stopped state (STATE_SHUTDOWN) until the user
is started. If a user credential (such as a PIN) is set, the Android user runs but
remains locked (STATE_RUNNING_LOCKED) until a person unlocks the lockscreen
for that user. When the user is unlocked, their credential encrypted storage is decrypted
and the data directories for that user become available. For typical user switching,
the background user isn't stopped and remains running and unlocked
(STATE_RUNNING_UNLOCKED), once unlocked.
Garage Mode, JobScheduler, and app updates for users
The recommended technique for Automotive apps to update data is to use JobScheduler
to schedule jobs to run when a device is in the idle state, through Garage Mode (for example, downloading
app updates from Google Play). After apps register jobs with JobScheduler and
JobSchedulerService,
the jobs are run when possible.
CarService sends a signal to JobSchedulerService to trigger jobs set to run
when the Automotive device is idle
through Garage Mode. For JobSchedulerService to run jobs for a background user, that
user must be in the state STATE_RUNNING_UNLOCKED. Jobs queued
into JobSchedulerService are persisted and survive across power cycles.
JobScheduler can't run jobs for a specific user if the user was never
unlocked after a power cycle. However, when the user is unlocked, and if the user remains in
STATE_RUNNING_UNLOCKED, jobs for the user can be run.