- dev - lists.openatom.io

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

11 Aug '26

会议主题 Subject OpenHarmony 架构SIG（第221次会议）会议时间 Time 2026-8-11 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=494536813632&pwd=OTM3MDk3&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/494536813632/2316d5ee657a345a… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：494536813632 嘉宾密码：937097 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig孵化仓：third_party_typescript-go 20 李彦澄 liyancheng2(a)huawei.com<mailto:liyancheng2@huawei.com> 编译运行时 SIG 鲜余强 xianyuqiang(a)huawei.com<mailto:xianyuqiang@huawei.com>; 吴鸿飞 wuhongfei5(a)huawei.com<mailto:wuhongfei5@huawei.com>; 唐春 tangchun(a)huawei.com<mailto:tangchun@huawei.com>; 刘源 liuyuan242(a)huawei.com<mailto:liuyuan242@huawei.com>; 彭卓立 pengzhuoli(a)huawei.com<mailto:pengzhuoli@huawei.com>; 刘家良 liujialiang10(a)huawei.com<mailto:liujialiang10@huawei.com>; 杜宇晗 duyuhan2(a)huawei.com<mailto:duyuhan2@huawei.com>; 叶楠 yenan10(a)huawei.com<mailto:yenan10@huawei.com>; 刘璟烁 liujingshuo2(a)huawei.com<mailto:liujingshuo2@huawei.com>; 张文鹏 zhangwenpeng4(a)huawei.com<mailto:zhangwenpeng4@huawei.com>; 2 sig仓申请孵化毕业： applications_intelligentscene 20 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> application-SIG 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> 陈向楷 chenxiangkai1(a)huawei.com<mailto:chenxiangkai1@huawei.com> 韩浩然 hanhaoran1(a)h-partners.com<mailto:hanhaoran1@h-partners.com> 3 sig仓申请孵化毕业： applications_players 20 曹震雄 caozhenxiong2(a)huawei.com<mailto:caozhenxiong2@huawei.com> application-SIG 曹震雄 caozhenxiong2(a)huawei.com<mailto:caozhenxiong2@huawei.com> 谷健 gujian14(a)huawei.com<mailto:gujian14@huawei.com> 陈嘉俊 chenjiajun47(a)huawei.com<mailto:chenjiajun47@huawei.com> 4 sig仓申请孵化毕业： applications_browser 20 范竞霄 fanjingxiao(a)huawei.com<mailto:fanjingxiao@huawei.com> application-SIG 范竞霄 fanjingxiao(a)huawei.com<mailto:fanjingxiao@huawei.com> 谷健 gujian14(a)huawei.com<mailto:gujian14@huawei.com> 5 sig仓申请孵化毕业： applications_screenrecorder 20 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> 陈伟 chenwei464(a)huawei.com<mailto:chenwei464@huawei.com> application-SIG 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> 陈伟 chenwei464(a)huawei.com<mailto:chenwei464@huawei.com> 韩浩然 hanhaoran1(a)h-partners.com<mailto:hanhaoran1@h-partners.com> 6 申请新建仓：deveco_harness、agent_kernel_oc 20 鲍开放 baokaifang(a)huawei.com<mailto:baokaifang@huawei.com> IDE_SIG 欧闻 ouwen7(a)huawei.com<mailto:ouwen7@huawei.com> 鲍开放 baokaifang(a)huawei.com<mailto:baokaifang@huawei.com> 邓成瑞 dengchengrui(a)huawei.com<mailto:dengchengrui@huawei.com> 陈晓闯 chenxiaochuang(a)huawei.com<mailto:chenxiaochuang@huawei.com> 7 申请新建sig孵化仓：data_computation_analysis_service遗留问题闭环 20 张浩东 zhanghaodong12(a)huawei.com<mailto:zhanghaodong12@huawei.com> sig_distributeddatamgr 张斌 night.zhangbin(a)huawei.com<mailto:night.zhangbin@huawei.com> 张浩东 zhanghaodong12(a)huawei.com<mailto:zhanghaodong12@huawei.com> 彭阳阳 pengyangyang3(a)huawei.com<mailto:pengyangyang3@huawei.com> 范静雅 fanjingya1(a)huawei.com<mailto:fanjingya1@huawei.com> 谢鑫鑫 xiexinxin2(a)huawei.com<mailto:xiexinxin2@huawei.com> 杨肖栋 yangxiaodong41(a)huawei.com<mailto:yangxiaodong41@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（第220次会议）纪要20260807
by Yangna (y) 11 Aug '26

11 Aug '26

会议主题 Subject OpenHarmony 架构SIG（第220次会议）会议时间 Time 2026-8-7 11:00-12:30(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仓申请孵化毕业：applications_simcardmanagement 议题2：sig仓申请孵化毕业：applications_simtoolkits 本次会议主要内容：议题1、sig仓申请孵化毕业：applications_simcardmanagement 汇报人：范云龙/高红星会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、确认架构图中通信框架部件名称；phone/pad 是否为同一模块。 2、启用/停用SIM卡，具体说明相关流程。 3、补充说明什么场景不需要调 telephonyKit，什么场景不需要调，什么场景会调用 simtoolkit。 4、特性层能力说明过于简单或者泛化，需要细化，包括实现了什么功能，怎么实现的，调用了什么依赖部件等。 5、开发说明中，对于代码篇幅无法展现的部分，通过注释补充说明，比如代码示例中调用了某个函数，则补充注释说明该函数具体做了什么。 6、新特性开发场景1，扩展业务能力，具体举例说明扩展什么业务，每个步骤为什么要这么做。 7、场景2，定制UI，与业务相关性不强，可以删除。 8、权限的使用场景要具象化，同 simtoolkit。议题2、sig仓申请孵化毕业：applications_simtoolkits 汇报人：曾晶会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、新增对专业术语的解释说，包括 BIP、USSD、DTMF 等术语。 2、新增产品层、common 层的模块说明，参考特性层模块说明。 3、架构图按社区规范绘制， kit 放在虚线中间。 4、什么时候拉起，和谁能拉起合并描述，按不同场景分开写。 5、修改设置入口，这块的描述有歧义，到底是改设置还是改 simtoolkit，要明确描述避免歧义。 6、新特性能力开发，步骤1、2、3的逻辑关联不清晰，这些步骤是为了什么业务而开发，每个步骤的逻辑没有清晰的体现出来。 7、目录说明中，有的描述过于泛化，需要具象化，譬如全局管理器等。 8、权限的使用场景要具象化，包括 START_ABILITIES_FROM_BACKGROUND、VIBRATE 等权限。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议纪要】OpenHarmony 架构SIG（第219次会议）纪要20260804
by Yangna (y) 11 Aug '26

11 Aug '26

会议主题 Subject OpenHarmony 架构SIG（第219次会议）会议时间 Time 2026-8-4 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仓：arkdata_intelligence_platform 议题2：申请新建sig仓：distributeddatamgr_data_fabric 议题3：申请新建sig仓：distributeddatamgr_data_mining 议题4：sig仓申请孵化毕业：applications_number_identity 议题5：sig仓申请孵化毕业：applications_startup_guide 议题6、sig仓申请孵化毕业：applications_tips 议题7、sig仓申请孵化毕业：applications_recorder 议题8、sig仓申请孵化毕业：applications_calendar 本次会议主要内容：议题1、申请新建sig仓：arkdata_intelligence_platform 汇报人：莫云/崔乐会议结论： 1、遗留问题闭环后再重新上会。遗留问题： 1、完善架构图，要体现出AI模型等关键能力以及关系密切的周边相关部件。 2、细化孵化目标，写清楚边界细节，比如基于什么文件类型构建知识库。 3、梳理kit关系，逐步废弃旧kit，归一到一套kit。议题2、申请新建sig仓：distributeddatamgr_data_fabric 汇报人：柴晓康会议结论： 1、遗留问题闭环后再重新上会。遗留问题： 1、按部件仓的维度重新绘制架构图，运行态和逻辑架构分开画。 2、标记清楚kit名称，接口属性等，架构图里标注哪些接口属于System接口，哪些属于Public接口。 3、业务术语解释清楚（譬如数据汇聚、编织等）。议题3、申请新建sig仓：distributeddatamgr_data_mining 汇报人：李卓峻会议结论： 1、遗留问题闭环后再重新上会。遗留问题： 1、明确清楚业务场景，仓的职责以及定位。 2、材料中的相关术语做好解释说明。 3、重新按照部件维度绘制架构图。议题4、sig仓申请孵化毕业：applications_number_identity 汇报人：赵维会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、架构图中的预制改成预置。 2、Phone和Pad属于一个模块要体现出来。 3、模块和架构图要能完全对应。 4、接口定义改成对外接口，并写上具体接口。 5、描述清楚数据库默认预置哪些数据。 6、针对不同开发者分别描述，譬如对用号码识别开发者可修改预置数据库；对于联系人、电话应用的开发者为只读属性。 7、架构图中右边的应用补上短信，在接口定义旁补上相关接口。 8、引用OpenHarmony SDK 按毕业时的主干版本写。 9、修改目录中的SDK说明，不能直接叫 SDK，build-profile.json5 改为工程级配置。议题5、sig仓申请孵化毕业：applications_startup_guide 汇报人：吴堃/程枫会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、startupGuide 的名称对照社区部件命名规范进行调整。 2、Phone和Pad属于一个模块要体现出来。 3、架构图中出现的每个模块对要有对应的解释，同其他应用中的分层设计章节、性层的模块的划分要和目录中的模块划分一致，要体现模块职责、模块层级。 4、事件调用关系要修改。 5、开机流程说明需要调整下，删除无关说明。 6、架构图页面生命周期改为页面生命周期管理。 7、场景要区分是首次开机、系统升级、非首次开机。 8、OpenHarmony SDK 按毕业时的主干版本写。 9、修改目录中的SDK说明，不能直接叫 SDK，build-profile.json5 改为工程级配置。议题6、sig仓申请孵化毕业：applications_tips 汇报人：郭云峰/邓奕星会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、common/model 这个名称评估是否再进行调整一下。 2、Phone和Pad属于一个模块要体现出来。 3、架构图中的 settings、sceneboard 确认相关性。 4、引用OpenHarmony SDK 按毕业时的主干版本写。 5、修改目录中的SDK说明，不能直接叫 SDK，build-profile.json5 改为工程级配置。议题7、sig仓申请孵化毕业：applications_recorder 汇报人：金鑫/赵卓屹会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、显式标注出不支持通话录音、应用内录音，只支持麦克风录音。 2、录音控制写清楚遵从音频框架的焦点能力。 3、补充录音文件保存的具体目录路径和数据库。 4、架构图没必要体现sceneboard，且Phone和Pad属于一个模块要体现出来，图标、卡片等入口无需特殊标注出来。 5、应用层分层设计里，特性层的模块的划分要和目录中的模块划分一致，要体现模块职责、模块层级。 6、调用场景只用写首次拉起的场景，改为录音机仅允许桌面拉起调用，播放中的调用无需涉及。 7、录音机开发说明中，widget、录音SDK、工程级SDK表述不准确，需要修改。 8、修改目录中的SDK说明，不能直接叫 SDK，build-profile.json5 改为工程级配置。 9、写清楚MODIFY_AUDIO_SETTINGS的具体权限场景。 10、仓库名和包名不一致，统一修改为soundrecorder。议题8、sig仓申请孵化毕业：applications_calendar 汇报人：黄辛未会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、phone，pad同一个hap包，需要归一。 2、去掉架构图中的SceneBoard部件。 3、CalendarData放在应用层还是服务层需要审视。 4、引用OpenHarmony SDK 按毕业时的主干版本写。 5、修改目录中的SDK说明，不能直接叫 SDK，build-profile.json5 改为工程级配置。 6、Calendar主要使用ohos.permission.READ_WHOLE_CALENDAR 和 ohos.permission.WRITE_WHOLE_CALENDAR 权限，READ_CALENDAR和WRITE_CALENDAR低权限描述去除退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【请阅】OpenHarmony PMC会议（第99次会议）纪要20260806
by Yangna (y) 07 Aug '26

07 Aug '26

会议时间 2026年8月6日9:30-12:00 会议地点线上会议召集人任革林与会人员任革林、董金光、李锋、马耀辉、王意明、鲜余强、邢文华、赵文华、纪永、巴延兴、候鹏飞、王石、庞伟；原野、李晓港、吴迈才、陶皓、黄然、刘满浩、金鑫、杨娜会议议题编号议题名称汇报人议题参与人 1 applications_recorder的committer调整申请金鑫 2 OH社区NFC领域 2个代码仓库committer的调整申请刘满浩文小林 3 multimedia_media_utils_lite代码仓库committer的调整黄然 4 developtools_hdc/developtools_dfx_skills仓库committer调整申请陶皓王棪腾、原野会议纪要本次会议主要内容议题1、applications_recorder的committer调整申请汇报人：金鑫会议结论： 1、同意熊帆（gcw_lumsLVSu）和金鑫（by4gold）为applications_recorder仓库的committer。新任committer要承担起应有的责任，及时处理仓库的PR/Issue等；若要退出需提前交接。 2、同意shaojunye和dingchengjie退出applications_recorder仓库committer。遗留问题： 1、新committer需在半年内达成贡献要求。议题2、OH社区NFC领域 2个代码仓库committer的调整申请汇报人：刘满浩会议结论： 1、同意文小林（wenxiaolin2）和杨晗（yh1719）为communication_secure_element、communication_connected_nfc_tag仓库的committer。新任committer要承担起应有的责任，及时处理仓库的PR/Issue等；若要退出需提前交接。 2、同意张秀平和程国红退出communication_secure_element、communication_connected_nfc_tag仓库committer。遗留问题： 1、新committer需在半年内达成贡献要求。议题3、multimedia_media_utils_lite代码仓库committer的调整汇报人：黄然会议结论： 1、同意陈晨（chennotfound）和李晓港（lxgang_1997）为multimedia_media_utils_lite仓库的committer。新任committer要承担起应有的责任，及时处理仓库的PR/Issue等；若要退出需提前交接。 2、同意zhu-mingliang和landwind退出multimedia_media_utils_lite仓库committer。遗留问题： 1、新committer需在半年内达成贡献要求。议题4、developtools_hdc/developtools_dfx_skills仓库committer调整申请汇报人：陶皓会议结论： 1、同意陶皓（th_0927）和吴迈才（mcai_wu）为developtools_hdc和third_party_libusb仓库的committer。新任committer要承担起应有的责任，及时处理仓库的PR/Issue等；若要退出需提前交接。 2、同意陶皓（th_0927）为developtools_dfx_skills仓库的committer。 2、同意原野和马耀辉退出developtools_hdc和third_party_libusb仓库committer；同意王棪腾退出developtools_dfx_skills仓库committer。遗留问题： 1、新committer需在半年内达成贡献要求。 OpenHarmony PMC例会 2026年8月6日

1 0

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

07 Aug '26

会议主题 Subject OpenHarmony 架构SIG（第220次会议）会议时间 Time 2026-8-7 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=490545081561&pwd=Nzk1Njc0&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/490545081561/6de4cea32f538ed2… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：490545081561 嘉宾密码：795674 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 sig仓申请孵化毕业： applications_simcardmanagement 20 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> application-SIG 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> 黄晓松 huangxiaosong4(a)h-partners.com<mailto:huangxiaosong4@h-partners.com> 2 sig仓申请孵化毕业： applications_simtoolkits 20 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> application-SIG 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> 温健聪 wenjiancong(a)h-partners.com<mailto:wenjiancong@h-partners.com> 3 sig仓申请孵化毕业： applications_intelligentscene 20 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> application-SIG 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> 陈向楷 chenxiangkai1(a)huawei.com<mailto:chenxiangkai1@huawei.com> 韩浩然 hanhaoran1(a)h-partners.com<mailto:hanhaoran1@h-partners.com> 4 会议公告 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 Commiter] Welcoming to become committer of OpenHarmony's arkui_ace_engine project : huangxiaolin
by dongjinguang 04 Aug '26

04 Aug '26

2 1

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

04 Aug '26

