Vehicle doc文档生成

cd /home/maqi/android13-r44javadoc -d /tmp/oem-api-docs \-sourcepath out/soong/.intermediates/vendor/oem/vehicle/android.oem.vehicle.property-java-source/gen \android.oem.vehicle.property# 产物：constant-values.html(常量值表) + OemVehiclePropertyId.html(类说明) + package-summary.html(包摘要)# ⚠️ constant-values 显示十进制；要显示十六进制 propId，必须在 .aidl 的 Javadoc 注释里手写 0x21400601

是的，编号段是 16 位，但 65535 只是「同一组 × 同一类型」内的上限，不是全局属性总数。    拆开看 propId 这个 32 位整数的三段：      [ 属性组 8 位 ][ 类型 8 位 ][ 属性编号 16 位 ]      bits 31-24      bits 23-16    bits 0-15    - 属性编号段：16 位，值域 0x0000~0xFFFF = 0~65535，共 65536 个编号    - 属性组段：8 位（0x11 系统、0x21 vendor，理论 256 个组）    - 类型段：8 位（INT32/FLOAT/STRING/BOOLEAN/INT64…约 10 种枚举）    所以「属性总数」不是被 65535 卡死的，而是被三段一起决定：理论空间 2^8 × 2^8 × 2^16 = 2^32 ≈ 42 亿种组合。65535 这个数只限制「同一组 + 同一类型」下能塞多少个编号。    具体到你的 OEM vendor 属性（0x21 组）：    - INT32 类型：0x21400000 ~ 0x2140FFFF，65536 个    - FLOAT 类型：0x21600000 ~ 0x2160FFFF，65536 个    - BOOLEAN：0x2120xxxx、STRING：0x2100xxxx、INT64：0x2150xxxx…每种类型各 65536 个    也就是 vendor 这一组，单是 INT32 就能定义 65536 个属性，FLOAT 又 65536 个，加起来几十万，对一个 OEM 来说根本用不完。    真正的瓶颈从来不是这个编号上限，而是 VHAL 运行时——所有属性都要加载进 VehiclePropertyStore（内存 + 启动遍历），CarService 维护属性列表和回调，属性多了才有性能问题。65536 这个数字你永远碰不到。