- dev - lists.openatom.io

【会议纪要】OpenHarmony 架构SIG（第212次会议）纪要20260609
by Yangna (y) 16 Jun '26

16 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第212次会议）会议时间 Time 2026-6-9 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林与会人 Attendees 任革林，董金光，各议题汇报人等历史纪要归档路径方式1：https://gitcode.com/openharmony/community/tree/master/sig/sig_architect… 方式2（优先）：dev邮件列表纪要查询方式：https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/，页面内可以按月份筛选会议议题 Agenda 议题1：申请新建sig仓: officeservice_enterprise_deploy_restore 议题2：申请新建sig仓: homegraph 议题3：申请sig仓孵化毕业（仅目录迁移）：device_board_hisilicon_hispark_aifly，device_soc_hisilicon_hispark_aifly，vendor_hisilicon_hispark_aifly 本次会议主要内容：议题1、申请新建sig仓: officeservice_enterprise_deploy_restore 汇报人：孙志勇会议结论： 1、闭环遗留问题后再重新上会。遗留问题： 1、梳理清楚和克隆应用的规格需求上有哪些差异，从需求和架构设计合理性评估是否需要新增企业批量部署恢复的服务。 2、从功能规格描述看，属于MDM范畴，评估是否可以纳入MDM模块统一管理。 3、仓名太长。议题2、申请新建sig仓: homegraph 汇报人：孙波会议结论： 1、闭环遗留问题后再重新上会。遗留问题： 1、接口定义和功能描述过于笼统，需要进一步具体化。明确代码仓库的主要功能，包括具体的查询接口和功能。 2、孵化目标进一步细化，并Smart化。议题3、申请sig仓孵化毕业（仅目录迁移）：device_board_hisilicon_hispark_aifly，device_soc_hisilicon_hispark_aifly，vendor_hisilicon_hispark_aifly 汇报人：邹美广会议结论： 1、L1新开发板先合入6.1 LTS分支，要求配套CI门禁冒烟测试看护版本质量、整机启动默认系统应用内存<100M，并且对比Hi3516DV300开发板，摸测性能、安全、可靠性。 2、6.1 LTS分支门禁验收完成后，再上会评审。遗留问题： 1、L1新开发板合入主干时要求有配套CI门禁，确保版本开发过程的可用性能得到保障。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

回复：OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug）
by Fuyao Kashizuku 16 Jun '26

16 Jun '26

Ping... ------------------------------------------------------------------ 发件人：pengpeng <pengpeng(a)iscas.ac.cn> 发送时间：2026年6月12日(周五) 14:13 收件人：fuyao<fuyao(a)sjterm.com> 抄　送：maijianzhang<maijianzhang(a)allwinnertech.com> 主　题：回复：[Dev] OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug）对于反馈的bug，社区已经没人负责和维护了吗？原始邮件发件人：Fuyao Kashizuku <fuyao(a)sjterm.com> 发件时间：2026年6月12日 11:39 收件人：侯朋朋 <pengpeng(a)iscas.ac.cn> 抄送：maijianzhang <maijianzhang(a)allwinnertech.com> 主题：回复：[Dev] OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug）收到，他们家就是自己玩儿。 kpi考核太严重了，都只管自己的 ------------------------------------------------------------------ 发件人：侯朋朋 via dev <dev(a)openharmony.io> 发送时间：2026年6月11日(周四) 22:58 收件人：dev<dev(a)openharmony.io> 抄　送：pengpeng<pengpeng(a)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 协助确认能力是否仍有效。祝好侯朋朋

1 0

【会议通知】OpenHarmony 架构SIG（第213次会议），时间：2026-6-16 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 16 Jun '26

16 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第213次会议）会议时间 Time 2026-6-16 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=455967880481&pwd=MDg4MzE0&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/455967880481/9c061244e6c3c93f… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：455967880481 嘉宾密码：088314 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓：useriam_ta 申请开源引入：SeetaFace 李兵 libing(a)talkweb.com.cn<mailto:libing@talkweb.com.cn> security-sig 李兵 libing(a)talkweb.com.cn<mailto:libing@talkweb.com.cn> 胡泽华 huzehua25966(a)talkweb.com.cn<mailto:huzehua25966@talkweb.com.cn> 2 申请新建sig仓: calendar 黄辛未 huangxinwei2(a)huawei.com<mailto:huangxinwei2@huawei.com> SIG_SystemApplication 黄辛未 huangxinwei2(a)huawei.com<mailto:huangxinwei2@huawei.com> 吴习文 wuxiwen3(a)huawei.com<mailto:wuxiwen3@huawei.com> 3 申请新建sig仓：applications_startup_guide 吴堃 kun.wu(a)huawei.com<mailto:kun.wu@huawei.com> 程枫 chengfeng32(a)huawei.com<mailto:chengfeng32@huawei.com> application-SIG 吴堃 kun.wu(a)huawei.com<mailto:kun.wu@huawei.com> 程枫 chengfeng32(a)huawei.com<mailto:chengfeng32@huawei.com> 蔡鹏程 caipengcheng3(a)huawei.com<mailto:caipengcheng3@huawei.com> 张晓伟 zhangxiaowei1(a)huawei.com<mailto:zhangxiaowei1@huawei.com> 刘荣凯 liurongkai(a)huawei.com<mailto:liurongkai@huawei.com> 沈腾 shenteng2(a)huawei.com<mailto:shenteng2@huawei.com> 4 申请新建sig仓: homegraph、bjc、haptest 孙波 bb.sunbo(a)huawei.com<mailto:bb.sunbo@huawei.com> programanalysis-SIG 5 sig仓孵化毕业申请：xts_acts_cangjie 张朋生 zhangpengsheng(a)huawei.com<mailto:zhangpengsheng@huawei.com> sig_test 张朋生 zhangpengsheng(a)huawei.com<mailto:zhangpengsheng@huawei.com> 刘天瑜 liutianyu8(a)huawei.com<mailto:liutianyu8@huawei.com> 方震 fangzhen12(a)huawei.com<mailto:fangzhen12@huawei.com> 高燕 gaoyan51(a)huawei.com<mailto:gaoyan51@huawei.com> 陈宜桓 chenyihuan3(a)h-partners.com<mailto:chenyihuan3@h-partners.com> 朱国倩 zhuguoqian1(a)huawei.com<mailto:zhuguoqian1@huawei.com> 谢彭非 xiepengfei13(a)huawei.com<mailto:xiepengfei13@huawei.com> 6 申请新建sig仓：open_pdf_service、third_party_pdfium 罗枭鸿 luoxiaohong5(a)huawei.com<mailto:luoxiaohong5@huawei.com> sig_basicsoftwareservice 罗枭鸿 luoxiaohong5(a)huawei.com<mailto:luoxiaohong5@huawei.com> 戎阳豪 rongyanghao(a)huawei.com<mailto:rongyanghao@huawei.com> 何宇轩 heyuxuan17(a)huawei.com<mailto:heyuxuan17@huawei.com> 会议公告 1、议题申报链接：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 2、评审完成后请在一天内反馈纪要至：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 3、收不到推送的情况，可以通过https://lists.openatom.io/postorius/lists/中dev邮件列表查看会议通知等退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug）
by 侯朋朋 11 Jun '26