会议主题 Subject OpenHarmony 架构SIG（第219次会议）会议时间 Time 2026-8-4 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=489934997721&pwd=ODM3MTU4&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/489934997721/f5db8524274ed667… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：489934997721 嘉宾密码：837158 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓：arkdata_intelligence_platform 15 莫云 moyun6(a)huawei.com<mailto:moyun6@huawei.com> 崔乐 cuile4(a)huawei.com<mailto:cuile4@huawei.com> sig_distributeddatamgr 张云虎 zhangyunhu(a)huawei.com<mailto:zhangyunhu@huawei.com> 冯行宇 fengxingyu(a)huawei.com<mailto:fengxingyu@huawei.com> 王汉才 wanghancai(a)huawei.com<mailto:wanghancai@huawei.com> 莫云 moyun6(a)huawei.com<mailto:moyun6@huawei.com> 文锦超 wenjinchao(a)huawei.com<mailto:wenjinchao@huawei.com> 李卓峻 lizhuojun3(a)huawei.com<mailto:lizhuojun3@huawei.com> 崔乐 cuile4(a)huawei.com<mailto:cuile4@huawei.com> 柴晓康 chaixiaokang(a)huawei.com<mailto:chaixiaokang@huawei.com> 胡涛 hutao105(a)huawei.com<mailto:hutao105@huawei.com> 2 申请新建sig仓： distributeddatamgr_data_fabric 15 柴晓康 chaixiaokang(a)huawei.com<mailto:chaixiaokang@huawei.com> sig_distributeddatamgr 3 申请新建sig仓： distributeddatamgr_data_mining 15 李卓峻 lizhuojun3(a)huawei.com<mailto:lizhuojun3@huawei.com> sig_distributeddatamgr 2 sig仓申请孵化毕业： applications_number_identity 10 赵维 zhaowei8(a)huawei.com<mailto:zhaowei8@huawei.com> application-SIG 赵维 zhaowei8(a)huawei.com<mailto:zhaowei8@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> 3 sig仓申请孵化毕业： applications_startup_guide 10 吴堃 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> 卜音悠扬 buyinyouyang(a)h-partners.com<mailto:buyinyouyang@h-partners.com> 4 sig仓申请孵化毕业： applications_tips 10 郭云峰 guoyunfeng8(a)h-partners.com<mailto:guoyunfeng8@h-partners.com> 邓奕星 dengyixing(a)huawei.com<mailto:dengyixing@huawei.com> application-SIG 郭云峰 guoyunfeng8(a)h-partners.com<mailto:guoyunfeng8@h-partners.com> 邓奕星 dengyixing(a)huawei.com<mailto:dengyixing@huawei.com> 谷健 gujian14(a)huawei.com<mailto:gujian14@huawei.com> 5 sig仓申请孵化毕业： applications_recorder 10 金鑫 jinxin12(a)huawei.com<mailto:jinxin12@huawei.com> 赵卓屹 zhaozhuoyi2(a)huawei.com<mailto:zhaozhuoyi2@huawei.com> application-SIG 金鑫 jinxin12(a)huawei.com<mailto:jinxin12@huawei.com> 赵卓屹 zhaozhuoyi2(a)huawei.com<mailto:zhaozhuoyi2@huawei.com> 肖梓煜 xiaoziyu1(a)huawei.com<mailto:xiaoziyu1@huawei.com> 6 sig仓申请孵化毕业： applications_calendar 10 黄辛未 huangxinwei2(a)huawei.com<mailto:huangxinwei2@huawei.com> application-SIG 黄辛未 huangxinwei2(a)huawei.com<mailto:huangxinwei2@huawei.com> 曹震雄 caozhenxiong2(a)huawei.com<mailto:caozhenxiong2@huawei.com> 7 sig仓申请孵化毕业： applications_simcardmanagement 10 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> application-SIG 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> 黄晓松 huangxiaosong4(a)h-partners.com<mailto:huangxiaosong4@h-partners.com> 8 sig仓申请孵化毕业： applications_simtoolkits 10 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> application-SIG 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> 温健聪 wenjiancong(a)h-partners.com<mailto:wenjiancong@h-partners.com> 9 sig仓申请孵化毕业： applications_intelligentscene 10 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> application-SIG 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> 陈向楷 chenxiangkai1(a)huawei.com<mailto:chenxiangkai1@huawei.com> 韩浩然 hanhaoran1(a)h-partners.com<mailto:hanhaoran1@h-partners.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（第218次会议）纪要20260728
by Yangna (y) 31 Jul '26

31 Jul '26

会议主题 Subject OpenHarmony 架构SIG（第218次会议）会议时间 Time 2026-7-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：skia依赖库独立建仓申请毕业：third_party_wuffs 议题2：申请日落仓：third_party_qrcodegen 议题3：申请新建sig仓： assessment_configuration_service 议题4：申请新建仓：deveco_harness、agent_kernel_oc 议题5：申请新建仓：applications_players、applications_browser 议题6：申请新建仓：applications_screenrecorder 议题7：sig仓申请孵化毕业：applications_recorder 本次会议主要内容：议题1、skia依赖库独立建仓申请毕业：third_party_wuffs 汇报人：黎富民会议结论： 1、闭环遗留问题后再次上会评审。遗留问题： 1、了解清楚wuffs的安全漏洞维护方式。 2、本次整改仅涉及代码仓路径的调整，还是涉及代码仓内容的变更。如果存在代码仓内容的变更，孵化过程还需完整验证整改后相关功能、XTS、TDD、性能等。 3、排查其他使用了wuffs仓库的部件，并一起整改。 4、了解PNG，JPEG，WEBP等格式不一起使用Wuffs整改的原因。议题2、申请日落仓：third_party_qrcodegen 汇报人：张绩会议结论： 1、同意退休，按退休流程下线。遗留问题：无。议题3、申请新建sig仓： assessment_configuration_service 汇报人：何佳承会议结论： 1、同意建仓，遗留问题在孵化前完成闭环。遗留问题： 1、提高部件规格描述的准确性，譬如： 1）通过弹窗提醒用户进入考试模式，非白名单app退出； 2）禁止用户通过系统能力截屏录屏，考试应用可以截屏录屏。 3）对远程控制能力增加具体示例， 4）增加AI助手相关禁用（包括语音唤醒和快捷键启动AI助手）。 5）低电量通知明确类型以及具体场景。 6）增加描述禁用分布式软总线，防止其他设备的分布式通知等转发等。 2、架构图绘制遵从社区架构图标准。架构图中列举完整周边相关部件，譬如拒接来电涉及本SA调用通话SA部件。议题4、申请新建仓：deveco_harness、agent_kernel_oc 汇报人：鲍开放会议结论： 1、闭环遗留问题后重新上会评审。遗留问题： 1、完整说明每个部件仓的功能、在整体架构中的位置、部件间的协同关系和每个代码仓的业务边界。 2、每个仓的新建申请材料分开写。 3、agent_kernel_oc（来源于opencode）要遵从OpenHarmony社区的三方库引入和选型以及仓库命名方式进行引用。议题5、申请新建仓：applications_players、applications_browser 汇报人：范竞霄、曹震雄会议结论： 1、同意在OpenHarmony-SIG下新建applications_players、applications_browser，归属SystemApplication SIG。毕业时闭环遗留问题。遗留问题： 1、共性问题： 1）架构图与分层描述与其他系统应用保持一致。 2）UI风格按照OpenHarmony风格，与其他系统应用保持一致。 3）细化功能特性，明确支持、不支持的能力。 4）明确描述产品的约束限制条件。 2、播放器： 1）版权合规：确认所有预置资源的经过了合法授权。 2）功能规划：确认是否规划分布式功能。 3）能力接入：接入系统播控中心。 3、浏览器： 1）明确支持的设备形态（手机/平板）。 2）补充进程管理相关设计说明。 3）补充提供的安全隐私能力。 4）功能和性能指标需对标业界标准。。 5）考虑适配接入系统入口。 6）明确对外提供的具体能力（打开文件格式，打印，媒体播放等）。议题6、申请新建仓：applications_screenrecorder 汇报人：王春会议结论： 1、同意在OpenHarmony-SIG下新建applications_screenrecorder仓，归属SystemApplication SIG。毕业时闭环遗留问题。遗留问题： 1、UX风格设计 1）确认录屏应用实况等UX设计符合OpenHarmony风格要求。 2、规格细化，按照开源范围表格刷新完整规格 1）禁止录屏等安全场景说明。 2）停止录屏场景说明。 3、架构图刷新： 1）按照OpenHarmony架构层次划分，配色风格等更新架构图。 2）截屏应用涉及的权限说明。 3）具体调用方的权限要求和具体场景说明。 4）录屏应用与周边相关业务的依赖关系。 4、本应用开源后, 原录屏demo应用下架，与原Demo应用沟通确认。议题7、sig仓申请孵化毕业：applications_recorder 汇报人：赵卓屹会议结论： 1、闭环遗留问题后再上会评审。遗留问题： 1、目录分为：录音/最近删除。 2、架构图风格需统一，包括关键kit和关键系统服务说明，架构图和文字描述要一致。 3、是否允许三方应用调用、需要哪些权限要在约束里详细说明。 4、模块说明要与架构图、目录结构一一对应，术语保持一致，产品形态和模块要区分开。 5、代码目录说明中的注释需要细化为录音机相关的具体内容。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's audio_framework project : tianluowen
by Yangna (y) 30 Jul '26

30 Jul '26

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's arkruntime project : daizihan
by Yangna (y) 30 Jul '26

30 Jul '26

1 0

[New Commiter] Welcoming to become committer of OpenHarmony's graphic_2d project : chensiyi
by Yangna (y) 30 Jul '26

30 Jul '26

1 0

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

28 Jul '26

会议主题 Subject OpenHarmony 架构SIG（第218次会议）会议时间 Time 2026-7-28 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=484852049625&pwd=MTQxNDgw&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/484852049625/e78a78fee06bc5f1… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：484852049625 嘉宾密码：141480 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 skia依赖库独立建仓： sig仓申请毕业：third_party_wuffs 20 黎富民 lifumin3(a)h-partners.com<mailto:lifumin3@h-partners.com> sig_graphics 赵娜 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> 2 申请日落仓：third_party_qrcodegen 10 张绩 zhangji56(a)huawei.com<mailto:zhangji56@huawei.com> sig_graphics 张浩萍 zhanghaoping(a)huawei.com<mailto:zhanghaoping@huawei.com> 卢旭玉 luxuyu(a)huawei.com<mailto:luxuyu@huawei.com> 3 申请新建sig仓： assessment_configuration_service 20 何佳承 hejiacheng2(a)huawei.com<mailto:hejiacheng2@huawei.com> sig_basicsoftwareservice 何佳承 hejiacheng2(a)huawei.com<mailto:hejiacheng2@huawei.com> 段续斌 duanxubin(a)huawei.com<mailto:duanxubin@huawei.com> 邓资袁 dengziyuan(a)huawei.com<mailto:dengziyuan@huawei.com> 4 申请新建仓：deveco_harness agent_kernel_oc 20 鲍开放 baokaifang(a)huawei.com<mailto:baokaifang@huawei.com> IDE_SIG 欧闻 ouwen7(a)huawei.com<mailto:ouwen7@huawei.com> 鲍开放 baokaifang(a)huawei.com<mailto:baokaifang@huawei.com> 5 申请新建仓： applications_players applications_browser 20 范竞霄 fanjingxiao(a)huawei.com<mailto:fanjingxiao@huawei.com> 曹震雄 caozhenxiong2(a)huawei.com<mailto:caozhenxiong2@huawei.com> application-SIG 曹震雄 caozhenxiong2(a)huawei.com<mailto:caozhenxiong2@huawei.com> 谷健 gujian14(a)huawei.com<mailto:gujian14@huawei.com> 李锋 lifeng(a)huawei.com<mailto:lifeng@huawei.com> 6 sig仓申请孵化毕业： applications_number_identity applications_startup_guide applications_tips applications_recorder applications_calendar applications_simcardmanagement applications_simtoolkits applications_intelligentscene 赵维 zhaowei8(a)huawei.com<mailto:zhaowei8@huawei.com> 吴堃 kun.wu(a)huawei.com<mailto:kun.wu@huawei.com> 程枫 chengfeng32(a)huawei.com<mailto:chengfeng32@huawei.com> 郭云峰 guoyunfeng8(a)h-partners.com<mailto:guoyunfeng8@h-partners.com> 邓奕星 dengyixing(a)huawei.com<mailto:dengyixing@huawei.com> 金鑫 jinxin12(a)huawei.com<mailto:jinxin12@huawei.com> 黄辛未 huangxinwei2(a)huawei.com<mailto:huangxinwei2@huawei.com> 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@huawei.com> application-SIG 赵维 zhaowei8(a)huawei.com<mailto:zhaowei8@huawei.com> 吴堃 kun.wu(a)huawei.com<mailto:kun.wu@huawei.com> 程枫 chengfeng32(a)huawei.com<mailto:chengfeng32@huawei.com> 郭云峰 guoyunfeng8(a)h-partners.com<mailto:guoyunfeng8@h-partners.com> 邓奕星 dengyixing(a)huawei.com<mailto:dengyixing@huawei.com> 金鑫 jinxin12(a)huawei.com<mailto:jinxin12@huawei.com> 黄辛未 huangxinwei2(a)huawei.com<mailto:huangxinwei2@huawei.com> 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> 王春 wchun.wang(a)huawei.com<mailto:wchun.wang@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> 谷健 gujian14(a)huawei.com<mailto:gujian14@huawei.com> 曹震雄 caozhenxiong2(a)huawei.com<mailto:caozhenxiong2@huawei.com> 肖梓煜 xiaoziyu1(a)huawei.com<mailto:xiaoziyu1@huawei.com> 王鸿升 wanghongsheng3(a)huawei.com<mailto:wanghongsheng3@huawei.com> 陈向楷 chenxiangkai1(a)huawei.com<mailto:chenxiangkai1@huawei.com> 卜音悠扬 buyinyouyang(a)h-partners.com<mailto:buyinyouyang@h-partners.com> 韩浩然 hanhaoran1(a)h-partners.com<mailto:hanhaoran1@h-partners.com> 黄晓松 huangxiaosong4(a)h-partners.com<mailto:huangxiaosong4@h-partners.com> 温健聪 wenjiancong(a)h-partners.com<mailto:wenjiancong@h-partners.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 PMC会议（第98次会议）纪要20260723
by Yangna (y) 27 Jul '26

27 Jul '26

会议时间 2026年7月23日9:30-12:00 会议地点线上会议召集人任革林与会人员任革林、董金光、高涵一、李锋、马耀辉、王意明、邢文华、张小田、李锋、赵鹏、赵文华、邢文华、鲜余强、强波、纪永、侯选哲、马尔利、魏江波、杨娜会议议题编号议题名称汇报人议题参与人 1 Softbus SIG Leader更换侯选哲马尔利 2 Driver SIG Leader更换魏江波赵文华 3 OpenHarmony社区支持多指令集芯片架构任革林会议纪要本次会议主要内容议题1、Softbus SIG Leader更换汇报人：侯选哲会议结论： 1、同意Softbus SIG组长更换为侯选哲。遗留问题： 1、制定领域技术规划和重点工作计划。 2、增进和伙伴的沟通交流，提取伙伴的诉求。议题2、Driver SIG Leader更换汇报人：魏江波会议结论： 1、同意Driver SIG组长更换为魏江波。遗留问题： 1、制定领域技术规划和重点工作计划。 2、增进和伙伴的沟通交流，提取伙伴的诉求。议题3、OpenHarmony社区支持多指令集芯片架构汇报人：任革林会议结论： 1、同意OpenHarmony社区SoC分级保障原则和规划。 2、具体准入标准会后发给PMC成员评审，一周后定稿上线。遗留问题：无。 OpenHarmony PMC例会 2026年7月23日

1 0

【会议纪要】OpenHarmony 架构SIG（第217次会议）纪要20260721
by Yangna (y) 27 Jul '26

27 Jul '26

会议主题 Subject OpenHarmony 架构SIG（第217次会议）会议时间 Time 2026-7-21 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仓：ai_plugin_engine；申请开源引入：mmn、ncnn、llama.cpp 议题2：申请新建sig孵化仓：graphic_2d_engine 遗留问题闭环议题3：申请新建sig孵化仓：data_computation_analysis_service 议题4：申请新建sig仓： assessment_configuration_service 议题5：申请仓更名：arkui_qrcodegen 议题6、申请新建sig仓：distributeddatamgr_data_fabric 本次会议主要内容：议题1、申请新建sig仓：ai_plugin_engine；申请开源引入：mmn、ncnn、llama.cpp 汇报人：潘栩荣会议结论： 1、暂不同意新建ai_plugin_engine。系统层面的接口标准化为时尚早，建议先考虑在应用层尝试。 2、开源引入的材料分别描述清楚引入的具体原因、与其他同类的对比情况后再重新上会。遗留问题：无。议题2、申请新建sig孵化仓：graphic_2d_engine 遗留问题闭环汇报人：王良江会议结论： 1、闭环以下遗留问题后，同意在OpenHarmony-SIG下新建graphic_2d_engine，归属sig_graphic。遗留问题： 1、架构图按照社区模板绘制、调用方加上app、三方库画在底层； 2、完善孵化目标：要包括整体功能目标、性能目标以及DFX能力，包括功能具体替换skia能力清单，Drawingsl使用范围；分阶段孵化交付节奏。议题3、申请新建sig孵化仓：data_computation_analysis_service 汇报人：张浩东会议结论： 1、闭环遗留问题后同意新建。遗留问题： 1、确认模型管理和模型运行是否一个进程中，原因是什么？ 2、DCAS名称是否合理？数据计算分析服务太大，是否可以改成模型管理，如何处理与大模型管理的关系，建议模型管理能力归一到一个部件，并刷新架构信息平台 3、架构图中注明清楚系统接口，可以举例几个业务调用方，接口不提供给三方使用。 4、架构图中芯片模型运行态进程也画出来。 5、模型运行的逻辑流程图（譬如LoadModel-->RunModel），LoadModel和RunModel容易有歧义，具体的接口定义是什么？ 6、仓库committer过多，精简到3~4位。 7、推理框架中对应KIT按照实际的调整。 8、架构解释：模型加载后为什么从DCAS获取结果，不直接从模型推理侧获取结果？ 9、部件是否继续归属于数据管理子系统？议题4、申请新建sig仓： assessment_configuration_service 汇报人：何佳承会议结论： 1、闭环遗留问题后同意新建。遗留问题： 1、补充app调用接口所需权限描述。 2、补充调用begin接口后应用可进行的操作与无法进行的操作，特别是通过紧急呼叫，紧急云推（譬如地震通知），定时器（譬如闹钟），呼入，分布式（如查找手机）等场景。 3、补充通知屏蔽场景具体屏蔽哪些通知内容。 4、确认部件名称。议题5、申请仓更名：arkui_qrcodegen 汇报人：张绩会议结论： 1、同意arkui_qrcodegen更名为commonlibrary_qrcode_generator。遗留问题：无。议题6、申请新建sig仓：distributeddatamgr_data_fabric 汇报人：胡涛会议结论： 1、暂不同意新建。遗留问题： 1、补充不能放到分布式数据管理service仓而需要新建仓的原因。 2、补充能力开放的范围。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

