Foreground and background user system handling

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. 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 locked (config_multiuserDelayUserDataLocking).
  • 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 apps 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 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 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). 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 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.