车辆信号通讯方式研究
本知识库以 MiCarSettings 应用为研究对象，结合整机《车控信号》资料，从”信号从哪来、怎么进 App、App 怎么收发、开发者怎么写”四个层面，多角度剖析车辆信号（Vehicle Signal / CarProperty）的通讯机制。
研究方法：7 个探索 agent 多角度并行调研 + 1 个对抗核验 agent 定向源码验证，所有关键论断均交叉确认，存疑点单列成篇。
一页纸结论（TL;DR）
- 主通道（三层混合架构，经对抗核验确认）：
- Manager 层 = AOSP：
android.car.hardware.property.CarPropertyManager（注意是新路径，旧路径android.car.hardware.CarPropertyManager在本项目 0 命中）。链路业务 Controller → SettingsCarPropertyManager → VehicleControlManager → LocalCarManager → android.car.Car → CarService(Binder) → VHAL → 车端 ECU - propId 字典层 = 小米：
mi.car.config.*（458 文件）提供常量数值 + 项目桥接类MiCarPropertyIds - 值类型/框架层 = 小米：
mi.car.hardware.MiCarPropertyValue/MiVehicleArea*+ mavenmi.car:vehicle.support - 即 Manager 运行时挂 AOSP，字典和值类型已用小米。
mi.car.MiCarPropertyManager（小米 SDK Manager）0 命中——迁移尚未开始但基础设施已就位。详见 08 篇
- Manager 层 = AOSP：
- 第二通道：
RTI DDS（settingsCommon/rtiLib），仅用于 8295 平台充电曲线/充电报告这类高频流式数据（全项目仅 2 个业务消费方）。 - App 内封装层：
settingsVehicleLib在 AOSP CarPropertyManager 之上加了缓存去重 / 超时监控 / 生命周期托管 / 回调分发收敛——业务禁止绕过它直接用车控。 - UI 刷新双轨：
- 主流（~200 Controller）：
CarPropertyMgrPreferenceController+onHandlePropertyChange回调推 UI - 新模式（充电领投）：
CarPropertyRepo(StateFlow) → UseCase(combine) → ViewModel(stateIn) →collectIn订阅
- 主流（~200 Controller）：
- 信号字典：
MiCarPropertyIds.java（在settingsBaseLib，不在settingsVehicleLib），但 propId 的真实数值来自外部 maven 依赖com.mi.car.config:api，项目自己不维护数字。 - 演进方向（整机层）：A17+ 整机在推
MiCarPropertySDK（mi.car），MiCarSettings 当前实现仍是 AOSP 路径——这是”当前 vs 演进”的差异，详见 08 篇。
阅读路线
初学者（想搞懂”信号怎么走”）：
01 全景 → 02 主通道 → 03 Controller 范式 → 09 开发模板
开发者（要新增一个信号功能）：
06 信号字典 → 09 开发模板 → 03 Controller 范式 → 11 调试手段
架构师（要做技术决策）：
01 全景 → 02 主通道 → 08 AOSP vs MiCarPropertySDK 演进 → 10 平台差异
调试（信号不生效/收不到）：
11 调试手段 → 02 主通道（超时/回退/去重机制）
文档索引
| # | 文档 | 角度 | 核心问题 |
|---|---|---|---|
| 00 | README（本文） | 索引 | 总览 + 一页纸结论 + 阅读路线 |
| 01 | 信号体系全景与术语 | 全链路 | 信号从车端 ECU 到 App UI 的完整链路、propId 位布局、术语对照 |
| 02 | 应用层主通道 - CarProperty 机制 | 底层封装 | settingsVehicleLib 五层封装（LocalCarManager → … → SettingsCarPropertyManager） |
| 03 | Controller 与 UI 刷新范式 | UI 层 | CarPropertyMgrPreferenceController + 三种业务基类 + onHandlePropertyChange |
| 04 | Flow 响应式架构 - 充电新模式 | UI 层(新) | CarPropertyRepo + UseCase + ViewModel + collectIn |
| 05 | RTI DDS 第二通道 | 旁路 | RTISignalMgr + 高频流式数据 + 8295 平台门控 |
| 06 | 信号字典与命名约定 | 数据模型 | MiCarPropertyIds + mi.car.config + grep 关键词表 + *PropertysMap |
| 07 | 配置字 CCP 与常驻监听 | 配置 | CarConfigManager + VehiclePermanentListener + Settings.Global 落地 |
| 08 | AOSP vs MiCarPropertySDK 演进 | 演进 | 当前用 AOSP，整机推 mi.car，迁移路径与风险 |
| 09 | 新增信号功能开发模板 | 实战 | 开关/Tab/Flow 三种标准模板 + 避坑清单 + 自检步骤 |
| 10 | global | 构建 | 一份源码编三平台 + framework.jar 切换机制 |
| 11 | 调试与验证手段 | 调试 | dumpsys micar_property / mock_from_car / 日志关键词 / 无车自检 |
关键约定
- 路径：本文档所有路径均为相对仓库根
/home/zbc/code_pangu/car/MiCarSettings/的相对路径，部分关键路径给绝对路径。 - 行号：所有行号截至 2026-07-12 / dev 分支，代码变动后可能漂移，以方法名为准。
- 置信度：经多 agent 交叉验证的结论直接陈述；存疑或与既有文档冲突的点，在 08 篇 单列裁决过程。
对抗分析记录
本研究对每个关键论断做了多 agent 交叉验证 + 独立核验 agent 定向源码裁决，主要冲突点：
| 冲突点 | 来源 A | 来源 B | 裁决 |
|---|---|---|---|
| RTI 是否主通道 | 最初猜测”RTI 可能是主通道” | 6 agent 一致 + 源码统计 | 非主通道，仅高频流式补充（见 05） |
| 是否用 LiveData/Flow | 既有文档”不用 Flow” | 业务层 agent 发现充电用 Flow | 双轨：主流回调 + Flow（见 03/04） |
| Flow 使用范围 | 早期 agent”仅充电” | 核验 agent grep 实证 | 以充电为主，已扩散到 micarDrivingSettings（跨 4 模块） |
| MiCarPropertyIds 位置 | docs/05 说 settingsVehicleLib | 多 agent 源码确认 | settingsBaseLib（文档错） |
| AOSP vs mi.car | 整机文档”应迁移 mi.car” | 应用层 agent”用 AOSP” | 三层混合：Manager=AOSP，字典/值类型=mi.car，迁移未开始（见 08） |
| AOSP Manager 路径 | 探索 agent 给旧路径 android.car.hardware.CarPropertyManager（误报 458 命中） | 核验 agent grep 实证 | 新路径 android.car.hardware.property.CarPropertyManager（旧路径 0 命中） |
| mi.car 是否只是字典 | 探索 agent”mi.car 只是 propId 字典” | 核验 agent 发现 mi.car:vehicle.support maven + mi.car.hardware 值类型 | 不只是字典，还有值类型和框架层 |
核验方法：纯 grep 定量 + 读 build.gradle 依赖 + 读底层类 import 区实证，不引用任何二手 agent 结论。行号抽样 6 个全部准确。