21 Jul '26

会议主题 Subject OpenHarmony 架构SIG（第217次会议）会议时间 Time 2026-7-21 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=475366718961&pwd=NjY5OTE1&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/475366718961/7350a7a33fbc6fe1… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：475366718961 嘉宾密码：669915 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓:ai_plugin_engine 申请开源引入：mmn、ncnn、llama.cpp 20 潘栩荣panxurong(a)talkweb.com.cn<mailto:潘栩荣panxurong@talkweb.com.cn> sig_ai_model 潘栩荣 panxurong(a)talkweb.com.cn<mailto:panxurong@talkweb.com.cn> 胡泽华 huzehua25966(a)talkweb.com.cn<mailto:huzehua25966@talkweb.com.cn> 侯鹏飞 houpengfei(a)talkweb.com.cn<mailto:houpengfei@talkweb.com.cn> 2 申请新建sig孵化仓：graphic_2d_engine 遗留问题闭环 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> 吴旭卿 xuqing.wu(a)unionman.com.cn<mailto:xuqing.wu@unionman.com.cn> 谢仲初 zhongchu.xie(a)unionman.com.cn<mailto:zhongchu.xie@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> 3 申请新建sig孵化仓：data_computation_analysis_service 20 张浩东 zhanghaodong12(a)huawei.com<mailto:zhanghaodong12@huawei.com> sig_distributeddatamgr 张斌 night.zhangbin(a)huawei.com<mailto:night.zhangbin@huawei.com> 张浩东 zhanghaodong12(a)huawei.com<mailto:zhanghaodong12@huawei.com> 徐大庆 xudaqing(a)huawei.com<mailto:xudaqing@huawei.com> 彭阳阳 pengyangyang3(a)huawei.com<mailto:pengyangyang3@huawei.com> 范静雅 fanjingya1(a)huawei.com<mailto:fanjingya1@huawei.com> 谢鑫鑫 xiexinxin2(a)huawei.com<mailto:xiexinxin2@huawei.com> 杨肖栋 yangxiaodong41(a)huawei.com<mailto:yangxiaodong41@huawei.com> 4 申请新建sig仓： assessment_configuration_service 20 何佳承 hejiacheng2(a)huawei.com<mailto:hejiacheng2@huawei.com> sig_basicsoftwareservice 何佳承 hejiacheng2(a)huawei.com<mailto:hejiacheng2@huawei.com> 段续斌 duanxubin(a)huawei.com<mailto:duanxubin@huawei.com> 邓资袁 dengziyuan(a)huawei.com<mailto:dengziyuan@huawei.com> 5 申请仓更名：arkui_qrcodegen 10 张绩 zhangji56(a)huawei.com<mailto:zhangji56@huawei.com> sig_appframework 张浩萍 zhanghaoping(a)huawei.com<mailto:zhanghaoping@huawei.com> 卢旭玉 luxuyu(a)huawei.com<mailto:luxuyu@huawei.com> 6 申请新建sig仓：developtools_dfx_mem_analyzer 20 胡昶 huchang4(a)huawei.com<mailto:huchang4@huawei.com> sig_basicsoftwareservice 夏中林 xiazhonglin(a)huawei.com<mailto:xiazhonglin@huawei.com> 段晓冬 martin.duanxiaodong(a)huawei.com<mailto:martin.duanxiaodong@huawei.com> 卢韬 lutao31(a)huawei.com<mailto:lutao31@huawei.com> 罗杰 luojie29(a)huawei.com<mailto:luojie29@huawei.com> 胡昶 huchang4(a)huawei.com<mailto:huchang4@huawei.com> 7 申请新建sig仓：distributeddatamgr_data_fabric 20 胡涛 hutao105(a)huawei.com<mailto:hutao105@huawei.com> sig_distributeddatamgr 张云虎 zhangyunhu(a)huawei.com<mailto:zhangyunhu@huawei.com> 冯行宇 fengxingyu(a)huawei.com<mailto:fengxingyu@huawei.com> 王汉才 wanghancai(a)huawei.com<mailto:wanghancai@huawei.com> 柴晓康 chaixiaokang(a)huawei.com<mailto:chaixiaokang@huawei.com> 郭富强 guofuqiang1(a)huawei.com<mailto:guofuqiang1@huawei.com> 胡涛 hutao105(a)huawei.com<mailto:hutao105@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第11次会议
by xulingyun 18 Jul '26

18 Jul '26

�� Subject OpenHarmony��SIG�� 2026��11�λ��飨Sig-ProgramAnalysis Meeting�� ʱ�� Time 7/21 (�ܶ�) 19:00-20:00 (UTC+08:00)Beijing ��Ƶ�� Video Meeting Host��https://imeeting.huawei.com/meeting/startwelink?id=99767692&pwd=MjkzO… Internal��https://imeeting.huawei.com/meeting/joinwelink?id=99767692&pwd=Mz… External��https://app.huawei.com/wmeeting/join/99767692/QOWRMTw8UDrtIQhkSGI… ��ID��99767692 ��룺310396 �� /�� 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（第216次会议）纪要20260707
by Yangna (y) 09 Jul '26

09 Jul '26

会议主题 Subject OpenHarmony 架构SIG（第216次会议）会议时间 Time 2026-7-7 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：星闪仓孵化申请毕业：communication_nearlink 议题2：sig仓孵化毕业申请：arkui_qrcodegen 议题3：申请新建 sig 仓 genui 议题4：iot_connect仓遗留问题闭环毕业申请议题5：homegraph/bjc/haptest建仓申请遗留问题闭环本次会议主要内容：议题1、星闪仓孵化申请毕业：communication_nearlink 汇报人：刘兆珅会议结论： 1、遗留问题1和2闭环后同意communication_nearlink SIG仓孵化毕业，配套的星闪驱动代码和接口同步孵化。 2、星闪协议栈先在OpenHarmony开源，若后续星闪协议栈独立开源运作，在满足OH开源引入条件下，可作为通用协议栈三方开源库方式引入到OpenHarmony社区使用。遗留问题： 1、readme资料遗留问题： 1）架构图非本模块颜色修改成其它颜色，加上kit名称。 2）架构图各层加上具体的名字，例如星闪服务。 3）每层整体能力描述，单个模块具体解释补充。 4）英文文档中架构图中文字修改为中文。 5）feature具体的配置路径，以P7885开发板作为示例，例如XXX平台，阐述每个feature的使用场景。 6）从开发者视角，在架构图后面补充典型业务场景示意流程图。 2、bundle.json问题： 1）三方库单独放在third_party中，参考其它模块实现。 2）排查是否有冗余部件依赖。 3、仓名修改为nearlink_service和部件名一致。 4、开发板 P7885星闪业务适配和使能 – 完成时间：2026年8月15日 5、给系统应用SIG提需求，开源系统应用设置中增加星闪开关、配置的相关功能。完成时间：2026年8月15日议题2、sig仓孵化毕业申请：arkui_qrcodegen 汇报人：张绩会议结论： 1、遗留问题闭环后，同意孵化毕业。遗留问题： 1、架构图使用二维码生成器的场景直接使用具体控件名称 -- 已闭环 2、架构图二维码生成器对子系统提供的接口模块名修改为inner接口，模块中直接写具体接口名称 -- 已闭环 3、架构图二维码生成器依赖bounds_checking_function，直接写依赖三方库名 -- 已闭环 4、去掉架构图中的依赖箭头。 -- 已闭环 5、在readme中补充支持mini，small和standard情况。 -- 已闭环议题3、申请新建 sig 仓 genui 汇报人：贾德祥会议结论： 1、同意在OpenHarmony-SIG下新建genui，归属sig_appframework。遗留问题： 1、架构图中依赖的ArkUI 和 ArkUI-x 的层次关系调整准确。 2、如果仅依赖 OpenHarmony API，建议名称修改为 openharmony 智能体协议。 3、genui sample迁移到applications_app_samples仓下。 4、考虑后续Kit回合 OH SDK，接口设计机制上需注意 kit 名变更对开发者的影响。议题4、iot_connect仓遗留问题闭环毕业申请汇报人：陈理恩会议结论： 1、线下闭环遗留问题后同意毕业。遗留问题： 1、基于iotc与基础设施一起打样构建这类型的API接口管理方案跟王意明对齐计划。 2、以7.0版本和海思3863芯片为例，刷新轻量系统IoT connect组件编译和特性配置指导。 3、裁剪指导部分资料描述："+"改为裁剪。议题5、homegraph/bjc/haptest建仓申请遗留问题闭环汇报人：孙波会议结论： 1、闭环遗留问题后同意在OpenHarmony-SIG下新建bjc和haptest，归属programanalysis-SIG。遗留问题： 1、HomeGraph 建议先以个人仓方式孵化，待满足基本合规要求后再评审建正式孵化仓。 2、BJC和HapTest孵化目标需要描述清楚，优化后发给任革林/董金光闭环。 3、BJC 仓库命名建议与法务工作组余甜沟通确认是否存在合规和舆情风险。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

07 Jul '26

会议主题 Subject OpenHarmony 架构SIG（第216次会议）会议时间 Time 2026-7-7 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=470382865249&pwd=NTkyMzE0&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/470382865249/78ced9182aef766e… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）观众 (内)：https://imeeting.huawei.com/meeting/joinxy?id=470382865249&pwd=NDIyMDA2&… 观众 (外)：https://welink.huaweicloud.com/meeting/#/j/470382865249/d2a25a5fefbd9166… 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 星闪仓孵化申请毕业：communication_nearlink 20 刘兆珅 liuzhaoshen(a)huawei.com<mailto:liuzhaoshen@huawei.com> sig_softbus 刘兆珅 liuzhaoshen(a)huawei.com<mailto:liuzhaoshen@huawei.com> 李龙 lilong32(a)huawei.com<mailto:lilong32@huawei.com> 程国红 guohong.cheng(a)huawei.com<mailto:guohong.cheng@huawei.com> 苏炯金 sujiongjin(a)huawei.com<mailto:sujiongjin@huawei.com> 陈子康 chenzikang4(a)huawei.com<mailto:chenzikang4@huawei.com> 吴旖珂 wuyike3(a)huawei.com<mailto:wuyike3@huawei.com> 周功宇 zhougongyu1(a)huawei.com<mailto:zhougongyu1@huawei.com> 2 sig仓孵化毕业申请：arkui_qrcodegen 20 zhangji56(a)huawei.com<mailto:zhangji56@huawei.com> sig_appframework 张浩萍 zhanghaoping(a)huawei.com<mailto:zhanghaoping@huawei.com> 卢旭玉 luxuyu(a)huawei.com<mailto:luxuyu@huawei.com> 3 申请新建 sig 仓 genui 20 贾德祥 jiadexiang(a)huawei.com<mailto:jiadexiang@huawei.com> sig_appframework jiangtao57(a)huawei.com<mailto:jiangtao57@huawei.com> jiadexiang(a)huawei.com<mailto:jiadexiang@huawei.com> 4 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> 5 homegraph/bjc/haptest建仓申请遗留问题闭环 20 孙波 bb.sunbo(a)huawei.com<mailto:bb.sunbo@huawei.com> programanalysis-SIG 会议公告 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 1

【会议纪要】OpenHarmony 架构SIG（第215次会议）纪要20260630
by Yangna (y) 03 Jul '26

03 Jul '26

会议主题 Subject OpenHarmony 架构SIG（第215次会议）会议时间 Time 2026-6-30 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：BQ3588仓孵化申请毕业：vendor/bearkey/bq3588、device/board/bearkey 议题2：申请新建sig仓遗留问题闭环：open_pdf_kit、third_party_pdfium 议题3：申请新建sig仓：filemanagement_archive 遗留问题闭环议题4：申请新建sig仓：bitfun_agent_kernel、bitfun_agent_kernel_next、bitfun_trace 本次会议主要内容：议题1、BQ3588仓孵化申请毕业：vendor/bearkey/bq3588、device/board/bearkey 汇报人：佘成东会议结论： 1、闭环遗留问题后再上会评审。遗留问题： 1、结合NFC短距协议栈孵化团队一起推进nfc功能。 2、MODEM需要保证IMS/VOP，电话短信等功能。 3、BQ3588需要保证编译无报警并提供编译日志。 4、统一渲染要确保基于统一大桌面进行验证。 5、完成opentrustee功能适配。 6、NPU基于社区AI推理框架进行适配。议题2、申请新建sig仓遗留问题闭环：open_pdf_kit、third_party_pdfium 汇报人：罗枭鸿会议结论： 1、同意在OpenHarmony-SIG下新建open_pdf_kit、third_party_pdfium仓，归属sig_basicsoftwareservice。毕业前闭环遗留问题。遗留问题： 1、pdfium架构图中渲染模块描述清楚其具体的功能，还有与底层三方库的关系。 2、pdfium的扩展模块需要进行侵入式修改合理性审视，评估对后续版本升级的影响（重要）。 3、pdfium接口开放数量需要进行严格控制，用单独头文件暴露需要使用的接口（重要）。 4、pdfium所使用的三方库lcms还在孵化中，openjpeg不在社区中，需要新建依赖仓和匹配开源版本选型配套关系。议题3、申请新建sig仓：filemanagement_archive 遗留问题闭环汇报人：江婧会议结论： 1、同意在OpenHarmony-SIG下新建filemanagement_archive，归属sig_kernel。毕业前闭环遗留问题。遗留问题： 1、zlib扩展的大文件压缩/解压缩HMxx接口和功能点梳理，实现功能归一至filemanagement_archive仓。议题4、申请新建sig仓：bitfun_agent_kernel、bitfun_agent_kernel_next、bitfun_trace 汇报人：鲍开放会议结论： 1、讲清楚和之前创建agent_code之间的关系后再重新上会评审。遗留问题：无。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

跨模块一致性问题回复 //回复: OpenHarmony 跨模块多机制一致性问题汇报（46 条 bug）
by dongjinguang 02 Jul '26

02 Jul '26

