09 - 对抗分析与选型对比
本篇是全库的裁决中枢：把 7 个调研方向的方案放进同一张对比矩阵，记录多 agent 交叉验证的关键争议裁决，给出”痛点 → 首选解药”映射和避坑清单。
多个独立 agent 的交叉印证（如 Cuttlefish、GRPCVehicleHardware、car-test-lib、COVESA VSS 被不同方向 agent 反复点名）显著提升了结论可信度。
1. 全景对比矩阵
按”注入层级 × 解决痛点 × 落地门槛 × ROI”横向对比所有候选方案：
| 方案 | 注入层 | 解决痛点 | 真机可用 | user 版 | 开源/免费 | 落地门槛 | ROI |
|---|---|---|---|---|---|---|---|
cmd car_service 按名字注入 | CarService | P1/P5 | ✅ | 否(userdebug) | ✅ | 极低 | ⭐⭐⭐⭐⭐ |
inject-error-event/emulate-driving-state | CarService | P6/场景 | ✅ | 否 | ✅ | 极低 | ⭐⭐⭐⭐⭐ |
⭐应用层 mock（mock_vehicle_property_env） | App 回调 | P6 | ✅ | ✅ | ✅(项目已有) | 极低 | ⭐⭐⭐⭐⭐ |
--mock_from_car --stat（现有主力） | VHAL | P6 | ✅ | ✅ | ✅ | 低 | ⭐⭐⭐⭐ |
vc_client_mock | vehiclecore | P7 | ✅ | — | ✅(已有) | 低 | ⭐⭐⭐ |
| Cuttlefish + vhalconfig JSON | 模拟器 | P7/P9 | ❌(模拟器) | — | ✅ | 高(需 AOSP 源码) | ⭐⭐⭐⭐⭐(战略) |
| AVD-Automotive | 模拟器 | P7(冒烟) | ❌ | — | ✅ | 极低 | ⭐⭐(仅冒烟) |
| Android 16 GRPCVehicleHardware | VHAL proxy | P7 | ✅(真机代理) | — | ✅ | 高(升 A16) | ⭐⭐⭐⭐⭐(战略) |
| cantools+python-can+vcan+can-utils | CAN/DBC | P7/P8 | ❌(PC) | — | ✅ | 中 | ⭐⭐⭐(电控团队) |
| candump/canplayer 录制回放 | CAN | P8 | ❌(PC) | — | ✅ | 低 | ⭐⭐⭐⭐ |
| LogPropMonitor.py（现有） | 脚本 | P8(弱) | ✅ | — | ✅(已有) | 低 | ⭐⭐⭐(待升级) |
| 自写 DDS Mock publisher（复用 nddsjava.jar） | DDS | P10 | ✅ | — | ✅ | 低 | ⭐⭐⭐⭐⭐ |
| car-test-lib（FakeCarPropertyService） | JVM 单测 | P9 | N/A | N/A | ✅ | 中(需重构) | ⭐⭐⭐⭐ |
| Hilt+FakeRepository | JVM 单测 | P9 | N/A | N/A | ✅ | 高(重构封装层) | ⭐⭐⭐⭐(长期) |
| COVESA VSS 命名标准 | 规范 | P1/P5(根因) | N/A | N/A | ✅ | 低(规范采纳) | ⭐⭐⭐⭐⭐ |
| RemotiveLabs（商业云） | 云 Broker | P7/P8 | — | — | ❌(订阅) | 中(采购/参考) | ⭐⭐⭐⭐ |
| Vector CANoe/dSPACE HIL | 总线/HIL | 电控 | ✅ | — | ❌(百万级) | 高 | ⭐(座舱App误购) |
录制回放（06 篇）、应用层测试（07 篇）两行的细节见对应专篇，agent 加固后补充。
2. 对抗裁决——多 agent 交叉验证的关键争议
裁决 1：离线环境选 Cuttlefish 还是 AVD-Automotive？
- 模拟器 agent + AAOS 官方 agent 双重印证：Cuttlefish 胜出。
- AVD-Automotive 零门槛但 priv-app 装不上、3791 prop 不支持 → 仅冒烟；CF 支持 vhalconfig JSON 加自定义 prop、userdebug 可重签 → 团队底座。
- 裁决：AVD 做 Day-1 demo，CF 做长期底座。
裁决 2：VHAL mock 还是 CAN 注入？
- 不是二选一，而是分层互补（CAN agent + 01 篇分层认知）。
- VHAL mock 验证 CarService 及以上（调 App UI 够）；CAN 注入多验证 vehiclecore 一层（DBC 解析/映射）。
- 裁决：MiCarSettings App 团队用 VHAL mock；vehiclecore/MCU 验证才上 CAN（平台团队范畴）。
裁决 3：DDS mock 要不要买 RTI license？
- DDS agent 直接读代码裁决：不用。项目已有
nddsjava.jar+ rtiddsgen 生成的 DataWriter，~50 行 Kotlin 即可 mock。 - Security 当前禁用 → 开源 DDS 也能接入。
- 裁决：自写 Mock publisher，商业工具仅 Express 免费版作锦上添花。
裁决 4：应用层测试用 car-test-lib 还是 Hilt+FakeRepo？
- 待 07 篇 agent 加固。初步判断（基于项目封装层硬编码
new VehicleControlManager(mContext)无 DI）：- car-test-lib：接得快，但只能 mock CarPropertyManager 行为层，覆盖有限；
- Hilt+FakeRepo：最干净，但要重构
SettingsCarPropertyManager出 Repository 接口，改造量大。
- 裁决（初稿）：短期 car-test-lib 补 Controller 单测；长期推 Repository 接口 + Hilt。
裁决 5：座舱 App 团队能不能采购 Vector CANoe？
- 业界 agent 强烈反对：CANoe 工作在 CAN/Ethernet 总线层，跨不到 Android Framework/VHAL 层，对 MiCarSettings 投入产出比极差。
- 裁决：座舱 App 团队禁采购 CANoe/dSPACE；这些是整车电控团队的工具。
裁决 6：要不要对齐 COVESA VSS？
- 业界 agent 列为”最重要建议”，且 AOSP 已有 Vehicle Signal Catalogs 对齐。
- 裁决：P0 采纳，作为自研 Broker 的命名标准，避免重新发明轮子。
3. 痛点 → 首选解药映射（一查即得）
| 痛点 | 首选解药 | 备选 | 见篇 |
|---|---|---|---|
| P1 propId 难记 | cmd car_service 按名字 + 推动 micar prop 注册进 HalPropertyDebugUtils | COVESA VSS 命名 | 02 |
| P2 areaId 语义 | get-carpropertyconfig 查配置 | — | 02 |
| P3 平台差异 | service list | grep automotive.vehicle 判定 + 11 篇 | — | — |
| P4 user 版拦截 | 应用层 mock（settings put）/ VHAL --mock_from_car（不受限） | — | 01 |
| P5 命令冗长 | cmd car_service 按名字 + 封装 CLI/GUI | CarDemo | 02 |
| P6 异常状态 | ⭐应用层 mock_vehicle_property_env + inject-error-event | --mock_from_car --stat | 01/02 |
| P7 难离车 | 短期 AVD 冒烟；长期 Cuttlefish + vhalconfig；战略 GRPCVehicleHardware | RemotiveLabs | 04/08 |
| P8 回放弱 | candump/canplayer（真车录制）+ 升级 LogPropMonitor.py | MCAP/Plotjuggler | 06 |
| P9 应用层难测 | car-test-lib 补单测 + 长期 Hilt+FakeRepo | Robolectric | 07 |
| P10 DDS 无入口 | ⭐自写 Mock publisher（复用 nddsjava.jar） | RTI Express | 05 |
4. 避坑清单（不推荐/误购）
| 坑 | 原因 |
|---|---|
❌ vhal_emulator.py 真机直接用 | 依赖 SocketComm 33452，小米 vendor VHAL 没集成 |
| ❌ CANdevStudio 当主力 | 2021 后维护停滞 |
| ❌ Corellium/Waydroid/redroid 跑 AAOS | 无 AAOS 镜像，car_service 跑不了 |
| ❌ AVD-Automotive 当调试主力 | priv-app 装不上、3791 prop 不支持，仅冒烟 |
| ❌ MiCarSettings 团队采购 Vector CANoe/dSPACE | 跨不到 Android Framework 层，误购 |
| ❌ 照搬 GM 移除 CarPlay 路线 | 用户反弹（业界反面教材） |
| ❌ 自研 Mock 用自创信号命名 | 应对齐 COVESA VSS，否则未来接第三方要重做映射 |
| ⚠️ DDS Security 一旦启用 | 开源 DDS 互通方案全失效，需跟踪 /data/vendor/rtidds/SOASecurityEnable.cfg |
⚠️ -h/--help 永远空输出 | 小米 vendor VHAL dump 无 help 分支，别指望 |
5. 选型一句话结论
短期（0 成本，立刻做）：把团队 SOP 从
--mock_from_car切到cmd car_service <名字>；用起来项目已有的应用层异常 mock（mock_vehicle_property_env）；自写 DDS Mock publisher；采纳 COVESA VSS 命名。中期（开源主导）：Cuttlefish + vhalconfig JSON 建离线底座；cantools/canplayer 做真车录制回放；car-test-lib 补 Controller 单测；升级 LogPropMonitor.py 为带时间戳的回放器。
长期（战略）：自研 “Mi Car Signal Broker”（参考 RemotiveLabs + VSS）；评估 Android 16 GRPCVehicleHardware；推
SettingsCarPropertyManager重构出 Repository 接口 + Hilt，建立应用层 CI 回归。绝不：座舱 App 团队采购 Vector/dSPACE 重型工具（那是整车电控团队的）。
详细分阶段动作见 10 落地路线图。