自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
前台和后台用户系统处理
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
在移动 Android 中,对多个用户的支持使用户能够在后台(当另一个用户处于活动状态时)和前台(也称为当前用户)运行。为了尽量节省资源,系统会管理用户关机事宜。始终要求有一个前台用户。
从 Android 10 开始,Android Automotive 的默认配置最多只允许三个用户同时运行 (config_multiuserMaxRunningUsers
)。因此,除了无头系统用户(用户 0)之外,只可以配置一个前台用户和一个后台用户。
- 通常,当前用户在前台运行,无头系统用户(用户 0)在后台运行。当用户进入后台时,系统会停用该用户,但不会锁定该用户。一旦达到最大用户数,系统就会停用并锁定使用时间最早的后台用户 (
config_multiuserDelayUserDataLocking
)。
- 系统会在车库模式下重启已停用但未锁定的后台用户。
访客用户是临时用户,只能在前台运行。一旦用户退出访客模式,系统就会停用该访客用户,该访客用户便无法在后台运行。
后台用户进程
一旦用户从前台切换到后台(反之亦然),系统就会终止该用户的所有 activity 和前台服务,继而停止与这些服务绑定的所有服务。但是,一些清理服务会继续运行。只要系统未停用当前在后台运行的用户,第一方和 OEM 系统应用的持久性服务就会继续运行。
由于持久性服务包含在 Android 内存不足 (OOM) 管理系统的高优先级存储分区中,因此这些服务更易出现问题。即使面向前台用户的应用需要更多内存,系统也不会终止这些持久性后台进程。因此,从前台用户的角度来看,持久性服务会永久地占用一定数量的内存,并且只有在用户重新启动汽车且系统停用任何后台用户时,系统才会释放该内存。
用户状态
用户处于停用状态 (STATE_SHUTDOWN
),直到系统启用该用户。如果系统设置了用户凭据(如 PIN 码),Android 用户会运行但保持锁定状态 (STATE_RUNNING_LOCKED
),直至该用户的锁屏被解锁。一旦该用户被解锁,其凭据加密存储空间将被解密,并且该用户的数据目录将变为可用。在典型的用户切换情况下,系统不会停用后台用户,该用户一经解锁即保持运行状态和解锁状态 (STATE_RUNNING_UNLOCKED
)。
面向用户的车库模式、JobScheduler 和应用更新
对于 Automotive 应用,更新数据的推荐方法如下:在车库模式下,使用 JobScheduler
预定在设备处于空闲状态时运行的作业(例如,从 Google Play 下载应用更新)。应用向 JobScheduler
和 JobSchedulerService
注册作业后,系统就会尽量运行这些作业。
CarService 会向 JobSchedulerService
发送信号,以便在车库模式下触发作业,这些作业设置为在 Automotive 设备处于空闲状态时运行。为了使 JobSchedulerService
能够为后台用户运行作业,该用户必须处于 STATE_RUNNING_UNLOCKED
状态。已加入 JobSchedulerService
队列的作业会保留下来,并且在重启后继续存在。
如果系统在重启后未解锁特定用户,JobScheduler
将无法为该用户运行作业。但是,一经解锁,并且用户保持为 STATE_RUNNING_UNLOCKED
,就可以为该用户运行作业。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Foreground and background user system handling\n\nIn mobile Android, support for multiple users enables users to run in the\nbackground (when another user is active) and in the foreground (also known as\nthe *current user* ). To conserve resources when appropriate, the system manages\nthe shutting down of users. *One foreground user is always required*.\n\nStarting with Android 10, Android Automotive has a default\nconfiguration of allowing a maximum of three users *only* to run at a time\n(`config_multiuserMaxRunningUsers`). Therefore, in addition to the headless\nsystem user (User 0), only one foreground user and one background user can be configured.\n\n- 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`).\n- Stopped and unlocked background users are restarted during [Garage Mode](/docs/automotive/power/garage_mode).\n\nGuest users are ephemeral and can run only in the foreground. When a person\nswitches out of guest, the guest user is stopped and can't run in the background.\n\nBackground user processes\n-------------------------\n\nWhen a user is switched from foreground to background (and vice versa), all activities\nand foreground services for that user are terminated. This stops\nall services bound from those services. However, some clean up remains.\n[Persistent\nservices](https://developer.android.com/guide/topics/manifest/application-element.html#persistent) from first-party and OEM system apps continue to run for as long as\nthe (now background) user isn't stopped.\n\nPersistent services are more problematic, as these\nservices are contained in a high-priority bucket in Android's Out of Memory (OOM)\nmanagement system. Even if apps for the foreground user require more memory, those persistent\nbackground processes aren't terminated. As a result, from the foreground user's\npoint of view, the persistent services permanently carve out some amount of memory and\nthat memory is returned only when a person reboots the car and any background\nusers are stopped.\n\nUser state\n----------\n\nA user is in a stopped state (`STATE_SHUTDOWN`) until the user\nis started. If a user credential (such as a PIN) is set, the Android user runs but\nremains locked (`STATE_RUNNING_LOCKED`) until a person unlocks the lockscreen\nfor that user. When the user is unlocked, their [credential encrypted](/docs/security/features/encryption/file-based) storage is decrypted\nand the data directories for that user become available. For typical user switching,\nthe background user isn't stopped and remains running and unlocked\n(`STATE_RUNNING_UNLOCKED`), once unlocked.\n\nGarage Mode, JobScheduler, and app updates for users\n----------------------------------------------------\n\nThe recommended technique for Automotive apps to update data is to use [`JobScheduler`](https://developer.android.com/reference/android/app/job/JobScheduler)\nto schedule jobs to run when a device is in the idle state, through [Garage Mode](/docs/automotive/power/garage_mode) (for example, downloading\napp updates from Google Play). After apps register jobs with `JobScheduler` and\n[`JobSchedulerService`](https://android.googlesource.com/platform/frameworks/base/+/3426b72/services/core/java/com/android/server/job/JobSchedulerService.java),\nthe jobs are run when possible.\n\nCarService sends a signal to `JobSchedulerService` to trigger jobs set to run\nwhen the Automotive device is [idle](https://developer.android.com/reference/android/app/job/JobInfo.Builder#setRequiresDeviceIdle(boolean))\nthrough Garage Mode. For `JobSchedulerService` to run jobs for a background user, that\nuser must be in the state `STATE_RUNNING_UNLOCKED`. Jobs queued\ninto `JobSchedulerService` are persisted and survive across power cycles.\n\n`JobScheduler` can't run jobs for a specific user if the user was never\nunlocked after a power cycle. However, when the user is unlocked, and if the user remains in\n`STATE_RUNNING_UNLOCKED`, jobs for the user can be run."]]