11 Jun '26

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 协助确认能力是否仍有效。祝好侯朋朋

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's arkcompiler_ets_runtime project : zhenglei
by dongjinguang 09 Jun '26

09 Jun '26

1 0

【会议通知】OpenHarmony 架构SIG（第212次会议），时间：2026-6-9 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 09 Jun '26

09 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第212次会议）会议时间 Time 2026-6-9 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=451199588089&pwd=MTY5NTU3&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/451199588089/ed7c2bd3c0a1b16f… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：451199588089 嘉宾密码：169557 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓: officeservice_enterprise_deploy_restore 20 孙志勇 sunzhiyong3(a)huawei.com<mailto:sunzhiyong3@huawei.com> sig_basicsoftwareservice 孙志勇 sunzhiyong3(a)huawei.com<mailto:sunzhiyong3@huawei.com> 殷长冬 yinchangdong(a)huawei.com<mailto:yinchangdong@huawei.com> 吴智杰 wuzhijie16(a)huawei.com<mailto:wuzhijie16@huawei.com> 2 申请新建sig仓: homegraph 20 孙波 bb.sunbo(a)huawei.com<mailto:bb.sunbo@huawei.com> programanalysis-SIG 3 申请sig仓孵化毕业（仅目录迁移）： device_board_hisilicon_hispark_aifly device_soc_hisilicon_hispark_aifly vendor_hisilicon_hispark_aifly 30 邹美广 zoumeiguang(a)huawei.com<mailto:zoumeiguang@huawei.com> Devboard SIG 刘洋 liu_yang(a)hoperun.com<mailto:liu_yang@hoperun.com> 黄然 huangran5(a)huawei.com<mailto:huangran5@huawei.com> 盛肄 shengyi(a)huawei.com<mailto:shengyi@huawei.com> 邓文彬 dengwenbin(a)huawei.com<mailto:dengwenbin@huawei.com> 高晓龙 gao_xiaolong(a)hoperun.com<mailto:gao_xiaolong@hoperun.com> 会议公告 1、议题申报链接：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 2、评审完成后请在一天内反馈纪要至：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 3、收不到推送的情况，可以通过https://lists.openatom.io/postorius/lists/中dev邮件列表查看会议通知等退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议纪要】OpenHarmony 架构SIG（第211次会议）纪要20260602
by Yangna (y) 08 Jun '26

08 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第211次会议）会议时间 Time 2026-6-2 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林与会人 Attendees 任革林，董金光，各议题汇报人等历史纪要归档路径方式1：https://gitcode.com/openharmony/community/tree/master/sig/sig_architect… 方式2（优先）：dev邮件列表纪要查询方式：https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/，页面内可以按月份筛选会议议题 Agenda 议题1：scene_board毕业遗留问题闭环议题2：申请新建sig仓: officeservice_enterprise_batch_deploy_restore_service 议题3：申请新建sig孵化仓: graphics_painter 议题4：sig仓孵化毕业申请：xts_acts_cangjie 议题5：申请新建sig仓: qrcode 议题6、申请新建sig仓: agents 本次会议主要内容：议题1、scene_board毕业遗留问题闭环汇报人：胡毕杰会议结论： 1、闭环遗留问题后同意毕业。从设备开发者的角度梳理整个流程，可真正指导开发。遗留问题： 1、架构图中英对应，术语保持一致。 2、补充说明ScenBoard与window_manager的关系：进程间的关系、依赖关系以及其他区别。建议图文结合进行描述。 3、伙伴产品如何适配，要有详细的指导说明。 4、补充“新增产品”条目，举例说明如何开发默认产品之外的其他产品。议题2、申请新建sig仓: officeservice_enterprise_batch_deploy_restore_service 汇报人：孙志勇会议结论： 1、闭环遗留问题后重新上会。遗留问题： 1、仓库的名字太长，需要精简。 2、参考社区重新绘制企业批量部署还原的架构图，架构图补充相关调用方和依赖方部件或模块关系图。 3、当前部件提供的inner API和备份恢复框架提供的system API是否存在重复。 4、明确应用使用的权限。 5、业务为什么不归属到MDM。议题3、申请新建sig孵化仓: graphics_painter 汇报人：王良江会议结论： 1、闭环遗留问题后重新上会。遗留问题： 1、架构图补充调用方和依赖方，包括和现有graphic_2d之间的关系以及后面部件孵化毕业后的归属关系，说明和drawing/skia的关系。 2、孵化目标补充性能和内存的指标，相比skia哪些超越，哪些指标持平。 3、说明spirv编译器和cpu后端的关系。 4、若未来孵化毕业进入主线前，需要在架构信息平台维护该部件信息清单和责任归属。议题4、sig仓孵化毕业申请：xts_acts_cangjie 汇报人：张朋生会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、需要给出社区构建结果。 2、xts工程中用例文件名称需要统一规范。 3、readme里面工程目录结构-源码存放目录需要描述清晰。 4、readme中用例文件app.json,module.json后缀修改成json5。 5、readmd中用例编写指导章节需新增XTS编写指导。 6、readme中运行章节对应的术语需要修改与编译章节术语保持一致。议题5、申请新建sig仓: qrcode 汇报人：张绩会议结论： 1、闭环遗留问题后同意在OpenHarmony-SIG下新建arkui_qrcodegen，归属sig_appframework。遗留问题： 1、架构图明确新增部件在架构中的层级关系。 2、孵化目标补充规格说明：最大输入512字节，生成正方形的二维码色块信息。 -- 已补充 3、子系统归属arkui 议题6、申请新建sig仓: agents 汇报人：王兴会议结论： 1、闭环遗留问题后同意在OpenHarmony-SIG下新建agents仓，归属AI software engineering SIG。遗留问题： 1、补充二三级目录的详细设计, 建议按照sig/子系统粒度的对领域进行分拆。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

