在 Android Automotive 中，系统通常采用 Headless System User Mode（无界面系统用户模式） 。这意味着 User 0（系统用户） 仅在后台运行系统服务，而真正的驾驶者操作的是 Secondary User（次要用户） 。
为了优化性能并增强安全性，我们需要根据用户角色的不同，决定哪些应用该出现，哪些该消失。
一、 为什么要针对用户禁用软件包？
- 性能优化： User 0 在后台运行，如果它加载了大量不必要的 UI 应用，会白白浪费系统内存（RAM）。
- 安全性： 限制“访客”或“非管理员”用户访问敏感应用（如工程模式、OTA 更新等）。
- 合规性： 某些驾驶辅助应用只应对主驾驶员可见。
二、 核心机制：白名单机制 (Whitelisting)
AAOS 弃用了早期的“全量禁用”模式，转而采用更加灵活的白名单机制。主要通过覆盖（Overlay）框架层资源文件 config.xml 来实现。
1. 关键配置项
在 AAOS 的资源定义中，有两个关键的 XML 属性：
config_userTypePackageWhitelistRes: 定义了一个 XML 资源，列出了哪些应用包属于哪个用户类型。config_deviceSpecificSystemUserPackages: 专门针对 User 0（系统用户）定义的设备特定包列表。
三、 实战：如何配置应用可见性
第一步：定义白名单 XML
你需要创建一个名为 sysconfig_whitelist.xml 的文件（名称可自定义），并在其中定义规则。
XML
<user-types>
<full-user>
<package name="com.android.settings" />
<package name="com.google.android.maps" />
</full-user>
<system-user>
<package name="com.android.providers.settings" />
<package name="com.oem.car.service" />
</system-user>
</user-types>
第二步：在 Framework 中启用覆盖
在你的设备 Overlays 目录下，修改 config.xml：
XML
<resources>
<string name="config_userTypePackageWhitelistRes">@xml/sysconfig_whitelist</string>
</resources>
四、 不同用户类型的差异化策略
AAOS 将用户细分为以下几种主要类型，你可以针对性地进行配置：
| 用户类型 (User Type) | 典型应用场景 | 配置建议 |
|---|---|---|
| SYSTEM (User 0) | 系统后台服务、HAL 层通信 | 极简原则。只允许核心 Provider 和无界面的 Service。 |
| FULL | 主驾驶员、管理员 | 全量权限。允许导航、多媒体和所有车辆控制。 |
| GUEST | 临时用车者、代驾 | 受限模式。禁用支付、个人账号同步及深度车辆设置。 |
五、 最佳实践
-
不要在 User 0 中运行 UI 应用： 除非该应用需要在所有用户切换间保持常驻（如某些倒车影像逻辑，但通常建议放在 SystemUI 或独立服务中），否则在 User 0 运行 UI 极其消耗资源。
-
利用
adb进行实时调试： 如果你发现某个包在某个用户下没出来，可以使用以下命令查看解析情况：adb shell dumpsys user | grep "Package whitelist" -
处理静态与动态包： 注意，某些通过 Google Play 下载的第三方包可能不在你的预置白名单中。对于这些包，AAOS 默认通常会允许它们在
FULL用户下运行，但你需要确保它们不会意外出现在系统用户中。
六、 总结
在 AAOS 中，禁用软件包不再是粗暴的 pm disable，而是一场优雅的资源调度。通过基于 user-types 的白名单配置，你可以确保：
- User 0 足够轻量，保证系统响应速度。
- 驾驶员拥有完整体验。
- 访客隐私得到保护。