侯朋朋，你好：首先非常感谢你系统性地梳理并反馈了这 46 条跨模块一致性问题，也感谢你持续跟进此前提交的issue。这类"一处机制声明、另一处缺少对应定义/注册/产物"的不一致问题，确实是当前多机制协同下容易累积的隐患，对提升源码质量很有价值。结合本地主线代码对反馈逐项做了初步核对，整体答复如下：一、关于 vendor 仓下产品与模拟器相关的问题（对应第 1、2、6 类及部分第 3 类）经确认，这类问题大多属实。根本原因是：vendor 仓下的部分产品与模拟器（如 QEMU、HiHope 部分形态（3588等））并不在当前的编译看护（CI 门禁）范围内，缺少持续构建校验，因此配置随主线组件演进出现漂移、遗留旧组件名等情况在所难免。例如我们本地复核确认：qemu_arm_linux_headless/config.json 仍选择appexecfwk_core，而注册表中该组件早已更名为 bundle_framework（appexecfwk_core 现仅作为 inner_api 目标/头文件路径存在），这正是一处典型的"选择项与注册定义"不一致。对这类问题，可行的处理方式是：聚焦 vendor 仓下用户实际使用的产品形态，逐个拉起完整编译，以真实构建结果为准进行校准，并逐一清理不在主线看护的型号或要求开发板厂商解决配置错误；对于已不再维护的模拟器/演示产品配置中的历史遗留项，我们会评估清理或补充说明。二、关于框架仓（foundation/base）内的一致性问题（对应第 4、5、7、8 类） 1、这部分不完全依赖产品编译即可判定，我们本地也复核确认了若干项确为真实缺陷，例如：hichecker inner kit 的 header_files 中错误地列入了 .cpp 实现文件；文件： base/hiviewdfx/hichecker/bundle.json { "name": "//base/hiviewdfx/hichecker/frameworks/native:libhichecker_source", "header": { "header_files": [ "caution.cpp", // ← 第71行，应为 caution.h "hichecker.cpp", // ← 第72行，应为 hichecker.h "hichecker_wrapper.cpp" // ← 第73行，应为 hichecker_wrapper.h ], "header_base": "//base/hiviewdfx/hichecker/interfaces/native/innerkits/include/" } } 2、device_status 的 bundle.json 声明了 motion 但注册表无对应独立组件等。这类问题我们会按归属仓库分发给对应仓库owner 确认，确认后通过正常流程修复。三、后续安排与请求 1. vendor 产品类问题安排开发板厂商以"实际编译 + 校准"方式收敛或逐一清理下线； 2. 框架仓类问题逐条通过ISSUE问题类跟踪问题并解决； 3. 若方便，请你补充每条问题对应的具体代码仓库版本/分支提出ISSUE并将ISSUE编号单独反馈单独反馈给我，部分示例如 HiHope 的 eudev、contacts 在我们当前检出的主线代码中未能复现，疑似版本差异或已修复。谢谢！发件人: 侯朋朋 via dev <dev(a)openharmony.io> 发送时间: 2026年6月11日 22:57 收件人: 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 跨模块多机制一致性问题汇报（46 条 bug）
by Fuyao Kashizuku 01 Jul '26

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

2 2

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

30 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第215次会议）会议时间 Time 2026-6-30 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=465686259201&pwd=ODg3MTky&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/465686259201/f0ac1095b4f0a98a… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：465686259201 嘉宾密码：887192 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 BQ3588仓孵化申请毕业： vendor/bearkey/bq3588 device/board/bearkey 20 佘成东 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> 2 申请新建sig仓遗留问题闭环： open_pdf_kit third_party_pdfium 20 罗枭鸿 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> 3 申请新建sig仓：filemanagement_archive 遗留问题闭环 20 江婧 jiangjing23(a)hisilicon.com<mailto:jiangjing23@hisilicon.com> sig_kernel 段晓蒙 duanxiaomeng(a)huawei.com<mailto:duanxiaomeng@huawei.com> 阮伦 ruanlun1(a)huawei.com<mailto:ruanlun1@huawei.com> 马家俊 majiajun(a)huawei.com<mailto:majiajun@huawei.com> 4 申请新建sig仓 bitfun_agent_kernel bitfun_agent_kernel_next bitfun_trace 20 鲍开放 baokaifang(a)huawei.com<mailto:baokaifang@huawei.com> IDE_SIG 欧闻 ouwen7(a)huawei.com<mailto:ouwen7@huawei.com> 邓成瑞 dengchengrui(a)huawei.com<mailto:dengchengrui@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

[New Commiter] Welcoming to become committer of OpenHarmony's bluetooth project : lilong
by dongjinguang 29 Jun '26

29 Jun '26

1 0

OpenHarmony 合规SIG例会纪要 20260626
by Yuyang (Gabriel) 29 Jun '26

29 Jun '26

会议主题 Subject OpenHarmony 合规 SIG 例会 0626（Sig-compliance Meeting）会议时间 Time 2026-06-26 11:00-11:30 轮值主持人于洋与会人 Attendees 合规SIG组成员会议议题 Agenda 编号 No. 议题名称 Topic 时长 Duration 起止时间 Time 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 OpenHarmony 6.1 LTS发布评审 30 min 11:00-11:30 徐亮于洋合规SIG组全体成员会议公告 Bulletins 合规SIG项目信息： https://gitee.com/openharmony/community/blob/master/sig/sig_compliance/sig_… 合规SIG议题申报：https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC 北京时间10月30日10:00前截止合规SIG重点工作协作平台：https://shimo.im/sheets/B1Aw1d18GeFygLqm/0991P 议题一：OpenHarmony 6.1 LTS发布评审，汇报人：徐亮 1. 确认6.1 LTS 基于6.0 Release的稳定版本构建，分支策略基于6.1 Release拉出。 2. 当前版本告警类问题清零，OAT敏感词Full Scan结果均为零，整体看板干净。遗留任务： 1. 棱镜扫描风险澄清清单，有部分澄清存在疑似问题，需要在6.1 LTS发布前确认，责任人：徐亮，完成时间：2026年6月30日 2. 确认7885板子的发布策略，责任人：徐亮，完成时间：2026年6月30日

1 0

【会议纪要】OpenHarmony 架构SIG（第214次会议）纪要20260623
by Yangna (y) 29 Jun '26

29 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第214次会议）会议时间 Time 2026-6-23 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仓: applications_simtoolkits 议题2：申请新建sig仓：SimCardManagement 议题3：iot_connect仓遗留问题闭环毕业申请议题4：遗留问题闭环并申请新建sig仓：open_pdf_kit、third_party_pdfium；申请开源软件独立选型：pdfium 议题5：申请新建sig仓：application_tips 本次会议主要内容：议题1、申请新建sig仓: applications_simtoolkits 汇报人：曾晶会议结论： 1、闭环遗留问题后同意在OpenHarmony-SIG下新增applications_simtoolkits仓。遗留问题： 1、详细补充仓库提供了哪些能力。 2、架构图重新绘制，需要体现和Telephony等关键依赖部件的完整交互逻辑。 3、STK不区分插卡平板和手机，架构图上去掉product和插卡平板。 4、补充几个典型的业务流程。议题2、申请新建sig仓：SimCardManagement 汇报人：范云龙会议结论： 1、闭环遗留问题后同意在OpenHarmony-SIG下新增applications_simcardmanagement仓。遗留问题： 1、架构图增加外部STK的调用入口，按照应用的三层逻辑（Common feature product）重新绘制，需包括上下游调用关系，如settings、stk、telephony服务。 2、架构图模块名称修改：支持SIM卡保护->SIM卡保护。议题3、iot_connect仓遗留问题闭环毕业申请汇报人：陈理恩会议结论： 1、遗留问题闭环后同意毕业。遗留问题： 1、架构图中把组件放到应用层，同步修改文档描述。 2、对外的接口建议定义具体名称，API版本号从1.0开始，增加与OpenHarmony的版本配套关系。 3、当前Feature颗粒度过大，建议按照典型场景重新规划Feature，裁剪指导按照feature颗粒度细化描述，持续优化内存占用。 4、通过iot_connect API打样，与基础设施工作组协作，并完善针对mini类型系统的API & Kit的治理平台管理工具和治理能力。议题4、遗留问题闭环并申请新建sig仓：open_pdf_kit、third_party_pdfium；申请开源软件独立选型：pdfium 汇报人：罗枭鸿会议结论： 1、闭环遗留问题后同意建仓。遗留问题： 1、仓名、部件名再做调整，不建议使用“kit”命名，明确归属子系统，以及完整的仓名。 2、确认pdfium是否需和Chromium归一，无法归一需给出具体的结论。【已闭环】 3、架构图中描述清楚与打印框架之间的关系。 4、架构图风格与社区保持一致，接口用虚线表示。议题5、申请新建sig仓：application_tips 汇报人：郭云峰会议结论： 1、闭环遗留问题1闭环后同意建仓，毕业时闭环其他遗留问题。遗留问题： 1、补充完整系统架构图。 2、设备支持情况描述清楚完整，最好做到多设备支持，或者UX上做到适应不同屏幕宽度。 3、添加跳转到其他应用的能力。 4、资料中补充详细的开发指导，介绍如何添加内容以及展示的步骤。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

27 Jun '26

�� Subject OpenHarmony��SIG�� 2026��10�λ��飨Sig-ProgramAnalysis Meeting�� ʱ�� Time 6/30 (�ܶ�) 19:00-20:00 (UTC+08:00)Beijing ��Ƶ�� Video Meeting Host��https://imeeting.huawei.com/meeting/startwelink?id=94535328&pwd=NDc4N… Internal��https://imeeting.huawei.com/meeting/joinwelink?id=94535328&pwd=Mj… External��https://app.huawei.com/wmeeting/join/94535328/dnlEW1oAIK6iWrDUljI… ��ID��94535328 ��룺204343 �� /�� 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 PMC会议（第97次会议）纪要20260611
by Yangna (y) 23 Jun '26

23 Jun '26

会议时间 2026年6月11日9:30-12:00 会议地点线上会议召集人任革林与会人员刘果；任革林、董金光、黄然、邢文华、赵文华、赵鹏、纪永、巴延兴、庞伟、候鹏飞；张博、朱敏、林洪亮、张召、张雷宇、Jet Ding、杨娜会议议题编号议题名称汇报人议题参与人 1 游戏SIG新增成员张雷宇黄然、张博、朱敏、Jet Ding 2 OpenHarmony Vulkan 3个代码仓库committer权限变更张召会议纪要本次会议主要内容议题1、游戏SIG新增成员汇报人：张雷宇会议结论： 1、闭环遗留问题1后同意游戏SIG新增成员朱敏和Jet Ding。遗留问题： 1、补充2位专家的简介和分工。责任人：张博 2、游戏SIG的会议运作后续在社区公开。议题2、OpenHarmony Vulkan 3个代码仓库committer权限变更汇报人：张召会议结论： 1、同意高攀（GaoPan_t）为third_party_vulkan-headers、third_party_vulkan-loader、third_party_vulkan-validationlayers仓库的committer。 2、同意stonesxd和lz-230退出third_party_vulkan-headers仓库committer、mk_gc和xuyuqiong退出third_party_vulkan-loader仓库committer、stonesxd和gongzhe_HUAWEI退出third_party_vulkan-validationlayers 仓库committer。遗留问题：无。 OpenHarmony PMC 例会 2026年6月11日

1 0

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

23 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第214次会议）会议时间 Time 2026-6-23 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=460822601193&pwd=ODkxNjY1&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/460822601193/c87700d48367d20a… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：460822601193 嘉宾密码：891665 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓: applications_simtoolkits 20 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> SIG_SystemApplication 曾晶 gundamseed.zeng(a)huawei.com<mailto:gundamseed.zeng@huawei.com> 王娜 wangna32(a)huawei.com<mailto:wangna32@huawei.com> 景沪川 jinghuchuan(a)huawei.com<mailto:jinghuchuan@huawei.com> 冯勋 fengxun4(a)h-partners.com<mailto:fengxun4@h-partners.com> 2 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> 3 遗留问题闭环并申请新建sig仓： open_pdf_kit third_party_pdfium 申请开源软件独立选型： pdfium 20 罗枭鸿 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> 4 申请新建sig仓：SimCardManagement 20 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> Telephony-SIG 范云龙 fanyunlong1(a)huawei.com<mailto:fanyunlong1@huawei.com> 高红星 gaohongxing(a)huawei.com<mailto:gaohongxing@huawei.com> 陈艺 chenyi201(a)h-partners.com<mailto:chenyi201@h-partners.com> 刘荣凯 liurongkai(a)huawei.com<mailto:liurongkai@huawei.com> 沈腾 shenteng2(a)huawei.com<mailto:shenteng2@huawei.com> 5 申请新建sig仓：Tips 20 郭云峰 guoyunfeng8(a)h-partners.com<mailto:guoyunfeng8@h-partners.com> application-SIG 郭云峰 guoyunfeng8(a)h-partners.com<mailto:guoyunfeng8@h-partners.com> 雷清林 leiqinglin(a)huawei.com<mailto:leiqinglin@huawei.com> 邓奕星 dengyixing(a)huawei.com<mailto:dengyixing@huawei.com> 刘荣凯 liurongkai(a)huawei.com<mailto:liurongkai@huawei.com> 沈腾 shenteng2(a)huawei.com<mailto:shenteng2@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（第213次会议）纪要20260616
by Yangna (y) 22 Jun '26

22 Jun '26

会议主题 Subject OpenHarmony 架构SIG（第213次会议）会议时间 Time 2026-6-16 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仓：useriam_ta；申请开源引入：SeetaFace 议题2：申请新建sig仓: calendar 议题3：申请新建sig仓：applications_startup_guide 议题4：申请新建sig仓: homegraph，bjc，haptest 议题5：sig仓孵化毕业申请：xts_acts_cangjie 议题6、申请新建sig仓：open_pdf_service、third_party_pdfium；申请开源软件独立选型：pdfium 本次会议主要内容：议题1、申请新建sig仓：useriam_ta；申请开源引入：SeetaFace 汇报人：李兵会议结论： 1、同意在OpenHarmony-SIG下新建仓库security_useriam_ta，归属Security-SIG。 2、SeetaFace6算法库社区活跃度不足，建议扩大范围寻找更合适的开源库；若无合适开源引入，需说明原因再考虑可行的方案。遗留问题： 1、需要评估当前人脸认证方案的安全性，明确人脸图像采集不放到TEE侧运行的原因，如果存在硬件限制需给开发板提需求。议题2、申请新建sig仓: calendar 汇报人：黄辛未会议结论： 1、同意在OpenHarmony-SIG下新建仓库applications_calendar，归属SystemApplication-SIG。毕业时闭环如下遗留问题。遗留问题： 1、架构图需要修改：将跨模块上下文和应用内架构在一个图上呈现。 2、支持多设备形态。议题3、申请新建sig仓：applications_startup_guide 汇报人：吴堃会议结论： 1、同意在OpenHarmony-SIG下新建仓库applications_startup_guide，归属SystemApplication-SIG。遗留问题： 1、需要按照社区设计风格刷新架构图。 2、评估使用三方开源组件lottie的ROM占用，能否使用ArkUI组件替代。议题4、申请新建sig仓: homegraph，bjc，haptest 汇报人：孙波会议结论： 1、遗留问题闭环后，同意建仓。遗留问题： 1、bjc孵化目标描述清楚功能、边界。 2、haptest架构图分清自身和周边的依赖关系，bjc和输出产物report不属于本仓的范围。 3、haptest孵化目标需清晰。 4、homegraph仓库架构按流水线描述。 5、homegraph孵化目标补充清晰的功能和性能指标。议题5、sig仓孵化毕业申请：xts_acts_cangjie 汇报人：张朋生会议结论： 1、遗留问题闭环后同意毕业。遗留问题： 1、细化index.cj 等三个文件在仓颉ACTS中的具体用途。 2、用例编号编码规则需要给出详细的规则描述。议题6、申请新建sig仓：open_pdf_service、third_party_pdfium；申请开源软件独立选型：pdfium 汇报人：罗枭鸿会议结论： 1、遗留问题闭环后，再上会评审。遗留问题： 1、确认是否能够共用chromium中的pdfium组件，给出可行性分析结论。 2、PDFService模块名进行调整。 3、架构视图优化层级显示，从上至下按接口层、框架层、库进行描述。 4、孵化目标需要细化到仓库中的每一个模块。 5、pdfium的孵化目标要额外补充新增的功能和能力。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议纪要】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 架构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

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

27 Apr '26

1 0

OpenHarmony 程序分析SIG例会2026第7次会议
by xulingyun 25 Apr '26

25 Apr '26

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

1 0

【会议纪要】OpenHarmony 架构SIG（第206次会议）纪要20260421
by Yangna (y) 24 Apr '26

24 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第206次会议）会议时间 Time 2026-4-21 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仓: communication_nearlink & peripheral_nearlink 议题2：申请新建sig仓：oha_cloud 议题3：sig仓孵化毕业遗留问题澄清：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 议题4：ani_rs、napi_rs建仓申请议题5：申请毕业：third_party_vma 议题6、申请sig仓毕业：filemanagement_disk_manager 议题7、softbus-SIG：iot_connect仓遗留问题闭环毕业申请本次会议主要内容：议题1、申请新建sig仓: communication_nearlink & peripheral_nearlink 汇报人：刘兆珅会议结论： 1、闭环遗留问题1后同意在OpenHarmony-SIG下新建communication_nearlink仓。其余遗留问题毕业时闭环。遗留问题： 1、孵化目标除现有的技术功能方面的描述外，补充上次业务层面的目标。 2、备注清楚部件仅支持标准系统。 3、按照标准分层框架绘制架构图。 4、确认测试验证方案。议题2、申请新建sig仓：oha_cloud 汇报人：辛海同会议结论： 1、闭环遗留问题后再上会评审。遗留问题： 1、以社区开发者的实际开发流程分析使用平台新增能力后，对发者体验的影响。 2、补充该部件详细的测试能力，与现有测试范围的差异。 3、补充具体的精准化测试方案，测试评分方案，看板呈现内容。议题3、sig仓孵化毕业遗留问题澄清：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 汇报人：聂威会议结论： 1、同意毕业。如下遗留问题在主线持续跟踪。遗留问题： 1、性能孵化数据和性能专项owner对齐。上主线后性能专项团队给出新板卡性能基线，后续社区版本基于优化后的性能基线准出。 2、二进制文件清单以markdown文档形式归档到社区，确保满足合规要求。议题4、ani_rs、napi_rs建仓申请汇报人：华鑫会议结论： 1、完成napi_rs自研后，将napi_rs、ani_rs自研代码放到Taihe仓单独目录。 2、在OH8.0版本完成Rust后端对接Taihe，引导开发者统一使用Taihe接口，并逐步完成存量代码整改。最终目标是收编所有现有过程宏接口，仅通过Taihe暴露接口。遗留问题：无。议题5、申请毕业：third_party_vma 汇报人：吕昂会议结论： 1、遗留问题评估解决后同意毕业。遗留问题： 1、只是整改了头文件的依赖路径，没有解决重复编译和重复加载问题。 2、统一整理对相关子系统的开放接口，避免把把全量接口和实现部分全部以头文件方式引用并编译方式，通过增加独立的CPP文件引用该头文件的方式，支持部件级独立编译为shared library。议题6、申请sig仓毕业：filemanagement_disk_manager 汇报人：宁竞莜会议结论： 1、闭环遗留问题后，同意孵化毕业。遗留问题： 1、架构图中不要体现napi/taihe相关的描述，SystemApi层更换为框架层，并补充完整信息。 2、已确认社区是能够编写验证SystemApi的XTS，需要补充SystemAPI验证用例。 3、Readme.md中，补充涉及相关三方仓库的链接和依赖关系。议题7、softbus-SIG：iot_connect仓遗留问题闭环毕业申请汇报人：陈理恩会议结论： 1、闭环遗留问题后，下次评审。遗留问题： 1、在sig仓上提供从控制端到被控端完整的代码实现，配套资料，配套用例和用户开发指导。 2、版本测试用例看护与纪永对齐。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

【会议纪要】OpenHarmony 架构SIG（第205次会议）纪要20260414
by Yangna (y) 22 Apr '26

22 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第205次会议）会议时间 Time 2026-4-14 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：ani_rs、napi_rs建仓申请议题2：申请sig仓毕业：arkcompiler_taihe_ffi_gen 议题3：申请sig仓毕业：window_scene_board，window_scene_session_manager 本次会议主要内容：议题1、ani_rs、napi_rs建仓申请汇报人：华鑫会议结论： 1、遗留问题闭环后评估仓合入Taihe。遗留问题： 1、建议后续只通过Taihe暴露接口给开发者，当前存量代码需要逐步完成整改。 2、评估TPC仓和OpenHarmony仓 napi_rs的同源可行性。议题2、申请sig仓毕业：arkcompiler_taihe_ffi_gen 汇报人：王明哲会议结论： 1、闭环遗留问题后同意仓孵化毕业。遗留问题： 1、readme结构调整，根据应用开发者/应用使用者进行分类说明。 2、架构图调整，给出清晰的模块解释，上下文说明保持一致。议题3、申请sig仓毕业：window_scene_board，window_scene_session_manager 汇报人：朱孝文会议结论： 1、闭环遗留问题后再上会评审。遗留问题：按照以下格式补充仓库说明。 1、补充简介部分：补充窗口子系统的所有部件简介，描述当前部件的作用和提供的具体能力，例如窗口管理能力和屏幕管理需要进一步细化。 2、架构图完善：分层描写逻辑架构，架构图中至少包括本部件包含的模块，依赖的其他子系统的部件等；详细描述各个模块的具体职责；各模块间如何配合并依赖实现具体业务。 3、详细说明如何采用一个架构同时支持两种渲染方式，以及开发者如何进行配置。 4、SceneBoard仓库补充：结合代码和文字一起说明典型的定制方式。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

21 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第206次会议）会议时间 Time 2026-4-21 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=417321570737&pwd=MjI3Mzg3&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/417321570737/3501d627f144738b… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：417321570737 嘉宾密码：227387 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓: communication_nearlink & peripheral_nearlink 20 刘兆珅 liuzhaoshen(a)huawei.com<mailto:liuzhaoshen@huawei.com> softbus-SIG 刘兆珅 liuzhaoshen(a)huawei.com<mailto:liuzhaoshen@huawei.com> 李龙 lilong32(a)huawei.com<mailto:lilong32@huawei.com> 程国红 guohong.cheng(a)huawei.com<mailto:guohong.cheng@huawei.com> 2 申请新建sig仓：ieyes 20 辛海同 xinhaitong(a)huawei.com<mailto:xinhaitong@huawei.com> sig_test 牛国亮 niuguoliang4(a)huawei.com<mailto:niuguoliang4@huawei.com> 揣振中 chuaizhenzhong(a)huawei.com<mailto:chuaizhenzhong@huawei.com> 范伟 fanwei41(a)huawei.com<mailto:fanwei41@huawei.com> 黄国辉 huangguohui6(a)huawei.com<mailto:huangguohui6@huawei.com> 王晓辉 wangxiaohui41(a)huawei.com<mailto:wangxiaohui41@huawei.com> 3 sig仓孵化毕业遗留问题澄清： vendor/revoview/wukong100 device/board/revoview/wukong100 device/soc/unisoc/p7885 20 佘成东 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> 马玉龙 ma_yulong(a)hoperun.com<mailto:ma_yulong@hoperun.com> 4 ani_rs、napi_rs建仓申请 20 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 周紫鹏 zhouzipeng(a)huawei.com<mailto:zhouzipeng@huawei.com> 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 胡凯 hukai45(a)huawei.com<mailto:hukai45@huawei.com> 龙剑吟 longjianyin(a)h-partners.com<mailto:longjianyin@h-partners.com> 万紫璇 wanzixuan(a)huawei.com<mailto:wanzixuan@huawei.com> 5 申请毕业：third_party_vma 20 吕昂 lvang3(a)huawei.com<mailto:lvang3@huawei.com> sig_graphics 胡思宇 husiyu1(a)huawei.com<mailto:husiyu1@huawei.com> 吕昂 lvang3(a)huawei.com<mailto:lvang3@huawei.com> 杨春林 yangchunlin4(a)huawei.com<mailto:yangchunlin4@huawei.com> 6 申请sig仓毕业： filemanagement_disk_manager 20 宁竞莜 ningjingyou(a)huawei.com<mailto:ningjingyou@huawei.com> sig_kernel 王张军 wangzhangjun(a)huawei.com<mailto:wangzhangjun@huawei.com> 任广 renguang(a)huawei.com<mailto:renguang@huawei.com> 张俊杰 zhangjunjie56(a)huawei.com<mailto:zhangjunjie56@huawei.com> 宁竞莜 ningjingyou(a)huawei.com<mailto:ningjingyou@huawei.com> 7 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> 会议公告 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 arkcompiler_ets_frontend project : wangyuzhong
by dongjinguang 16 Apr '26

16 Apr '26

1 0

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

14 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第205次会议）会议时间 Time 2026-4-14 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=412438881873&pwd=MDAxMTE2&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/412438881873/e546f323d1bbffcf… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：412438881873 嘉宾密码：001116 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 ani_rs、napi_rs建仓申请 20 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 周紫鹏 zhouzipeng(a)huawei.com<mailto:zhouzipeng@huawei.com> 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 胡凯 hukai45(a)huawei.com<mailto:hukai45@huawei.com> 龙剑吟 longjianyin(a)h-partners.com<mailto:longjianyin@h-partners.com> 万紫璇 wanzixuan(a)huawei.com<mailto:wanzixuan@huawei.com> 2 申请sig仓毕业：arkcompiler_taihe_ffi_gen 25 王明哲 wangmingzhe8(a)huawei.com<mailto:wangmingzhe8@huawei.com> sig_compileruntime 王明哲 wangmingzhe8(a)huawei.com<mailto:wangmingzhe8@huawei.com> 刘潇 liuxiao78(a)huawei.com<mailto:liuxiao78@huawei.com> 万紫璇 wanzixuan(a)huawei.com<mailto:wanzixuan@huawei.com> 3 申请sig仓毕业：window_scene_board，window_scene_session_manager 25 朱孝文 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

OpenHarmony 程序分析SIG例会2026第6次会议
by xulingyun 11 Apr '26

11 Apr '26

�� Subject OpenHarmony��SIG�� 2026��6�λ��飨Sig-ProgramAnalysis Meeting�� ʱ�� Time 4/14 (�ܶ�) 19:00-20:00 (UTC+08:00)Beijing ��Ƶ�� Video Meeting Host��https://imeeting.huawei.com/meeting/startwelink?id=97426363&pwd=MTcwN… Internal��https://imeeting.huawei.com/meeting/joinwelink?id=97426363&pwd=Nj… External��https://app.huawei.com/wmeeting/join/97426363/MfD4twHUKPW3eQMEdo7… ��ID��97426363 ��룺654653 �� /�� 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

[New Committer] Welcoming to become committer of OpenHarmony's docs project : liurongrong
by dongjinguang 10 Apr '26

10 Apr '26

1 0

【会议纪要】OpenHarmony 架构SIG（第204次会议）纪要20260407
by Yangna (y) 10 Apr '26

10 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第204次会议）会议时间 Time 2026-4-7 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：申请sig仓毕业：arkcompiler_taihe_ffi_gen 议题2：申请新建sig仓：filemanagement_disk_manager 议题3：申请新建sig仓：commonlibrary_linxkit 议题4：sig仓新建仓申请：dfx_skills 议题5：busmanager_usb_manager更名以及新建仓busmanager_serial_manager申请议题6：申请新建sig仓：multidevicecompatibility_compatibility_config_center 议题7：sig仓申请孵化毕业：hiviewdfx_api_metrics 议题8：sig仓申请孵化毕业：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 本次会议主要内容：议题1、申请sig仓毕业：arkcompiler_taihe_ffi_gen 汇报人：王明哲会议结论： 1、闭环遗留问题后同意仓孵化毕业。遗留问题： 1、完善架构图和架构说明文档。 2、明确构建环境、构建流水线和构建产物。 3、优化开发者体验，避免手动文件拷贝。 4、联合 Rust 团队，沟通共仓共建可能性。议题2、申请新建sig仓：filemanagement_disk_manager 汇报人：王张军会议结论： 1、完成遗留问题1后同意在OpenHarmony-SIG下新建filemanagement_disk_manager仓，归属kernel-sig，其余遗留问题孵化毕业时需完成。遗留问题： 1、与内核sig沟通该仓的归属SIG。 2、补充开源社区架构图、修改部件的描述，展现仓库内部实现原理和能力。 3、针对涉及filemanagement相关已有部件的功能范围调整，需要同步刷新和修改。议题3、申请新建sig仓：commonlibrary_linxkit 汇报人：胡瀛会议结论： 1、完成遗留问题后同意新建sig仓。遗留问题： 1、要兼容其他芯片平台的适配。 2、梳理P7885、X86、RISCV K1/K2/K3、平头哥等芯片的加速接口可行性。 3、考虑到三方应用适配工作量，能否不新增API 情况下予以解决，需要评估一下方案的可行性。 4、部件去掉kit后缀，修改为合适的部件名，避免和开放Kit概念混淆。议题4、sig仓新建仓申请：dfx_skills 汇报人：王棪腾会议结论： 1、同意在OpenHarmony-SIG下新建developtools_dfx_skills。议题5、busmanager_usb_manager更名以及新建仓busmanager_serial_manager申请汇报人：周葛会议结论： 1、同意usb_usb_manager更名为busmanager_usb_manager。 2、同意在OpenHarmony-SIG下新建仓busmanager_serial_manager，归属drivers-sig。遗留问题： 1、 serial_manager仓库ReadMe文档说明要补充serial_manager实现通用串口方案与原本实现在usb_manager的usb转串口功能关系的架构图，与兼容性说明。 2、同步刷新usb_manager仓相关说明。议题6、申请新建sig仓：multidevicecompatibility_compatibility_config_center 汇报人：肖贵军会议结论： 1、暂不同意建仓。遗留问题： 1、继续分析系统级统一配置方案。议题7、sig仓申请孵化毕业：hiviewdfx_api_metrics 汇报人：龚飞/薛传颂会议结论： 1、闭环遗留问题后同意仓孵化毕业。遗留问题： 1、架构图更新。 2、测试用例补充打点数据持久化、可靠性的用例，同时测试用例需要基于RK3568 开发板验证。议题8、sig仓申请孵化毕业：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 汇报人：马玉龙/聂威会议结论： 1、遗留问题2、3闭环后同意毕业，其他遗留问题在主线持续跟踪。遗留问题： 1、Vulkan统一渲染、TEE特性目前调试中，跟踪4月底完成交付。 2、在社区详细说明每个二进制文件的用途，需要整改的二进制文件按在OH 7.0完成整改。 3、分析7885劣于3568性能项并与反馈测试SIG上基线的评估结论，上主线后性能专项团队给出新板卡性能基线，后续社区主线版本基于新性能基线优化准出。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

07 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第204次会议）会议时间 Time 2026-4-7 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=007505984969&pwd=NDY1MDY5&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/007505984969/aaeb23bb9286929a… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：007505984969 嘉宾密码：465069 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；井天成；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请sig仓毕业：arkcompiler_taihe_ffi_gen 30 王明哲 wangmingzhe8(a)huawei.com<mailto:wangmingzhe8@huawei.com> sig_compileruntime 王明哲 wangmingzhe8(a)huawei.com<mailto:wangmingzhe8@huawei.com> 刘潇 liuxiao78(a)huawei.com<mailto:liuxiao78@huawei.com> 万紫璇 wanzixuan(a)huawei.com<mailto:wanzixuan@huawei.com> 2 申请新建sig仓：filemanagement_disk_manager 20 王张军 wangzhangjun(a)huawei.com<mailto:wangzhangjun@huawei.com> sig_kernel 王张军 wangzhangjun(a)huawei.com<mailto:wangzhangjun@huawei.com> 任广 renguang(a)huawei.com<mailto:renguang@huawei.com> 张俊杰 zhangjunjie56(a)huawei.com<mailto:zhangjunjie56@huawei.com> 宁竞莜 ningjingyou(a)huawei.com<mailto:ningjingyou@huawei.com> 3 申请新建sig仓：commonlibrary_linxkit 20 胡瀛 roger.huying(a)hisilicon.com<mailto:roger.huying@hisilicon.com> sig_compileruntime 权建校 quanjianxiao(a)hisilicon.com<mailto:quanjianxiao@hisilicon.com> 任俊康 renjunkang(a)huawei.com<mailto:renjunkang@huawei.com> 朱俊达 zhujunda2(a)hisilicon.com<mailto:zhujunda2@hisilicon.com> 胡瀛 roger.huying(a)hisilicon.com<mailto:roger.huying@hisilicon.com> 4 sig仓新建仓申请：dfx_skills 20 刘沛 liupei.liu(a)huawei.com<mailto:liupei.liu@huawei.com> sig_basicsoftwareservice 王棪腾 wangyanteng(a)huawei.com<mailto:wangyanteng@huawei.com> 刘沛 liupei.liu(a)huawei.com<mailto:liupei.liu@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 busmanager_usb_manager更名以及新建仓busmanager_serial_manager申请 20 周葛 zhouge7(a)huawei.com<mailto:zhouge7@huawei.com> sig_driver 魏江波 weijiangbo1(a)huawei.com<mailto:weijiangbo1@huawei.com> 杨明亮 yangmingliang9(a)huawei.com<mailto:yangmingliang9@huawei.com> 赵祯 zhaozhen30(a)huawei.com<mailto:zhaozhen30@huawei.com> 周葛 zhouge7(a)huawei.com<mailto:zhouge7@huawei.com> 平先登 pingxiandeng1(a)huawei.com<mailto:pingxiandeng1@huawei.com> 6 申请新建sig仓：multidevicecompatibility_compatibility_config_center 20 肖贵军xiaoguijun(a)h-partners.com<mailto:肖贵军xiaoguijun@h-partners.com> sig_appframework 武超 wuchao106(a)huawei.com<mailto:wuchao106@huawei.com> 赵夏 zhaoxia6(a)huawei.com<mailto:zhaoxia6@huawei.com> 谭彬彬 tanbinbin(a)huawei.com<mailto:tanbinbin@huawei.com> 肖贵军 xiaoguijun(a)h-partners.com<mailto:xiaoguijun@h-partners.com> 7 sig仓申请孵化毕业：hiviewdfx_api_metrics 30 龚飞 gongfei9(a)huawei.com<mailto:gongfei9@huawei.com> 薛传颂 xuechuansong(a)huawei.com<mailto:xuechuansong@huawei.com> sig_basicsoftwareservice 龚飞 gongfei9(a)huawei.com<mailto:gongfei9@huawei.com> 薛传颂 xuechuansong(a)huawei.com<mailto:xuechuansong@huawei.com> 李开龙 likailong(a)huawei.com<mailto:likailong@huawei.com> 廖瀚文 liaohanwen4(a)huawei.com<mailto:liaohanwen4@huawei.com> 8 sig仓申请孵化毕业： vendor/revoview/wukong100 device/board/revoview/wukong100 device/soc/unisoc/p7885 佘成东 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> 马玉龙 ma_yulong(a)hoperun.com<mailto:ma_yulong@hoperun.com> 杨靖宇 jyyangdr(a)isoftstone.com<mailto:jyyangdr@isoftstone.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（第203次会议）纪要20260331
by Yangna (y) 03 Apr '26

03 Apr '26

会议主题 Subject OpenHarmony 架构SIG（第203次会议）会议时间 Time 2026-3-31 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：sig仓申请孵化毕业：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 议题2：申请在sig_basicsoftwareservice下面建立代码仓hiviewdfx_api_metrics 议题3：申请在sig_basicsoftwareservice下面建立代码仓developtools_dfx_ai 议题4：ani_rs、napi_rs建仓申请议题5：申请新建sig仓：multidevicecompatibility_compatibility_config_center 本次会议主要内容：议题1、sig仓申请孵化毕业：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 汇报人：佘成东会议结论： 1、闭环遗留问题后同意毕业。遗留问题： 1、从系统开发者视角审视并精简二进制文件，仅保留开发者可见的二进制，说明每个二进制文件的用途以及后续开源计划。 2、性能不达标项要重新测试验收，并与测试代表对齐。 3、开发者指导资料文档，要具备实际指导作用，能让普通开发者参考指导文档成功完成版本移植、版本编译、刷机启动等操作，并调研资料文档开发者的真实体验情况。议题2、申请在sig_basicsoftwareservice下面建立代码仓hiviewdfx_api_metrics 汇报人：薛传颂/龚飞会议结论： 1、闭环遗留问题后同意建仓。遗留问题： 1、开源仓内容补充API打点规范、示例代码，云侧上传数据格式和端侧适配指导等信息。 2、架构图细化本部件内部模块以及和周边部件/实体的交互关系。 3、优化写本地数据库的时机、减少对应用和整机性能的影响，同时补充数据的可靠性设计。 4、补充本地数据库的处理策略，避免长期运行后数据无限膨胀。 5、分析打点代码支持自动生成的可行性。 6、补充对廋设备的支持策略。议题3、申请在sig_basicsoftwareservice下面建立代码仓developtools_dfx_ai 汇报人：刘沛会议结论： 1、闭环遗留问题后重新上会评审。遗留问题： 1、补充部件定位问题的具体范围，是否包括系统问题和应用问题？用技术语言描述孵化目标，目标需SMART化。 2、架构图中补充skills和相关部件的关系。 3、仓库目录结构按故障类型组织skill。 4、补充skill规范说明，包括DFX故障定位格式规范、测试验证标准等。议题4、ani_rs、napi_rs建仓申请汇报人：华鑫会议结论： 1、待审视遗留问题闭环情况后再确定是否建仓。遗留问题： 1、材料补充业界实现情况，会后评估提供工具转换，避免编译过程依赖的可行性。议题5、申请新建sig仓：multidevicecompatibility_compatibility_config_center 汇报人：肖贵军会议结论： 1、闭环遗留问题后重新上会评审。遗留问题： 1、从开源社区角度进一步明确仓的定位和价值。 2、补充分层逻辑架构图，以及与相关部件如何协同。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

[compliance-sig] [会议纪要] OpenHarmony 合规SIG例会，2026/03/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京, 每两周 (周五)
by 1065338537 03 Apr '26

03 Apr '26

会议主题  Subject OpenHarmony 合规 SIG 例会 0327（Sig-compliance Meeting）会议时间  Time 2026-03-27 10:45-11:45(UTC+08:00)Beijing 视频会议  Video Meeting 会议时间：2026/03/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京点击链接入会，或添加至会议列表： https://meeting.tencent.com/dm/wtKJqhBRcwWs #腾讯会议：811-346-085 轮值主持人牛长安与会人  Attendees 合规SIG组成员会议议题 Agenda 编号 No. 议题名称 Topic 时长 Duration 起止时间 Time 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 开源软件EULA及二进制合规检测分析调研 30 min 10:45-11:15 王莹牛长安合规SIG组全体成员会议公告 Bulletins 合规SIG项目信息： https://gitee.com/openharmony/community/blob/master/sig/sig… 合规SIG议题申报：https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC   北京时间10月30日10:00前截止合规SIG重点工作协作平台：https://shimo.im/sheets/B1Aw1d18GeFygLqm/0991P 议题一：开源软件EULA及二进制合规检测分析调研，汇报人：王逸飞将该任务拆分为三个部分：辨析EULA和其它开源许可证的区别；对EULA结构化分析并总结使用场景；向OAT工具提供检测分析能力。问题和讨论：如何准确捕捉到EULA文件；如何区分和界定EULA和开源license；社区的真实具体的需求；检测方案的范围，如OAT集成、是否需要逆向、EULA分析检测范围等。遗留任务：会后讨论确认会上问题以及下一步方案和计划，责任人：于洋，彭期雄，王莹，完成时间：2026年4月10日

1 0

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

31 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第203次会议）会议时间 Time 2026-3-31 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=004741538097&pwd=NzAwMjcw&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/004741538097/2ee87d85f7d73c53… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：004741538097 嘉宾密码：700270 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 sig仓申请孵化毕业： vendor/revoview/wukong100 device/board/revoview/wukong100 device/soc/unisoc/p7885 20 佘成东 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> 马玉龙 ma_yulong(a)hoperun.com<mailto:ma_yulong@hoperun.com> 2 申请在sig_basicsoftwareservice下面建立代码仓hiviewdfx_api_metrics 20 龚飞 gongfei9(a)huawei.com<mailto:gongfei9@huawei.com> 薛传颂 xuechuansong(a)huawei.com<mailto:xuechuansong@huawei.com> sig_basicsoftwareservice 龚飞 gongfei9(a)huawei.com<mailto:gongfei9@huawei.com> 薛传颂 xuechuansong(a)huawei.com<mailto:xuechuansong@huawei.com> 李开龙 likailong(a)huawei.com<mailto:likailong@huawei.com> 廖瀚文 liaohanwen4(a)huawei.com<mailto:liaohanwen4@huawei.com> 3 申请在sig_basicsoftwareservice下面建立代码仓developtools_dfx_ai 20 刘沛 liupei.liu(a)huawei.com<mailto:liupei.liu@huawei.com> sig_basicsoftwareservice 王棪腾 wangyanteng(a)huawei.com<mailto:wangyanteng@huawei.com> 刘沛 liupei.liu(a)huawei.com<mailto:liupei.liu@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> 4 ani_rs、napi_rs建仓申请 20 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 周紫鹏 zhouzipeng(a)huawei.com<mailto:zhouzipeng@huawei.com> 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 胡凯 hukai45(a)huawei.com<mailto:hukai45@huawei.com> 龙剑吟 longjianyin(a)h-partners.com<mailto:longjianyin@h-partners.com> 5 申请新建sig仓：multidevicecompatibility_compatibility_config_center 20 肖贵军xiaoguijun(a)h-partners.com<mailto:肖贵军xiaoguijun@h-partners.com> sig_appframework 武超 wuchao106(a)huawei.com<mailto:wuchao106@huawei.com> 赵夏 zhaoxia6(a)huawei.com<mailto:zhaoxia6@huawei.com> 谭彬彬 tanbinbin(a)huawei.com<mailto:tanbinbin@huawei.com> 肖贵军 xiaoguijun(a)h-partner.com<mailto:xiaoguijun@h-partner.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 accesscontrol related project : renzehua
by dongjinguang 28 Mar '26

28 Mar '26

1 0

[New Committer] Welcoming to become committer of OpenHarmony's windows_manager project : zhaoliang
by dongjinguang 28 Mar '26

28 Mar '26

1 0

OpenHarmony 程序分析SIG例会2026第5次会议
by xulingyun 28 Mar '26

28 Mar '26

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

1 0

【请阅】OpenHarmony PMC会议（第96次会议）纪要20260326
by Yangna (y) 28 Mar '26

28 Mar '26

会议时间 2026年3月26日9:30-12:00 会议地点线上会议召集人任革林与会人员任革林、董金光、付天福、高涵一、黄然、李锋、王意明、万承臻、鲜余强、邢文华、易见、余枝强、赵文华、张小田、巴延兴、候鹏飞、庞伟；胡毕杰、吴莲、任晗、鲁玉佳、杨伟、唐春、吕彤、吴金华、杨娜会议议题编号议题名称汇报人议题参与人 1 ide-sig Leader和成员刷新唐春陈晓闯 2 申请成立HarmonyOS SDK for OpenHarmonySIG 吴金华 3 窗口管理代码库commiter权限变更胡毕杰会议纪要本次会议主要内容议题1、ide-sig Leader和成员刷新汇报人：唐春会议结论： 1、同意IDE-SIG Leader变更为唐春，同意IDE-SIG的成员变更。 2、同意刷新SIG_IDE的工作目标、工作范围。遗留问题： 1、刷新SIG工作范围，体现交付件，刷新SIG技术架构，原子化服务和底座对接。 --责任人：唐春，闭环时间：2026/3/26 2、和AI软件工程能力（SIG_AI_SWE）SIG对齐业务边界。 --责任人：唐春、王意明，闭环时间：2026/3/27 议题2、申请成立HarmonyOS SDK for OpenHarmonySIG 汇报人：吴金华会议结论： 1、完善遗留问题内容并刷新材料后再次上会评审。遗留问题： 1、SIG名称过长，需重新命名。 2、进一步清晰SIG定位，SDK支持应用端还是设备端？还是两者均支持；SDK的具体集成方法、发布流程未确定；SDK与OpenHarmony、HarmonyOS版本和API Level的配套关系未明确。 3、SDK中部分Kit涉及云侧部署，运营主体，配套云侧能力，权益以及责任方需要进一步明确。 4、建议SIG中增加几家典型应用厂商和设备厂商；当前SIG成员人数需精简。 5、与王意明沟通基础配套设施相关事宜，补齐门禁。 6、Kit XTS兼容性认证的标准，标准制定主体，认证执行主体、认证证书等进一步明确；Kit中SYSCAPS定义和设备形态的关系也需明确。 7、SDK发布的形式以及如何发布未明确，二进制还是源码形式？发布方式及与底座的配套关系如何？若采用源码形式，源码的编译主体未确定。 8、SDK与IDE的配套关系未明确，IDE是否设置SDK入口？IDE是否默认支持该SDK？以及开发者使用SDK时是手动操作还是自动适配。仿真器类似情况也要考虑。 9、SDK代码质量保障相关事宜未明确，包括已开展的测试类型、测试用例覆盖情况、是否有仿真应用验证；SDK公开可用标准。 10、建议从开发者视角完整梳理该SDK的各种典型场景，评估能力差距。议题3、窗口管理代码库commiter权限变更汇报人：胡毕杰会议结论： 1、为了业务顺利开展，临时同意王浩帆、胡毕杰为window_scene_session_manager和window_scene_board仓库committer。 2、同意刘超、叶飞、张贝贝退出window_scene_session_manager和window_scene_board仓库committer。遗留问题： 1、上述代码仓毕业时，王浩帆、胡毕杰需达到社区Committer标准。 OpenHarmony PMC例会 2026年3月26日

1 0

【会议纪要】OpenHarmony 架构SIG（第202次会议）纪要20260324
by Yangna (y) 28 Mar '26

28 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第202次会议）会议时间 Time 2026-3-24 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：opencore-amr开源软件独立选型申请议题2：gptfdisk版本火车引入改为OpenHarmony独立选型议题3：申请在sig_ide下面建立代码仓库议题4：ani_rs、napi_rs移仓申请议题5：sig仓申请孵化毕业：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 议题6：softbus-SIG：iot_connect仓遗留问题闭环毕业申请本次会议主要内容：议题1、opencore-amr开源软件独立选型申请汇报人：蔡雷会议结论： 1、闭环遗留问题后同意独立选型。（已闭环）遗留问题： 1、补充opencore-amr核心开发者的情况。闭环情况：开源作者：Martin Storsjo；国家：芬兰；组织：无组织；社区：无维护社区；代码托管：https://sourceforge.net/projects/opencore-amr/ 该项目属于Martin Storsjo个人英雄式开源项目，从AOSP的opencore媒体框架里提取AMR为独立库。议题2、gptfdisk版本火车引入改为OpenHarmony独立选型汇报人：任广会议结论： 1、不同意。遗留问题： 1、GPT fdisk开源软件近两年还有版本发布，针对风险评估不满足建议重新审视后再决策是否有必要独立选型。议题3、申请在sig_ide下面建立代码仓库汇报人：陈晓闯会议结论： 1、闭环遗留问题后同意在OpenHarmony-SIG下新建codegenie-cli、codegenie-tools、codegenie-skills代码仓，归属IDE-SIG。遗留问题： 1、刷新3个仓的职责定位，从开发者使用视角说明每个代码仓的功能，支持使用者定制。 2、定义codegenie相关规范，譬如tools、skills 代码仓分几层组织，每一层如何分类，以及构建粒度。 3、完善每个仓的架构图。议题4、ani_rs、napi_rs移仓申请汇报人：华鑫会议结论： 1、闭环如下遗留问题后上会评审。遗留问题： 1、外部应用需要用到的接口，需要通过OpenHarmony-TPC对外暴露。 2、OpenHarmony仓库中不对外暴露Rust接口，需要明确处理方式。 3、napi_rs和ani_rs在同一仓库孵化。议题5、sig仓申请孵化毕业：vendor/revoview/wukong100，device/board/revoview/wukong100，device/soc/unisoc/p7885 汇报人：佘成东会议结论： 1、闭环遗留问题后上会评审。遗留问题： 1、当前性能指标相比rk3568的提升情况给出分析解释（后续主干会基于新板卡给出指标基线，专项解决）。 2、梳理当前的二进制列表和说明。 3、未闭环问题继续跟踪闭环。议题6、softbus-SIG：iot_connect仓遗留问题闭环毕业申请汇报人：陈理恩会议结论： 1、暂不同意毕业。遗留问题： 1、补充统一互联协议标准，以及如何遵从标准。 2、从解决方案层面端到端审视方案，包括控制端，配套资料，测试用例，配套应用等。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

[compliance-sig] OpenHarmony 合规SIG例会，2026/03/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京, 每两周 (周五)
by 1065338537 26 Mar '26

26 Mar '26

欢迎参加 OpenHarmony 合规 SIG 例会会议主题  Subject OpenHarmony 合规 SIG 例会 0327（Sig-compliance Meeting）会议时间  Time 2026-03-27 10:45-11:45(UTC+08:00)Beijing 视频会议  Video Meeting 会议时间：2026/03/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京点击链接入会，或添加至会议列表： https://meeting.tencent.com/dm/wtKJqhBRcwWs #腾讯会议：811-346-085 轮值主持人周乃鑫与会人  Attendees 合规SIG组成员会议议题 Agenda 编号 No. 议题名称 Topic 时长 Duration 起止时间 Time 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 开源软件EULA及二进制合规检测分析调研 30 min 10:45-11:15 王莹牛长安合规SIG组全体成员会议公告 Bulletins 合规SIG项目信息： https://gitee.com/openharmony/community/blob/master/sig/sig… 合规SIG议题申报：https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC   北京时间10月30日10:00前截止合规SIG重点工作协作平台：https://shimo.im/sheets/B1Aw1d18GeFygLqm/0991P

1 0

【会议纪要】OpenHarmony 架构SIG（第201次会议）纪要20260317
by Yangna (y) 25 Mar '26

25 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第201次会议）会议时间 Time 2026-3-17 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：sig仓申请孵化毕业：officeservice_object_editor 议题2：仓库孵化毕业申请：window_scene_session_manager, window_scene_board 议题3：申请新建sig仓：xts_acts_cangjie 议题4：ani_rs、napi_rs移仓申请议题5：申请在sig_ide下面建立代码仓库本次会议主要内容：议题1、sig仓申请孵化毕业：officeservice_object_editor 汇报人：韦国宁会议结论： 1、遗留问题闭环后同意毕业。遗留问题：（已闭环） 1、架构图中的应用层使用“OE客户端应用”和“OE服务端应用”。 2、HMID建议修改为OHID，同步增加定义，具体作用，以及如何生成（用什么工具？）和使用，。 3、时序图增加序号，并补充相关描述，描述和图可完全匹配。议题2、仓库孵化毕业申请：window_scene_session_manager, window_scene_board 汇报人：朱孝文会议结论： 1、闭环遗留问题刷新材料后再重新上会评审。遗留问题：关于分离架构和合一架构： 1、补充说明如何通过编译开关进行架构的切换；补充架构切换后业务交互流程的变化；架构切换和日落的计划以及影响。 2、同步刷新Window_Manager等配套的仓。 3、详细说明本仓的定位和逻辑架构、相关仓如何配合完成系统业务，本仓和周边仓的关系。 4、补充SceneBoard仓的目录、开发视图以及设计和约束。在架构说明文档中补充运行、编译、部署等技术细节。 5、补充说明如何支持社区产品的定制和扩展？通过实例化进一步对定制方案（包括产品定制、特性定制）进行说明。 6、窗口+桌面的XTS的如何看护？是否涉及功能要求，例如桌面、图标、壁纸、锁屏等。议题3、申请新建sig仓：xts_acts_cangjie 汇报人：张朋生会议结论： 1、同意在OpenHarmony-SIG下新建仓xts_acts_cangjie，长期考虑针对仓颉语言的测试能力及工具的演进。遗留问题： 1、确认仓颉接口的 syscap 是否复用 ArkTS的接口，并可以复用 PCS 定义。 2、确认XTS测试套件的周边配套文件如何组织和管理。议题4、ani_rs、napi_rs移仓申请汇报人：华鑫会议结论： 1、遗留问题闭环后再次评审。遗留问题： 1、确认系统内使用napi_rs的子系统列表，以供参考。 2、确认rust语言在OpenHarmony的演进方向，分析引入的必要性。 3、分析该仓库合入taihe仓库的优劣势。 4、完善架构图，说明清楚该仓库的定位。 5、若是涉及开放napi_rs接口，建议仅对系统开放，在技术方案上做好防护，避免接口被应用开放使用，导致应用兼容性问题。议题5、申请在sig_ide下面建立代码仓库汇报人：陈晓闯会议结论： 1、遗留问题闭环刷新材料后再上会评审。遗留问题： 1、补充申请代码仓与opencode之间的逻辑关系，并说明mcp、skills等每个代码仓的定位和具体职责，规范约束。 2、参考业界优秀实践，如何进行高效运作和组织。 3、申报OH PMC会议，同步ide-sig进展以及sig成员刷新信息。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

已取消: OpenHarmony 程序分析SIG例会2026第5次会议
by xulingyun 24 Mar '26

24 Mar '26

��CCF��ӣ�3��22��̫�̣��λ��Ƴ�һ�ܡ��µĻ��֪ͨ�Ժ��ٷ� �� Subject OpenHarmony��SIG�� 2026��5�λ��飨Sig-ProgramAnalysis Meeting�� ʱ�� Time 3/24 (�ܶ�) 19:00-20:00 (UTC+08:00)Beijing ��Ƶ�� Video Meeting Host��https://imeeting.huawei.com/meeting/startwelink?id=94890056&pwd=NTMwM… Internal��https://imeeting.huawei.com/meeting/joinwelink?id=94890056&pwd=ND… External��https://app.huawei.com/wmeeting/join/94890056/XdrQCBN651Tgcx1JDnB… ��ID��94890056 ��룺488271 �� /�� 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（第202次会议），时间：2026-3-24 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 24 Mar '26

24 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第202次会议）会议时间 Time 2026-3-24 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=999910911817&pwd=Njk3NzMy&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/999910911817/dfd8d3f79d61ccac… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：999910911817 嘉宾密码：697732 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 opencore-amr开源软件独立选型申请 15 蔡雷 cailei24(a)h-partners.com<mailto:cailei24@h-partners.com> sig_media 邸佩云 dipeiyun(a)huawei.com<mailto:dipeiyun@huawei.com> 苏若炎 suruoyan1(a)huawei.com<mailto:suruoyan1@huawei.com> 2 gptfdisk版本火车引入改为OpenHarmony独立选型 15 任广 renguang(a)huawei.com<mailto:renguang@huawei.com> sig_kernel 王张军 wangzhangjun(a)huawei.com<mailto:wangzhangjun@huawei.com> 谷德贺 gudehe(a)huawei.com<mailto:gudehe@huawei.com> 张俊杰 zhangjunjie56(a)huawei.com<mailto:zhangjunjie56@huawei.com> 宁竞莜 ningjingyou(a)huawei.com<mailto:ningjingyou@huawei.com> 3 申请在sig_ide下面建立代码仓库 25 陈晓闯 chenxiaochuang(a)huawei.com<mailto:chenxiaochuang@huawei.com> sig_ide 赵文广 zhaowenguang2(a)huawei.com<mailto:zhaowenguang2@huawei.com> 欧闻 ouwen7(a)huawei.com<mailto:ouwen7@huawei.com> 4 ani_rs、napi_rs移仓申请 25 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 周紫鹏 zhouzipeng(a)huawei.com<mailto:zhouzipeng@huawei.com> 胡凯 hukai45(a)huawei.com<mailto:hukai45@huawei.com> 龙剑吟 longjianyin(a)h-partners.com<mailto:longjianyin@h-partners.com> 5 sig仓申请孵化毕业： vendor/revoview/wukong100 device/board/revoview/wukong100 device/soc/unisoc/p7885 25 佘成东 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> 马玉龙 ma_yulong(a)hoperun.com<mailto:ma_yulong@hoperun.com> 6 softbus-SIG：iot_connect仓遗留问题闭环毕业申请 25 陈理恩 chenlien(a)huawei.com<mailto:chenlien@huawei.com> sig_softbus 吕鑫 david.lv(a)huawei.com<mailto:david.lv@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第5次会议
by xulingyun 20 Mar '26

20 Mar '26

��ӭ�μ�OpenHarmony ��SIG�� [cid:image001.jpg@01DCB8A1.59BEE380] �� Subject OpenHarmony��SIG�� 2026��5�λ��飨Sig-ProgramAnalysis Meeting�� ʱ�� Time 3/24 (�ܶ�) 19:00-20:00 (UTC+08:00)Beijing ��Ƶ�� Video Meeting Host��https://imeeting.huawei.com/meeting/startwelink?id=94890056&pwd=NTMwM… Internal��https://imeeting.huawei.com/meeting/joinwelink?id=94890056&pwd=ND… External��https://app.huawei.com/wmeeting/join/94890056/XdrQCBN651Tgcx1JDnB… ��ID��94890056 ��룺488271 �� /�� 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（第201次会议），时间：2026-3-17 9:30-12:00，地点：线上会议，请您准时与会。
by Yangna (y) 17 Mar '26

17 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第201次会议）会议时间 Time 2026-3-17 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=995031567393&pwd=NTA5MDkw&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/995031567393/884731e61a12277e… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：995031567393 嘉宾密码：509090 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；杨霖；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 sig仓申请孵化毕业：officeservice_object_editor 20 韦国宁 weiguoning2(a)huawei.com<mailto:weiguoning2@huawei.com> sig_appframework 朱伟 wei.zhu(a)huawei.com<mailto:wei.zhu@huawei.com> 马文兵 mawenbing(a)huawei.com<mailto:mawenbing@huawei.com> 2 仓库孵化毕业申请：window_scene_session_manager, window_scene_board 25 朱孝文 zhuxiaowen4(a)huawei.com<mailto:zhuxiaowen4@huawei.com> sig_graphics 周耀颖 zhouyaoying(a)huawei.com<mailto:zhouyaoying@huawei.com> 沈腾 liangyong13(a)huawei.com<mailto:liangyong13@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> 3 申请新建sig仓：xts_acts_cangjie 25 张朋生 zhangpengsheng(a)huawei.com<mailto:zhangpengsheng@huawei.com> sig_test 刘天瑜 liutianyu8(a)huawei.com<mailto:liutianyu8@huawei.com> 方震 fangzhen12(a)huawei.com<mailto:fangzhen12@huawei.com> 崔腾飞 cuitengfei3(a)huawei.com<mailto:cuitengfei3@huawei.com> 4 ani_rs、napi_rs移仓申请 25 胡凯 hukai45(a)huawei.com<mailto:hukai45@huawei.com> 周紫鹏 zhouzipeng(a)huawei.com<mailto:zhouzipeng@huawei.com> 华鑫 huaxin6(a)huawei.com<mailto:huaxin6@huawei.com> 龙剑吟 longjianyin(a)h-partners.com<mailto:longjianyin@h-partners.com> 5 申请在sig_ide下面建立代码仓库 25 陈晓闯 chenxiaochuang(a)huawei.com<mailto:chenxiaochuang@huawei.com> sig_ide 胡扶同 hufutong(a)huawei.com<mailto:hufutong@huawei.com> 赵文广 zhaowenguang2(a)huawei.com<mailto:zhaowenguang2@huawei.com> 欧闻 ouwen7(a)huawei.com<mailto:ouwen7@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

[New Committer] Welcoming to become committer of OpenHarmony's multimedia_av_codec project : taihang
by dongjinguang 16 Mar '26

16 Mar '26

1 0

[New Committer] Welcoming to become committer of OpenHarmony's drivers_external_device_manager project : zhouge
by dongjinguang 16 Mar '26

16 Mar '26

1 0

【会议纪要】OpenHarmony 架构SIG（第200次会议）纪要20260310
by Yangna (y) 16 Mar '26

16 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第200次会议）会议时间 Time 2026-3-10 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：sig仓申请孵化毕业：officeservice_object_editor 议题2：仓库孵化毕业申请：third_party_xmp_toolkit_sdk 本次会议主要内容：议题1、sig仓申请孵化毕业：officeservice_object_editor 汇报人：韦国宁会议结论： 1、闭环遗留问题后同意仓库毕业。遗留问题： 1、架构图中object_editor 作为OH部件而非模块进行描述，部件包含两部分：框架层和服务层。 2、补充框架层提供的三种能力：OEExtension开发框架（用于开发OE服务端应用），客户端如何嵌入OE文档、提供其他相关接口。 3、补充说明服务层如何把相关能力串在一起，譬如如何注册、取消注册、OE运行态管理等。 4、清晰定义方案中的关键概念，以及这些概念之间的关系，并围绕这些概念逐步展，相关组件是如何配合实现方案的，以便开发者能够容易理解。 5、在文档嵌入流程中补充说明：HMID的生成和使用需要明确说明（多个服务端应用的ID不一样），包括存在多个服务端应用时如何选择哪个服务端应用打开，当不存在注册的服务端应用时如何打开。 6、时序图增加序号，并补充相关文字描述。 7、配置文件中的配置项需要明确哪些是关键配置项，如type和metadata，以及他们的作用需要详细说明，Config名称写成有差异的。 8、增加HMID说明可以复用其他系统类似技术的ID。 9、object_editor部件默认打开编译，给出开发者关闭编译选项的具体方案。 10、注册流程SA和BMS的箭头是双向，写清楚BMS从配置文件中获取哪些信息。说明BMS怎么和Object editor交互：两个接口：SA启动时会向BMS获取全量信息，应用安装或者卸载时会通过回调函数通知SA。议题2、仓库孵化毕业申请：third_party_xmp_toolkit_sdk 汇报人：鲍思源会议结论： 1、闭环遗留问题后同意仓库毕业。遗留问题： 1、架构图整改：（已闭环） a) 接口层中的Image Framework(OH API) -> ImageKit； b) 服务层改为框架层； c) 框架层中的"Media Service"可以删除； d) image_framework模块中不需要展示与XMP SDK无关的模块。 2、确认XMP SDK是否是必选特性，必选特性要在PCS中添加 (已闭环，作为imageKit的新增接口) 3、应用开发者中的接口示例，要补充具体的使用场景。（已闭环） 4、XTS用例以及XTS报告补齐（已闭环）退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