OpenHarmony 程序分析SIG例会2026第9次会议
by xulingyun 05 Jun '26

05 Jun '26

�� Subject OpenHarmony��SIG�� 2026��9�λ��飨Sig-ProgramAnalysis Meeting�� ʱ�� Time 6/9 (�ܶ�) 19:00-20:00 (UTC+08:00)Beijing ��Ƶ�� Video Meeting Host��https://imeeting.huawei.com/meeting/startwelink?id=96737983&pwd=NDczO… Internal��https://imeeting.huawei.com/meeting/joinwelink?id=96737983&pwd=OT… External��https://app.huawei.com/wmeeting/join/96737983/9Jct1FPIj24A5m3W5Vq… ��ID��96737983 ��룺964982 �� /�� Attendees ��SIG��Ա �� Agenda �� No. �� Topic ʱ�� Duration ��ֹʱ�� Time �� Reporter �� Members 1 ArkAnalyzer��չͬ�� 10 mins 19:00 �C 19:10 All ��SIG��ȫ��Ա 2 ��Ӧ�� 20 mins 19:10 �C 19:30 ��ԣ�� SIG��ȫ��Ա 3 �� C ��ϸ��Զ��ĺ��Ӧ�ø��Ż��о� 10 mins 19:30 �C 19:40 �� SIG��ȫ��Ա 4 �� C ��ں��ArkUI��ҳ��Զ��Ż��о� 10 mins 19:40 �C 19:50 �� SIG��ȫ��Ա 5 �� C ��ϵͳ��ֽ��Ƭ��ģ��˫��Ĵ�� 10 mins 19:50 �C 20:00 ��Զ ��SIG��ȫ��Ա ��鹫�� Bulletins 1��ٵ��ˡ� 2��ƻ��ʱ�䣬��ʱ��Ҫ��ǿ�һ��Ч�Ļᣡ

1 0

【会议通知】OpenHarmony 架构SIG（第211次会议），时间：2026-6-2 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 02 Jun '26

02 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第211次会议）会议时间 Time 2026-6-2 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=446163471353&pwd=ODgyNTAy&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/446163471353/490389c8b5a5d5ba… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：446163471353 嘉宾密码：882502 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 scene_board毕业遗留问题闭环 20 胡毕杰 hubijie(a)huawei.com<mailto:hubijie@huawei.com> sig_graphics 周耀颖 zhouyaoying(a)huawei.com<mailto:zhouyaoying@huawei.com> 朱孝文 zhuxiaowen4(a)huawei.com<mailto:zhuxiaowen4@huawei.com> 路保虎 lubaohu(a)huawei.com<mailto:lubaohu@huawei.com> 聂志远 niezhiyuan(a)huawei.com<mailto:niezhiyuan@huawei.com> 杨奕波 yangyibo6(a)huawei.com<mailto:yangyibo6@huawei.com> 沈腾 shenteng2(a)huawei.com<mailto:shenteng2@huawei.com> 胡毕杰 hubijie(a)huawei.com<mailto:hubijie@huawei.com> 2 申请新建sig仓: officeservice_enterprise_batch_deploy_restore_service 20 孙志勇 sunzhiyong3(a)huawei.com<mailto:sunzhiyong3@huawei.com> sig_basicsoftwareservice 孙志勇 sunzhiyong3(a)huawei.com<mailto:sunzhiyong3@huawei.com> 殷长冬 yinchangdong(a)huawei.com<mailto:yinchangdong@huawei.com> 吴智杰 wuzhijie16(a)huawei.com<mailto:wuzhijie16@huawei.com> 3 申请新建sig孵化仓: graphics_painter 20 王良江 wangliangjiang1(a)huawei.com<mailto:wangliangjiang1@huawei.com> sig_graphics 石鑫栋 shixindong(a)huawei.com<mailto:shixindong@huawei.com> 孙国飞 sunguofei2(a)huawei.com<mailto:sunguofei2@huawei.com> 朱俏威 qiaowei.zhu(a)unionman.com.cn<mailto:qiaowei.zhu@unionman.com.cn> 孙珍奇 sunzhenqi(a)huawei.com<mailto:sunzhenqi@huawei.com> 张亮恺 zhangliangkai1(a)huawei.com<mailto:zhangliangkai1@huawei.com> 叶良 yeliang8(a)huawei.com<mailto:yeliang8@huawei.com> 颜锦 rose.yan(a)huawei.com<mailto:rose.yan@huawei.com> 杨春林 yangchunlin4(a)huawei.com<mailto:yangchunlin4@huawei.com> 王意远 wangyiyuan4(a)huawei.com<mailto:wangyiyuan4@huawei.com> 吴涛 wutao67(a)hisilicon.com<mailto:wutao67@hisilicon.com> 4 sig仓孵化毕业申请：xts_acts_cangjie 20 张朋生 zhangpengsheng(a)huawei.com<mailto:zhangpengsheng@huawei.com> sig_test 张朋生 zhangpengsheng(a)huawei.com<mailto:zhangpengsheng@huawei.com> 刘天瑜 liutianyu8(a)huawei.com<mailto:liutianyu8@huawei.com> 方震 fangzhen12(a)huawei.com<mailto:fangzhen12@huawei.com> 高燕 gaoyan51(a)huawei.com<mailto:gaoyan51@huawei.com> 陈宜桓 chenyihuan3(a)h-partners.com<mailto:chenyihuan3@h-partners.com> 朱国倩 zhuguoqian1(a)huawei.com<mailto:zhuguoqian1@huawei.com> 谢彭非 xiepengfei13(a)huawei.com<mailto:xiepengfei13@huawei.com> 5 申请新建sig仓: qrcode 20 张绩 zhangji56(a)huawei.com<mailto:zhangji56@huawei.com> sig_graphics 张浩萍 00799198 zhanghaoping(a)huawei.com<mailto:zhanghaoping@huawei.com> 裴太乙 00452466 peitaiyi(a)huawei.com<mailto:peitaiyi@huawei.com> 兰望桂 00450246 lanwanggui(a)huawei.com<mailto:lanwanggui@huawei.com> 6 申请新建sig仓: agents 20 王兴 raymond.wangxing(a)huawei.com<mailto:raymond.wangxing@huawei.com> AI software engineering SIG 鲁波 bo.lu(a)huawei.com<mailto:bo.lu@huawei.com> 王意明 youthdragon.wangyiming(a)huawei.com<mailto:youthdragon.wangyiming@huawei.com> 会议公告 1、议题申报链接：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 2、评审完成后请在一天内反馈纪要至：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 3、收不到推送的情况，可以通过https://lists.openatom.io/postorius/lists/中dev邮件列表查看会议通知等退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议纪要】OpenHarmony 架构SIG（第210次会议）纪要20260526
by Yangna (y) 02 Jun '26

