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 (3) 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. Once 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
- Stopped and unlocked background Users are restarted during Garage Mode.
Guest Users are ephemeral and can only run in the foreground. When a person switches out of Guest, the Guest User is stopped and cannot run in the background.
Background User Processes
When User switching from foreground to background (and vice versa) occurs, all activities and foreground services for that User are terminated. This leads to the stoppage of all services bound from those services. However, some clean-up remains. Persistent services from first party and OEM system applications continue to run for as long as the (now background) User is not 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 will not be 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.
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 will run but
remain locked (
STATE_RUNNING_LOCKED) until a person unlocks the lockscreen
for that User. Once the User is unlocked, their credential encrypted storage will be decrypted
and the data directories for that User will become available. For typical User switching,
the background User is not 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, the downloading of app updates from the Google Play Store). Once 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 background Users, that
User must be in the state
STATE_RUNNING_UNLOCKED. Jobs queued
into JobSchedulerService are persisted and survive across power cycles.
JobScheduler cannot run jobs for a specific User if the User was never
unlocked after a power cycle. However, once unlocked, and if the User remains in
STATE_RUNNING_UNLOCKED, jobs for the User can be run.