10 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第200次会议）会议时间 Time 2026-3-10 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=990216337929&pwd=NjYzODQy&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/990216337929/d137ce0cec1bf0c4… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：990216337929 嘉宾密码：663842 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；宋国雷；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 sig仓申请孵化毕业：officeservice_object_editor 30 韦国宁 weiguoning2(a)huawei.com<mailto:weiguoning2@huawei.com> sig_appframework 朱伟 wei.zhu(a)huawei.com<mailto:wei.zhu@huawei.com> 马文兵 mawenbing(a)huawei.com<mailto:mawenbing@huawei.com> 2 仓库孵化毕业申请：third_party_xmp_toolkit_sdk 30 鲍思源 baosiyuan(a)huawei.com<mailto:baosiyuan@huawei.com> sig_media 赵娜 zhaona45(a)huawei.com<mailto:zhaona45@huawei.com> 吴子琛 wuzichen3(a)h-partners.com<mailto:wuzichen3@h-partners.com> 徐理东 xulidong4(a)huawei.com<mailto:xulidong4@huawei.com> 姚星宇 yaoxingyu3(a)huawei.com<mailto:yaoxingyu3@huawei.com> 黎富民 lifumin3(a)h-partners.com<mailto:lifumin3@h-partners.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（第199次会议）纪要20260303
by Yangna (y) 09 Mar '26