02 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第210次会议）会议时间 Time 2026-5-26 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林与会人 Attendees 任革林，董金光，各议题汇报人等历史纪要归档路径方式1：https://gitcode.com/openharmony/community/tree/master/sig/sig_architect… 方式2（优先）：dev邮件列表纪要查询方式：https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/，页面内可以按月份筛选会议议题 Agenda 议题1：申请新建sig仓：filemanagement_archive 议题2：申请sig仓毕业：arkui_idlize，闭环遗留问题议题3：chromium依赖三方仓孵化毕业议题4：申请sig仓孵化毕业：developtools_dfx_skills 议题5：申请sig仓孵化毕业（仅目录迁移）：device_board_hisilicon_hispark_aifly，device_soc_hisilicon_hispark_aifly，vendor_hisilicon_hispark_aifly 本次会议主要内容：议题1、申请新建sig仓：filemanagement_archive 汇报人：江婧会议结论： 1、遗留问题闭环后同意在OpenHarmony-SIG下建仓filemanagement_archive。遗留问题： 1、补充该代码仓的架构图. 2、仓名字filemanagement_archive是否业界通用。 3、说明支持的详细规格. 4、当前Basic service kit 已包含对 zlib的封装，需要考虑压缩解压缩对外统一呈现。议题2、申请sig仓毕业：arkui_idlize，闭环遗留问题汇报人：郭泽均会议结论： 1、遗留问题闭环后同意arkui_idlize仓孵化毕业。遗留问题： 1、以ReadMe作为总入口，区分开发者和使用者，从使用者角度介绍。议题3、chromium依赖三方仓孵化毕业汇报人：华梦峥会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、chromium依赖三方仓的范围是否合理，对比业界OS平台Webview Chromium依赖的三方仓的引入情况。议题4、申请sig仓孵化毕业：developtools_dfx_skills 汇报人：刘沛会议结论： 1、暂不同意毕业，继续完善、增强孵化仓的能力。遗留问题： 1、Readme需要完善：1）各个skills的功能职责、能解决的问题（故障模式）、能力边界等；2）使用方法要更加详细，小白也能用；3）开源贡献的约束说明。 2、完成门禁配置，codex、合规扫描等 3、二进制工具不要直接放在开源仓，考虑开源或单独渠道下载部署。 4、毕业时收集用户使用报告，进行功能成熟度评估。 5、支持的故障问题定位能力（对于故障模式库的覆盖），包括基础能力和领域能力，要达到一定的覆盖度再考虑毕业。议题5、申请sig仓孵化毕业（仅目录迁移）：device_board_hisilicon_hispark_aifly，device_soc_hisilicon_hispark_aifly，vendor_hisilicon_hispark_aifly 汇报人：邹美广会议结论： 1、遗留问题闭环后，再上会评审。遗留问题： 1、L1新开发板代码合入要匹配社区6.1 LTS版本计划。 2、提拉社区CI门禁陪跑L1新开发板计划，确保代码合入质量要求。 3、readme作为资料文档的总入口，以开发者视角审视文档命名、内容组织，特性涉及多种方案的要给出建议，配套架构图能够指导开发。 4、确认fip.bin能否预置到单板固件中，不引入到代码仓；或者选型引入trusted-firmware源码开放。 5、SoC软件参考界内做法尽量开源，闭源库分类合并、按需加载，提拉计划至630完成整改。 6、L1新开发板暂不要求支持LiteOS_A。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's arkui_ace_engine project : guozejun
by dongjinguang 29 May '26

29 May '26

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's selectionfwk project : zhenglei
by dongjinguang 29 May '26

29 May '26

1 0

Fw:Welcome to the "dev" mailing list
by miaojj0704 27 May '26

27 May '26

苗姣姣 miaojj0704(a)thundersoft.com Forwarded message: From：dev-request<dev-request(a)openharmony.io>Date：2026-05-27 11:32:35(中国 (GMT+08:00))To：miaojj0704<miaojj0704(a)thundersoft.com>Cc：Subject：Welcome to the "dev" mailing listWelcome to the "dev" mailing list! To post to this list, send your message to: dev(a)openharmony.io You can unsubscribe or make adjustments to your options via email by sending a message to: dev-request(a)openharmony.io with the word 'help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You will need your password to change your options, but for security purposes, this password is not included here. If you have forgotten your password you will need to reset it via the web UI.

1 0

【会议通知】OpenHarmony 架构SIG（第210次会议），时间：2026-5-26 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 26 May '26

26 May '26

