[Dev] 回复：OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug）

Ping... ------------------------------------------------------------------ 发件人：pengpeng <pengpeng@iscas.ac.cn> 发送时间：2026年6月12日(周五) 14:13 收件人：fuyao<fuyao@sjterm.com> 抄　送：maijianzhang<maijianzhang@allwinnertech.com> 主　题：回复：[Dev] OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug） 对于反馈的bug，社区已经没人负责和维护了吗 ？ 原始邮件 发件人：Fuyao Kashizuku <fuyao@sjterm.com> 发件时间：2026年6月12日 11:39 收件人：侯朋朋 <pengpeng@iscas.ac.cn> 抄送：maijianzhang <maijianzhang@allwinnertech.com> 主题：回复：[Dev] OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug） 收到，他们家就是自己玩儿。 kpi考核太严重了，都只管自己的 ------------------------------------------------------------------ 发件人：侯朋朋 via dev <dev@openharmony.io> 发送时间：2026年6月11日(周四) 22:58 收件人：dev<dev@openharmony.io> 抄　送：pengpeng<pengpeng@iscas.ac.cn> 主　题：[Dev] OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug） OpenHarmony 社区各位维护者好： 我们近期围绕 OpenHarmony 源码中的跨模块跨机制一致性问题做了检查。这类问题的典型形态是：一个能力或部件在某个机制或者模块中被声明、选择或引用，但在另一个配套机制中无法找到对应定义、产物、注册信息或能力声明。例如产品 parts 选择了不存在的 component，BUILD.gn external_deps 引用了在当前产品上下文无法解析的 component，ohos.build 的 subsystem 与 preloader 期望不一致，SystemAbility profile 指向的 so 产物缺少对应构建或打包证据，SysCap 在 API、checker 和 provider bundle 之间不一致，或者 NDK/header/prebuilt 声明的源路径在源码树中不存在。 我们之前给社区提交 issue 但是长久一直没人处理，通过这个邮件我们希望社区协助确认这些跨模块跨机制的bug是真还是假阳性。 如果收到邮件麻烦您回复一下：） 下面按问题族列出 46 个问题的描述。每个问题都包含涉及模块、问题说明和建议协作模块。为便于和此前记录对应，问题编号保留原编号；同一类别中的问题编号可能不是连续递增。 一、产品选择的 component 在 registry 中不可解析 问题 1：HiHope 多个产品选择了 registry 无法解析的 component 涉及模块：vendor_hihope、productdefine_common、build/preloader，以及 applications、thirdparty、startup 等相关 component owner。 问题说明：tablet_core_system 和 2in1_core_system 选择 thirdparty:eudev；default_core_system 选择 applications:contacts；ipcamera_core_system 选择 thirdparty:libsnd；neptune_iotlink_demo 选择 startup:init_lite；tv 选择 applications:launcher；wearable 选择 applications:call。产品配置和继承配置将这些 component 展开到产品 parts 中，但当前 component registry 中找不到对应 component。这样产品选择层已经认为这些能力应进入构建输入，而 registry 无法提供合法映射，容易导致构建图加载失败或产品配置长期漂移。 代码上下文和不一致逻辑解释：在 OpenHarmony 的产品矩阵中，产品继承配置和 vendor 产品配置最终会被 preloader 展开成 subsystem:component 形式的 parts。这里 tablet_core_system、2in1_core_system、default_core_system、ipcamera_core_system、neptune_iotlink_demo、tv、wearable 等产品已经在选择链路中引用 eudev、contacts、libsnd、init_lite、launcher、call 等 component，但 registry 侧没有对应 bundle.json 或 ohos.build component 定义。也就是说，产品层已经把这些能力当作构建输入，构建层却无法从 component registry 找到实现入口；这种 selected part 与 registry definition 的断裂会让产品配置、构建图和维护者理解三者不一致。 建议协作：建议 vendor_hihope 先确认这些产品是否仍应选择上述 component；productdefine_common 和 build/preloader 协助确认产品继承展开是否符合预期；对应 applications、thirdparty、startup 模块 owner 协助确认 component 是否已迁移、重命名、下线，或者需要补充 registry/alias。 问题 2：rk3568_mini_system 使用 rockchip_products 未声明的 feature 涉及模块：vendor_hihope、device_board_hihope、device_soc_rockchip、build/preloader、productdefine_common。 问题说明：rk3568_mini_system 产品配置中使用了 is_support_boot_animation，并且产品选择了 rockchip_products:rockchip_products。若该 feature 是产品向 rockchip_products 传递的有效开关，建议确认其是否应在对应 component 的 feature contract 中被声明；如果没有声明，构建系统和维护者无法区分它是有效开关、拼写问题还是历史残留。 代码上下文和不一致逻辑解释：vendor/hihope/rk3568_mini_system/config.json 中使用 is_support_boot_animation，同时该产品选择 rockchip_products:rockchip_products。从配置契约角度看，产品通常只应向 component 暴露其声明过的可配置开关；否则 build/preloader 无法判断该字段是有效 feature、拼写问题还是历史残留。这里产品侧使用 feature，但 component contract 侧没有相应声明，形成 product feature input 与 component feature schema 的不一致。 建议协作：建议 vendor_hihope 和 rockchip_products 相关 owner 确认该 feature 是否仍有效；build/preloader 和 productdefine_common 协助确认 feature contract 的规范位置；如果 feature 有效，应补齐声明；如果已废弃，应从产品配置中移除。 问题 3：hdc 的 Rust external dependency 在部分产品构建上下文中不可解析 涉及模块：developtools_hdc、third_party_rust、commonlibrary_rust、build/preloader，以及使用 hdc 的具体产品配置 owner。 问题说明：developtools/hdc 的 BUILD.gn 中引用 rust_libc:lib。当前源码中已经存在 thirdparty:rust_libc，因此这不是简单的“全量 registry 缺少 rust_libc”。问题更准确地说，是被选中的 GN target 在具体产品构建上下文中引用了 rust_libc external dependency，但该产品上下文没有把 thirdparty:rust_libc 纳入可解析 dependency 域，或者 external_deps 的解析域与产品 parts/component selection 没有闭合。 代码上下文和不一致逻辑解释：developtools/hdc/BUILD.gn 中的 Rust target 使用 rust_libc:lib external_dep，commonlibrary/rust 相关 target 也存在类似依赖。当前全量 registry 中可以看到 thirdparty:rust_libc，因此问题不宜再描述为源码全局缺 rust_libc，而应描述为具体产品/GN 上下文没有把 thirdparty:rust_libc 纳入可解析依赖域。也就是说，代码层声明了 external_dep，registry 层存在 provider，但产品选择和 GN 解析域之间没有闭合，导致同一依赖在全局存在、在被选产品构建上下文中不可解析。 建议协作：建议 developtools_hdc、third_party_rust 和 commonlibrary_rust 共同确认 rust_libc 的 canonical component 归属、inner kit 暴露方式和 external_deps 写法；build/preloader 协助确认产品 parts 是否应自动传递该依赖；相关产品 owner 协助确认 hdc 在该产品中是否需要启用。 问题 4：QEMU arm 产品选择或引用了不可解析的 component 涉及模块：vendor_ohemu、security_access_token、security_asset、appexecfwk、build/preloader。 问题说明：qemu-arm-linux-headless 产品选择 appexecfwk:appexecfwk_core，但当前 registry 中没有 appexecfwk_core component。另一个相关问题是 security:access_token 在特定 QEMU arm 产品上下文中引用 asset:saf_agent_fence 时无法解析。需要注意的是，当前源码中存在 security:asset 和 saf_agent_fence 相关源码，因此这不是“全量源码缺 asset”，而是产品上下文、dependency propagation 或 external_deps 解析域没有闭合。 代码上下文和不一致逻辑解释：QEMU arm 产品配置中选择 appexecfwk:appexecfwk_core，但 registry 中没有 appexecfwk_core component；同时 security:access_token 的 accesstoken manager GNI 中引用 asset:saf_agent_fence，在特定 QEMU 产品上下文中无法解析。security:asset 源码和 saf_agent_fence target 本身存在，因此这里的核心不一致不在于源文件缺失，而是产品 parts、component provider 和 GN external_dep 解析域没有形成同一个闭环。被选 component 依赖另一个 component 时，依赖 component 需要在该产品上下文中可达，否则构建图无法判断该依赖是否合法。 建议协作：建议 vendor_ohemu 和 build/preloader 先确认 qemu-arm 产品的 parts 展开是否正确；appexecfwk owner 确认 appexecfwk_core 是否为旧名或应迁移到新 component；security_access_token 与 security_asset owner 共同确认 saf_agent_fence 的 external_deps 写法和产品依赖传递方式。 问题 5：QEMU device subsystem 旧名和新名漂移 涉及模块：device_qemu、vendor_ohemu、build/preloader。 问题说明：QEMU x86_64 和 riscv64 相关 device 路径中，ohos.build 声明的 subsystem 名称与 preloader 或产品配置期望的 subsystem 名称不一致。例如源码侧仍出现 device_x86_64_virt、device_riscv64_virt 等旧式命名，而产品/preloader 侧使用 device_qemu-x86_64-linux、device_qemu-riscv64-linux 等新式命名。此类不一致会导致同一路径下 component 的归属无法被 build/preloader 正确匹配。 代码上下文和不一致逻辑解释：device/qemu/x86_64_virt/linux/ohos.build 和 device/qemu/riscv64_virt/linux/ohos.build 中仍使用 device_x86_64_virt、device_riscv64_virt 这类旧 subsystem 名称，而产品/preloader 侧期望 device_qemu-x86_64-linux、device_qemu-riscv64-linux 等新名称。ohos.build 是 component registry 的事实来源，产品 parts 是构建输入事实来源；同一路径的 subsystem 在两边不一致时，preloader 无法把产品选择映射到源码实现，属于典型的 subsystem identity drift。 建议协作：建议 device_qemu 与 vendor_ohemu 共同确认 QEMU device subsystem 的 canonical 命名；build/preloader 协助确认是否存在官方 alias 机制。如果没有 alias，应统一 ohos.build、产品 parts 和 preloader 期望名称。 问题 6：vendor_hisilicon 产品目录 subsystem 与 preloader 期望不一致 涉及模块：vendor_hisilicon、build/preloader、productdefine_common。 问题说明：watchos 和 hispark_taurus_standard 等产品目录的 ohos.build 仍使用 product_hisilicon 作为 subsystem，但 preloader 对具体产品期望的是 product_watchos 或 product_hispark_taurus_standard。产品目录本身的 part/subsystem 与 preloader 生成的产品级 registry 期望不一致，会导致产品 component 归属关系断裂。 代码上下文和不一致逻辑解释：vendor/hisilicon/watchos/ohos.build 和 vendor/hisilicon/hispark_taurus_standard/ohos.build 中声明 product_hisilicon，但产品级构建输入期望的是 product_watchos、product_hispark_taurus_standard。产品目录的 ohos.build 不只是普通元数据，它定义了该产品 component 在 registry 中的身份；如果多个具体产品仍共用过宽的 product_hisilicon，而 preloader 期待具体产品名，就会导致产品目录 registry identity 与产品构建 identity 不一致。 建议协作：建议 vendor_hisilicon 确认这些产品目录是否应使用产品级 subsystem 名称；build/preloader 和 productdefine_common 协助确认产品目录 ohos.build 的命名规范。如果应使用产品名，应修正 subsystem；如果 product_hisilicon 是兼容聚合名，应提供明确 alias 或转换规则。 问题 7：hispark_phoenix board subsystem mismatch 涉及模块：device_board_hisilicon、vendor_hisilicon、build/preloader。 问题说明：hispark_phoenix board 路径中的 ohos.build 声明使用 hisilicon_products，但产品/preloader 期望的是 device_hispark_phoenix。device board 侧 subsystem 与产品构建输入侧期望不一致，会让 board component 在 registry 中无法按预期定位。 代码上下文和不一致逻辑解释：device/board/hisilicon/hispark_phoenix/linux/ohos.build 声明 hisilicon_products，但产品/board 选择链路期望 device_hispark_phoenix。board 目录的 ohos.build 应该和 board selection 形成可追踪的映射；如果 board 源码使用泛化 subsystem，而产品构建期望具体 board subsystem，就会导致 board component 无法被稳定归入对应产品构建图。 建议协作：建议 device_board_hisilicon 与 vendor_hisilicon 共同确认 hispark_phoenix 的 board component 应归属哪个 subsystem；build/preloader 协助确认 board path 到 subsystem 的映射规范。 问题 8：ipcamera_hispark_aries 选择 commonlibrary:os_dump 但 registry 无法解析 涉及模块：vendor_hisilicon、commonlibrary、build/preloader。 问题说明：ipcamera_hispark_aries 产品 parts 中选择 commonlibrary:os_dump，但当前 component registry 中没有 os_dump component。产品选择层声明该 component 应进入构建，但 registry 无法提供该 component 的定义。 代码上下文和不一致逻辑解释：ipcamera_hispark_aries 的产品 parts 选择 commonlibrary:os_dump，但 registry 中不存在 os_dump component。这里的不一致链路很直接：product selection 已经把 os_dump 当成需要装配的 component，而 bundle/ohos.build registry 没有该 component 的定义。构建系统无法从 selected part 找到对应源码入口，维护者也无法判断这是旧名、遗漏注册还是废弃依赖。 建议协作：建议 vendor_hisilicon 确认 ipcamera_hispark_aries 是否仍需要 os_dump；commonlibrary owner 确认 os_dump 是否已更名、迁移或删除；build/preloader 协助确认是否需要 alias 或产品配置迁移。 问题 9：hispark_pegasus lite build config 引用不可达 third_party target 涉及模块：vendor_hisilicon、third_party_cJSON、third_party_optimized-routines、build_lite 或 build/preloader。 问题说明：hispark_pegasus mini/lite 构建配置中引用了 cJSON:cjson、optimized-routines:optimize_math、optimized-routines:optimized_static 等 target，但在对应 lite 产品构建上下文下这些 target 不可达。这里的问题不是普通文件缺失，而是产品生成的 build config 已经声明了依赖边，但 GN/lite target graph 不能满足这些依赖。 代码上下文和不一致逻辑解释：hispark_pegasus mini/lite 产品的 thirdparty build config 引用 //third_party/cJSON:cjson、//third_party/optimized-routines:optimize_math、//third_party/optimized-routines:optimized_static 等 target，但这些 target 在 lite 产品上下文中不可达。构建配置文件本质上声明了目标依赖边；如果被声明的 GN target 不存在或只在另一套构建体系下存在，就会出现 build config 与实际 target graph 不一致，导致 lite 产品无法可靠生成构建图。 建议协作：建议 vendor_hisilicon 与 third_party_cJSON、third_party_optimized-routines owner 确认 lite 产品下这些 target 的 canonical 名称；build_lite/build 维护者协助确认是否需要条件保护、target 重命名或 lite 专用 target。 二、HDF/HCS 配置生命周期不一致 问题 10：rk3568 BMP581 deviceMatchAttr 缺少对应 private match_attr 涉及模块：vendor_hihope、device_board_hihope、drivers/hdf sensor 相关模块。 问题说明：rk3568 的 HDF/HCS 配置中存在 BMP581 相关 deviceMatchAttr，但在对应 private HCS 配置侧没有找到匹配的 match_attr。HDF 编码规范要求 device_info.hcs 中的 deviceMatchAttr 与驱动私有配置中的 matchAttr 保持一致，否则设备节点和私有配置无法稳定建立映射。 代码上下文和不一致逻辑解释：HDF/HCS 的 device_info.hcs 通过 deviceMatchAttr 将设备节点和驱动私有配置关联起来，驱动私有 HCS 中则应有对应 matchAttr。rk3568 BMP581 相关配置中，device_info 侧出现 BMP581 deviceMatchAttr，但 private config 侧缺少匹配 match_attr。这样 HDF 框架在加载驱动配置时可能只能看到设备节点，却无法找到同名私有参数块，属于 HDF 配置生命周期中的 declaration-to-private-config 断裂。 建议协作：建议 vendor_hihope 和 device_board_hihope 确认 rk3568 是否实际启用 BMP581；drivers/hdf sensor owner 协助确认 BMP581 的 canonical matchAttr 命名。如果该传感器仍支持，应补齐 private match_attr；如果未启用，应移除或条件化相关 device_info 配置。 三、feature contract 和跨 component 依赖不一致 问题 11：productdefine/common 中多处 product feature 与 component contract 不一致 涉及模块：productdefine_common、build/preloader、对应 feature 所属 component owner。 问题说明：productdefine/common 中存在产品配置使用的 feature 未被对应 component contract 明确声明的情况。产品 feature 是产品配置和 component 可配置接口之间的契约。如果产品侧使用未声明 feature，会造成配置项是否生效不透明，也会掩盖拼写问题或历史残留。 代码上下文和不一致逻辑解释：productdefine/common 中的产品配置承担跨产品继承和 feature 输入职责，而 component 的 bundle/ohos.build feature contract 应声明它接受哪些 feature。当前存在产品层使用 feature、component contract 层没有声明的情况。该不一致逻辑是 schema-less feature injection：产品把字段传给 component，但 component 元数据没有承认该字段，导致拼写问题、废弃开关和真实开关无法被构建系统区分。 建议协作：建议 productdefine_common 和 build/preloader 明确 feature contract 的校验规则；对应 component owner 确认 feature 是否有效。有效 feature 应补充声明，废弃 feature 应从产品配置中移除。 问题 12：ipcamera_core_system 的 dsoftbus/input feature 未进入 bundle contract 涉及模块：vendor_hihope、communication_dsoftbus、drivers_interface_input 或 input 相关 component、build/preloader。 问题说明：ipcamera_core_system 使用了 dsoftbus/input 相关 feature，但对应 bundle contract 中缺少这些 feature 的明确声明。产品配置向 component 传入 feature 时，component contract 应明确承认这些开关，否则 build/preloader 无法可靠判断这些 feature 是合法配置还是历史残留。 代码上下文和不一致逻辑解释：ipcamera_core_system 产品配置使用了 dsoftbus/input 相关 feature，但 communication_dsoftbus 或 input 相关 bundle contract 没有完整声明这些 feature。产品配置到 component contract 的边应该是显式契约，而不是靠字符串约定；否则产品侧以为自己打开了某能力，component 侧却可能完全不消费该字段，最终造成产品能力声明和实际构建行为不一致。 建议协作：建议 vendor_hihope 确认 ipcamera_core_system 是否仍需要这些 feature；communication_dsoftbus 和 input 相关 owner 确认 feature 的语义与归属；build/preloader 协助统一 feature contract 校验。 问题 13：device_status 同时在 bundle 和 GN 中依赖 motion，但 registry 无 motion component 涉及模块：msdp_device_status、motion 相关模块 owner、build/preloader。 问题说明：device_status 模块在 bundle 依赖和 GN external_deps 中都指向 motion，但当前 registry 中找不到 motion component。由于 bundle 和 GN 两个机制都指向同一缺失 component，这比单点字符串漂移更强，说明 component 依赖契约没有闭合。 代码上下文和不一致逻辑解释：base/msdp/device_status 的 bundle.json 和 BUILD.gn 同时指向 motion，这说明 motion 不是偶然出现在一个注释或单点字符串中，而是被元数据和构建依赖共同当作 component 使用。但 registry 中没有 motion component。这样的双证据断裂说明 device_status 的 component dependency contract 指向了一个不可解析 provider，构建系统无法从 dependency 字段找到对应 component 和 target。 建议协作：建议 msdp_device_status owner 确认 motion 是否仍是有效独立 component；相关 motion owner 确认是否已合并、重命名或迁移；build/preloader 协助确认是否需要 registry alias 或依赖字段迁移。 问题 14：player_framework 引用 histreamer_ext，但 registry 无 histreamer_ext component 涉及模块：multimedia_player_framework、multimedia_av_codec、build/preloader。 问题说明：player_framework 相关依赖引用 histreamer_ext:http_curl_client，但当前 registry 中没有 histreamer_ext component；源码中相关 target 更像是位于 av_codec 路径。也就是说，依赖字段使用的 component 域与实际实现所在模块域不一致。 代码上下文和不一致逻辑解释：multimedia player_framework 相关依赖引用 histreamer_ext:http_curl_client，但 registry 中没有 histreamer_ext component，相关实现更接近 multimedia_av_codec 路径。external_dep 的左侧 component 名是构建系统解析依赖的命名空间，如果写成一个未注册的 histreamer_ext，即使右侧 target 存在于别的模块，依赖解析也不会自然闭合。这是依赖字段中的 component domain 与实际实现 domain 不一致。 建议协作：建议 multimedia_player_framework 与 multimedia_av_codec 共同确认 histreamer_ext 是否为旧名、逻辑子模块名或应注册的 component；build/preloader 协助确认 external_deps 是否应引用 av_codec 下的 canonical component。 问题 15：storage_service 可选依赖 libmtp/libgphoto2，但 registry 无对应 component 涉及模块：filemanagement_storage_service、third_party libmtp/libgphoto2 相关模块、build/preloader。 问题说明：storage_service 中存在 libmtp/libgphoto2 相关可选依赖，但当前 registry 中找不到 libmtp 和 libgphoto2 component。如果这些 third_party 能力在某些产品或 feature 条件下可启用，registry 和依赖声明应能闭合；如果它们已经废弃，应移除或增加条件保护。 代码上下文和不一致逻辑解释：filemanagement_storage_service 中保留 libmtp/libgphoto2 相关可选依赖，但 registry 中没有 libmtp、libgphoto2 component。可选依赖仍然需要在条件成立时有合法 provider；否则一旦 global_parts_info 或产品 feature 触发该分支，就会引用不存在的 component。该问题的本质是 conditional dependency 的 provider contract 缺失，而不是简单的未启用代码路径。 建议协作：建议 filemanagement_storage_service 确认可选依赖是否仍有效；third_party 相关 owner 确认是否存在迁移后的 component 名；build/preloader 协助确认条件可选依赖是否需要显式 registry contract。 四、SystemAbility profile、HDI/codegen 与打包产物一致性 问题 16：netmanager_base SA profile 指向 libdns_resolver_manager.z.so，但缺少清晰构建/打包证据 涉及模块：communication_netmanager_base、build/package、SystemAbility 管理相关模块。 问题说明：netmanager_base 的 SystemAbility profile 中声明了 libdns_resolver_manager.z.so。SA profile 中的 libpath 是运行时加载服务的关键入口，应该能在 GN output 或最终 package image 中找到对应 shared library 产物。如果 profile 指向的 so 没有对应构建或打包证据，运行时可能出现服务无法加载、profile 与实际产物漂移等问题。 代码上下文和不一致逻辑解释：foundation/communication/netmanager_base/sa_profile/1156.json 中声明 libdns_resolver_manager.z.so。SystemAbility profile 的 libpath 是运行时加载服务库的入口，因此它应能对应到 GN 构建输出和最终 package image 中的同名 shared library。若 profile 指向的 so 没有清晰构建/打包来源，就会形成 profile declares service library 但 build/package 不一定提供该 library 的断裂，运行期可能表现为服务加载失败或 profile 陈旧。 建议协作：建议 communication_netmanager_base owner 确认该 SA profile 是否仍有效；build/package owner 协助确认 libdns_resolver_manager.z.so 是否由某个 target 生成并进入产品镜像；SystemAbility 相关维护者协助确认 profile libpath 的规范检查方式。 问题 17：device_standby SA profile 要求 libtp_proxy_1.0.z.so，但需要 HDI/codegen/package 证据闭合 涉及模块：resourceschedule_device_standby、drivers_interface 或相关 HDI owner、ability_idl_tool、build/package。 问题说明：device_standby 的 SA profile 中包含 libtp_proxy_1.0.z.so。该名字看起来像 HDI proxy 或 codegen 产物。若 profile 依赖该 so，应该能从 IDL/HDI codegen、GN target、package image 中找到完整链路；否则 profile 可能指向不存在或未打包的 proxy library。 代码上下文和不一致逻辑解释：foundation/resourceschedule/device_standby/sa_profile/1914.json 中声明 libtp_proxy_1.0.z.so，该名称看起来像 HDI/IDL codegen 生成的 proxy library。SA profile 依赖 proxy so 时，应该能追踪到 IDL 定义、codegen target、GN output 和 package 产物。当前链路缺少完整证据，意味着 profile 层声明了运行期依赖，但 generated/built/packaged 层未能自解释地证明该 so 一定存在。 建议协作：建议 resourceschedule_device_standby owner 确认该 SA profile 的运行时需求；HDI/interface owner 和 ability_idl_tool 维护者协助确认 libtp_proxy_1.0.z.so 是否应由 codegen 生成；build/package owner 协助确认该产物是否进入目标产品镜像。 五、inner_kits / header_base / header_files / NDK header 路径契约不一致 问题 18：Bluetooth A2DP inner kit header_base 少 include 层级 涉及模块：drivers_interface、Bluetooth interface、SDK/header export 相关模块。 问题说明：Bluetooth A2DP inner kit 中 header_base 指向 a2dp/include，但实际头文件路径包含更深的 include 层级。header_base/header_files 组合应能拼出真实存在的导出头文件路径；否则 SDK 或其他模块引用 inner kit 时可能拿到不正确的导出路径。 代码上下文和不一致逻辑解释：drivers/interface/bluetooth/bundle.json 中 A2DP inner kit 的 header_base/header_files 组合指向 drivers/interface/bluetooth/a2dp/audio_adapter.h，但真实头文件位于 drivers/interface/bluetooth/a2dp/include/audio_adapter.h。inner_kits 元数据用于给外部模块和 SDK 导出头文件；当 header_base 少了一层 include 时，消费者按元数据拼出的路径不存在，说明 metadata export contract 与源码布局不一致。 建议协作：建议 drivers_interface Bluetooth owner 确认 A2DP inner kit 的 canonical 导出目录；SDK/header export 维护者协助确认 header_base 与 header_files 的组合规则。 问题 19：graphic_3d 中 scene_adpater 拼写漂移 涉及模块：graphic_graphic_3d、SDK/header export 相关模块。 问题说明：graphic_3d 的 bundle 元数据中出现 scene_adpater 这样的拼写，疑似应为 scene_adapter。此类拼写漂移会导致 header/export 路径和真实源码路径之间断裂，也会长期污染 SDK 元数据。 代码上下文和不一致逻辑解释：foundation/graphic/graphic_3d/bundle.json 中出现 scene_adpater 这类拼写，而正常英文和相关路径语义应为 scene_adapter。bundle 元数据中的路径/模块名会参与 header export 或 target 组织，拼写漂移会导致工具按不正确名称寻找目录或头文件。即使某些兼容路径暂时遮蔽问题，metadata 中长期保留非 canonical 拼写也会让新消费者和自动化工具无法判断 canonical 目录。 建议协作：建议 graphic_graphic_3d owner 确认 scene_adpater 是否为历史兼容名；SDK/header export 维护者协助确认是否已有兼容 alias。如果不是有意兼容，应修正为 canonical 拼写。 问题 20：i18n_lite 的 zone/include header_base 路径不一致 涉及模块：global_i18n_lite、SDK/header export 相关模块。 问题说明：i18n_lite 的 bundle 元数据中存在 zone/include 相关 header_base，但对应路径与源码实际导出路径不一致。header export 元数据如果指向不存在路径，会影响依赖方通过 inner kit 获取正确头文件。 代码上下文和不一致逻辑解释：base/global/i18n_lite/bundle.json 中 zone/include 相关 header_base 与实际源码布局不一致。header_base 的逻辑是给 header_files 提供公共前缀，二者拼接后应落到真实存在的头文件。如果 bundle 元数据指向不存在的 zone/include，依赖方按 inner kit 导入 i18n_lite 时会得到不正确 include 根目录。 建议协作：建议 global_i18n_lite owner 确认 zone 相关头文件当前真实导出目录；SDK/header export 维护者协助确认应修正 header_base 还是 header_files。 问题 21：third_party benchmark header_base 少 benchmark 层级 涉及模块：third_party_benchmark、build/SDK metadata 相关模块。 问题说明：third_party benchmark 的 bundle 元数据中 header_base/header_files 组合无法直接对应真实头文件路径，表现为缺少一层 benchmark 路径。第三方库的 header export 一旦不一致，依赖方可能需要写非规范 include 路径才能编译通过。 代码上下文和不一致逻辑解释：third_party/benchmark/bundle.json 的 header_base/header_files 组合缺少 benchmark 目录层级，导致元数据拼出的导出路径和真实第三方库头文件布局不一致。third_party 组件通常被其他模块复用，header export 不一致会让依赖方绕过标准 inner kit 机制改用硬编码路径，增加后续升级风险。 建议协作：建议 third_party_benchmark owner 确认实际头文件布局；build/SDK metadata owner 协助确认是否应修正 header_base 或 header_files。 问题 22：hichecker 的 inner_kits.header_files 中包含 .cpp 文件 涉及模块：hiviewdfx_hichecker、SDK/header export 相关模块。 问题说明：hichecker 的 inner_kits.header_files 中出现 .cpp 文件。header_files 按语义应描述对外导出的头文件，而不是源码实现文件。将 .cpp 放入 header_files 会造成 SDK 元数据语义不一致，也可能影响自动化导出或依赖方扫描。 代码上下文和不一致逻辑解释：base/hiviewdfx/hichecker/bundle.json 的 inner_kits.header_files 中包含 .cpp 文件。header_files 字段的语义是声明对外可包含的头文件，而 .cpp 是实现文件，不适合作为 SDK/header export 的一部分。把实现文件放入 header_files 会让元数据类型语义不一致，也可能让自动导出、依赖扫描或 SDK 检查产生异常结果。 建议协作：建议 hiviewdfx_hichecker owner 确认该 .cpp 是否误填；SDK/header export 维护者协助确认 header_files 字段是否应增加类型校验。 问题 42：window_manager dmndk NDK headers source 路径缺少 dm 层级 涉及模块：window_window_manager、NDK/SDK header export 相关模块。 问题说明：dmndk 的 ohos_ndk_headers 声明中存在裸 header 路径，例如 interfaces/kits/dmndk/oh_display_capture.h，但真实源码路径位于 dm 子目录下。NDK header target 声明的 source 应能解析到真实文件，否则 SDK/NDK header 导出可能遗漏或失败。 代码上下文和不一致逻辑解释：foundation/window/window_manager 的 dmndk ohos_ndk_headers 声明了 interfaces/kits/dmndk/oh_display_capture.h，但真实文件在 interfaces/kits/dmndk/dm/oh_display_capture.h。NDK header target 的 source 列表应是可解析的实际源码路径；声明路径少了 dm 子目录，会让 SDK/NDK 导出规则查找不存在文件。 建议协作：建议 window_window_manager owner 确认 dmndk header 的真实导出目录；NDK/SDK header export 维护者协助确认 ohos_ndk_headers 是否应改为包含 dm 子目录。 问题 43：window_manager ndk NDK headers source 路径缺少 wm 层级 涉及模块：window_window_manager、NDK/SDK header export 相关模块。 问题说明：ndk 的 ohos_ndk_headers 声明中存在裸 header 路径，例如 interfaces/kits/ndk/oh_window.h，但真实源码路径位于 wm 子目录下。该问题与 dmndk 类似，属于 NDK header target 声明和实际源码路径不一致。 代码上下文和不一致逻辑解释：foundation/window/window_manager 的 ndk ohos_ndk_headers 声明了 interfaces/kits/ndk/oh_window.h，但真实文件在 interfaces/kits/ndk/wm/oh_window.h。和 dmndk 问题一样，header source 列表与真实源码布局不一致，会导致 NDK 导出 target 无法按声明路径收集头文件。 建议协作：建议 window_window_manager owner 与 NDK/SDK header export 维护者共同确认 ndk header 的 canonical 导出路径，并同步修正 source 列表。 六、HAP build-profile 与应用模块目录不一致 问题 23：USB dialog 顶层 build-profile 保留不存在的 ./entry 涉及模块：busmanager_usb_manager、应用构建/HAP 打包工具相关模块。 问题说明：USB dialog 的 build-profile.json5 中保留了 ./entry 模块路径，但对应 entry 目录不存在。build-profile 是应用构建和打包的重要入口，如果顶层 profile 保留不存在模块，容易造成 IDE、构建、打包或工具链扫描时产生误导。 代码上下文和不一致逻辑解释：base/usb/usb_manager/frameworks/dialog/dialog_ui/build-profile.json5 中保留 ./entry 模块声明，但同目录下 entry 模块不存在。build-profile.json5 是 HAP/ArkUI 工程的模块入口描述，声明了构建工具应遍历和打包哪些 module。profile 指向不存在目录时，项目结构与构建入口不一致，IDE、构建器或打包工具会基于陈旧 module 信息工作。 建议协作：建议 busmanager_usb_manager owner 确认该 dialog_ui 是否仍作为 HAP/ArkUI 工程维护；应用构建/HAP 工具 owner 协助确认 build-profile 中 stale module 是否应报错或 warning。 问题 24：VPN dialog 顶层 build-profile 保留不存在的 ./entry 涉及模块：communication_netmanager_ext、应用构建/HAP 打包工具相关模块。 问题说明：VPN dialog 的 build-profile.json5 中同样保留了 ./entry 模块路径，但对应 entry 目录不存在。该问题与 USB dialog 类似，属于 profile 声明和实际模块目录之间的不一致。 代码上下文和不一致逻辑解释：foundation/communication/netmanager_ext/frameworks/vpn_dialog/dialog_ui/build-profile.json5 同样声明 ./entry，但实际 entry 目录不存在。这个问题的不一致逻辑与 USB dialog 一致：顶层 profile 声明了一个 module，源码树没有该 module 实体，导致 profile declaration 与 source module layout 断裂。 建议协作：建议 communication_netmanager_ext owner 确认 VPN dialog 的 HAP 工程结构；应用构建/HAP 工具 owner 协助确认是否需要清理 stale module 或补充目录。 七、prebuilt / package 输入路径一致性 问题 44：updateservice 的 updater_sa.rc prebuilt source 路径错位 涉及模块：base_update_updateservice、build/package、SystemAbility 或 init rc 打包相关模块。 问题说明：updateservice 中 updater_sa.rc 的 prebuilt source 指向 inner_api/engine/etc 路径，但当前实际文件位于 services/engine/etc。prebuilt 或 copy target 的 source 路径若指向不存在文件，会造成打包输入不稳定，或者依赖历史路径残留。 代码上下文和不一致逻辑解释：base/update/updateservice 的 prebuilt/copy 规则指向 interfaces/inner_api/engine/etc/updater_sa.rc，但真实 updater_sa.rc 位于 services/engine/etc。rc 文件是服务启动和打包的重要输入；构建元数据指向不存在的旧路径，而源码实际文件在新路径，说明 copy source 与源码布局迁移没有同步。 建议协作：建议 base_update_updateservice owner 确认 updater_sa.rc 的 canonical 位置；build/package owner 协助确认 prebuilt/copy target 是否应改为 services/engine/etc 路径。 问题 45：accessibility_service.rc prebuilt source 缺失 涉及模块：foundation_barrierfree_accessibility、build/package、init rc 打包相关模块。 问题说明：accessibility_service.rc 的 prebuilt source 指向当前源码中不存在的路径。若该 rc 文件仍应进入镜像，源码或生成规则需要补齐；如果该服务启动方式已迁移，应清理 stale prebuilt 声明。 代码上下文和不一致逻辑解释：foundation/barrierfree/accessibility 的 accessibility_service.rc prebuilt source 指向 services/aams/etc/accessibility_service.rc，但该路径下文件不存在。若 accessibility service 仍依赖该 rc 进入镜像，则 source 缺失会影响打包；若服务启动方式已经迁移，则 prebuilt 声明未清理，属于 stale packaging metadata。 建议协作：建议 accessibility owner 确认服务启动 rc 是否仍需要；build/package owner 协助确认对应 prebuilt source 是迁移、生成还是废弃。 问题 46：appspawn standard duplicate rc target source 指向不存在路径 涉及模块：base_startup_appspawn、build/package、init rc 打包相关模块。 问题说明：appspawn standard 相关重复 rc target 中存在 source 指向不存在路径的情况。该项目前更适合作为 P2 cleanup，因为它可能被其他更强 target 或产品条件遮蔽；但从元数据一致性角度看，重复 target 中保留不存在 source 仍会造成长期维护风险。 代码上下文和不一致逻辑解释：base/startup/appspawn 的 standard 相关重复 rc target 中仍保留 source 指向不存在路径。即使该 target 可能被其他目标遮蔽或只在特定产品条件下触发，元数据中保留不可解析 source 仍会让构建图存在潜在断裂点；后续产品矩阵变化或条件切换时，这类 shadowed stale source 可能变成真实构建失败。 建议协作：建议 base_startup_appspawn owner 确认重复 rc target 是否仍有必要；build/package owner 协助判断是否应删除 shadowed target、修正 source，或增加明确条件保护。 八、SysCap/API/checker/provider/bundle 契约不一致 问题 25：多项 SysCap 未进入 SDK checker allow-list 或 checker 契约不闭合 涉及模块：interface_sdk-js、interface_sdk_c、相关 API owner、相关 provider component owner。 问题说明：部分 API 或文档中出现的 SysCap 与 SDK checker allow-list 或 component provider 声明之间没有完整闭合。SysCap 是设备能力、API 可见性和产品能力集之间的重要契约；如果 API 暴露了某个 SysCap，但 checker 或 provider 侧没有一致声明，应用开发者和产品裁剪都可能看到不一致结果。 代码上下文和不一致逻辑解释：SysCap 是 API 可见性、设备能力和产品 profile 之间的统一能力名。若 API 注解或文档中出现某个 SysCap，而 interface_sdk-js/interface_sdk_c checker allow-list 或 provider bundle 没有对应声明，应用开发者可能看到 API 声称需要某能力，但工具链无法校验或产品侧无法证明该能力由谁提供。这是 API declaration、checker contract 和 provider contract 之间的不一致。 建议协作：建议 interface_sdk-js、interface_sdk_c 和对应 API owner 共同确认 SysCap canonical 名称；provider component owner 确认是否应声明该能力；checker 维护者确认 allow-list 或校验规则是否需要更新。 问题 26：SecureElement 相关 SysCap 在 API/checker 与 provider bundle 之间不一致 涉及模块：drivers_interface、interface_sdk-js、SecureElement provider 或 driver 相关模块。 问题说明：SecureElement 相关 API/checker 中存在 SysCap 暴露或校验线索，但对应 provider bundle 声明链不完整。若该能力对应用或系统服务可见，应存在明确 provider component；否则 API/checker 暴露会和设备实际能力来源不一致。 代码上下文和不一致逻辑解释：SecureElement 相关能力在 drivers_interface/API/checker 侧出现，但 provider bundle 声明链不完整。对于硬件接口能力，API 暴露的 SysCap 应能回溯到驱动或服务 provider；如果只有 API/checker 侧名字，没有对应 provider component，那么产品能力集无法判断设备是否真正提供 SecureElement 能力。 建议协作：建议 drivers_interface 和 SecureElement provider owner 确认能力提供方；interface_sdk-js 维护者协助确认 checker 是否应承认该 SysCap 或下线相关声明。 问题 27：UDMF DataIntelligence SysCap 与 bundle/provider 声明不一致 涉及模块：distributeddatamgr_udmf、interface_sdk-js、SysCap/checker 相关模块。 问题说明：UDMF/DataIntelligence 相关 SysCap 在 API/checker 和 bundle/provider 声明之间存在不一致线索。若 API 层宣称该能力可用，应该能追溯到提供该能力的 component 或产品 capability profile。 代码上下文和不一致逻辑解释：UDMF/DataIntelligence 相关 SysCap 在 API/checker 和 distributeddatamgr_udmf 的 provider 声明之间不闭合。能力生命周期应当从 API exposure 追踪到 bundle provider 和产品 profile；如果 API 侧使用该能力名，而 provider 侧没有稳定声明，checker 和产品裁剪就无法判断该 API 在目标设备上是否可用。 建议协作：建议 distributeddatamgr_udmf owner 确认 DataIntelligence 能力是否由该模块提供；interface_sdk-js 和 SysCap checker owner 协助确认 canonical SysCap 名称和 checker 规则。 问题 28：Audio DeviceEnhance SysCap provider 缺口 涉及模块：multimedia_audio_framework、interface_sdk-js、SysCap/checker 相关模块。 问题说明：Audio DeviceEnhance 相关 SysCap 在 API 或 checker 侧出现，但 provider bundle 声明链不完整。此类问题可能导致 API 能力声明与产品实际提供能力之间发生漂移。 代码上下文和不一致逻辑解释：Audio DeviceEnhance 相关 SysCap 在 multimedia_audio_framework 的 API 或 checker 侧可见，但 provider bundle 声明链不完整。音频增强能力通常会受设备硬件、服务实现和产品能力集共同影响；如果 API/checker 暴露了能力，但 provider 侧没有声明，应用侧能力判断和系统侧能力提供会发生漂移。 建议协作：建议 multimedia_audio_framework owner 确认 DeviceEnhance 能力归属；interface_sdk-js 和 checker owner 协助确认该 SysCap 是否应进入 allow-list、provider 声明或产品 profile。 问题 29：Image 相关 root SysCap 与细分 SysCap 命名漂移 涉及模块：multimedia_image_framework、interface_sdk-js、interface_sdk_c、API 文档相关模块。 问题说明：Image 相关 API 中存在 root SysCap 和细分 SysCap 之间的命名漂移。若同一能力同时以粗粒度和细粒度名称出现，checker、文档、API annotation 和 provider bundle 需要保持统一，否则应用开发者和产品裁剪会看到不一致的能力语义。 代码上下文和不一致逻辑解释：multimedia_image_framework 中 root SysCap 与细分 SysCap 混用，会让同一图像能力在 API 注解、C/JS SDK checker、文档和 provider bundle 中以不同粒度出现。若没有明确的父子关系或 alias 规则，工具链无法判断粗粒度能力是否覆盖细粒度能力，开发者也无法判断应在代码中检查哪个 SysCap。 建议协作：建议 multimedia_image_framework、interface_sdk-js、interface_sdk_c 和 API 文档 owner 共同确认 Image SysCap 的 canonical 分层策略；如果保留兼容名，应明确 alias 规则。 问题 30：BusManager.Serial API 暴露但 driver bundles 未声明对应 SysCap 涉及模块：drivers_interface、drivers_peripheral_serial、drivers_peripheral_usb、interface_sdk-js。 问题说明：BusManager.Serial 能力在 API 或 checker 侧可见，但 serial/usb 等 driver provider bundle 中缺少相应 SysCap 声明。若该能力由 driver 模块提供，provider bundle 应能表达该能力来源；否则 API 暴露和实际 provider 之间不一致。 代码上下文和不一致逻辑解释：BusManager.Serial API 在 drivers_interface 或 checker 侧暴露，但 drivers_peripheral_serial、drivers_peripheral_usb 等 provider bundle 没有相应 SysCap 声明。Serial/BusManager 是典型硬件接口能力，API 可见性应与 driver provider 能力声明一致；否则 API 层会向应用暴露一个无法由产品能力集证明来源的能力。 建议协作：建议 drivers_interface 与 serial/usb driver owner 共同确认能力归属；interface_sdk-js 协助确认 checker/API annotation 是否应更新。 问题 31：docs 中 SysCap 大小写与 canonical 名称漂移 涉及模块：docs、interface_sdk-js、interface_sdk_c、productdefine_common。 问题说明：文档中的部分 SysCap 大小写与 checker/API 中的 canonical 名称不一致。SysCap 名称大小写通常具有契约意义，文档漂移会误导应用开发者，也可能影响自动化检查。 代码上下文和不一致逻辑解释：docs 中部分 SysCap 名称大小写与 interface checker/API 的 canonical 写法不一致。SysCap 字符串是机器可消费的能力标识，不只是自然语言描述；大小写漂移会让文档示例、应用检查代码和 checker allow-list 使用不同 token，从而制造文档与工具链之间的能力名不一致。 建议协作：建议 docs 与 interface_sdk-js/interface_sdk_c 共同确认 canonical SysCap 名称；productdefine_common 协助确认产品 profile 中是否使用同一写法。 问题 32：DeviceManager SysCap 大小写异常 涉及模块：distributedhardware_device_manager、docs、interface_sdk-js。 问题说明：DeviceManager 相关 SysCap 中出现 DISTRIBUTEDHARDWARE.deviceManager 与 DistributedHardware.DeviceManager 等大小写漂移。若 checker、API 和文档各自使用不同写法，开发者难以判断哪个名称有效。 代码上下文和不一致逻辑解释：distributedhardware_device_manager 相关能力中出现 DISTRIBUTEDHARDWARE.deviceManager 与 DistributedHardware.DeviceManager 这类大小写漂移。由于 DeviceManager 能力会跨 docs、API annotation、checker 和产品 profile 使用，不同大小写会被工具视为不同 token，导致能力声明和校验无法稳定匹配。 建议协作：建议 distributedhardware_device_manager owner 与 docs、interface_sdk-js 共同确认 canonical 名称；如果历史写法需要兼容，应在 checker 和文档中明确 alias。 问题 33：NeuralNetworkRuntime SysCap 中 Ai / AI 大小写漂移 涉及模块：ai_neural_network_runtime、docs、interface checker 相关模块。 问题说明：NeuralNetworkRuntime 相关 SysCap 中存在 Ai 与 AI 大小写漂移。该类问题虽然不一定直接导致构建失败，但会破坏 API/checker/doc 的同名契约。 代码上下文和不一致逻辑解释：ai_neural_network_runtime 中 Ai 与 AI 的大小写漂移属于同一类 token identity 问题。NeuralNetworkRuntime 的 SysCap 如果在文档、API 或 checker 中使用不同大小写，构建和 SDK 工具无法自动判断它们是否等价，应用开发者也可能复制不一致写法。 建议协作：建议 ai_neural_network_runtime owner 与 docs、checker owner 确认 canonical 命名；必要时做文档和 checker 同步修正。 问题 34：samgr_lite 中 HilogLite/HieventLite 与 checker 大小写不一致 涉及模块：systemabilitymgr_samgr_lite、interface_sdk-js、interface_sdk_c、hiviewdfx 相关模块。 问题说明：samgr_lite 相关能力中出现 HilogLite/HieventLite 与 HiLogLite/HiEventLite 等大小写不一致。由于这些能力名称跨文档、API、checker 和 provider 使用，应统一 canonical 写法或明确兼容策略。 代码上下文和不一致逻辑解释：systemabilitymgr_samgr_lite 与 hiviewdfx 相关能力中出现 HilogLite/HieventLite 和 HiLogLite/HiEventLite 等写法差异。HiLog/HiEvent 是已有命名风格，lite 能力名如果在 checker、文档、provider 之间大小写不统一，会让同一轻量能力在不同机制中呈现为不同 SysCap。 建议协作：建议 systemabilitymgr_samgr_lite、hiviewdfx owner 与 interface checker 维护者共同确认 canonical 命名。 问题 35：applications_notes 使用旧 component 名作为依赖 涉及模块：applications_notes、hiviewdfx_hilog、web_webview 或 web 相关模块、global_resource_management、multimedia_media_library、build/preloader。 问题说明：applications_notes 的 bundle 依赖中出现 hiviewdfx_hilog_native、web_webview、resourceManager、medialibrary_standard 等旧名或非 canonical component 名。当前 registry 中这些名称无法直接解析或已存在更规范的归属。该问题会导致应用依赖和全局 component registry 之间发生 taxonomy drift。 代码上下文和不一致逻辑解释：applications_notes 的 bundle 依赖中使用 hiviewdfx_hilog_native、web_webview、resourceManager、medialibrary_standard 等旧名或非 canonical 名。bundle deps 是 component 级依赖契约，应能映射到当前 registry 中的 subsystem:component；如果字段中保留旧名，build/preloader 无法可靠区分这是历史 alias、进程名、库名还是缺失 component。 建议协作：建议 applications_notes owner 确认这些依赖是否仍需要；相关 component owner 确认 canonical component 名；build/preloader 协助确认是否存在旧名 alias 或需要迁移依赖字段。 问题 36：call_manager 依赖 watch_system_service 但 registry 无该 component 涉及模块：telephony_call_manager、wearable/watch system 相关模块、build/preloader。 问题说明：call_manager 的 GN 依赖中引用 watch_system_service，但当前 registry 中没有 watch_system_service component。若这是可选 wearable/watch 能力，依赖应有明确条件和 registry 映射；如果已迁移，应更新到 canonical component。 代码上下文和不一致逻辑解释：base/telephony/call_manager/BUILD.gn 中引用 watch_system_service，但 registry 中没有 watch_system_service component。GN external_deps 或 deps 中出现的 component 名应能由 registry 解析到 provider；否则 telephony_call_manager 在某些条件下会依赖一个构建系统不知道如何提供的 watch/wearable 服务。 建议协作：建议 telephony_call_manager 与 wearable/watch system owner 共同确认该依赖是否仍有效；build/preloader 协助确认 conditional dependency 和 component registry 的表达方式。 问题 37：av_session 依赖 CollaborationFwk，但 registry 无该 component 涉及模块：multimedia_av_session、collaboration 或 distributed framework 相关模块、build/preloader。 问题说明：av_session 的 bundle 依赖中出现 CollaborationFwk，但当前 registry 中没有该 component。这个名字可能是旧模块名、框架名或未注册 component；不管是哪种情况，bundle deps 与 registry contract 没有闭合。 代码上下文和不一致逻辑解释：foundation/multimedia/av_session/bundle.json 中依赖 CollaborationFwk，但 registry 中没有 CollaborationFwk component。bundle dependency 是组件层面的声明，而 CollaborationFwk 更像框架名或历史模块名；如果没有注册为 component，也没有 alias，依赖字段就无法被 build/preloader 转成实际 provider。 建议协作：建议 multimedia_av_session 与 collaboration/distributed framework owner 确认 CollaborationFwk 的现行归属；build/preloader 协助确认是否需要 alias 或依赖字段迁移。 问题 38：permission_lite mini target subsystem 与 registry 归属不一致 涉及模块：security_permission_lite、build_lite、build/preloader。 问题说明：permission_lite mini 目标中使用 permission_lite:permission_lite 归属，但 registry 中存在的是 security:permission_lite。也就是说 target 声明的 subsystem 和 registry 中 component 的 canonical subsystem 不一致。 代码上下文和不一致逻辑解释：base/security/permission_lite/services/pms/BUILD.gn 中声明 subsystem_name = "permission_lite"，但 registry 中存在的是 security:permission_lite，而 permission_lite:permission_lite 不存在。BUILD.gn 的 subsystem_name 和 part_name 决定 target 归属；这里 target 自称属于 permission_lite subsystem，但 component registry 把它归入 security subsystem，导致 target ownership 与 registry ownership 不一致。 建议协作：建议 security_permission_lite owner 与 build_lite/build owner 确认 lite 目标的 subsystem 命名规范；如果 security 是 canonical subsystem，应更新 mini target；如果 permission_lite 是兼容名，应提供 alias。 问题 39：sensors start 中 msdp:start 与 registry 归属不一致 涉及模块：sensors_start、msdp 相关模块、build/preloader。 问题说明：start 相关 BUILD.gn 中使用 msdp:start，但 registry 中存在的是 sensors:start。该问题表现为实现路径、target 声明和 component registry 对同一能力归属不一致。 代码上下文和不一致逻辑解释：base/sensors/start/etc/init/BUILD.gn 中声明 subsystem_name = "msdp"，形成 msdp:start 这样的归属，但 registry 中存在的是 sensors:start。init target 的 subsystem/part_name 应与 component registry 对同一能力使用同一身份；否则同一个 start component 在构建 target 和 registry 中属于不同 subsystem。 建议协作：建议 sensors_start 与 msdp owner 共同确认 start component 的归属；build/preloader 协助确认是否应迁移 subsystem_name 或补充 alias。 问题 40：Rockchip HDF target 使用 hdf:rockchip_products，与 registry 归属不一致 涉及模块：device_soc_rockchip、device_board_hihope、HDF/build 相关模块。 问题说明：Rockchip HDF target 中出现 hdf:rockchip_products，但 registry 中对应 component 更像是 rockchip_products:rockchip_products。这说明 HDF target 的 subsystem 域和产品/SoC registry 的 component 归属不一致。该问题可能不会在所有产品中造成阻断，但属于真实 taxonomy drift。 代码上下文和不一致逻辑解释：Rockchip HDF target 使用 hdf:rockchip_products，但 registry 中存在的是 rockchip_products:rockchip_products。HDF 构建目标、SoC 产品 component 和 board 产品配置之间需要共同识别 rockchip_products；如果 HDF target 把它放在 hdf subsystem，而 registry 把它放在 rockchip_products subsystem，跨机制 join 时就会出现同名 part 不同 subsystem 的 taxonomy drift。 建议协作：建议 device_soc_rockchip、device_board_hihope 与 HDF/build 维护者共同确认 rockchip_products 的 canonical subsystem；如果 HDF 侧需要单独 subsystem，应明确映射关系。 问题 41：docs/checker 中 SysCap 大小写 cleanup 涉及模块：docs、interface_sdk-js、interface_sdk_c、相关 API owner。 问题说明：文档和 checker 中仍存在一些 SysCap 大小写、命名分层或历史写法不一致的问题。这些问题不一定都是构建阻断，但会影响 API 文档、checker 校验和产品 profile 的一致性。 代码上下文和不一致逻辑解释：docs/checker 中的 SysCap 大小写和命名分层 cleanup 属于能力 token 的全链路一致性问题。文档负责指导开发者，checker 负责机器校验，API annotation 负责接口能力声明；如果三者没有使用同一 canonical 名称，就会出现文档能搜到、checker 不接受，或 checker 接受但文档不一致的情况。 建议协作：建议 docs 与 interface SDK/checker owner 建立一次 SysCap canonical 名称对齐；相关 API owner 协助确认能力是否仍有效。 祝好 侯朋朋