09 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第199次会议）会议时间 Time 2026-3-3 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：申请新建sig仓：third_party_opencore-amr 议题2：申请新建sig仓：third_party_opus 议题3：skia依赖库独立建仓：申请新建sig仓third_party_vma、申请重新开启代码仓third_party_expat 议题4：sig仓申请孵化毕业：officeservice_object_editor 本次会议主要内容：议题1、申请新建sig仓：third_party_opencore-amr 汇报人：高梓喻会议结论： 1、闭环遗留问题1后，同意在OpenHarmony-SIG下新建third_party_opencore-amr仓。其余遗留问题毕业时闭环。遗留问题： 1、在材料中补充专利信息，OpenHarmony社区产品商业使用时是否有专利收费/纠纷问题，在材料中补充专利律师的意见。 2、分析对硬件编解码的支持。 3、该特性对于典型产品是必选还是可选特性，若为必选则需同步刷新PCS规范。 4、材料中补充上游社区情况现状，以及与AOSP的关系。议题2、申请新建sig仓：third_party_opus 汇报人：高梓喻会议结论： 1、闭环遗留问题1后，同意在OpenHarmony-SIG下新建third_party_opus仓。其余遗留问题毕业时闭环。遗留问题： 1、在材料中补充专利信息，OpenHarmony社区产品商业使用时是否有专利收费/纠纷问题，在材料中补充专利律师的意见。 2、分析对硬件编解码的支持。 3、该特性对于产品是必选还是可选特性，若为必选则需同步刷新PCS规范。 4、材料中补充上游社区情况现状，以及与AOSP的关系。议题3、skia依赖库独立建仓：申请新建sig仓third_party_vma、申请重新开启代码仓third_party_expat 汇报人：胡思宇会议结论： 1、遗留问题1闭环后同意在OpenHarmony-SIG下新建third_party_vma仓。 2、同意重启third_party_expat仓，需要单独建立分支进行孵化而后回合主干。遗留问题： 1、分别补充third_party_vma与third_party_expat的孵化目标和具体孵化内容。 2、分别梳理OH社区其它依赖vma与expat的代码仓，联合整改。议题4、sig仓申请孵化毕业：officeservice_object_editor 汇报人：韦国宁会议结论： 1、下次再上会评审。遗留问题： 1、架构图中相关术语保持一致，服务端的名称修改成ObjectEditorExtension。 2、在有多个服务端注册的时候，如何选择用哪个服务端，增加描述。 3、时序图增加序号，并补充相关描述。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