会议主题 Subject OpenHarmony 架构SIG（第210次会议）会议时间 Time 2026-5-26 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=441504038632&pwd=NjEzMzM5&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/441504038632/0ee25a33f605871a… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：441504038632 嘉宾密码：613339 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓：filemanagement_archive 20 江婧 jiangjing23(a)hisilicon.com<mailto:jiangjing23@hisilicon.com> sig_appframework 段晓蒙 duanxiaomeng(a)huawei.com<mailto:duanxiaomeng@huawei.com> 阮伦 ruanlun1(a)huawei.com<mailto:ruanlun1@huawei.com> 马家俊 majiajun(a)huawei.com<mailto:majiajun@huawei.com> 2 申请sig仓毕业：arkui_idlize，闭环遗留问题 20 郭泽均 guozejun(a)huawei.com<mailto:guozejun@huawei.com> sig_web 郭泽均 guozejun(a)huawei.com<mailto:guozejun@huawei.com> 孙斐 sunfei.sun(a)huawei.com<mailto:sunfei.sun@huawei.com> 3 chromium依赖三方仓孵化毕业 20 华梦峥 huamengzheng(a)huawei.com<mailto:huamengzheng@huawei.com> sig_basicsoftwareservice 陈云九 chenyunjiu1(a)huawei.com<mailto:chenyunjiu1@huawei.com> 任康 renkang2(a)huawei.com<mailto:renkang2@huawei.com> 张小田 zhangxiaotian(a)huawei.com<mailto:zhangxiaotian@huawei.com> 4 申请sig仓孵化毕业： developtools_dfx_skills 20 刘沛 liupei.liu(a)huawei.com<mailto:liupei.liu@huawei.com> Devboard SIG 刘沛 liupei.liu(a)huawei.com<mailto:liupei.liu@huawei.com> 王棪腾 wangyanteng(a)huawei.com<mailto:wangyanteng@huawei.com> 沈潼 tong.shen(a)huawei.com<mailto:tong.shen@huawei.com> 李煜 liyu1(a)huawei.com<mailto:liyu1@huawei.com> 马耀辉 stesen.ma(a)huawei.com<mailto:stesen.ma@huawei.com> 5 申请sig仓孵化毕业（仅目录迁移）： device_board_hisilicon_hispark_aifly device_soc_hisilicon_hispark_aifly vendor_hisilicon_hispark_aifly 20 邹美广 zoumeiguang(a)huawei.com<mailto:zoumeiguang@huawei.com> sig_kernel 刘洋 liu_yang(a)hoperun.com<mailto:liu_yang@hoperun.com> 黄然 huangran5(a)huawei.com<mailto:huangran5@huawei.com> 盛肄 shengyi(a)huawei.com<mailto:shengyi@huawei.com> 邓文彬 dengwenbin(a)huawei.com<mailto:dengwenbin@huawei.com> 高晓龙 gao_xiaolong(a)hoperun.com<mailto:gao_xiaolong@hoperun.com> 会议公告 1、议题申报链接：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 2、评审完成后请在一天内反馈纪要至：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 3、收不到推送的情况，可以通过https://lists.openatom.io/postorius/lists/中dev邮件列表查看会议通知等退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议纪要】OpenHarmony 架构SIG（第209次会议）纪要20260519
by Yangna (y) 25 May '26

25 May '26

会议主题 Subject OpenHarmony 架构SIG（第209次会议）会议时间 Time 2026-5-19 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林与会人 Attendees 任革林，董金光，各议题汇报人等历史纪要归档路径方式1：https://gitcode.com/openharmony/community/tree/master/sig/sig_architect… 方式2（优先）：dev邮件列表纪要查询方式：https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/，页面内可以按月份筛选会议议题 Agenda 议题1：申请sig仓毕业：window_scene_board 议题2：申请新建sig仓: applications_number_identity 议题3：codegenie_cli、codegenie_tools、codegenie_skills代码仓名称变更议题4：申请sig仓毕业：arkui_idlize，闭环遗留问题议题5：softbus-SIG：iot_connect仓遗留问题闭环毕业申请本次会议主要内容：议题1、申请sig仓毕业：window_scene_board 汇报人：朱孝文/胡毕节会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、补充MainAbility的作用说明，以及不同产品间有什么具体的差异。 2、简介中桌面系统应用描述不准确，建议修改为合一桌面。 3、补充有哪些hsp，每个hsp的作用。 4、实现方式的举例中，所有文字说明，补充完整对应代码示例。议题2、申请新建sig仓: applications_number_identity 汇报人：赵维会议结论： 1、同意在OpenHarmony-SIG下新建applications_number_identity，归属sig_systemapplications。遗留问题： 1、补充号码识别内部架构与周边依赖，说明开源部分与未开源部分。 2、从端到端可用视角，给出完整的依赖模块的解决方案。议题3、codegenie_cli、codegenie_tools、codegenie_skills代码仓名称变更汇报人：陈晓闯会议结论： 1、同意代码仓库名称修改： 1）codegenie_cli 代码仓名称变为deveco-code。 2）codegenie_tools 代码仓名称变为deveco-cli。 3）codegenie_skills 代码仓名称变为deveco-skills。遗留问题：无。议题4、申请sig仓毕业：arkui_idlize，闭环遗留问题汇报人：郭泽均会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、工具用户文档和工具开发者文档之间不要相互引用，做好隔离。 2、文档中不要出现难以理解的概念，要让没有相关背景知识的开发者能看懂。议题5、softbus-SIG：iot_connect仓遗留问题闭环毕业申请汇报人：陈理恩会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、组网图按照模块或者设备的维度视角进行调整。 2、调整架构图，样式跟社区保持统一，接口层改为框架层，适配层只体现组件本身的模块能力。 3、补充关键交互流程，数据上下行流程。 4、先按L0的组件定位合主干，L1和软总线的分工需讨论明确。 5、详细说明如何按功能裁剪，包括哪些宏和裁剪后的rom和ram数据。 6、确定iot connect sdk名称，建议去掉sdk，避免和OpenHarmony SDK概念混淆。 7、接口模块描述完善，不要出现上下不一致的表述。 8、补充南向接口以及指导。 9、完善系统应用开发指导，用开发者能够清楚如何开发、集成。 10、bundle.json补充rom和ram信息。 11、iot_connect涉及的系统应用北向System API，以及南向接口标准化，需要分别获得对应SIG或技术评审组织的评审，并对System API 和南向接口进行ACTS、DCTS的例行看护，纳入接口看护平台管理范畴。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议纪要】OpenHarmony 架构SIG（第208次会议）纪要20260512
by Yangna (y) 20 May '26

20 May '26

