04 - AAOS 模拟器与离线环境
解决 P7（难脱离真车）的根本方案：让车控信号链路在没有真车/实机的情况下跑起来。本篇对标业界所有 AAOS 模拟器/云真机方案。
解决痛点：P7 难离车 / P9 应用层 CI（间接）。
1. 方案速览与结论
| 方案 | 能跑 car_service 全链路 | 支持 3791 自定义 prop | priv-app+平台签名 | 免费 | 结论 |
|---|---|---|---|---|---|
| Cuttlefish AAOS | ✅ 完整 | ✅ vhalconfig JSON | ✅ userdebug 可重签 | ✅ 开源 | ⭐ 小米最该投入的底座 |
| AVD-Automotive | ✅ 完整 | ❌ 仅标准 prop | ❌ release build | ✅ | 仅冒烟，不能当主力 |
| Genymotion SaaS | ✅ 完整 | ⚠️ 需定制 | ⚠️ 需定制 | ❌ $179+/月 | 备用（出差/演示） |
| Corellium | ❌ 无 AAOS 镜像 | ❌ | ✅ | ❌ 企业价 | 不推荐 |
| Waydroid/redroid | ❌ 无 AAOS 镜像 | ❌ | ❌ | ✅ | 不推荐 |
两个独立 agent（模拟器方向 + AAOS 官方方向）都点名 Cuttlefish + vhalconfig JSON 是 Google 给 OEM 的”标准答案”，交叉印证可信。
2. Cuttlefish (CF) —— 推荐底座
原理
AOSP 官方”准真实”虚拟设备，基于 crosvm + KVM，跑未改动的完整 AOSP 镜像（bootloader/kernel/system/vendor 全套），含完整 car_service/VehicleService/FakeVehicleHardware。AAOS 目标：aosp_cf_x86_64_auto-userdebug。
本地起一台
sudo apt install -y cuttlefish-common cuttlefish-base cuttlefish-user
sudo usermod -aG cuttlefish-network,kvm $USER && reboot
repo init -u .../platform/manifest -b android-latest-release && repo sync -c -j8
source build/envsetup.sh && lunch aosp_cf_x86_64_auto-userdebug && m
HOME=$PWD launch_cvd --num_instances=1 -daemon=true
adb connect localhost:6520 # 或 acloud create --local-instance
stop_cvd在 CF 上注入信号（工具全可用）
adb shell cmd car_service inject-vhal-event HVAC_POWER_ON 1 # 按名字（见 02 篇）
adb shell cmd car_service emulate-driving-state drive # 聚合驾驶态
python3 vhal_emulator.py --prop 0x11400400 --value 60 --area 0 # host 工具三大拦路虎与对策
- 小米 3791 自定义 prop 不在 AOSP → 写代码生成器，从小米 VHAL AIDL/头文件导出成
/vendor/etc/automotive/vhalconfig/xiaomi.json（Android 14+ 零代码，无需改 VHAL 源码）。 - priv-app + 平台签名 → 生成小米 platform key，MiCarSettings 同 key 签名，预装
/system/priv-app/MiCarSettings/+ 写privapp-permissions-xiaomi.xml。 - CarService 私有 API 漂移 → 小米 car-builtin 改动需 cherry-pick 到 CF manifest，建议直接 fork 小米整车 manifest。
- 链接：https://source.android.com/docs/devices/cuttlefish ｜ 源码：
device/google/cuttlefish/
3. acloud —— 团队共享封装
AOSP 自带 AVD 管理 CLI，launch_cvd 的上层包装 + 远端 GCE 编排：
acloud create --local-instance # 本地起 CF
acloud create --build-id <id> # 从 ci.android.com 拉指定 build团队推广：把”小米定制 CF 镜像”封装成 micar-emulator start/stop/inject <prop> <val> 一键 CLI，成员 micar-emulator pull --version <x> 拉镜像。远程模式国内走自建机房（避免 GCE 跨境合规）。
4. AVD-Automotive —— 零门槛但仅冒烟
Android Studio AVD Manager 直接下发的 AAOS 镜像（含 “Automotive With Play Store”），基于 Goldfish/QEMU，5 分钟启动、零源码。自带 GUI “VHAL Properties” 面板（Tools > VHAL）。
致命局限：
- Google release build，无 root adb / 不能 remount → priv-app 装不上（MiCarSettings 直接 INSTALL_FAILED）。
- VHAL 只有 AOSP 标准 prop，小米 3791 自定义 prop 不存在。
- 仅适合”编译能不能过 / 标准 Car SDK API 对不对”的快速冒烟，不能替代真车。
- 想真正可用：用 CF 的 userdebug 自定义镜像通过 AVD Manager 加载。
5. Genymotion SaaS AAOS 14 —— 商业云（备用）
2024 起官方提供 AAOS 14 镜像，核心卖点是可编程 gRPC VHAL（CI 友好）。~$179–219/月。
- 仍需自己定制 priv-app/3791 prop（同 CF 问题），叠加订阅费，性价比不如自建。
- gRPC VHAL 思路值得借鉴（与 02 篇 Android 16
GRPCVehicleHardware同源）。 - 链接：https://www.genymotion.com/blog/android-automotive-14-saas/
6. 不推荐：Corellium / Waydroid / redroid
- Corellium：Arm 虚拟化强，但无现成 AAOS 镜像（官方 generic device 基于 Ranchu，无 car_service）。
- Waydroid/redroid：容器化方案，目标是 mobile AOSP，AAOS 依赖的
car_service+VHAL+car-builtin-lib都不在镜像里，VHAL 注入无解，实际不可行。
7. 小米落地路线（4 阶段）
| 阶段 | 周期 | 人 | 产出 |
|---|---|---|---|
| P1 基线镜像 | 1-2 周 | 1 | 高配 Linux+KVM 服务器（32C/64G/500G），aosp_cf_x86_64_auto-userdebug 跑通 inject-vhal-event |
| P2 小米定制 | 2-3 周 | 2 | ⭐从小米 VHAL AIDL 生成 vhalconfig/xiaomi.json（3791 prop）；MiCarSettings 平台签名预装；CarDemo 功能迁移成 inject 脚本/Web 控制台 |
| P3 团队平台化 | 1-2 周 | 1-2 | 封装 micar-emulator CLI；镜像归档内部制品库；CI 每 PR 起一台 CF 跑 UI/信号冒烟 |
| P4 云真机演进 | 长期 | — | 中心化部署内部机房；引入 Android 16 GRPCVehicleHardware，信号源 server 团队共享 |
关键风险
- 3791 prop 数据缺失：必须从小米 VHAL 团队拿完整 prop 定义表，否则 JSON 生成不出——最大依赖。
- 私有 API 漂移：CF manifest 建议 fork 小米整车 manifest。
- arm-only native lib：CF 主力 x86_64，遇 arm-only so 需编译 arm64 CF（实验性）或临时砍除。
预期收益（vs 真机 + CarDemo）
- 开发者人手一台”虚拟车”，等车时间从天级降到秒级。
- 可覆盖真车难触发的故障码/极限信号，UI 测试覆盖率提升一个量级。
- CI 自动化回归；新人 onboarding 不依赖申请真机。