Quartz 4

🔍 搜索

08 - AOSP vs MiCarPropertySDK 演进（对抗裁决）

7 min read

08 - AOSP vs MiCarPropertySDK 演进（对抗裁决）

本篇是整个研究对抗分析的核心产出。它回答一个关键问题：整机文档说”A17+ 应用应迁移到 mi.car.MiCarPropertySDK”，但 MiCarSettings 代码里到处是 android.car——到底用的是什么？要不要迁移？什么时候迁移？

本篇的所有结论由独立对抗核验 agent（纯 grep 定量 + 源码 import 实证）验证，不引用任何二手结论。

1. 问题陈述：两份资料的冲突

调研中发现两份”权威”说法打架：

来源说法
整机《车控信号》资料（/home/zbc/micode/.../车控信号）A17+ 应用若用到 MiCar 定义的信号，必须迁移到 MiCarPropertySDK（MiCar.createCar + mi.car.MiCarPropertyManager），否则信号获取不到
MiCarSettings 代码（7 个探索 agent 一致）用的是 android.car.CarPropertyManager（AOSP），通过 LocalCarManager → Car.createCar → Car.PROPERTY_SERVICE

直接看会得出”项目违规用了 AOSP”或”整机文档过时”的结论。两者都不准确。真相需要定量核验。

2. 对抗核验方法

派独立 agent，纯靠 grep + 读源码 import，不引用前述 agent 结论，定量回答：

  1. import android.car vs import mi.car 的命中对比
  2. build.gradle 依赖里有没有小米车控 SDK
  3. 底层类（LocalCarManager / VehicleControlManager）实际 import 的是什么
  4. 关键类行号是否准确
  5. MiCarPropertyIds 真实位置

3. 核验裁决

3.1 命中统计（核验实证）

grep 模式命中文件数说明
import android.car671AOSP 框架
import mi.car514小米框架
mi.car.config458propId 字典
com.mi.car845小米相关
MiCarPropertyManager（小米 SDK 类）0未迁移
android.car.hardware.CarPropertyManager（旧 AOSP 路径）0旧路径已不用
android.car.hardware.property.CarPropertyManager（新 AOSP 路径）6AOSP Manager
android.car.Car15AOSP Car 入口

3.2 build.gradle 依赖实证（base/settingsBaseLib/build.gradle）

// micar-support-api for vehicle property control
api 'mi.car:vehicle.support:0.11.56-test3'      ← 小米车控支持 SDK
api 'mi.car:core.api:0.1.2.48'
api 'mi.car:sdk.static:6.5.1.13'
api 'com.mi.car.config:api:0.0.15-SNAPSHOT'      ← propId 字典
api 'mi.car:sdk.dynamic:0.2.4.67'

AOSP 侧：android.car_*.jar（compileOnly，设备框架提供）。

3.3 底层类 import 实证

VehicleControlManager.java 头部 import：

import android.car.Car;                                            ← AOSP
import android.car.hardware.CarPropertyConfig;                     ← AOSP
import android.car.hardware.CarPropertyValue;                      ← AOSP
import android.car.hardware.property.CarPropertyManager;           ← AOSP（新路径）
import mi.car.config.CommonConstants;                              ← 小米 propId 常量

类声明：extends NewBaseCarServiceManager<CarPropertyManager>（泛型是 AOSP 的）。

LocalCarManager.java：持有 AOSP android.car.Car 实例。

4. 最终裁决：三层混合架构

核验证实，MiCarSettings 既不是”纯 AOSP”，也不是”纯 mi.car”，而是三层混合：

┌─ Manager 层（AOSP）─────────────────────────────┐
│  android.car.hardware.property.CarPropertyManager │
│  （6 文件直 import + 项目自家 3 包装类）           │
│  LocalCarManager 持有 android.car.Car             │
└──────────────────────────────────────────────────┘
                    │ 用 ID ↓        │ 用值类型 ↓
┌─ propId 字典层（小米）──────────────────────────┐
│  mi.car.config.*（458 文件，752 import）           │
│  MiCarPropertyIds（桥接类，settingsBaseLib）       │
└──────────────────────────────────────────────────┘
┌─ 值类型/框架层（小米）──────────────────────────┐
│  mi.car.hardware.MiCarPropertyValue / MiVehicleArea│
│  mi.car:vehicle.support maven                      │
└──────────────────────────────────────────────────┘