会议主题 Subject OpenHarmony 架构SIG（第208次会议）会议时间 Time 2026-5-12 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林与会人 Attendees 任革林，董金光，各议题汇报人等历史纪要归档路径方式1：https://gitcode.com/openharmony/community/tree/master/sig/sig_architect… 方式2（优先）：dev邮件列表纪要查询方式：https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/，页面内可以按月份筛选会议议题 Agenda 议题1：申请新建sig仓：vendor_devexel、device_board_devexel 议题2：OpenHarmony 开源软件mksh申请独立选型议题3：申请sig仓毕业：third_party_opus、third_party_opencore-amr 议题4：sig仓申请架构评审：xts_acts_cangjie 议题5：申请sig仓毕业：arkui_idlize 议题6：skia依赖库独立建仓，申请新建sig仓：third_party_wuffs 申请sig仓库third_party_dng_sdk、third_party_piex、third_party_libwebp信息变更：sig名称由sig_graphics变更为sig_media 议题7：softbus-SIG：iot_connect仓遗留问题闭环毕业申请议题8：申请sig仓毕业：window_scene_board，window_scene_session_manager 本次会议主要内容：议题1、申请新建sig仓：vendor_devexel、device_board_devexel 汇报人：佘成东会议结论： 1、闭环遗留问题1后同意在OpenHarmony-SIG下新建vendor_devexel、device_board_devexel仓。遗留问题： 1、仓库内的commiter中要包含芯片原厂和板卡厂商 2、删掉dayu相关的内容。议题2、OpenHarmony 开源软件mksh申请独立选型汇报人：严明圳会议结论： 1、同意mksh在CleanSource 9.0独立选型，继续使用R59c版本，同时及时跟踪社区新增的修改提交，同步回合关键修改。遗留问题：无。议题3、申请sig仓毕业：third_party_opus、third_party_opencore-amr 汇报人：高梓喻会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、在两个仓中分别补齐如何编译，avcodec对三方部件的调用链，调用时机，在源码目录层面能清晰区分出三方仓上游内容和新增修改内容。 2、bundle.json信息整改。 3、补齐xts，UT用例。议题4、sig仓申请架构评审：xts_acts_cangjie 汇报人：张朋生会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、readme中仓颉不涉及的部分需删除。 2、acts_cangjie目录结构每个文件需给出文件作用描述。 3、补充unittest测试框架说明。 4、构建模块方法介绍(按子系统、模块、包)需描述清楚，并给出示例。 5、测试执行方法介绍(按子系统、模块、包)需描述清楚，并给出示例。 6、给出社区构建结果。 7、抽查工程中无正常场景用例。议题5、申请sig仓毕业：arkui_idlize 汇报人：郭泽均会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、所有文档补充中文版本，README作为所有路由的总入口。 2、补充架构图和 idl接口规范（放到doc目录下），。 3、对于工具的使用者(ArkUI的开发者）：如何定义idl接口，开发流程，包括初次开发，新增接口，参数变更等场景。 4、对于工具的开发者：补充工具的基本概念，核心模块简介，结合架构图进行介绍其运行原理。 5、README中补充runner，arkgen，etsgen等工具的所有参数的解释，并举例说明如何使用。议题6、skia依赖库独立建仓，申请新建sig仓：third_party_wuffs；申请sig仓库third_party_dng_sdk、third_party_piex、third_party_libwebp信息变更：sig名称由sig_graphics变更为sig_media 汇报人：黎富民会议结论： 1、暂不同意，建议重新上会。遗留问题：无。议题7、softbus-SIG：iot_connect仓遗留问题闭环毕业申请汇报人：陈理恩会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、资料补充iot_connect组件技术架构图、组网图标记出iot_connect组件位置。 2、补充设备发现配网、端云连接、设备控制等资料。议题8、申请sig仓毕业：window_scene_board，window_scene_session_manager 汇报人：朱孝文会议结论： 1、遗留问题闭环后，再上会评审。遗留问题： 1、资料中架构图请统一规范，按照分层描述架构内容。 2、文档中的上下文的用语统一，描述精确，详细解释独有术语。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议通知】OpenHarmony 架构SIG（第209次会议），时间：2026-5-19 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 19 May '26

19 May '26

会议主题 Subject OpenHarmony 架构SIG（第209次会议）会议时间 Time 2026-5-19 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=436654497457&pwd=NzMzNDQ1&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/436654497457/471ba92cf7c8d224… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：436654497457 嘉宾密码：733445 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请sig仓毕业：window_scene_board 20 朱孝文 zhuxiaowen4(a)huawei.com<mailto:zhuxiaowen4@huawei.com> sig_graphics 朱孝文 zhuxiaowen4(a)huawei.com<mailto:zhuxiaowen4@huawei.com> 周耀颖 zhouyaoying(a)huawei.com<mailto:zhouyaoying@huawei.com> 沈腾 shenteng2(a)huawei.com<mailto:shenteng2@huawei.com> 王斌 wangbin23(a)huawei.com<mailto:wangbin23@huawei.com> 胡毕杰 hubijie(a)huawei.com<mailto:hubijie@huawei.com> 付坤 fukun11(a)huawei.com<mailto:fukun11@huawei.com> 2 申请新建sig仓: applications_number_identity (number_identity) 20 赵维 zhaowei8(a)huawei.com<mailto:zhaowei8@huawei.com> sig_systemapplications 赵维 zhaowei8(a)huawei.com<mailto:zhaowei8@huawei.com> 沈腾 shenteng2(a)huawei.com<mailto:shenteng2@huawei.com> 3 codegenie-cli、codegenie-tools、codegenie-skills代码仓名称变更 20 陈晓闯 chenxiaochuang(a)huawei.com<mailto:chenxiaochuang@huawei.com> sig_ide 胡扶同 hufutong(a)huawei.com<mailto:hufutong@huawei.com> 欧闻 ouwen7(a)huawei.com<mailto:ouwen7@huawei.com> 4 申请sig仓毕业：arkui_idlize，闭环遗留问题 20 郭泽均 guozejun(a)huawei.com<mailto:guozejun@huawei.com> sig_appframework 郭泽均 guozejun(a)huawei.com<mailto:guozejun@huawei.com> 孙斐 sunfei.sun(a)huawei.com<mailto:sunfei.sun@huawei.com> 5 softbus-SIG：iot_connect仓遗留问题闭环毕业申请 20 陈理恩 chenlien(a)huawei.com<mailto:chenlien@huawei.com> sig_softbus 吕鑫 david.lv(a)huawei.com<mailto:david.lv@huawei.com> 朱淼 zhumiao3(a)huawei.com<mailto:zhumiao3@huawei.com> 金钟 jinzhong1(a)huawei.com<mailto:jinzhong1@huawei.com> 牛少卿 niushaoqing(a)huawei.com<mailto:niushaoqing@huawei.com> 会议公告 1、议题申报链接：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 2、评审完成后请在一天内反馈纪要至：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 3、收不到推送的情况，可以通过https://lists.openatom.io/postorius/lists/中dev邮件列表查看会议通知等退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

