解读

车载场景对“身份”与“账户”的定义与手机差异巨大：

1. 驾驶者≠所有者，车辆可能被家庭成员、网约车司机、共享车队等多人高频切换；
2. 行驶中不允许复杂输入，必须“无感”识别；
3. 国内法规（《汽车数据安全管理若干规定》）要求人脸、指纹等生物特征在车内处理、不得出境；
4. 车机硬件由主机厂深度定制，Android 版本从 9 到 14 并存，且大量 OEM 在 Framework 层裁剪，不能假设 GMS 或 Google Automotive 完整可用；
5. 多账户切换必须保证安全驾驶相关应用（仪表、ADAS 报警）不被中断，而媒体、导航、座椅记忆等用户属性应用随账户热插拔。
   因此，面试想考察的是：能否在 AOSP 基础上，给出一条“合规、可落地、对车规无侵入”的完整技术路径，而非简单复述 Android UserManager 接口。

知识点

1. Android 多用户原理：UserManagerService、UserHandle、ActivityManager 对 userId 的隔离机制，及 SystemUI 在切换时的 resume/suspend 流程。
2. 车载系统特有服务：CarService、CarUserService、CarUserNoticeService（Android 11+ 引入），支持“无感登录/注销”与“访客模式”。
3. 国内合规生物识别：Face++、商汤等 SDK 的 On-Device 模式，数据不出 TEE；FIDO2 车载 profile；国密 SM2/SM3 用于模板签名。
4. 车规级身份因子：
   • 近场：NFC 卡片（比亚迪、蔚来主驾 B 柱）、BLE 手机钥匙（CCC Digital Key 2.0/3.0）；
   • 生物：IR 摄像头+ToF 活体检测，光线差时 fallback 到方向盘电容指纹；
   • 行为：座椅压力传感器、蓝牙 RSSI 指纹、语音声纹。
5. 账户绑定与 OTA：AccountManager 与 CarService 的扩展 HAL（vehicle_hal.proto）打通，把 userId 与座椅、空调、HUD 记忆坐标写入 VehicleProperty；同时通过 OEM OTA 服务器下发对称密钥，确保账户数据在 MCU 与 AP 之间加密回写。
6. 安全与性能：
   • SELinux 给每用户分配 unique SELinux user + MLS range，防止 app 跨用户访问行车记录仪视频；
   • 切换时延：Zygote fork 预加载 common-class dex，在 720 MHz 车规芯片上把冷启动压缩到 600 ms 以内；
   • 驾驶过程中只允许“静默切换”——即新用户后台预加载，旧用户前台保活，直到挡位切入 P 档才完成真正的 Activity 栈迁移。

答案

分四层回答：识别→绑定→切换→合规。

1. 识别层
   a. 硬件抽象：在 vehicle HAL 新增 PROPERTY_USER_IDENTITY（int32[]），底层 MCU 把 NFC 卡 UID、BLE key 哈希、人脸特征哈希按优先级填充。
   b. 服务封装：继承 CarUserService，重写 onAuthenticationChanged()，把 HAL 上报的 token 通过 FIDO2 本地校验，校验通过后调用 UserManager.createUserEvenWhenDisallowed() 创建“车载受信用户”。
   c. fallback：当生物特征失效（夜间 IR 过曝）时，自动降级到语音唤醒词+座椅压力阈值双重校验，确保 DMS 摄像头不被频繁点亮而超标耗电。

2. 绑定层
   利用 AccountManager 添加本地账户 TYPE_CAR_LOCAL，把 userId、座椅记忆、导航历史、QQ 音乐登录态以 SQLCipher 加密落盘到 /data/system_ce/userId/vehicle/；加密密钥由 TEE 生成的 AES-256 密钥+国密 SM4 二次加密，密钥句柄通过 Keystore “车规密钥别名”保存，即使拆机读 eMMC 也无法解密。

3. 切换层
   a. 静默预加载：CarUserService 监听挡位 PROPERTY_GEAR_SELECTION，当处于 D 档时，只把新用户进程通过 ActivityManagerInternal.startUserInBackground() 拉起，不切换前台；仪表、AEB 等安全应用运行在系统用户，不受切换影响。
   b. 真正切换：挡位切入 P 档且车速为 0，发送 CarUserManager.USER_LIFECYCLE_EVENT_UNLOCK 广播，SystemUI 调用 ActivityManager.switchUser()，同时 CarService 把 VehicleProperty.USER_ACTIVE_ID 写入 MCU，MCU 再把座椅、方向盘、后视镜调到记忆位置；整个流程在 1.2 s 内完成，低于 OEM 要求的 2 s 上限。
   c. 快速回退：若切换过程中车门突然打开（司机下车），立即调用 UserManager.stopUser()，系统回滚到上一次用户，保证仪表盘不会黑屏重启。

4. 合规层
   人脸特征模板只保存在 TEE OS（Trusty 或华为 iTrustee），外部模块通过 Keymaster 签名的 token 访问，不上传云端；当用户要求删除账户时，触发《个人信息保护法》第四十七条“删除权”，在 TEE 侧调用 secure_storage_delete()，并回写防篡改日志到 SafetyCenter，供国家抽检审计。

这样即可在纯 AOSP 代码基础上，零侵入 Google 专有服务，实现符合国内法规、满足车规时延与功能安全的多账户无感切换方案。

拓展思考

1. 如果车辆卖给二手车主，如何批量清除所有车载用户数据且不让原车主远程恢复？—— 可结合 OEM 云端“过户令牌”+ E2EE 密钥吊销，在 MCU 写一次性熔断位，永久擦除 TEE 密钥区。
2. 当车辆进入无网地下车库，生物识别又失效，如何既保证安全又不让乘客被困车外？—— 可在车机本地维护一次用“数字钥匙离线计数器”，允许 NFC 卡或手机 BLE 在 24 h 内离线认证 50 次，超过阈值才强制联网校验。
3. 未来 V2X 场景下，账户能否跨车迁移？—— 需建立“分布式身份 DID”与车辆联盟链，把用户偏好加密写入区块链，换车时通过零知识证明验证身份，而不泄露隐私；这对密钥托管、跨链手续费、实时性都是新的考验。