为什么这样设计？

  • AOSP CarPropertyManager 提供通用属性读写框架，但只认识标准 AAOS 信号（136 个）
  • 小米的车控信号体系有约 3791 个自定义 prop，需要自己的字典（mi.car.config）和值类型（mi.car.hardware，多出 relative/extension 字段）
  • 项目用 MiCarPropertyIds 把小米字典桥接成项目内统一 ID 表，再通过 AOSP Manager 读写

这正是整机”A17+ 迁移”的前提：目前 Manager 层挂 AOSP（读写运行时），字典和值类型已用小米；迁移会把 Manager 层也改走 mi.car.MiCarPropertyManager。

5. 当前状态：未迁移

  • mi.car.MiCarPropertyManager（小米 SDK Manager 类）在本项目 0 命中 → Manager 层迁移尚未开始
  • 但 mi.car:vehicle.support maven 已引入（注释 “for vehicle property control”）→ 基础设施已就位
  • mi.car.hardware.MiCarPropertyValue / MiVehicleAreaBody 已被 32 处使用 → 值类型层已在用小米

6. 整机演进方向（来自整机资料）

6.1 为什么整机要推 MiCarPropertySDK

原因说明
信号数量SOA 需要 400+ 信号，标准 AAOS 只有 136 个
Payload 字段SOA 比标准多了 relative / extension 字段，AOSP 容器装不下
双实例复杂度VHAL 有 /default（AOSP）+ /micar（小米）两个实例，标准 CarPropertyManager 只对接 /default

6.2 MiCarPropertySDK 机制

  • MiCar.createCar(context, handler, CAR_WAIT_TIMEOUT_DO_NOT_WAIT, listener)
  • MiCar.isMiCarServiceSupported()：通过 getPackageInfo("com.mi.car.property") 检测
  • MiCar.getServiceType()：NOT_INITIALIZED / MICAR_SERVICE / NATIVE_CAR_SERVICE
  • API 与 CarPropertyManager 几乎一致：getProperty / getBooleanProperty / ... / registerCallback
  • SDK 自动适配两种实现：MiCarPropertyImpl（走 MiCar AIDL）/ DefaultCarPropertyImpl（回退原生）
  • 日志 Tag：服务端 PropServer-*，SDK 端 PropSDK-*

6.3 迁移影响（业务侧要改什么）

项AOSP（当前）mi.car（迁移后）
Car 入口android.car.Car.createCarMiCar.createCar
Managerandroid.car.hardware.property.CarPropertyManagermi.car.MiCarPropertyManager
ValueCarPropertyValueMiCarPropertyValue（多 relative/extension）
status 判断== STATUS_AVAILABLE同（小米 status 枚举一致）

对 MiCarSettings 而言，因为已经有 settingsVehicleLib 封装层，迁移成本主要在 VehicleControlManager / LocalCarManager 这一层——把 AOSP Manager 换成 mi.car Manager，业务侧 Controller 代码基本不动。这是封装层的最大价值。

7. 给 MiCarSettings 的建议

  1. 当前不用动：项目运行正常，mi.car.MiCarPropertyManager 0 命中说明没到强制迁移节点（A14/A12 可不迁移，A17 才需要）
  2. 关注整机通知：当目标车型升到 A17+，整机《信号变更说明》会发迁移要求，届时在 VehicleControlManager 层做替换
  3. 不要在业务层混用：业务侧永远走 SettingsCarPropertyManager，不要直接 import android.car.hardware.property.CarPropertyManager 或 mi.car.MiCarPropertyManager
  4. 保持封装层稳定：settingsVehicleLib 的五层封装是迁移的缓冲带，保持它的接口稳定
  5. status 判断用对：无论 AOSP 还是 mi.car，都用 getStatus() == STATUS_AVAILABLE，不要用 != STATUS_UNAVAILABLE（小米新增了 TIMEOUT(4)/TIMEOUT_UNAVAILABLE(5)）

8. 对抗分析的价值（方法论小结）

这次调研如果只看一个 agent 或只看既有文档，会得出错误结论：

单一来源会得出的错误结论
只看既有 docs/05”项目一切走 settingsVehicleLib/CarPropertyManager，没有其它通道”（漏了 RTI）
只看整机文档”项目应该用 mi.car SDK”（误判当前状态）
只看一个应用层 agent”用 AOSP android.car.hardware.CarPropertyManager”（路径错了，是旧路径）
只看 grep mi.car”项目大量用小米 SDK”（误判——多数是 propId 字典，不是 Manager）

只有多角度并行 + 对抗核验才得到准确结论：三层混合，Manager 层 AOSP（新路径），字典和值类型小米，迁移尚未开始但基础设施已就位。

Graph View

Backlinks