OpenHarmony 程序分析SIG例会2026第8次会议
by xulingyun 15 May '26

15 May '26

�� Subject OpenHarmony��SIG�� 2026��8�λ��飨Sig-ProgramAnalysis Meeting�� ʱ�� Time 5/19 (�ܶ�) 19:00-20:00 (UTC+08:00)Beijing ��Ƶ�� Video Meeting Host��https://imeeting.huawei.com/meeting/startwelink?id=96330165&pwd=NDAwN… Guest��https://imeeting.huawei.com/meeting/joinwelink?id=96330165&pwd=MTQwO… External��https://app.huawei.com/wmeeting/join/96330165/2oW0SeRAKXrSOYTeJLu… ��ID��96330165 ��룺140867 �� /�� Attendees ��SIG��Ա �� Agenda �� No. �� Topic ʱ�� Duration ��ֹʱ�� Time �� Reporter �� Members 1 ArkAnalyzer��չͬ�� 10 mins 19:00 �C 19:10 All ��SIG��ȫ��Ա 2 ��Ӧ�� 20 mins 19:10 �C 19:30 ��ԣ�� SIG��ȫ��Ա 3 �� C ��ϸ��Զ��ĺ��Ӧ�ø��Ż��о� 10 mins 19:30 �C 19:40 �� SIG��ȫ��Ա 4 �� C ��ں��ArkUI��ҳ��Զ��Ż��о� 10 mins 19:40 �C 19:50 �� SIG��ȫ��Ա 5 �� C ��ϵͳ��ֽ��Ƭ��ģ��˫��Ĵ�� 10 mins 19:50 �C 20:00 ��Զ ��SIG��ȫ��Ա ��鹫�� Bulletins 1��ٵ��ˡ� 2��ƻ��ʱ�䣬��ʱ��Ҫ��ǿ�һ��Ч�Ļᣡ

1 0

【会议通知】OpenHarmony 架构SIG（第208次会议），时间：2026-5-12 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 12 May '26

12 May '26

会议主题 Subject OpenHarmony 架构SIG（第208次会议）会议时间 Time 2026-5-12 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=431829385944&pwd=Nzg5Njk3&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/431829385944/f7300dabd4182d95… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：431829385944 嘉宾密码：789697 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓：vendor_devexel、device_board_devexel 15 佘成东 she_chengdong(a)hoperun.com<mailto:she_chengdong@hoperun.com> Devboard SIG 刘洋 liu_yang(a)hoperun.com<mailto:liu_yang@hoperun.com> 聂威 leon.niewei(a)huawei.com<mailto:leon.niewei@huawei.com> 李思同 li_sitong1(a)hoperun.com<mailto:li_sitong1@hoperun.com> 佘成东 she_chengdong(a)hoperun.com<mailto:she_chengdong@hoperun.com> 田旭东 tianxudong2(a)huawei.com<mailto:tianxudong2@huawei.com> 2 OpenHarmony 开源软件mksh申请独立选型 15 严明圳 yanmingzhen1(a)huawei.com<mailto:yanmingzhen1@huawei.com> sig_kernel 严明圳 yanmingzhen1(a)huawei.com<mailto:yanmingzhen1@huawei.com> 陈兵兵 chenbingbing12(a)huawei.com<mailto:chenbingbing12@huawei.com> 3 申请sig仓毕业： third_party_opus third_party_opencore-amr 15 高梓喻 gaoziyu(a)h-partners.com<mailto:gaoziyu@h-partners.com> media-sig 苏若炎 suruoyan1(a)huawei.com<mailto:suruoyan1@huawei.com> 高梓喻 gaoziyu(a)h-partners.com<mailto:gaoziyu@h-partners.com> 4 sig仓申请架构评审： xts_acts_cangjie 15 张朋生 zhangpengsheng(a)huawei.com<mailto:zhangpengsheng@huawei.com> sig_test 张朋生 zhangpengsheng(a)huawei.com<mailto:zhangpengsheng@huawei.com> 刘天瑜 liutianyu8(a)huawei.com<mailto:liutianyu8@huawei.com> 方震 fangzhen12(a)huawei.com<mailto:fangzhen12@huawei.com> 高燕 gaoyan51(a)huawei.com<mailto:gaoyan51@huawei.com> 陈宜桓 chenyihuan3(a)h-partners.com<mailto:chenyihuan3@h-partners.com> 朱国倩 zhuguoqian1(a)huawei.com<mailto:zhuguoqian1@huawei.com> 谢彭非 xiepengfei13(a)huawei.com<mailto:xiepengfei13@huawei.com> 5 申请sig仓毕业：arkui_idlize 15 郭泽均 guozejun(a)huawei.com<mailto:guozejun@huawei.com> sig_appframework 郭泽均 guozejun(a)huawei.com<mailto:guozejun@huawei.com> 孙斐 sunfei.sun(a)huawei.com<mailto:sunfei.sun@huawei.com> 6 skia依赖库独立建仓：申请新建sig仓：third_party_wuffs 15 黎富民 lifumin3(a)h-partners.com<mailto:lifumin3@h-partners.com> sig_media 赵娜 zhaona45(a)huawei.com<mailto:zhaona45@huawei.com> 高爽 gaoshuang23(a)h-partners.com<mailto:gaoshuang23@h-partners.com> 徐理东 xulidong4(a)huawei.com<mailto:xulidong4@huawei.com> 鲍思源 baosiyuan(a)huawei.com<mailto:baosiyuan@huawei.com> 姚星宇 yaoxingyu3(a)huawei.com<mailto:yaoxingyu3@huawei.com> 黎富民 lifumin3(a)h-partners.com<mailto:lifumin3@h-partners.com> 7 softbus-SIG：iot_connect仓遗留问题闭环毕业申请 15 陈理恩 chenlien(a)huawei.com<mailto:chenlien@huawei.com> sig_softbus 吕鑫 david.lv(a)huawei.com<mailto:david.lv@huawei.com> 朱淼 zhumiao3(a)huawei.com<mailto:zhumiao3@huawei.com> 金钟 jinzhong1(a)huawei.com<mailto:jinzhong1@huawei.com> 牛少卿 niushaoqing(a)huawei.com<mailto:niushaoqing@huawei.com> 8 申请sig仓毕业：window_scene_board，window_scene_session_manager 15 朱孝文 zhuxiaowen4(a)huawei.com<mailto:zhuxiaowen4@huawei.com> sig_graphics 朱孝文 zhuxiaowen4(a)huawei.com<mailto:zhuxiaowen4@huawei.com> 周耀颖 zhouyaoying(a)huawei.com<mailto:zhouyaoying@huawei.com> 沈腾 shenteng2(a)huawei.com<mailto:shenteng2@huawei.com> 王斌 wangbin23(a)huawei.com<mailto:wangbin23@huawei.com> 胡毕杰 hubijie(a)huawei.com<mailto:hubijie@huawei.com> 付坤 fukun11(a)huawei.com<mailto:fukun11@huawei.com> 会议公告 1、议题申报链接：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 2、评审完成后请在一天内反馈纪要至：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 3、收不到推送的情况，可以通过https://lists.openatom.io/postorius/lists/中dev邮件列表查看会议通知等退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