openharmony6.0下编译 hi3816出错
by 王飞翔 05 Mar '26

05 Mar '26

是不是6.0没有适配3816了？后续会继续适配吗

1 0

[New Committer] Welcoming to become committer of OpenHarmony's arkcompiler_runtime_core project : Pukhov
by dongjinguang 03 Mar '26

03 Mar '26

1 0

[New Committer] Welcoming to become committer of OpenHarmony's homecheck project : xudan
by dongjinguang 03 Mar '26

03 Mar '26

1 0

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

03 Mar '26

会议主题 Subject OpenHarmony 架构SIG（第199次会议）会议时间 Time 2026-3-3 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=985400911033&pwd=MjE4MDY2&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/985400911033/69ccc2ec728158dd… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：985400911033 嘉宾密码：218066 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；宋国雷；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 申请新建sig仓：third_party_opencore-amr 20 高梓喻gaoziyu(a)h-partners.com<mailto:高梓喻gaoziyu@h-partners.com> sig_media 苏若炎 suruoyan1(a)huawei.com<mailto:suruoyan1@huawei.com> 邸佩云 dipeiyun(a)huawei.com<mailto:dipeiyun@huawei.com> 2 申请新建sig仓：third_party_opus 20 高梓喻gaoziyu(a)h-partners.com<mailto:高梓喻gaoziyu@h-partners.com> sig_media 苏若炎 suruoyan1(a)huawei.com<mailto:suruoyan1@huawei.com> 邸佩云 dipeiyun(a)huawei.com<mailto:dipeiyun@huawei.com> 3 skia依赖库独立建仓：申请新建sig仓：third_party_vma 申请重新开启代码仓并更换committer：third_party_expat 20 胡思宇husiyu1(a)huawei.com<mailto:胡思宇husiyu1@huawei.com> sig_graphics 胡思宇 husiyu1(a)huawei.com<mailto:husiyu1@huawei.com> 胥旺 xuwang7(a)h-partners.com<mailto:xuwang7@h-partners.com> 4 sig仓申请孵化毕业：officeservice_object_editor 25 韦国宁 weiguoning2(a)huawei.com<mailto:weiguoning2@huawei.com> sig_appframework 朱伟 wei.zhu(a)huawei.com<mailto:wei.zhu@huawei.com> 马文兵 mawenbing(a)huawei.com<mailto:mawenbing@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（第198次会议）纪要20260227
by Yangna (y) 28 Feb '26

28 Feb '26

会议主题 Subject OpenHarmony 架构SIG（第198次会议）会议时间 Time 2026-2-27 9:15-10:30(UTC+08:00)Beijing 召集人 Convener 任革林与会人 Attendees 任革林，董金光，各议题汇报人等历史纪要归档路径方式1：https://gitcode.com/openharmony/community/tree/master/sig/sig_architect… 方式2：dev邮件列表纪要查询方式：https://lists.openatom.io/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：sig仓申请孵化毕业：communication_fusion_connectivity 本次会议主要内容：议题1、sig仓申请孵化毕业：communication_fusion_connectivity 汇报人：唐嘉会议结论： 1、遗留问题闭环后同意毕业。遗留问题： 1、先介绍术语概念，再描述架构图。相关术语前后一致；语句语义清晰完整，明确动作主体。 2、架构图中高亮显示本部件模块，其它部件置灰。 3、完善PartnerAgent服务动态启停的逻辑，包括如何通过系统参数控制常驻以及PartnerAgent服务卸载的具体逻辑。 4、补充伙伴设备Extension被拉起/销毁的具体时机，以及伙伴设备应用卸载后，PartnerAgent服务自动删除应用注册信息等。 5、补充多个伙伴设备应用注册同一个设备后，ParterAgent服务发现该设备连接后，拉起所有伙伴设备Extension的逻辑。 6、细化代理通知相关逻辑。 7、补充开发指南，包括系统设备开发者如何使能该部件，以及如何开发PartnerAgentExtension应用。 8、XTS用例覆盖情况需进一步评估， XTS用例覆盖完整。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

[compliance-sig] [会议纪要] OpenHarmony 合规SIG例会，2026/02/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京, 每两周 (周五)
by 1065338537 28 Feb '26

28 Feb '26

会议主题  Subject OpenHarmony 合规 SIG 例会 0227（Sig-compliance Meeting）会议时间  Time 2026-02-27 10:45-11:45(UTC+08:00)Beijing 视频会议  Video Meeting 会议时间：2026/02/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京点击链接入会，或添加至会议列表： https://meeting.tencent.com/dm/MSuyJA0aLTyM #腾讯会议：492-596-594 轮值主持人牛长安与会人  Attendees 合规SIG组成员会议议题 Agenda 编号 No. 议题名称 Topic 时长 Duration 起止时间 Time 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 6.1 Release评审 30 min 10:45-11:15 徐亮牛长安合规SIG组全体成员会议公告 Bulletins 合规SIG项目信息： https://gitee.com/openharmony/community/blob/master/sig/sig… 合规SIG议题申报：https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC 合规SIG重点工作协作平台：https://shimo.im/sheets/B1Aw1d18GeFygLqm/0991P   议题一：OpenHarmony 6.1 Release发布评审，汇报人：徐亮 6.1 Release发布前需要闭环7个FossLiscence扫描疑似问题以及1个兼容性扫描疑似问题，并在QA-SIG上审视门禁扫描问题完成闭环、Notice按照要求完成生成，版本发布后评审材料再进行归档   议题二：合规SIG 2026年规划任务同步合规SIG的检测工具都已经切换到新的数字化协作平台上，SBOM部分在进行系统调试 EULA相关的分析将通过社区共建任务的形式发布，欢迎感兴趣的老师认领合规SIG与法务工作组计划2026年联合组织下线meetup，时间明确后在合规SIG例会上讨论   遗留任务： 6.1 Release发布前完成疑似问题闭环，责任人：徐亮，完成时间：2026年2月28日 EULA分析的社区共建任务发布，责任人：于洋，完成时间：2026年2月28日

1 0

【会议通知】OpenHarmony 架构SIG（第198次会议），时间：2026-2-27 9:15-10:30，地点：线上会议，请您准时与会。
by Yangna (y) 27 Feb '26

27 Feb '26

会议主题 Subject OpenHarmony 架构SIG（第198次会议）会议时间 Time 2026-2-27 9:15-10:30(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=983085851185&pwd=ODQxMTY3&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/983085851185/fef280b2d3682cf8… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：983085851185 嘉宾密码：841167 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；宋国雷；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 communication_fusion_connectivity 仓孵化毕业申请 30 唐嘉 tangjia15(a)huawei.com<mailto:tangjia15@huawei.com> softbus-SIG 会议公告 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

[compliance-sig] OpenHarmony 合规SIG例会，2026/02/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京, 每两周 (周五)
by 1065338537 26 Feb '26

26 Feb '26

欢迎参加 OpenHarmony 合规 SIG 例会会议主题  Subject OpenHarmony 合规 SIG 例会 0227（Sig-compliance Meeting）会议时间  Time 2026-02-27 10:45-11:45(UTC+08:00)Beijing 视频会议  Video Meeting 会议时间：2026/02/27 10:45-11:45 (GMT+08:00) 中国标准时间 - 北京点击链接入会，或添加至会议列表： https://meeting.tencent.com/dm/MSuyJA0aLTyM #腾讯会议：492-596-594 轮值主持人牛长安与会人  Attendees 合规SIG组成员会议议题 Agenda 编号 No. 议题名称 Topic 时长 Duration 起止时间 Time 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 6.1 Release评审 30 min 10:45-11:15 徐亮牛长安合规SIG组全体成员会议公告 Bulletins 合规SIG项目信息： https://gitee.com/openharmony/community/blob/master/sig/sig… 合规SIG议题申报：https://shimo.im/sheets/B1Aw1d18GeFygLqm/MODOC   北京时间10月30日10:00前截止合规SIG重点工作协作平台：https://shimo.im/sheets/B1Aw1d18GeFygLqm/0991P  

1 0

【请阅】OpenHarmony PMC会议（第95次会议）纪要20260212
by Yangna (y) 14 Feb '26

14 Feb '26

会议时间 2026年2月12日9:30-12:00 会议地点线上会议召集人任革林与会人员刘果；任革林、董金光、付天福、高涵一、李锋、马耀辉、鲜余强、易见、赵文华、庞伟、巴延兴、邢文华、候鹏飞；刁猛、毛亚东、杨娜会议议题编号议题名称汇报人议题参与人 1 car-sig组织成员刷新刁猛毛亚东会议纪要本次会议主要内容议题1、car-sig组织成员刷新汇报人：刁猛会议结论： 1、同意Car Sig副组长变更为毛亚东。 2、同意Car SIG的成员变更。遗留问题： 1、加强SIG组运作；细化2026年SIG的具体目标，包括达成的效果、需要技术规格能力等。 2、继续吸纳车机产业链有意愿的伙伴加入。 OpenHarmony PMC例会 2026年2月12日

1 0

【会议纪要】OpenHarmony 架构SIG（第197次会议）纪要20260210
by Yangna (y) 14 Feb '26

14 Feb '26

会议主题 Subject OpenHarmony 架构SIG（第197次会议）会议时间 Time 2026-2-10 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：解决遗留意见后二次申请新建sig仓：vendor_radxa，device_board_radxa，device_soc_cix 议题2：仓库孵化毕业申请：third_party_xmp_toolkit_sdk 本次会议主要内容：议题1、解决遗留意见后二次申请新建sig仓：vendor_radxa，device_board_radxa，device_soc_cix 汇报人：yuan wang 会议结论： 1、闭环遗留问题后同意在OpenHarmony-SIG下新建仓vendor_radxa、device_board_radxa、device_soc_cix。遗留问题： 1、细化图形、AI和安全部分的孵化目标，体现该开发板相比其他开发板的优势、特色。 2、补充开发计划。议题2、仓库孵化毕业申请：third_party_xmp_toolkit_sdk 汇报人：徐理东会议结论： 1、遗留问题解决后再申报议题。遗留问题： 1、补充XMPFiles和XMPCore在系统的整体架构图，包含调用关系、如何对外暴露、开发者如何使用、内部子系统如何集成等信息。 2、readme要站在开发者的角度详述如何使用该能力，包括设备开发者和应用开发者分别说明。明确说明在系统的哪个仓进行适配，详细写清楚如何使用xmpsdk、何时加载so、哪个build.gn下添加依赖等；简单呈现对应用开发者的接口，示例代码细化修改。 3、xmpsdk那部分特性支持定制化，如何定制化？并补充其对三方库如何依赖系统。 4、与刘勋对齐xmpsdk能力是可选还是必选，PCS如何定义，syscap、featrues定义清楚。 5、摸测ArkTS接口与C接口性能差异。 6、优化对三方开源软件skia的依赖软件expat间接依赖、及直接依赖软件zlib依赖关系的整改，实现OH系统平台的三方开源软件归一。 7、针对bundle.json补充syscap、featrues、rom、ram字段。 8、针对具体接口补充XTS，测试图片版权、授权问题。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

[New Committer] Welcoming to become committer of OpenHarmony's accessibility project : fanzexuan
by dongjinguang 10 Feb '26

10 Feb '26

1 0

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

10 Feb '26

会议主题 Subject OpenHarmony 架构SIG（第197次会议）会议时间 Time 2026-2-10 10:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=970844686105&pwd=NDM3MDI1&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/970844686105/a4aeec117df0c8f8… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：970844686105 嘉宾密码：437025 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；宋国雷；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 解决遗留意见后二次申请新建sig仓： vendor_radxa，device_board_radxa，device_soc_cix 25 yuan wang: yuanwang.wy(a)hotmail.com<mailto:yuanwang.wy@hotmail.com> sig_arm Hejun Jun.He(a)arm.com<mailto:Jun.He@arm.com> 何佳 justin.he(a)arm.com<mailto:justin.he@arm.com> 王培瑶 peter(a)radxa.com<mailto:peter@radxa.com> Lina lina.wu(a)cixtech.com<mailto:lina.wu@cixtech.com> Jammy Jammy.zhou(a)cixtech.com<mailto:Jammy.zhou@cixtech.com> 陈景欣 chenjingxin(a)kaihong.com<mailto:chenjingxin@kaihong.com> yuan wang yuanwang.wy(a)hotmail.com<mailto:yuanwang.wy@hotmail.com> 2 仓库孵化毕业申请：third_party_xmp_toolkit_sdk 25 徐理东 xulidong4(a)huawei.com<mailto:xulidong4@huawei.com> sig_media 赵娜 zhaona45(a)huawei.com<mailto:zhaona45@huawei.com> 吴子琛 wuzichen3(a)h-partners.com<mailto:wuzichen3@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> 会议公告 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（第196次会议）纪要20260203
by Yangna (y) 06 Feb '26

06 Feb '26

会议主题 Subject OpenHarmony 架构SIG（第196次会议）会议时间 Time 2026-2-3 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 议题2：Chromium独立选型评审本次会议主要内容：议题1、仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 汇报人：王威会议结论： 1、闭环遗留问题后同意third_party_libvpx、third_party_dav1d毕业。遗留问题： 1、readme按OH默认适配工作与系统开发者典型修改场景如何适配描述，按照如下顺序做章节调整修改： a) 兼容性要求 b) OH默认适配工作 c) 系统开发者的典型场景(如修改profile) 如何适配。 2、产品默认不编译该部件，部件内的相关特性默认打开。 3、补充设备厂商如何适配支持对应硬件编辑码相关内容。议题2、Chromium独立选型评审汇报人：华梦峥会议结论： 1、遗留问题澄清后，同意独立选型。遗留问题： 1、llvm/rust作为Chromium的依赖软件与OpenHarmony系统侧选型不一致，是否会导致兼容性问题，以及工具链的适配问题。 2、洞察其他移动操作系统与Chromium的llvm/rust的配套关系。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

03 Feb '26

会议主题 Subject OpenHarmony 架构SIG（第196次会议）会议时间 Time 2026-2-3 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=965995366745&pwd=MDAxMjYx&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/965995366745/74eb896691cf2e65… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：965995366745 嘉宾密码：001261 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；宋国雷；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 30 王威 wangwei234(a)huawei.com<mailto:wangwei234@huawei.com> sig_media 邸佩云 dipeiyun(a)huawei.com<mailto:dipeiyun@huawei.com> 韩正士 hanzhengshi(a)huawei.com<mailto:hanzhengshi@huawei.com> 李林格 lilinge(a)huawei.com<mailto:lilinge@huawei.com> 李静怡 lijingyi20(a)huawei.com<mailto:lijingyi20@huawei.com> 陈阳 chenyang54(a)huawei.com<mailto:chenyang54@huawei.com> 杨昊龙 yanghaolong2(a)h-partners.com<mailto:yanghaolong2@h-partners.com> 刘鹏鹏 liupengpeng9(a)h-partners.com<mailto:liupengpeng9@h-partners.com> 2 Chromium独立选型评审 30 华梦峥 huamengzheng(a)huawei.com<mailto:huamengzheng@huawei.com> sig_web 任康 renkang2(a)huawei.com<mailto:renkang2@huawei.com> 张小田 zhangxiaotian(a)huawei.com<mailto:zhangxiaotian@huawei.com> 董金光 dongjinguang(a)huawei.com<mailto:dongjinguang@huawei.com> 宋国雷 songguolei(a)huawei.com<mailto:songguolei@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（第195次会议）纪要20260127
by Yangna (y) 31 Jan '26

31 Jan '26

会议主题 Subject OpenHarmony 架构SIG（第195次会议）会议时间 Time 2026-1-27 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：sig仓闭源库和内核审核：device/soc/unisoc/p7885 议题2：仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 本次会议主要内容：议题1、sig仓闭源库和内核审核：device/soc/unisoc/p7885 汇报人：佘成东会议结论： 1、同意当前闭源库方案。遗留问题： 1、所有涉及闭源库的bug，需要由原厂和相关维护isv进行维护和更新。 2、NPU驱动是否可以闭源，法务层面做好评估、明确结论，在6.6内核版本需要改善闭源情况。 3、涉及GPL协议相关法务问题由原厂处理。 4、二进制文件提交正式仓库时要遵从“End User License Agreement”许可协议并经过OH社区法务代表审核，确保开源社区合规授权使用。 5、内核源码获取方式，需要在开发板仓库中有明确的指示说明。 6、TEE要使能OpenHarmony社区的OpenTrust开源解决方案，去掉原有二进制部分，无需归档。议题2、仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 汇报人：王威会议结论： 1、闭环遗留问题后再重新上会。遗留问题： 1、完善相关资料说清楚系统使能AV1和VPX解码后的具体要求。 2、详细描述VPX和AV1解码对设备厂商的具体要求，并在OH社区的PCS兼容性规范中增加相关要求。 3、站在系统开发者的角度，在资料中详细说明引入三方库相关关键场景该如何适配（包含编译和代码层面）。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0

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

27 Jan '26

会议主题 Subject OpenHarmony 架构SIG（第194次会议）会议时间 Time 2026-1-20 9:30-12:00(UTC+08:00)Beijing 召集人 Convener 任革林视频会议 Video Meeting 嘉宾 (内)：https://imeeting.huawei.com/meeting/joinxy?id=956314730817&pwd=Mzg4Mzk0&… 嘉宾 (外)：https://welink.huaweicloud.com/meeting/#/j/956314730817/b4c50a3a0d54d695… （请您实名接入：公司+姓名，未实名将移出会议，感谢理解）会议ID：956314730817 嘉宾密码：388394 与会人 Attendees 任革林；董金光；万承臻；赵文华；强波；宋国雷；陶冶会议议题 Agenda 编号No. 议题名称Topic 时长Duration 汇报人Reporter 隶属SIG 议题参与人Members 1 sig仓申请孵化毕业： vendor/revoview/wukong100 device/board/revoview/wukong100 device/soc/unisoc/p7885 25 佘成东 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> 马玉龙 ma_yulong(a)hoperun.com<mailto:ma_yulong@hoperun.com> 2 仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 25 王威 wangwei234(a)huawei.com<mailto:wangwei234@huawei.com> sig_media 邸佩云 dipeiyun(a)huawei.com<mailto:dipeiyun@huawei.com> 韩正士 hanzhengshi(a)huawei.com<mailto:hanzhengshi@huawei.com> 李林格 lilinge(a)huawei.com<mailto:lilinge@huawei.com> 李静怡 lijingyi20(a)huawei.com<mailto:lijingyi20@huawei.com> 杨昊龙 yanghaolong2(a)h-partners.com<mailto:yanghaolong2@h-partners.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（第194次会议）纪要20260120
by Yangna (y) 26 Jan '26

26 Jan '26

会议主题 Subject OpenHarmony 架构SIG（第194次会议）会议时间 Time 2026-1-20 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/postorius/lists/ ，找dev->Archives，页面左侧可以按月份筛选会议议题 Agenda 议题1：sig仓申请孵化毕业：vendor/revoview/wukong100、device/board/revoview/wukong100、device/soc/unisoc/p7885 议题2：仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 议题3：新系统应用及p7885上主干策略本次会议主要内容：议题1、sig仓申请孵化毕业：vendor/revoview/wukong100、device/board/revoview/wukong100、device/soc/unisoc/p7885 汇报人：佘成东会议结论： 1、闭环遗留问题后重新上会评审。遗留问题： 1、已知的问题清零。 2、根据合入时间倒排计划，确保验证环境可部署。 3、确认其他需要配合修改的相关仓库当前的适配完成情况。 4、开发者使用p7885时如何进行开发，要有完整详细的指导说明。 5、p7885相比rk3568的性能提升在用户体验上能够同步呈现。 6、列出完整的二进制清单，评估是否符合社区的规则要求，例外情况备注原因。 7、明确OpenHarmony Linux 内核选型策略及展锐适配计划。议题2、仓库孵化毕业申请：third_party_libvpx、third_party_dav1d 汇报人：王威会议结论： 1、闭环遗留问题后重新上会评审。遗留问题： 1、在OpenHarmony的具体解码规格在readme里完整呈现 (譬如支持的profile、level等)，根据规格要求补充XTS用例。 2、bundle.json里补充rom、ram等相关信息。 3、完整描述OpenHarmony系统是如何适配这两款软件的。议题3、新系统应用及p7885上主干策略汇报人：沈腾会议结论：充分考虑对社区伙伴的可能影响，建议在以下2种策略中选其一。 1、逐步切换：新应用上线后，旧应用仍继续维护，给伙伴预留逐步切换的时间。 2、直接切换：与社区A/B/C类等伙伴逐一沟通，说明新老应用功能和对硬件要求的差异，应用切换引入的适配工作量，收集伙伴相关意见后再综合评估。遗留问题：无。退订dev邮件列表请点击https://lists.openatom.io/postorius/lists/dev.openharmony.io/，取消订阅后将收不到所有通过dev邮件列表发送的邮件，请谨慎退订！

1 0