Information confirm // [New Commiter] Welcoming to become committer of OpenHarmony's arkanalyzer project : sunbo
by xulingyun 06 May '26

06 May '26

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's graphic_2d project : liuchuan
by dongjinguang 06 May '26

06 May '26

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's arkanalyzer project : sunbo
by dongjinguang 06 May '26

06 May '26

1 0

【会议纪要】OpenHarmony 架构SIG（第207次会议）纪要20260428
by Yangna (y) 30 Apr '26

30 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第207次会议）会议时间 Time 2026-4-28 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林与会人 Attendees 任革林，董金光，各议题汇报人等历史纪要归档路径方式1：https://gitcode.com/openharmony/community/tree/master/sig/sig_architect… 方式2（优先）：dev邮件列表纪要查询方式：https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/，页面内可以按月份筛选会议议题 Agenda 议题1：lame开源软件独立选型2026复核议题2：OpenHarmony 开源软件jsoncpp申请独立选型，OpenHarmony 开源软件libxml2申请独立选型议题3：申请sig仓孵化毕业（仅目录迁移）：device_board_hisilicon_hispark_aifly，device_soc_hisilicon_hispark_aifly，vendor_hisilicon_hispark_aifly 本次会议主要内容：议题1、lame开源软件独立选型2026复核汇报人：苏若炎会议结论： 1、同意lame开源软件继续在OH独立选型。遗留问题：无。议题2、OpenHarmony 开源软件jsoncpp申请独立选型，OpenHarmony 开源软件libxml2申请独立选型汇报人：张宁会议结论： 1、jsoncpp同意保留当前版本1.9.6。 2、libxml2当前可以维持 2.14.0 ，建议OH7.1上选型2.15.3，提前做好(网络拉取改造排查、解压逻辑重构)的分析验证。遗留问题：无。议题3、申请sig仓孵化毕业（仅目录迁移）：device_board_hisilicon_hispark_aifly，device_soc_hisilicon_hispark_aifly，vendor_hisilicon_hispark_aifly 汇报人：邹美广会议结论： 1、遗留问题闭环后，再上会评审决策。遗留问题： 1、ALSA音频集成方案和音频责任人对齐。 2、分析音视频媒体DRM组件功能，考虑L1上孵化带屏音箱、教育学习机等场景应用。 3、AI特性孵化和AI子系统负责人对齐，共建L1上使用Agent辅助做端侧推理。 4、闭源库按照模块详细打开看看闭源的理由、识别开源的价值。 5、搭建流水线，与主线相关仓完成联合构建，可参考P7885：基于主线最新代码的Patch，先打patch、再编译；要求门禁陪跑：主线前陪跑（dev+master）和合入主线后陪跑 6、提供本地TDD测试用例测试报告。 7、3403孵化毕业后，原有已退休的3516等芯片源码清理，减少非必要的合规内容确认。 8、开源三方不匹配的软件提供整改计划；trusted-firmware参考界内主流做法、线下对齐策略。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议通知】OpenHarmony 架构SIG（第207次会议），时间：2026-4-28 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 28 Apr '26

28 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第208次会议）会议时间 Time 2026-4-28 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=422100096465&pwd=MDg5NTgy&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/422100096465/fe692065678428e0… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：422100096465 嘉宾密码：089582 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 lame开源软件独立选型2026复核 15 苏若炎 suruoyan1(a)huawei.com<mailto:suruoyan1@huawei.com> media-sig 苏若炎 suruoyan1(a)huawei.com<mailto:suruoyan1@huawei.com> 蔡雷 cailei24(a)h-partners.com<mailto:cailei24@h-partners.com> 2 OpenHarmony 开源软件jsoncpp申请独立选型 OpenHarmony 开源软件libxml2申请独立选型 15 张宁 zhangning134(a)huawei.com<mailto:zhangning134@huawei.com> 王勇 wangyong56(a)huawei.com<mailto:wangyong56@huawei.com> 邹连峰 zoulianfeng1(a)huawei.com<mailto:zoulianfeng1@huawei.com> 3 申请sig仓孵化毕业（仅目录迁移）： device_board_hisilicon_hispark_aifly device_soc_hisilicon_hispark_aifly vendor_hisilicon_hispark_aifly 25 邹美广 zoumeiguang(a)huawei.com<mailto:zoumeiguang@huawei.com> Devboard SIG 刘洋 liu_yang(a)hoperun.com<mailto:liu_yang@hoperun.com> 黄然 huangran5(a)huawei.com<mailto:huangran5@huawei.com> 盛肄 shengyi(a)huawei.com<mailto:shengyi@huawei.com> 邓文彬 dengwenbin(a)huawei.com<mailto:dengwenbin@huawei.com> 高晓龙 gao_xiaolong(a)hoperun.com<mailto:gao_xiaolong@hoperun.com> 会议公告 1、议题申报链接：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 2、评审完成后请在一天内反馈纪要至：https://shimo.im/sheets/XKq42Y1JMXSrJrAN/MODOC 3、收不到推送的情况，可以通过https://lists.openatom.io/postorius/lists/中dev邮件列表查看会议通知等退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

[New Committer] Welcoming to become committer of OpenHarmony's arkui_ace_engine project : chennaifeng
by dongjinguang 27 Apr '26

27 Apr '26

1 0