- dev - lists.openatom.io

【会议通知】 OpenHarmony 架构SIG，时间：2021-08-20 09:10-10:30，地点：线上会议，请您准时与会：）
by hengting (A) 18 Aug '21

18 Aug '21

会议主题 Subject OpenHarmony 架构SIG 会议时间 Time 2021-08-20 09:10-10:30(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting · 加入会议 : Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=1c758b03c1974ba78fc7a8d4dab…> · Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0189538452&app=welink> · Join (External) >><https://welink.zhumu.com/j/189538452> · 会议ID : 0189538452 与会人 Attendees 万承臻；任革林；张勇智；强波；董金光外部与会人 External Participants dev(a)openharmony.io<mailto:dev@openharmony.io> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 新增Linux内核5.10仓 https://gitee.com/openharmony/kernel_linux_5.10 新增Linux内核5.10，合入社区主线 10 吴祚煜吴祚煜吴祚煜吴祚煜 2 新增ace_ets_loader和ace_js_loader仓 https://gitee.com/openharmony/ace_ets_loader https://gitee.com/openharmony/ace_js_loader 新增ets_loader和js_loader编译工具合入社区主线 10 王纯王纯王纯李洪（lihong67(a)huawei.com) 王纯（chunn.wang(a)huawei.com) 陈功平（chengongping(a)huawei.com)

1 0

OpenHarmoy PMC Biweekly Meeting Time: 2021-08-19 09:10-11:00
by hengting (A) 17 Aug '21

17 Aug '21

会议主题 Subject OpenHarmoy PMC Biweekly Meeting 会议时间 Time 2021-08-19 09:10-10:30(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting ・加入会议 : Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=67b27137f4974370b8734c2627e…> ・ Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0134638027&app=welink> ・ Join (External) >><https://welink.zhumu.com/j/134638027> ・会议ID : 0134638027 与会人 Attendees 李毅；董金光；马占福；万承臻；任革林；王意明；邢文华；肖峰；聂欣外部与会人 External Participants noel@openatom.org,kelei@iscas.ac.cn<mailto:noel@openatom.org,kelei@iscas.ac.cn> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 三方开开发板移植专项进展 1 图形、媒体、输入统一的HDI接口，隔离芯片平台内核驱动的差异，提升移植效率； 2 OpenHarmony 内核三方开发移植优化方案&进展 3 DRM驱动玻璃SOC芯片平台驱动的可行性进展 https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/message/JQRZQF… 30min 董金光专项一：候选哲专题二：李家欣专题三：陈鑫候选哲李政牛立华梁克雷刘洋 2 新增OLA sig 为OH提供基于通用标准应用层连接协议平台 10min 钟伟跃东跃东钟伟跃东黄明龙梁克雷 3 新增物流机器人os平台sig 为OH提供通用标准物流机器人OS平台 10min 孙敏刚孙敏刚孙敏刚孙敏刚黄明龙梁克雷 4 新增Taro sig 将Taro向OH平台迁移，并将Taro生态的应用提供向OH转换的能力 10min 马剑马剑马剑马剑黄明龙梁克雷 5 OpenHarmony 输入法应用开发策略输入法应用要求的专业性极强，目前仅少数商业公司具备此方面的能力，鉴于这个特点，输入法应用开源版本，建议仅做打字机功能（简单的英文、数字输入，没有中文），并以sample形式对外公布 10min 张晓伟张晓伟张晓伟张晓伟 6 编译框架整改方案汇总对现有编译框架结构进行梳理并输出一套切实可行的落地方案 30min 黄明龙梁克雷刘洋李传钊黄明龙罗未梁克雷刘洋李传钊黄明龙 7 新增工业Paas平台 SIG 为OH的工业OS提供PaaS云平台架构 5min 解伟俊解伟俊何向阳黄明龙何向阳解伟俊 8 新增教育信息化平台 SIG 为OH 教育平台提供信息化（数据采集、处理、展示等）标准 5min 解伟俊解伟俊何向阳黄明龙何向阳解伟俊 9 OpenHarmony社区文档开发&SIG Docs运作社区文档开发流程&SIG Docs运作机制 10min 杨妮 (Neen.yang(a)huawei.com<mailto:Neen.yang@huawei.com>) 杨妮杨妮刘果梁克雷黄明龙

1 0

【会议纪要】Project Management Committee Meeting 2021-07-22
by hengting (A) 16 Aug '21

16 Aug '21

Project Management Committee Meeting 2021-07-22 Attendance: The attendance have reached quorum with 7 participants in the meeting. Agenda: 1. Review the actions from last meetings 2. Review the issues and PRs from the community which need to higlight 3. Open discussion Review the actions from last meetings: Topic 1: Proposal for solution-component * The basic OS capability has not been incorporated into the openharmony project, should be embeded in the form of vendor repository. Topic 2: QEMU Progress Report * Agree to the repository of vendor_ohemu will be accepted into OpenHarmony project. Topic 3: Proposal the ark toolchain and runtime as a default runtime of OpenHarmony * Agree the proposal Topic 4: Proposal for creating blockchain sig * As a part of project of security sig Topic 5: Proposal for creating Python SIG * The code of the SIG group has been refactored and will setup in OpenHarmony SIG group. Topic 6: Proposal for creating CICD SIG * Suggest to rename as infrastructure SIG and will setup in OpenHarmony SIG group. Topic 7: Porting thirdparty devboard requirements for OpenHarmony * It is tracked by some special issue. Topic 8: Proposal for creating Linkboy sig * Agree the proposal and establish education sig. Review the issues and PRs from the community which need to higlight Open discussion From: hengting (A) Sent: Wednesday, July 21, 2021 11:45 AM To: dongjinguang <dongjinguang(a)huawei.com<mailto:dongjinguang@huawei.com>>; Liyi (Nicholas, Software Engineering Device OS Dept) <nicholas.li(a)huawei.com<mailto:nicholas.li@huawei.com>>; Futianfu (FU Tianfu, CBG) <futianfu(a)huawei.com<mailto:futianfu@huawei.com>>; Mazhanfu <mazhanfu(a)huawei.com<mailto:mazhanfu@huawei.com>>; wanchengzhen <wanchengzhen(a)huawei.com<mailto:wanchengzhen@huawei.com>>; Rengelin <rengelin(a)huawei.com<mailto:rengelin@huawei.com>>; Wangyiming (Youthdragon) <youthdragon.wangyiming(a)huawei.com<mailto:youthdragon.wangyiming@huawei.com>>; Xingwenhua <xw.hua(a)huawei.com<mailto:xw.hua@huawei.com>>; Xiaofeng (Blue) <blue.xiaofeng(a)huawei.com<mailto:blue.xiaofeng@huawei.com>>; Niexin (A) <niexin.nie(a)huawei.com<mailto:niexin.nie@huawei.com>>; Litao (Tom) <litao33(a)huawei.com<mailto:litao33@huawei.com>>; wanchengzhen <wanchengzhen(a)huawei.com<mailto:wanchengzhen@huawei.com>>; Likailong (kkup, Development Dept Seven of Device OS) <likailong(a)huawei.com<mailto:likailong@huawei.com>>; maguangyao <maguangyao(a)huawei.com<mailto:maguangyao@huawei.com>>; laokz(a)foxmail.com<mailto:laokz@foxmail.com>; zhushengle <zhushengle(a)huawei.com<mailto:zhushengle@huawei.com>>; zuoyl(a)neusoft.com<mailto:zuoyl@neusoft.com>; baineng(a)digitalchina.com<mailto:baineng@digitalchina.com>; jianghan (A) <jianghan2(a)huawei.com<mailto:jianghan2@huawei.com>>; gongjunsong <gongjunsong(a)huawei.com<mailto:gongjunsong@huawei.com>>; minglong(a)iscas.ac.cn<mailto:minglong@iscas.ac.cn>; Lizhiqi (OS) <lizhiqi1(a)huawei.com<mailto:lizhiqi1@huawei.com>>; liuyuehua (A) <liuyuehua1(a)huawei.com<mailto:liuyuehua1@huawei.com>>; Houpengfei (A) <pengfei.hou(a)huawei.com<mailto:pengfei.hou@huawei.com>>; Houxuanzhe (George) <houxuanzhe(a)huawei.com<mailto:houxuanzhe@huawei.com>>; Yinyouzhan <yinyouzhan(a)huawei.com<mailto:yinyouzhan@huawei.com>>; Xuwenfang <xuwenfang(a)huawei.com<mailto:xuwenfang@huawei.com>>; 910360201(a)QQ.COM<mailto:910360201@QQ.COM> Cc: Xieyan (E) <xieyan20(a)huawei.com<mailto:xieyan20@huawei.com>>; Liyi (Nicholas, Software Engineering Device OS Dept) <nicholas.li(a)huawei.com<mailto:nicholas.li@huawei.com>>; Chenjian (Jeffrey, Chen) <Thor.chen(a)huawei.com<mailto:Thor.chen@huawei.com>>; Daizhicheng <daizhicheng(a)huawei.com<mailto:daizhicheng@huawei.com>>; gaoquan 00222800 <gaoquan(a)huawei.com<mailto:gaoquan@huawei.com>>; huangqing (I) <huangqing14(a)huawei.com<mailto:huangqing14@huawei.com>>; Liuying (Loewe) <loewe.liu(a)huawei.com<mailto:loewe.liu@huawei.com>>; Wangchangliang (A) <austin.wang(a)huawei.com<mailto:austin.wang@huawei.com>>; xianyuqiang <xianyuqiang(a)huawei.com<mailto:xianyuqiang@huawei.com>>; Zhongxiaofei (Device OS) <zhongxiaofei(a)huawei.com<mailto:zhongxiaofei@huawei.com>>; Zhushuang(Walker,CBG R&D) <zhushuang(a)huawei.com<mailto:zhushuang@huawei.com>>; Chencheng (J) <beyond.chen(a)huawei.com<mailto:beyond.chen@huawei.com>>; Chenfeng (Scott) <chenfeng469(a)huawei.com<mailto:chenfeng469@huawei.com>>; Chengguohong (guohong) <guohong.cheng(a)huawei.com<mailto:guohong.cheng@huawei.com>>; Gongashi <gongashi(a)huawei.com<mailto:gongashi@huawei.com>>; Guojinwei <guojinwei(a)huawei.com<mailto:guojinwei@huawei.com>>; Houpengfei (A) <pengfei.hou(a)huawei.com<mailto:pengfei.hou@huawei.com>>; Houweibo <houweibo(a)huawei.com<mailto:houweibo@huawei.com>>; Huanghuijin <huanghuijin(a)huawei.com<mailto:huanghuijin@huawei.com>>; Ligang (william) <william.ligang(a)huawei.com<mailto:william.ligang@huawei.com>>; Lijiaxin (Nina Li) <nina.lijiaxin(a)huawei.com<mailto:nina.lijiaxin@huawei.com>>; liyu (M) <liyu1(a)huawei.com<mailto:liyu1@huawei.com>>; Niuhui <niuhui(a)huawei.com<mailto:niuhui@huawei.com>>; Qiangbo(Paul,Device OS) <qiangbo2(a)huawei.com<mailto:qiangbo2@huawei.com>>; tanliwen (A) <tanliwen1(a)huawei.com<mailto:tanliwen1@huawei.com>>; Wangjun (iov) <wangjun145(a)huawei.com<mailto:wangjun145@huawei.com>>; Wangjuntao (Pis, OS) <wangjuntao.wang(a)huawei.com<mailto:wangjuntao.wang@huawei.com>>; Wangmihu <wangmihu(a)huawei.com<mailto:wangmihu@huawei.com>>; Wangxiangyang (Walton) <walton.wang(a)huawei.com<mailto:walton.wang@huawei.com>>; Wangxing (Raymond) <raymond.wangxing(a)huawei.com<mailto:raymond.wangxing@huawei.com>>; Wangzaishang <wangzaishang(a)huawei.com<mailto:wangzaishang@huawei.com>>; Yangni (A) <neen.yang(a)huawei.com<mailto:neen.yang@huawei.com>>; Yanyongjie <yongjie.yan(a)huawei.com<mailto:yongjie.yan@huawei.com>>; dev(a)openharmony.io<mailto:dev@openharmony.io> Subject: 【会议通知】 OpenHarmoy PMC Biweekly Meeting，时间：2021-07-22 14:30-16:00，地点：线上会议，请您准时与会：）会议主题 Subject OpenHarmoy PMC Biweekly Meeting 会议时间 Time 2021-07-22 14:30-16:00(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting 加入会议 : Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=99f8191480664ab09125863680d…> Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0156054198&app=welink> Join (External) >><https://welink.zhumu.com/j/156054198> 会议ID : 015 605 419 8 与会人 Attendees 李毅；董金光；马占福；万承臻；任革林；王意明；邢文华；肖峰；聂欣外部与会人 External Participants noel@openatom.org,kelei@iscas.ac.cn<mailto:noel@openatom.org,kelei@iscas.ac.cn> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 OpenHamony社区状态审视 20min 董金光邢文华邢文华 2 申请新增SIG：solution-component 将尚未收编到openharmony社区的一些OS公共基础能力通过SIG孵化，更方便快捷去支持南向生态拓展。 15min 李涛李涛李涛李涛、万承臻 3 qemu进展汇报 qemu标准化编译 qemu加入门禁 qemu图形显示和鼠标键盘输入 15min 李开龙李开龙马广耀张凯、朱生乐、马广耀、左永亮柏能 4 方舟JS/TS部分作为OpenHarmony的JS/TS语言编译工具链和运行时子系统开源 1）提供JS/TS编译工具链 2）提供JS语言运行时 15min 蒋晗蒋晗蒋晗龚俊松 5 新增blockchain sig 增加OH区块链功能拓展 5min 尚璇尚璇尚璇尚璇 6 新增python sig 为OH增加python样例 5min 唐佐林唐佐林唐佐林唐佐林 7 新增cicd sig OpenHarmony的CICD能力提升与改进 5min 梁克雷梁克雷梁克雷梁克雷/黄明龙 8 L2对Linux需求讨论L2对Linux的基础需求，便于三方芯片厂家接入 15min 梁克雷梁克雷梁克雷梁克雷、李之琦刘跃华、侯鹏飞候选哲、尹友展徐文方 9 新增 Linkboy sig 为OpenHarmony提供可视化编程能力 5min 王强王强王强王强

1 0

OpenHarmoy PMC Biweekly Meeting Time: 2021-08-19 09:00-11:00
by hengting (A) 16 Aug '21

16 Aug '21

会议主题 Subject OpenHarmoy PMC Biweekly Meeting 会议时间 Time 2021-08-19 09:10-10:30(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting ・加入会议 : Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=67b27137f4974370b8734c2627e…> ・ Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0134638027&app=welink> ・ Join (External) >><https://welink.zhumu.com/j/134638027> ・会议ID : 0134638027 与会人 Attendees 李毅；董金光；马占福；万承臻；任革林；王意明；邢文华；肖峰；聂欣外部与会人 External Participants noel@openatom.org,kelei@iscas.ac.cn<mailto:noel@openatom.org,kelei@iscas.ac.cn> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 三方开开发板移植专项进展 1 图形、媒体、输入统一的HDI接口，隔离芯片平台内核驱动的差异，提升移植效率； 2 OpenHarmony 内核三方开发移植优化方案&进展 3 DRM驱动玻璃SOC芯片平台驱动的可行性进展 https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/message/JQRZQF… 30min 董金光专项一：候选哲专题二：李家欣专题三：陈鑫候选哲李政牛立华梁克雷刘洋 2 新增OLA sig 为OH提供基于通用标准应用层连接协议平台 10min 钟伟跃东跃东钟伟跃东黄明龙梁克雷 3 新增物流机器人os平台sig 为OH提供通用标准物流机器人OS平台 10min 孙敏刚孙敏刚孙敏刚孙敏刚黄明龙梁克雷 4 新增Taro sig 将Taro向OH平台迁移，并将Taro生态的应用提供向OH转换的能力 10min 马剑马剑马剑马剑黄明龙梁克雷 5 OpenHarmony 输入法应用开发策略输入法应用要求的专业性极强，目前仅少数商业公司具备此方面的能力，鉴于这个特点，输入法应用开源版本，建议仅做打字机功能（简单的英文、数字输入，没有中文），并以sample形式对外公布 10min 张晓伟张晓伟张晓伟张晓伟

1 0

OpenHarmoy PMC Biweekly Meeting Time: 2021-08-19 09:00-11:00
by hengting (A) 16 Aug '21

16 Aug '21

会议主题 Subject OpenHarmoy PMC Biweekly Meeting 会议时间 Time 2021-08-19 09:10-10:30(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting · 加入会议 : Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=67b27137f4974370b8734c2627e…> · Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0134638027&app=welink> · Join (External) >><https://welink.zhumu.com/j/134638027> · 会议ID : 0134638027 与会人 Attendees 李毅；董金光；马占福；万承臻；任革林；王意明；邢文华；肖峰；聂欣外部与会人 External Participants noel@openatom.org,kelei@iscas.ac.cn<mailto:noel@openatom.org,kelei@iscas.ac.cn> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 三方开开发板移植专项进展 1 图形、媒体、输入统一的HDI接口，隔离芯片平台内核驱动的差异，提升移植效率； 2 OpenHarmony 内核三方开发移植优化方案&进展 3 DRM驱动玻璃SOC芯片平台驱动的可行性进展 https://lists.openatom.io/hyperkitty/list/dev@openharmony.io/message/JQRZQF… 30min 董金光专项一：候选哲专题二：李家欣专题三：陈鑫候选哲李政牛立华梁克雷刘洋 2 新增OLA sig 为OH提供基于通用标准应用层连接协议平台 10min 钟伟跃东跃东钟伟跃东黄明龙梁克雷 3 新增物流机器人os平台sig 为OH提供通用标准物流机器人OS平台 10min 孙敏刚孙敏刚孙敏刚孙敏刚黄明龙梁克雷 4 新增Taro sig 将Taro向OH平台迁移，并将Taro生态的应用提供向OH转换的能力 10min 马剑马剑马剑马剑黄明龙梁克雷 5 OpenHarmony 输入法应用开发策略输入法应用要求的专业性极强，目前仅少数商业公司具备此方面的能力，鉴于这个特点，输入法应用开源版本，建议仅做打字机功能（简单的英文、数字输入，没有中文），并以sample形式对外公布 10min 张晓伟张晓伟张晓伟张晓伟

1 0

SIG-MiniBlink（申请新建SIG）
by 马铁 15 Aug '21

15 Aug '21

SIG组工作目标和范围工作目标打造一款多平台，高精简的H5渲染内核组件工作范围 H5渲染内核代码仓代码仓地址： MiniBlink：https://gitee.com/weolar_admin/miniblink57 SIG组成员 Leader @码云账号(https://gitee.com/weolar) @码云账号(https://gitee.com/ampereufo) Committers列表暂无会议会议时间：2021-08-20（目前是独立开发者，大部分时间都比较自由，随时可以会议）会议申报：会议链接：会议通知：会议纪要：联系方式(可选) 王斌：QQ：93527630、手机/微信：13714449252 马铁：QQ：17136608、手机/微信：13726276317

1 0

尝试编译arm
by 962030＠qq.com 15 Aug '21

15 Aug '21

各位，昨天今天尝试编译ohos-arm64，编译不过，碰到的主要问题是-Wall -Werror导致的一些Warning被当作错误。仔细看挡住的这些Warning，基本上都是从32切到64以后，long的范围变化导致的。在64位系统下，int为了与之前的兼容，仍占4字节32位，而long被扩展到了8字节64位。如下面的例子： /foundation/communication/wifi/services/wifi_standard/wifi_framework/wifi_manage/idl_client/wifi_idl_client.cpp:879:41: warning: format specifies type 'int' but the argument has type 'std::__h::vector<int, std::__h::allocator<int> >::size_type' (aka 'unsigned long') [-Wformat] LOGD("start GetChipIds %{public}d", ids.size()); /* fixed compile error, -Werror,-Wunused-parameter */ ~~~~~~~~~~ ^~~~~~~~~~ %lu 解决办法有两个：1、改代码，消除Warning；2、改编译选项，压制相关的Warning。尝试了一下，都有点行不通，改代码，地方太多了，而且也不知道怎么改好，大的改小了还是小的改大了。改编译选项，本来以为在\build\config\compiler\BUILD.gn中加入-Wno-error=format即可，但是实际上不行。整个编译构建体系，不知道哪个小可爱在后面又加入了-Wall -Werror，如下图：这种搞法真的是让人无所适从。李传钊 962030(a)qq.com

1 0

OpenHarmony 架构SIG 会议纪要
by minglong 14 Aug '21

14 Aug '21

会议主题 Subject OpenHarmony 架构SIG 会议时间 Time 2021-08-11 14:15-15:30(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting Join Conference Join (Host) >> Join (Internal) >> Join (External) >> Meeting ID 0137362574 与会人 Attendees 万承臻；任革林；张勇智；强波；董金光外部与会人 External Participants dev(a)openharmony.io 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 新增 workscheduler和backgroundtask manager 仓 "https://gitee.com/openharmony/resourceschedule_workscheduler", "https://gitee.com/openharmony/resourceschedule_backgroundtaskmanager" 在开源社区启动backgrundtask manager和workscheduler的开发，需要新增两个仓，该仓属于资源调度子系统resourceschedule 10 wanghui hujun hujun hujun 2 新增ipc_auth仓 https://gitee.com/openharmony/ipc_auth permission功能已经交接给安工部门，ipc_auth功能属于轻鸿蒙，因此需要挪出来单独建仓 10 蒋晓峰/00421855 江丽丽/00291086 江丽丽/00291086 江丽丽/00291086 蒋晓峰/00421855 3 新增DLLite-Micro仓 https://gitee.com/openharmony/dllite_micro DLLite-Micro sig孵化毕业，合入主线 10 施裕瀚施裕瀚施裕瀚施裕瀚黄明龙梁克雷 4 小熊派代码合入主线评审 https://gitee.com/openharmony/vendor_bearpi https://gitee.com/openharmony/applications_sample_bearpi_hm_nano https://gitee.com/openharmony/device_bearpi_bearpi_hm_nano 小熊派代码合入主线评审 10 王城王城王城王城黄明龙梁克雷 5 新增三方厂商的sig仓库 device_asrmicro: asr三方单板sdk的仓库 vendor_beken：博通集成，黑蜂智造智能采耳棒产品 vendor_bouffalolab: 博流产品连接类模组格兰仕/九阳/格力 vendor_bestechnic: 恒玄产品连接类模组、语音、显示图形华为xxx产品 vendor_ingenic: 君正产品万研通词典笔 vendor_allwinner: 全志产品讯飞录音笔 vendor_asrmicro: asr 连接类模组美的家居 vendor_winnermicro: 联盛德连接类模组美的家居生态产品拓展，三方芯片厂商在openharmony-sig下建仓 10 李开龙李开龙蔡俊蔡俊李开龙刘洋李凯关浔陈俊（BES）邱东升（君正）赵安璞（博流）刘大伟（ASR）（全志）（联盛德）（博通集成）议题决议如下: 1. 新增 workscheduler和backgroundtask manager 仓议题人没有上会。作为遗留问题。 2. 新增ipc_auth仓背景如下：permission 仓下有ipc_auth 鉴权能力，但是permission功能已经交接给安工部门，ipc_auth功能还未交接出，其功能属于轻鸿蒙，因此需要将ipc_auth仓挪出来到security仓下，与permission仓平级目录，申请单独建仓。 -permission下有两个功能，一个为ipc鉴权（看通信时是否有访问权限），一个是应用的权限鉴定（该功能已经交接给安工部了） -安工部反馈ipc_auth 不应该放在permission仓下，应属于security子集功能，会影响其permission仓的更新和维护，因此申请将ipc_auth 功能仓转出到security子仓下，新建仓ipc_auth，与permission同级目录 -具体permission架构如下： -应用权限管理主要是对应用在其配置表中的权限进行持久化存储和管理，提供应用申请和取消服务等 -ipc 鉴权通信不仅仅应用于应用程序，包括整个系统运行过程中所有的bundle通信，以ipc通信方式进行通讯的都需要经过ipc鉴权管理，在L1 上部分替代SE Linux功能，在L2上没有此功能 -对外提供的接口不会有变化，唯一变化的是内部系统服务在配置，目录地址会变化。因为轻设备没有单独编译的模块的sdk这一级，所以在使用时直接引入 ipc头文件，如果做了inner scq就没有上述问题 -如果做上述修改，其他子系统都需要根据修改做对应的修改（主要是系统服务相关的目录结构要改变），目前libspace无变化，只是目录路径发生变化 -想要移仓的主要是因为目前permission仓的功能和ipc_auth仓功能进行了拆分，permission仓交接给安工部，ipc_auth仓与安工部的permission仓耦合在一起，不易于后续的维护 -不建议现在进行整改 -下周与安工部会议统一对齐后，再进行探讨 -inner SDK 统一部署后 -目前整改与否对主线影响不大。等上述事项完成后，再进行整改 3. 新增DLLite-Micro仓 -之前已经与架构成员完成评审，此议题关闭 4. 小熊派代码合入主线评审 -一共需要新建三个仓 https://gitee.com/openharmony/vendor_bearpi https://gitee.com/openharmony/applications_sample_bearpi_hm_nano https://gitee.com/openharmony/device_bearpi_bearpi_hm_nano -另外还需要引入两个三方仓，将会以外链加patch的形式进行引入 Chipset -|hisilicon -|xxx Device (目录放板级和芯片) -board -|bearpi -|st -|hispark -qemu 按照上述文档进行整改 -后续需要解决的问题是，各自的非官方开发板引入主仓后需要各自负责人定期维护 -整改的方向明确，整体代码的具体整改以渐进的方式进行（先新建一套新的目录结构，逐渐替换现有目录结构的方式进行） 5. 新增三方厂商的sig仓库 - device_asrmicro: asr三方单板sdk的仓库 - vendor_beken：博通集成，黑蜂智造智能采耳棒产品 - vendor_bouffalolab: 博流产品连接类模组格兰仕/九阳/格力 - vendor_bestechnic: 恒玄产品连接类模组、语音、显示图形华为xxx产品 - vendor_ingenic: 君正产品万研通词典笔 - vendor_allwinner: 全志产品讯飞录音笔 - vendor_asrmicro: asr 连接类模组美的家居 - vendor_winnermicro: 联盛德连接类模组美的家居 -所有仓，对应的device仓已经建立 -所有仓的vendor device仓都由各自厂商提供并提供代码 -编译的工具链都是厂家子集提供 -先在sig仓建立，后续要求跟今天目录结构整改保持一致，以保证后续整改一致 -后续所有芯片级别的建仓按照今天的情况进行汇总并汇报一下 -开发者 Nagesh 希望贡献 Arduino Nano 33 BLE 开发板后续由社区负责对接，目前已经加入zulip，持续跟进其工作进度。

1 0

Proposal to add New MCU hardware support for OpenHarmony
by Nagesh shamnur 13 Aug '21

13 Aug '21

Dear OpenHarmony PMC, This mail is to propose adding new hardware such as Arduino Nano 33 BLE as supported MCU for OpenHarmony which is targeted for L0-L1 devices. Detailed information about the proposal I have added in the attached .md file. I am sending this mail after having an initial discussion with likailong (likailong(a)huawei.com<mailto:likailong@huawei.com>) over the welink messaging. Looking forward for the meeting to present the proposal in the upcoming meeting. Regards, Nagesh.

2 1

[SIG-Charter-Proposal-Telephony]
by zhf 12 Aug '21

12 Aug '21

SIG-Telephony SIG组工作目标和范围工作目标电话服务子系统开源贡献工作范围电话服务子系统开源贡献，包含搜网、卡、通话、短彩信、数据业务等代码仓代码仓地址：当前已存在的核心服务：https://gitee.com/openharmony/telephony_core_service 蜂窝通话：https://gitee.com/openharmony/telephony_cellular_call 通话管理：https://gitee.com/openharmony/telephony_call_manager 注册服务：https://gitee.com/openharmony/telephony_state_registry 短彩信：https://gitee.com/openharmony/telephony_sms_mms 本次新增 ril：https://gitee.com/openharmony/telephony_ril_adapter 数据业务：https://gitee.com/openharmony/telephony_cellular_data 网络管理：https://gitee.com/openharmony/communication_netmanager_standard Leader @码云账号(https://gitee.com/zhang-hai-feng) Committers列表 @码云账号 https://gitee.com/zhang-hai-feng https://gitee.com/jyh926 会议会议时间：每周四例行会议申报：可参考PMC例会申请方式，提供石墨共享文档链接，便于SIG相关申报人自行申请议题会议链接: Welink或其他会议会议通知: 请订阅邮件列表 dev(a)openharmony.xn--io -q31m340b7l6b1o6eowvavz3a 会议纪要: 归档链接地址联系方式(可选)

1 0

Re: 鸿蒙OS 适配RK3399 的SDK 有正式释放的版本吗
by minglong 11 Aug '21

11 Aug '21

您好。目前OpenHarmony在适配RK3399 芯片。等适配完成后，会将手册及代码开源。欢迎加入zulip 参与我们讨论。 https://zulip.openharmony.cn/join/yd44lblwyoe64hyvljomyisf/ On Aug 11, 2021 14:25，qinfanzhong@jlinksz.com<qinfanzhong(a)jlinksz.com> wrote：各位，请教下，鸿蒙OS 适配RK3399 的SDK 有正式释放的版本吗，谁了解这方面信息的，能分享下吗？ qinfanzhong(a)jlinksz.com 覃凡忠 13631628245 深圳市瑞拓创展科技有限公司深圳市南山区西丽平山一路南山云谷二期14栋6楼602

1 0

升级到鸿蒙系统以后，USB摄像头设备无法识别
by 付丙瑞 11 Aug '21

11 Aug '21

我的P40 Pro手机，更新到鸿蒙系统以后，就识别不到USB摄像头了。另外，其他的手机比如MATE30也有同样的问题。我是通过android app程序来监控摄像头插拔的，但是升级到鸿蒙以后，就无法监控了。 -- -- 致礼 13636683506

4 3

Re: 回复：企业如何参与到RK3399的适配工作
by qinfanzhong＠jlinksz.com 10 Aug '21

10 Aug '21

xzmu和xiaofan，请问下，目前RK3399 适配鸿蒙系统的进度如何？是否可以share进度。 qinfanzhong(a)jlinksz.com 覃凡忠 13631628245 深圳市瑞拓创展科技有限公司深圳市南山区西丽平山一路南山云谷二期14栋6楼602 发件人： ‪noel@openatom.org‬ 发送时间： 2021-06-26 17:21 收件人： SM0387; dongjinguang(a)huawei.com; 梁克雷; 谭小凡抄送： dev(a)openharmony.io 主题： [Dev] 回复：企业如何参与到RK3399的适配工作非常感谢上海商米的同事 OH社区非常希望您这样的团队加入。目前3399的移植是由xzmu@openatom.org，xiaofan@iscas.ac.cn 在推进，请xzmu和xiaofan将上海商米的同事的力量整合起来发自手机 -------- 原始邮件 -------- 发件人： SM0387 <liyang(a)sunmi.com> 日期： 2021年6月24日周四上午10:52 收件人： dongjinguang(a)huawei.com 抄送： dev(a)openharmony.io 主题： [Dev] 企业如何参与到RK3399的适配工作您好, 我们是来自上海的一家企业: 上海商米科技集团股份有限公司, 我们致力于为商用领域提供丰富且优秀的智能IoT硬件及软硬结合的数字化解决方案. 我们的官网: https://www.sunmi.com/index 目前我们在进行Harmony的技术预研, 后续我们希望部分产品可以使用 Harmony OS. 我们从网上了解到 FireFly 在进行 RK3399的移植工作, 并且我们内部也有RK3399的量产项目, 我们团队拥有丰富的软硬件开发能力. 请问, 如何参与到 Harmony 的 RK3399 的移植项目? 李阳 15221450901 上海商米科技集团股份有限公司

1 0

【会议通知】 OpenHarmony 架构SIG，时间：2021-08-11 14:15-15:30，地点：线上会议，请您准时与会：）
by hengting (A) 10 Aug '21

10 Aug '21

会议主题 Subject OpenHarmony 架构SIG 会议时间 Time 2021-08-11 14:15-15:30(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting Join Conference Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=b6c902bf4bb24971ac35ee0b84c…> Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0137362574&app=welink> Join (External) >><https://welink.zhumu.com/j/137362574> Meeting ID 0137362574 与会人 Attendees 万承臻；任革林；张勇智；强波；董金光外部与会人 External Participants dev(a)openharmony.io<mailto:dev@openharmony.io> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 新增 workscheduler和backgroundtask manager 仓 "https://gitee.com/openharmony/resourceschedule_workscheduler", "https://gitee.com/openharmony/resourceschedule_backgroundtaskmanager" 在开源社区启动backgrundtask manager和workscheduler的开发，需要新增两个仓，该仓属于资源调度子系统resourceschedule 10 wanghui hujun hujun hujun 2 新增ipc_auth仓 https://gitee.com/openharmony/ipc_auth permission功能已经交接给安工部门，ipc_auth功能属于轻鸿蒙，因此需要挪出来单独建仓 10 蒋晓峰/00421855 江丽丽/00291086 江丽丽/00291086 江丽丽/00291086 蒋晓峰/00421855 3 新增DLLite-Micro仓 https://gitee.com/openharmony/dllite_micro DLLite-Micro sig孵化毕业，合入主线 10 施裕瀚施裕瀚施裕瀚施裕瀚黄明龙梁克雷 4 小熊派代码合入主线评审 https://gitee.com/openharmony/vendor_bearpi https://gitee.com/openharmony/applications_sample_bearpi_hm_nano https://gitee.com/openharmony/device_bearpi_bearpi_hm_nano 小熊派代码合入主线评审 10 王城王城王城王城黄明龙梁克雷 5 新增三方厂商的sig仓库 device_asrmicro: asr三方单板sdk的仓库 vendor_beken：博通集成，黑蜂智造智能采耳棒产品 vendor_bouffalolab: 博流产品连接类模组格兰仕/九阳/格力 vendor_bestechnic: 恒玄产品连接类模组、语音、显示图形华为xxx产品 vendor_ingenic: 君正产品万研通词典笔 vendor_allwinner: 全志产品讯飞录音笔 vendor_asrmicro: asr 连接类模组美的家居 vendor_winnermicro: 联盛德连接类模组美的家居生态产品拓展，三方芯片厂商在openharmony-sig下建仓 10 李开龙李开龙蔡俊蔡俊李开龙刘洋李凯关浔陈俊（BES）邱东升（君正）赵安璞（博流）刘大伟（ASR）（全志）（联盛德）（博通集成）

1 0

文档图片404
by Paddy 06 Aug '21

06 Aug '21

3 2

请反馈会议纪要//RE: 【会议通知】 OpenHarmoy PMC Biweekly Meeting，时间：2021-07-22 14:30-16:00，地点：线上会议，请您准时与会：）
by hengting (A) 05 Aug '21

05 Aug '21

会议纪要反馈链接：https://shimo.im/sheets/N2A1MZgDZxfbBVAD/MODOC 会议主题 Subject OpenHarmoy PMC Biweekly Meeting 会议时间 Time 2021-07-22 14:30-16:00(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting 加入会议 : Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=99f8191480664ab09125863680d…> Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0156054198&app=welink> Join (External) >><https://welink.zhumu.com/j/156054198> 会议ID : 015 605 419 8 与会人 Attendees 李毅；董金光；马占福；万承臻；任革林；王意明；邢文华；肖峰；聂欣外部与会人 External Participants noel@openatom.org,kelei@iscas.ac.cn<mailto:noel@openatom.org,kelei@iscas.ac.cn> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 OpenHamony社区状态审视 20min 董金光邢文华邢文华 2 申请新增SIG：solution-component 将尚未收编到openharmony社区的一些OS公共基础能力通过SIG孵化，更方便快捷去支持南向生态拓展。 15min 李涛李涛李涛李涛、万承臻 3 qemu进展汇报 qemu标准化编译 qemu加入门禁 qemu图形显示和鼠标键盘输入 15min 李开龙李开龙马广耀张凯、朱生乐、马广耀、左永亮柏能 4 方舟JS/TS部分作为OpenHarmony的JS/TS语言编译工具链和运行时子系统开源 1）提供JS/TS编译工具链 2）提供JS语言运行时 15min 蒋晗蒋晗蒋晗龚俊松 5 新增blockchain sig 增加OH区块链功能拓展 5min 尚璇尚璇尚璇尚璇 6 新增python sig 为OH增加python样例 5min 唐佐林唐佐林唐佐林唐佐林 7 新增cicd sig OpenHarmony的CICD能力提升与改进 5min 梁克雷梁克雷梁克雷梁克雷/黄明龙 8 L2对Linux需求讨论L2对Linux的基础需求，便于三方芯片厂家接入 15min 梁克雷梁克雷梁克雷梁克雷、李之琦刘跃华、侯鹏飞候选哲、尹友展徐文方 9 新增 Linkboy sig 为OpenHarmony提供可视化编程能力 5min 王强王强王强王强会议公告 Bulletins 上次会议纪要如下：https://codehub-y.huawei.com/openharmony/mom_for_pmc/files?ref=mas… OpenHarmony Committer清单：https://codehub-y.huawei.com/openharmony/pmc-committer/files?re…

1 0

OpenHarmony 2.2 Beta2（2021-08-04）Release
by Fuchao (Process Quality Dept) 04 Aug '21

04 Aug '21

OpenHarmony 2.2 Beta2（2021-08-04）Release 版本概述当前版本在OpenHarmony 2.0 Canary的基础上，针对轻量系统、小型系统和标准系统都有增加新的特性，并修复已知缺陷：标准系统新增特性功能如下： * 新增分布式远程拉起能力端到端的构建。 * 新增系统基础应用的拖拽能力和新增若干Sample应用。 * 新增媒体三大服务能力，提供更好的媒体系统功能。轻量和小型系统新增特性功能如下： * 新增轻量级linux版本构建能力。 * 新增轻量级内核能力增强，包括文件系统增强、内核调试工具增强支持、内核模块支持可配置、三方芯片适配支持、支持ARM9架构等。 * 轻量级图形能力增强支持，包括支持多语言字体对齐、支持显示控件轮廓、支持点阵字体、供统一多后端框架支持多芯片平台等。 * DFX能力增强支持，包括HiLog功能增强、HiEvent功能增强，提供轻量级系统信息dump工具、提供重启维侧框架等。 * AI能力增强支持，包括新增linux内核适配支持、AI引擎支持基于共享内存的数据传输。配套关系表 1 版本软件和工具配套关系软件版本备注 OpenHarmony 2.2 Beta2 NA HUAWEI DevEco Studio（可选） DevEco Studio 2.2 Beta1 OpenHarmony应用开发推荐使用。 HUAWEI DevEco Device Tool（可选） Deveco DeviceTool 2.2 Beta1 OpenHarmony智能设备集成开发环境推荐使用。源码获取方式一（推荐）通过repo + ssh 下载（需注册公钥，请参考码云帮助中心<https://gitee.com/help/articles/4191>）。 repo init -u git@gitee.com:openharmony/manifest.git<mailto:git@gitee.com:openharmony/manifest.git> -b refs/tags/OpenHarmony-v2.2-Beta2 --no-repo-verify repo sync -c repo forall -c 'git lfs pull' 方式二通过repo + https 下载。 repo init -u https://gitee.com/openharmony/manifest.git -b refs/tags/OpenHarmony-v2.2-Beta2 --no-repo-verify repo sync -c repo forall -c 'git lfs pull' 详细信息请见Release notes：https://gitee.com/openharmony/docs/blob/master/zh-cn/release-notes/Op…

1 0

hispark_pegasus仓库的审核人员奇慢，请协调解决。
by 947828231 04 Aug '21

04 Aug '21

hi3861芯片作为现在开发者最热衷的目标芯片之一收到很多关注，但是代码issue和pr的反馈极慢，给热心的开发者贡献代码和及时更正错误增添了障碍。希望能及时解决这个问题。谢谢。郎鹏

2 1

能否优化dco检查的机制，让开发人员在网页端通过轻量级pr轻松修改代码
by 947828231 04 Aug '21

04 Aug '21

是否可以通过固定格式署名等方式便利网页在线修改代码，使轻量级pr也能进行和通过dco检查，进一步提升代码贡献效率呢？谢谢。郎鹏

3 2

OpenHarmony编译框架设计分享与问题交流
by denny 02 Aug '21

02 Aug '21

Denny 邀请您参加腾讯会议会议主题：OpenHarmony编译框架设计分享与问题交流会议时间：2021/08/03 14:00-16:00 (GMT+08:00) 中国标准时间 - 北京点击链接入会，或添加至会议列表： https://meeting.tencent.com/s/Dc3eRGBzmPml 会议 ID：225 450 407 手机一键拨号入会 +8675536550000,,225450407# (中国大陆) +85230018898,,,2,225450407# (中国香港) 根据您的位置拨号 +8675536550000 (中国大陆) +85230018898 (中国香港) 复制该信息，打开手机腾讯会议App V2.13以上版本即可参与议程：编译框架设计思路 ---peitaiyi 常见应用场景案例演示 ---peitaiyi 问题讨论和改进建议 ---ALL

1 0

《OpenHarmony三方芯片移植现状和诉求讨论 -- 会议纪要》
by dongjinguang 31 Jul '21

31 Jul '21

1、OpenHarmony平台类公共问题&优化措施： • （1）针对音频、视频、输入的提供标准Linux参考实现（ALSA、V4L2、Input Event），尤其是TDE（图形二维加速器）、VO对DRM依赖需要规划统一的HDI接口，隔离芯片平台内核驱动的差异，提升移植效率; owner: houxuanzhe<https://gitee.com/zianed>, lizheng<https://gitee.com/lz-230>, niulihua<https://gitee.com/niulihua>, liangkelei<https://gitee.com/xzmu> • （2）小海思评估可否提供一套参考的DRM驱动，作为OpenHarmony开源社区的用户态驱动的开源实现；owner： chenxin<https://gitee.com/northking-super> • （3）内核LTS多版本支持诉求，从交流来看，目前OpenHarmony并未强制指定4.19内核，为了降低三方SOC针对不同LTS版本kernel移植的便捷性和实际与三方SOC合作的可行性，初步协商如下解决措施： owner: lijiaxin<nina.lijiaxin(a)huawei.com> o a、策略一：维护一套common kernel（譬如4.19），针对不同的LTS版本，将OpenHarmony依赖内核的default defconfig特性和驱动针对不同的LTS版本制作成不同版本的patch：LTS kernel patches + 移植指导； o b、策略二：随着OpenHarmony南向生态逐步完善，逐步牵引SOC来维护common kernel和不同SOC tree的方式； 2、外部开发者暴露问题&优化措施： • （1）缺乏编译单个模块的能力 -- 通过编译选项[可选] --build-target 指定编译目标，可以指定多个 • （2）预编译init、rc等问题 --730 master主线版本解决 • （3）GPIO管脚服用、时钟树、GIC（中断控制器）L0~L1上缺少统一的HDF驱动框架，当前由于Iot SOC 跨芯片平台的差异，未统一设计，从跨芯片平台移植和易用性考虑来看需要统一规划，针对该问题建议采取如下措施： • a、临时解决方案：内核启动初始化init阶段统一初始化配置； • b、由OpenHarmony 驱动框架SIG Leader或社区开发者通过社区PR方式逐步完善对应的驱动框架HDF的能力； owner：houxuanzhe<https://gitee.com/zianed> • （4）OpenHarmony1.1.0 LTS版本是否有计划回合master主线上的HDF MMC驱动框架，在社区中可以与LTS维护者沟通回合的必要性 ; owner:zhangguang<https://gitee.com/zhangg05283106>, 侯鹏飞<1290635392(a)qq.com> • （5）liteos-a 移植中的芯片差异导致的内存映射差异、移植指导说明，需要收集devboard sig移植过程中的问题，并针对性的完善； owner：likailong<https://gitee.com/kkup180>, liuyang<https://gitee.com/liuyang198591> • （6）调测手段单一繁琐，针对OS系统调测只能编译、烧录，不支持单模块替换、模拟器等方式调试，目前标准系统的调测功能相对单一，建议新增调试工具链相关需求进行完善；owner: wangzaishang<https://gitee.com/wangzaishang> 遗留问题，请对应领域责任人周期性的议题在PMC例会上进行问题闭环 -----约会原件----- 发件人: wangke (AN) 发送时间: 2021年7月26日 17:22 收件人: Mazhanfu; dongjinguang; Zhanglei (LeiBJ, OS3); Lijiaxin (Nina Li); Wangmihu; Rengelin; wanchengzhen; Houxuanzhe (George); Likailong (kkup, Development Dept Seven of Device OS); chenxin (H); Yuanwenhong 抄送: Liyi (Nicholas, Software Engineering Device OS Dept); Yuxiaoqi; Xuejiancheng 主题: 链接刷新//【会议通知】OpenHarmony三方芯片移植现状和诉求讨论//时间：07-27（周二） 19:00-20:30//请您预留时间准时接入，谢谢~ 时间: 2021年7月27日星期二 19:00-20:30(UTC+08:00) 北京，重庆，香港特别行政区，乌鲁木齐。地点: 语音接入会议主题 OpenHarmony三方芯片移植现状和诉求讨论会议时间 2021-07-27（周二） 19:00-20:30 与会人马占福、董金光、任革林、张磊、李加欣、万承臻、候选哲、李开龙、陈鑫、袁文鸿会议议题编号议题名称引导人 1 OpenHarmony三方芯片移植现状和诉求讨论董金光语音会议加入会议(Host)<http://imeeting.huawei.com/meeting/startzoom?id=93c55a819ff54e1ea24ca09f657…> 加入会议(Internal)<http://imeeting.huawei.com/meeting/joinzoom?id=0207747088&app=welink> 加入会议(External)<https://welink.zhumu.com/j/207747088> 会议ID 0207747088 会议公告 1、请勿迟到、早退。 2、会议期间，请将手机设为振动或转至秘书座机。 3、请控制会议时间，及时输出会议纪要，让我们开一个高效的会！

1 0

Re: Welcome to the "dev" mailing list
by 黄节两 31 Jul '21

31 Jul '21

At 2021-07-31 17:12:21, dev-request(a)openharmony.io wrote: >Welcome 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

刷新会议时间为16:30开始，请知//【会议通知】 OpenHarmony 2.2 beta2版本发布评审会议，时间：2021-07-30 16:30-17:30(UTC+08:00)，
by hengting (A) 30 Jul '21

30 Jul '21

发件人: wangke (AN) 发送时间: 2021年7月29日 17:56 收件人: wangke (AN) <wangke148(a)huawei.com<mailto:wangke148@huawei.com>> 抄送: pmc(a)openharmony.io<mailto:pmc@openharmony.io>; dev(a)openharmony.io<mailto:dev@openharmony.io>; kelei(a)iscas.ac.cn<mailto:kelei@iscas.ac.cn>; noel(a)openatom.org<mailto:noel@openatom.org>; minglong(a)iscas.ac.cn<mailto:minglong@iscas.ac.cn>; lotus(a)openatom.org<mailto:lotus@openatom.org> 主题: 【会议通知】 OpenHarmony 2.2 beta2版本发布评审会议，时间：2021-07-30 16:30-17:30 (UTC+08:00)，会议主题 OpenHarmony 2.2 beta2版本发布评审会议会议时间 2021-07-30 16:30-17:30 (UTC+08:00)Beijing 视频会议加入会议(External)<https://welink.zhumu.com/j/189730780> 会议ID Meeting ID：0189730780 与会人马占福、董金光、任革林、张勇智、聂欣、肖峰、陈雅旬、王意明、傅超、邢文华、张明修、张磊、鲍国涛、艾勇福、纪永、杨妮、喻靖、刘果外部抄送人 pmc@openharmony.io、dev@openharmony.io、kelei@iscas.ac.cn、noel@openatom.org、minglong@iscas.ac.cn、lotus@openatom.org<mailto:pmc@openharmony.io、dev@openharmony.io、kelei@iscas.ac.cn、noel@openatom.org、minglong@iscas.ac.cn、lotus@openatom.org> 会议议题编号议题名称汇报人 1 OpenHarmony 2.2 beta2版本准出评审邢文华会议公告提示 Tips 请点击会议链接按照提示下载客户端，下载后请不要注册，重新点击链接入会。操作指导<https://app.huawei.com/eshare/meetings?locale=zh_CN> Click the conference link to download the client as prompted. After downloading the client, do not register. Click the link to join the conference again. Operation Guide<https://app.huawei.com/eshare/meetings?locale=en_US>

1 0

刷新会议时间为16:00开始，请知//【会议通知】 OpenHarmony 2.2 beta2版本发布评审会议，时间：2021-07-30 16:00-17:30(UTC+08:00)，
by hengting (A) 30 Jul '21

30 Jul '21

发件人: wangke (AN) 发送时间: 2021年7月29日 17:56 收件人: wangke (AN) <wangke148(a)huawei.com<mailto:wangke148@huawei.com>> 抄送: pmc(a)openharmony.io<mailto:pmc@openharmony.io>; dev(a)openharmony.io<mailto:dev@openharmony.io>; kelei(a)iscas.ac.cn<mailto:kelei@iscas.ac.cn>; noel(a)openatom.org<mailto:noel@openatom.org>; minglong(a)iscas.ac.cn<mailto:minglong@iscas.ac.cn>; lotus(a)openatom.org<mailto:lotus@openatom.org> 主题: 【会议通知】 OpenHarmony 2.2 beta2版本发布评审会议，时间：2021-07-30 16:00-17:30 (UTC+08:00)，会议主题 OpenHarmony 2.2 beta2版本发布评审会议会议时间 2021-07-30 16:00-17:30 (UTC+08:00)Beijing 视频会议加入会议(External)<https://welink.zhumu.com/j/189730780> 会议ID Meeting ID：0189730780 与会人马占福、董金光、任革林、张勇智、聂欣、肖峰、陈雅旬、王意明、傅超、邢文华、张明修、张磊、鲍国涛、艾勇福、纪永、杨妮、喻靖、刘果外部抄送人 pmc@openharmony.io、dev@openharmony.io、kelei@iscas.ac.cn、noel@openatom.org、minglong@iscas.ac.cn、lotus@openatom.org<mailto:pmc@openharmony.io、dev@openharmony.io、kelei@iscas.ac.cn、noel@openatom.org、minglong@iscas.ac.cn、lotus@openatom.org> 会议议题编号议题名称汇报人 1 OpenHarmony 2.2 beta2版本准出评审邢文华会议公告提示 Tips 请点击会议链接按照提示下载客户端，下载后请不要注册，重新点击链接入会。操作指导<https://app.huawei.com/eshare/meetings?locale=zh_CN> Click the conference link to download the client as prompted. After downloading the client, do not register. Click the link to join the conference again. Operation Guide<https://app.huawei.com/eshare/meetings?locale=en_US>

1 0

FW: 【会议通知】 OpenHarmony 2.2 beta2版本发布评审会议，时间：2021-07-30 14:15-16:00(UTC+08:00)，
by hengting (A) 30 Jul '21

30 Jul '21

From: wangke (AN) Sent: Friday, July 30, 2021 9:14 AM To: hengting (A) <hengting1(a)huawei.com> Subject: 转发: 【会议通知】 OpenHarmony 2.2 beta2版本发布评审会议，时间：2021-07-30 14:15-16:00(UTC+08:00)，发件人: wangke (AN) 发送时间: 2021年7月29日 17:56 收件人: wangke (AN) <wangke148(a)huawei.com<mailto:wangke148@huawei.com>> 抄送: pmc(a)openharmony.io<mailto:pmc@openharmony.io>; dev(a)openharmony.io<mailto:dev@openharmony.io>; kelei(a)iscas.ac.cn<mailto:kelei@iscas.ac.cn>; noel(a)openatom.org<mailto:noel@openatom.org>; minglong(a)iscas.ac.cn<mailto:minglong@iscas.ac.cn>; lotus(a)openatom.org<mailto:lotus@openatom.org> 主题: 【会议通知】 OpenHarmony 2.2 beta2版本发布评审会议，时间：2021-07-30 14:15-16:00(UTC+08:00)，会议主题 OpenHarmony 2.2 beta2版本发布评审会议会议时间 2021-07-30 14:15-16:00(UTC+08:00)Beijing 视频会议加入会议(External)<https://welink.zhumu.com/j/189730780> 会议ID Meeting ID：0189730780 与会人马占福、董金光、任革林、张勇智、聂欣、肖峰、陈雅旬、王意明、傅超、邢文华、张明修、张磊、鲍国涛、艾勇福、纪永、杨妮、喻靖、刘果外部抄送人 pmc@openharmony.io、dev@openharmony.io、kelei@iscas.ac.cn、noel@openatom.org、minglong@iscas.ac.cn、lotus@openatom.org<mailto:pmc@openharmony.io、dev@openharmony.io、kelei@iscas.ac.cn、noel@openatom.org、minglong@iscas.ac.cn、lotus@openatom.org> 会议议题编号议题名称汇报人 1 OpenHarmony 2.2 beta2版本准出评审邢文华会议公告提示 Tips 请点击会议链接按照提示下载客户端，下载后请不要注册，重新点击链接入会。操作指导<https://app.huawei.com/eshare/meetings?locale=zh_CN> Click the conference link to download the client as prompted. After downloading the client, do not register. Click the link to join the conference again. Operation Guide<https://app.huawei.com/eshare/meetings?locale=en_US>

1 0

求助：OpenHarmony 如何配置适用于嵌入式系统的最小组件配置？
by Luo Xiaogang 28 Jul '21

28 Jul '21

dear all : OpenHarmony 如何配置适用于嵌入式系统的最小组件配置？目标：配置嵌入式系统(linux)需要的最少的组件。硬件环境：arm926，主频 300M ，内存 128M , flash 64M 软件业务：协议网关类产品，网络和串口之间的协议转换。没有音视频，没有UI界面，没有分布式业务。以前系统：u-boot + linux + busybox 我在 Hi3516DV300.json 基础上只修改了 ”parts“ 的配置，其他保持不变，做了如下尝试： 1、"startup:init":{} 编译结束，组建文件体统时，提示找不到 root 目录，构建文件系统失败。只有 startup:init 组件相关的程序。 2、"startup":init{}, "common:common":{} 编译失败，gn gen 生成 ninja 文件的时候失败，提示如下： build configs generation is complete. ERROR at //build/templates/cxx/cxx.gni:648:7: Script returned non-zero exit code. exec_script(external_deps_script, arguments) ^---------- Current dir: /home/luo/linux/openharmony/tmp/out/ohos-arm-release/ Command: /usr/bin/env /home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py --external-deps hiviewdfx_hilog_native:libhilog --parts-src-flag-file build_configs/parts_src_flag.json --external-deps-temp-file gen/utils/native/base/utilsbase_external_deps_temp.json --sdk-base-dir ../../sdk/ohos-arm --sdk-dir-name sdk/ohos-arm --current-toolchain //build/toolchain/ohos:ohos_clang_arm Returned 1 and printed out: file '../../sdk/ohos-arm/hiviewdfx_hilog_native/sdk_info.json' doesn't exist. stderr: Traceback (most recent call last): File "/home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py", line 239, in <module> sys.exit(main()) File "/home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py", line 205, in main sdk_module_info, adapted_ok = _get_external_module_from_sdk( File "/home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py", line 73, in _get_external_module_from_sdk raise Exception("part '{}' doesn't exist in sdk modules.".format( Exception: part 'hiviewdfx_hilog_native' doesn't exist in sdk modules. See //utils/native/base/BUILD.gn:100:1: whence it was called. ohos_static_library("utilsbase") { ^--------------------------------- See //third_party/sqlite/BUILD.gn:72:5: which caused the file to be included. "//utils/native/base:utils", ^-------------------------- build: gn gen error 3、"startup":init{}, "common:common":{},"utils:utils_base":{} 编译失败，gn gen 生成 ninja 文件的时候失败，提示和2类似可能需要的子系统：startup、common、xts 不需要的子系统：distributeddatamgr、account、hiviewdfx、communication、distributedschedule、multimedia、telephony、distributedhardware 使用哪些组件可以配置一个适用于嵌入式的最小的 openHarmony 系统（linux）？谢谢！

1 0

求助：OpenHarmony 如何配置适用于嵌入式系统的最小组件配置？
by 骆小刚 28 Jul '21

28 Jul '21

dear all : OpenHarmony 如何配置适用于嵌入式系统的最小组件配置？目标：配置嵌入式系统(linux)需要的最少的组件。硬件环境：arm926，主频 300M ，内存 128M , flash 64M 软件业务：协议网关类产品，网络和串口之间的协议转换。没有音视频，没有UI界面，没有分布式业务。以前系统：u-boot + linux + busybox 我在 Hi3516DV300.json 基础上只修改了 ”parts“ 的配置，其他保持不变，做了如下尝试： 1、"startup:init":{} 编译结束，组建文件体统时，提示找不到 root 目录，构建文件系统失败。只有 startup:init 组件相关的程序。 2、"startup":init{}, "common:common":{} 编译失败，gn gen 生成 ninja 文件的时候失败，提示如下： build configs generation is complete. ERROR at //build/templates/cxx/cxx.gni:648:7: Script returned non-zero exit code. exec_script(external_deps_script, arguments) ^---------- Current dir: /home/luo/linux/openharmony/tmp/out/ohos-arm-release/ Command: /usr/bin/env /home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py --external-deps hiviewdfx_hilog_native:libhilog --parts-src-flag-file build_configs/parts_src_flag.json --external-deps-temp-file gen/utils/native/base/utilsbase_external_deps_temp.json --sdk-base-dir ../../sdk/ohos-arm --sdk-dir-name sdk/ohos-arm --current-toolchain //build/toolchain/ohos:ohos_clang_arm Returned 1 and printed out: file '../../sdk/ohos-arm/hiviewdfx_hilog_native/sdk_info.json' doesn't exist. stderr: Traceback (most recent call last): File "/home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py", line 239, in <module> sys.exit(main()) File "/home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py", line 205, in main sdk_module_info, adapted_ok = _get_external_module_from_sdk( File "/home/luo/linux/openharmony/tmp/build/templates/common/external_deps_handler.py", line 73, in _get_external_module_from_sdk raise Exception("part '{}' doesn't exist in sdk modules.".format( Exception: part 'hiviewdfx_hilog_native' doesn't exist in sdk modules. See //utils/native/base/BUILD.gn:100:1: whence it was called. ohos_static_library("utilsbase") { ^--------------------------------- See //third_party/sqlite/BUILD.gn:72:5: which caused the file to be included. "//utils/native/base:utils", ^-------------------------- build: gn gen error 3、"startup":init{}, "common:common":{},"utils:utils_base":{} 编译失败，gn gen 生成 ninja 文件的时候失败，提示和2类似可能需要的子系统：startup、common、xts 不需要的子系统：distributeddatamgr、account、hiviewdfx、communication、distributedschedule、multimedia、telephony、distributedhardware 使用哪些组件可以配置一个适用于嵌入式的最小的 openHarmony 系统（linux）？谢谢！

1 0

标准系统开发n-api的JS模块的一些问题以及解决方法
by 谭小凡 28 Jul '21

28 Jul '21

存在的问题问题1. NAPI_CALL一族函数可能会导致函数体返回，造成内存泄露（2021/7/25更新）该状态已经得到缓解，目前代码中看到的是在外层函数中申请资源，调用Wrap函数去实际干活。Wrap函数中随意使用NAPI_CALL宏，一旦异常返回，外层函数负责回收申请到的资源。但是这种机制未解决了所有内存泄露的问题，以NAPI_GetProcessName函数为例（为了板书简短，下面代码做了适当精简） napi_value NAPI_GetProcessName(napi_env env, napi_callback_info info) { ProcessNameCB *processNameCB = CreateProcessNameCBInfo(env); if (processNameCB == nullptr) returnnullptr; napi_value ret = GetProcessNameWrap(env, info, processNameCB); if (ret == nullptr && processNameCB != nullptr) { delete processNameCB; processNameCB = nullptr; } return ret; } napi_value GetProcessNameWrap(napi_env env, napi_callback_info info, ProcessNameCB *processNameCB) { if (processNameCB == nullptr) returnnullptr; size_t argcAsync = 1; const size_t argcPromise = 0; const size_t argCountWithAsync = argcPromise + ARGS_ASYNC_COUNT; napi_value args[ARGS_MAX_COUNT] = {nullptr}; napi_value ret = nullptr; NAPI_CALL(env, napi_get_cb_info(env, info, &argcAsync, args, nullptr, nullptr)); if (argcAsync > argCountWithAsync || argcAsync > ARGS_MAX_COUNT) returnnullptr; if (argcAsync > argcPromise) ret = GetProcessNameAsync(env, args, argcAsync, argcPromise, processNameCB); else ret = GetProcessNamePromise(env, processNameCB); return ret; } napi_value GetProcessNameAsync( napi_env env, napi_value *args, size_t argcAsync, const size_t argcPromise, ProcessNameCB *processNameCB) { if (args == nullptr || processNameCB == nullptr) returnnullptr; napi_value resourceName = nullptr; NAPI_CALL(env, napi_create_string_latin1(env, __func__, NAPI_AUTO_LENGTH, &resourceName)); napi_valuetype valuetype = napi_undefined; NAPI_CALL(env, napi_typeof(env, args[argcPromise], &valuetype)); if (valuetype == napi_function) NAPI_CALL(env, napi_create_reference(env, args[argcPromise], 1, &processNameCB->cbBase.cbInfo.callback)); NAPI_CALL(env, napi_create_async_work(env, nullptr, resourceName, GetProcessNameExecuteCB, GetProcessNameAsyncCompleteCB, (void *)processNameCB, &processNameCB->cbBase.asyncWork)); NAPI_CALL(env, napi_queue_async_work(env, processNameCB->cbBase.asyncWork)); napi_value result = nullptr; NAPI_CALL(env, napi_get_null(env, &result)); return result; } void GetProcessNameAsyncCompleteCB(napi_env env, napi_status status, void *data) { ProcessNameCB *processNameCB = (ProcessNameCB *)data; napi_value callback = nullptr; napi_value undefined = nullptr; napi_value result[ARGS2] = {nullptr}; napi_value callResult = nullptr; NAPI_CALL_RETURN_VOID(env, napi_get_undefined(env, &undefined)); result[PARAM0] = GetCallbackErrorValue(env, NO_ERROR); result[PARAM1] = WrapProcessName(env, processNameCB); NAPI_CALL_RETURN_VOID(env, napi_get_reference_value(env, processNameCB->cbBase.cbInfo.callback, &callback)); NAPI_CALL_RETURN_VOID(env, napi_call_function(env, undefined, callback, ARGS2, &result[PARAM0], &callResult)); if (processNameCB->cbBase.cbInfo.callback != nullptr) NAPI_CALL_RETURN_VOID(env, napi_delete_reference(env, processNameCB->cbBase.cbInfo.callback)); NAPI_CALL_RETURN_VOID(env, napi_delete_async_work(env, processNameCB->cbBase.asyncWork)); delete processNameCB; processNameCB = nullptr; } 目前仍然存在的问题 cbInfo.callback和asyncWork泄露 GetProcessNameAsync调用了napi_create_reference创建了一个processNameCB->cbBase.cbInfo.callback，一旦后续步骤发生失败，将返回空指针到NAPI_GetProcessName 就会发生NAPI_GetProcessName仅删除了processNameCB资源，并未删除processNameCB->cbBase.cbInfo.callback。同理napi_queue_async_work函数运行失败，也会造成processNameCB->cbBase.asyncWork这个资源泄露 NAPI_CALL_RETURN_VOID导致泄露在async_work的complete回调中，并未采用Wrap函数这种技巧，可能导致无法顺利执行资源释放的工作。 processNameCB,cbInfo.callback,asyncWork都将有未释放的风险对不再使用的局部变量置空是无意义的写法 delete processNameCB; processNameCB = nullptr; 问题2. 何时使用NAPI_CALL这一族宏定义来检查n-api函数是否成功从目前代码中来看该族函数，大部分napi函数都使用了NAPI_CALL这一族宏定义来判断状态，但还是有很多未检查的代码，例如 napi_value NAPI_KillProcessesByBundleName(napi_env env, napi_callback_info info) { size_t argc = 2; napi_value argv[argc]; NAPI_CALL(env, napi_get_cb_info(env, info, &argc, argv, NULL, NULL)); std::string bundleName; ParseBundleName(env, bundleName, argv[0]); // 内部使用了NAPI_CALL但外部未检查返回值是否为空指针bool callBackMode = false; if (argc >= 2) { napi_valuetype valuetype; NAPI_CALL(env, napi_typeof(env, argv[1], &valuetype)); NAPI_ASSERT(env, valuetype == napi_function, "Wrong argument type. Function expected."); callBackMode = true; } AsyncKillProcessCallbackInfo *async_callback_info = new (std::nothrow) AsyncKillProcessCallbackInfo{.env = env, .asyncWork = nullptr, .deferred = nullptr}; if (async_callback_info == nullptr) returnnullptr; async_callback_info->bundleName = bundleName; if (callBackMode) napi_create_reference(env, argv[1], 1, &async_callback_info->callback[0]); // 未检查 napi_value ret = NAPI_KillProcessesByBundleNameWrap(env, info, callBackMode, async_callback_info); if (ret == nullptr) { delete async_callback_info; async_callback_info = nullptr; } return ((callBackMode) ? (nullptr) : (ret)); } napi_value NAPI_KillProcessesByBundleNameWrap( napi_env env, napi_callback_info info, bool callBackMode, AsyncKillProcessCallbackInfo *async_callback_info) { if (callBackMode) { napi_value resourceName; napi_create_string_latin1(env, "NAPI_KillProcessesByBundleNameCallBack", NAPI_AUTO_LENGTH, &resourceName); // 未检查 napi_create_async_work(env, nullptr, resourceName, [](napi_env env, void *data) { HILOG_INFO("killProcessesByBundleName called(CallBack Mode)..."); AsyncKillProcessCallbackInfo *async_callback_info = (AsyncKillProcessCallbackInfo *)data; async_callback_info->result = GetAbilityManagerInstance()->KillProcess(async_callback_info->bundleName); }, [](napi_env env, napi_status status, void *data) { HILOG_INFO("killProcessesByBundleName compeleted(CallBack Mode)..."); AsyncKillProcessCallbackInfo *async_callback_info = (AsyncKillProcessCallbackInfo *)data; napi_value result[2] = {0}; napi_value callback; napi_value undefined; napi_value callResult = 0; result[0] = GetCallbackErrorValue(async_callback_info->env, BUSINESS_ERROR_CODE_OK); // 内部使用了NAPI_CALL但外部未检查返回值是否为空指针 napi_create_int32(async_callback_info->env, async_callback_info->result, &result[1]); // 未检查 napi_get_undefined(env, &undefined); // 未检查 napi_get_reference_value(env, async_callback_info->callback[0], &callback); // 未检查 napi_call_function(env, undefined, callback, 2, &result[0], &callResult); // 未检查if (async_callback_info->callback[0] != nullptr) { napi_delete_reference(env, async_callback_info->callback[0]); // 未检查，但此处确实无需检查 } napi_delete_async_work(env, async_callback_info->asyncWork); // 未检查，但此处确实无需检查delete async_callback_info; }, (void *)async_callback_info, &async_callback_info->asyncWork); // 未检查 NAPI_CALL(env, napi_queue_async_work(env, async_callback_info->asyncWork)); napi_value ret = 0; NAPI_CALL(env, napi_create_int32(env, 0, &ret)); // 若此函数失败程序可能会崩溃，因为会出现double delete的问题。return ret; } else { napi_value resourceName; napi_create_string_latin1(env, "NAPI_KillProcessesByBundleNamePromise", NAPI_AUTO_LENGTH, &resourceName); // 未检查 napi_deferred deferred; napi_value promise; NAPI_CALL(env, napi_create_promise(env, &deferred, &promise)); async_callback_info->deferred = deferred; napi_create_async_work(env, nullptr, resourceName, [](napi_env env, void *data) { HILOG_INFO("killProcessesByBundleName called(Promise Mode)..."); AsyncKillProcessCallbackInfo *async_callback_info = (AsyncKillProcessCallbackInfo *)data; async_callback_info->result = GetAbilityManagerInstance()->KillProcess(async_callback_info->bundleName); }, [](napi_env env, napi_status status, void *data) { HILOG_INFO("killProcessesByBundleName compeleted(Promise Mode)..."); AsyncKillProcessCallbackInfo *async_callback_info = (AsyncKillProcessCallbackInfo *)data; napi_value result; napi_create_int32(async_callback_info->env, async_callback_info->result, &result); // 未检查 napi_resolve_deferred(async_callback_info->env, async_callback_info->deferred, result); // 未检查 napi_delete_async_work(env, async_callback_info->asyncWork); // 未检查，但此处确实无需检查delete async_callback_info; }, (void *)async_callback_info, &async_callback_info->asyncWork); // 未检查 napi_queue_async_work(env, async_callback_info->asyncWork); // 未检查return promise; } } 问题3. Promise模式和Callback模式代码混乱 promise和callback的语义不统一 void AsyncCompleteCallback(napi_env env, napi_status status, void *data) { AsyncPermissionCallbackInfo *asyncCallbackInfo = (AsyncPermissionCallbackInfo *)data; if (asyncCallbackInfo == nullptr) return; const size_t cbCount = 2; napi_value callback = 0; napi_value undefined = 0; napi_get_undefined(env, &undefined); napi_value result = 0; napi_value callResult = 0; NAPI_GetNapiValue(env, &asyncCallbackInfo->native_data, &result); if (asyncCallbackInfo->run_status) { if (asyncCallbackInfo->callback[0] != nullptr) { napi_get_reference_value(env, asyncCallbackInfo->callback[0], &callback); napi_call_function(env, undefined, callback, 1, &result, &callResult); napi_delete_reference(env, asyncCallbackInfo->callback[0]); } } else { if (asyncCallbackInfo->callback[1] != nullptr) { napi_value rev[2] = {nullptr}; napi_create_int32(env, asyncCallbackInfo->error_code, &rev[0]); napi_create_int32(env, asyncCallbackInfo->run_status ? 0 : -1, &rev[1]); napi_get_reference_value(env, asyncCallbackInfo->callback[1], &callback); napi_call_function(env, undefined, callback, cbCount, rev, &callResult); napi_delete_reference(env, asyncCallbackInfo->callback[1]); } } napi_delete_async_work(env, asyncCallbackInfo->asyncWork); delete asyncCallbackInfo; } void PromiseCompleteCallback(napi_env env, napi_status status, void *data) { AsyncPermissionCallbackInfo *asyncCallbackInfo = (AsyncPermissionCallbackInfo *)data; if (asyncCallbackInfo != nullptr) { napi_value result = 0; NAPI_GetNapiValue(env, &asyncCallbackInfo->native_data, &result); napi_resolve_deferred(env, asyncCallbackInfo->deferred, result); napi_delete_async_work(env, asyncCallbackInfo->asyncWork); delete asyncCallbackInfo; } } 以上述代码为例，callback分为成功回调和失败回调。那为何promise始终都用napi_resolve_deferred而不用napi_reject_deferred呢？现存代码中callback有两种写法传入一个或两个callback，第一个表success_cb，第二个表fail_cb 传入一个callback对象，其中携带success, fail, complete三个回调代码过于重复大部分同时支持promise模式和callback模式的函数拥有着高度重复的代码，严重降低代码的可维护性，代码数量快速膨胀。解决思路问题1,2 这两个问题的根源内存泄露，其实只要解决了内存泄露，那问题1,2就能迎刃而解了建议为asyncCallbackInfo添加析构函数，由析构函数负责释其所管理的所有资源。具体的来说，在析构函数中调用napi_delete_reference,api_delete_async_work等资源清理函数建议用std::unique_ptr来管理asyncCallbackInfo指针当函数因失败而返回，或者正常退出且需要释放asyncCallbackInfo的场合，std::unique_ptr可以自动释放资源当函数正常结束无需释放asyncCallbackInfo的场合，调用std::unique_ptr<T>::release()接口即可取消自动释放资源的功能问题3 为async_callback_data抽象一个共同的基类来屏蔽promise，callback的差异，实现只需要写一份代码，就可以同时实现两种模式 class AsyncWorkData { public: // 构造函数，需要持有一个napi_env对象 AsyncWorkData(napi_env env); // 析构函数，释放本对象管理的所有资源 ~AsyncWorkData(); // argc,argv// argc == 0: promise模式// argc == 1: callback模式// * 如果type(argv[0]) == napi_function// 则将argv作为success_cb// * 如果type(argv[0]) == napi_object 的话// 则将argv[0].success作为success_cb，argv[0].fail作为fail_cb，argv[0].complete作为complete_cb// argc == 2: callback模式// 将argv[0]作为success_cb, argv[1]作为fail_cb// retval// 若为promise模式，则使*retval = promise对象// 若为callback模式，则使*retval = nullptrbool parse_args(size_t argc, napi_value argv[], napi_value *retval); // 若为promise模式:// 根据resolved值来调用napi_resolve_deferred或napi_reject_deferred函数，result作为resolve/reject的参数。// 若为callback模式// 根据resolved值来调用complete_cb(result)或fail_cb(result)。如果存在complete_cb，则调用complete_cb()void notify(napi_value result， bool resolved = true); // 每个这个成员与参数解析无关，但他是所有async_callback_data的共同成员，所以放在基类里统一管理 napi_async_work async_work; protected: napi_env env; private: napi_ref success_cb; napi_ref fail_cb; napi_ref complete_cb; napi_deferred deferred; }; 使用这种技巧编写这种同时支持callback和promise的应用将会非常简单，例如开发一个getProcessInfo的函数 struct GetProcessNameAsyncInfo : public AsyncWorkData { GetProcessInfoAsyncInfo(napi_env env); Ability *ability; std::shared_ptr<ProcessInfo> process_info; }; static napi_value NAPI_getProcessInfo(napi_env env, napi_callback_info info) { size_t argc = 1; napi_value argv[1], retval, resourceName; NAPI_CALL(env, napi_get_cb_info(env, info, &argc, argv, NULL, NULL)); GetProcessInfoAsyncInfo *async_callback_info = new GetProcessInfoAsyncInfo { env }; std::unique_ptr<GetProcessInfoAsyncInfo> cleaner { async_callback_info }; // 如果回调参数下标是从n开始的话，可以写作parse_args(argc-n, argv+n, &retval)if (!async_callback_info->parse_args(argc, argv, &retval)) returnnullptr; NAPI_CALL(env, util_get_ability(env, &async_callback_info->ability)); NAPI_CALL(env, napi_create_string_latin1(env, __func__, NAPI_AUTO_LENGTH, &resourceName)); NAPI_CALL(env, napi_create_async_work( env, nullptr, resourceName, [](napi_env env, void *data) { GetProcessInfoAsyncInfo *async_callback_info = reinterpret_cast<GetProcessInfoAsyncInfo*>(data); async_callback_info->process_info = async_callback_info->ability->GetProcessInfo(); }, [](napi_env env, napi_status status, void *data) { GetProcessInfoAsyncInfo *async_callback_info = reinterpret_cast<GetProcessInfoAsyncInfo*>(data); std::unique_ptr<GetProcessInfoAsyncInfo> cleaner { async_callback_info }; ProcessInfo &process_info = *async_callback_info->process_info; napi_value result; napi_value pid, name; NAPI_CALL_RETURN_VOID(env, napi_create_object(env, &result)); NAPI_CALL_RETURN_VOID(env, util_napi_value_from_string_utf8(env, process_info.GetProcessName(), &name)); NAPI_CALL_RETURN_VOID(env, napi_create_uint32(env, (uint32_t)process_info.GetPid(), &pid)); NAPI_CALL_RETURN_VOID(env, napi_set_named_property(env, result, "processName", name)); NAPI_CALL_RETURN_VOID(env, napi_set_named_property(env, result, "pid", pid)); async_callback_info->notify(result); // 如果此处有失败分支的话，令第三个参数为false即可。 }, reinterpret_cast<void*>(async_callback_info), &async_callback_info->async_work)); NAPI_CALL(env, napi_queue_async_work(env, async_callback_info->async_work)); cleaner.release(); return retval; } 这样一来，以上代码同时支持callback模式和promise模式 vm = this// callback风格: 只传一个success_cb getProcessInfo(info => { vm.message = 'name: ' + info.processName }) // callback风格: 传两个回调函数 getProcessInfo(info => { vm.message = 'name: ' + info.processName }, err => { vm.message = 'fail: ' + err.message }) // callback风格: 传入一个携带success,fail,complete信息的对象 getProcessInfo({ success: info => { vm.message = 'name: ' + info.processName }, fail: err => { vm.message = 'fail: ' + err.message }, complete: () => { console.log('complete') } }) // callback风格: 传入一个不完整的回调对象 getProcessInfo({ success: info => { vm.message = 'name: ' + info.processName }, }) // promise风格 getProcessInfo() .then(info => { vm.message = info.processName }) .catch(err => { vm.message = 'fail: ' + err.message })

2 2

Re: SIG项目孵化询问
by minglong 26 Jul '21

26 Jul '21

开发者你好。正在推动SIG毕业流程。我后续会按照SIG毕业孵化流程跟咱们一起跟进。祝好。 On Jul 21, 2021 13:51，Shi Yuhan<YuhanShi53(a)outlook.com> wrote：您好，我们在OpenHarmony-SIG仓下有个DLLite Micro组件需要孵化毕业，请问当前孵化合入OpenHarmony的要求有哪些？代码仓地址：dllite_micro: 为了支持AI模型在IoT设备上完成推理功能，使IoT设备具备AI能力，并能够更好的匹配OpenHarmonyOS的各种设备形态，DLLite SIG不仅需要为用户提供基础的推理服务，包括统一的API和 (gitee.com) 祝好！ Yuhan

1 0

Fw:Welcome to the "dev" mailing list
by fengyuanrong168 24 Jul '21

24 Jul '21

-------- Forwarding messages -------- From: dev-request(a)openharmony.io Date: 2021-07-24 17:00:33 To: fengyuanrong <fengyuanrong168(a)163.com> Subject: Welcome to the "dev" mailing list Welcome 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

Re: 社区刚刚发布的开发板移植指导文档，我有话说
by Netroby 24 Jul '21

24 Jul '21

大家好，我也是一名开发者，也一直关注着鸿蒙系统的开发和进展。 @李传钊大佬分享的观点很有建设性意义。我也反思，咱们该如何把社区建设，开发指南这些机制做好。如果各位有建设性的意见，也可以一起分享出来。。找到问题，不足，我们反馈出来，这肯定是很好的。但是在这个基础之上，我们能提供解题思路。能提供解决难题的方案。那更是功德无量。以下观点，仅抛砖引玉：目前做的好的Linux kernel，我们可以看到他们有 LTS 分支和 mainline的划分就是如果你的业务，是不关注新特性，新功能，那么是可以选用LTS 分支，我知道很多公司还在用2.x的内核。。。因为它太稳了。。如果在这个基础上，有精力，那么可以跟一跟 mainline版本。。鸿蒙也可以参考这一点。看是不是可以做支持。软件迭代开发是肯定要做的，开拓创新，积极进取。但是也不能说，我自己飙车，爽就完事了。那这样其他小伙伴跟不上你的节奏，那这个游戏还怎么玩。跑的快的继续跑。但是也要有关照跑的慢的同学。所以我以为解决开发者对鸿蒙跑太快了的顾虑，可能就是拿一个LTS方案。。 LTS分支， API固定，保证兼容，不经常大改架构。但是会修复性能缺陷，安全漏洞等。支持期可以是十年，二十年。这样开发者就不会担心，我怎么一个星期没看到代码，就完全看不懂了？？我相信以华为强大的技术实力，一天做一百个变更，是可以的。是小菜一碟。但对于第三方开发者，可能就要哭晕了。。。这怎么学，怎么跟得上嘛。 Appreciate your time. ---------------------------- Netroby dongjinguang <dongjinguang(a)huawei.com> 于2021年7月24日周六上午9:09写道： > > > 传钊你好 > 非常感谢你反馈的这些问题，对OpenHarmony的推广和生态建设都是非常有建设性的建议，初步计划下周二晚上我们组织内核、驱动框架、海思芯片平台等的相关专家一起对这些问题和建议进行研讨，诚邀你能一起参与讨论和交流。 > > > > ________________________________ > > 董金光 Dong Jinguang > Mobile: +86-50000008869(For Welink,eSpace Calls) > Email: dongjinguang(a)huawei.com > 发件人：962030 <962030(a)qq.com> > 收件人：dev <dev(a)openharmony.io> > 时间：2021-07-23 20:43:42 > 主题：[Dev] 社区刚刚发布的开发板移植指导文档，我有话说 > > 各位， > > 刚刚看到社区新发布的移植指导文档，我认为其内容偏离真实的三方开发板移植工作，是在缺乏真正的开发板移植经验的情况下写出的。 > > 我有如下问题： > 1.LiteOS-a移植过程中不需要考虑芯片的差异？不需要仔细阅读芯片手册？ > 2.LiteOS-a移植过程中不需要进行内存映射的计算和设计？ > 3.LiteOS-a移植过程中不需要考虑启动过程，与uboot的衔接？ > 4.Standard系统要求大家尽量采用4.19内核，这在大多数场合下是做不到的。 > 5.Standard系统对图形部分DRM毫无涉及，难道这块不用管就能跑起来？OpenHarmony的代码能适配所有芯片？ > 6.Standard系统的移植不需要调整rc？ > > 第三方芯片移植是一个极其重要，对于OpenHarmony有生死意义的工作，期间涉及到的技术内容，即使写一本书，都不嫌罗嗦，建议重视此文档的持续改进。 > > 另外目前的第三方芯片移植仍旧是困难重重，OS与kernel，OS与芯片的耦合现象仍旧十分严重，此问题暴露已久，大家要想出办法来，别再掩耳盗铃了！！！ > > 也请邮件组中的各位老板，你们仔细了解一下移植的难度，忙着点赞的同时也客观评价一下工作的进度。大家都是做技术出身的，你们都知道远离技术的真相是多么可怕的事情。 > > 李传钊 2021.7.23 > > > ________________________________ > 962030(a)qq.com > _______________________________________________ > dev mailing list -- dev(a)openharmony.io > To unsubscribe send an email to dev-leave(a)openharmony.io

2 1

关于展锐T618适配的疑问
by free 24 Jul '21

24 Jul '21

各位开发人员，您好, 目前我手上有一块展锐T618芯片的板子，想问一下 1、openharmony是否支持展锐T618 2、不支持的话，后续会不会增加相关的支持 3、是否有相关的移植文档百忙之中打扰各位十分抱歉，感谢各位

4 4

社区刚刚发布的开发板移植指导文档，我有话说
by 962030＠qq.com 24 Jul '21

24 Jul '21

各位，刚刚看到社区新发布的移植指导文档，我认为其内容偏离真实的三方开发板移植工作，是在缺乏真正的开发板移植经验的情况下写出的。我有如下问题： 1.LiteOS-a移植过程中不需要考虑芯片的差异？不需要仔细阅读芯片手册？ 2.LiteOS-a移植过程中不需要进行内存映射的计算和设计？ 3.LiteOS-a移植过程中不需要考虑启动过程，与uboot的衔接？ 4.Standard系统要求大家尽量采用4.19内核，这在大多数场合下是做不到的。 5.Standard系统对图形部分DRM毫无涉及，难道这块不用管就能跑起来？OpenHarmony的代码能适配所有芯片？ 6.Standard系统的移植不需要调整rc？第三方芯片移植是一个极其重要，对于OpenHarmony有生死意义的工作，期间涉及到的技术内容，即使写一本书，都不嫌罗嗦，建议重视此文档的持续改进。另外目前的第三方芯片移植仍旧是困难重重，OS与kernel，OS与芯片的耦合现象仍旧十分严重，此问题暴露已久，大家要想出办法来，别再掩耳盗铃了！！！也请邮件组中的各位老板，你们仔细了解一下移植的难度，忙着点赞的同时也客观评价一下工作的进度。大家都是做技术出身的，你们都知道远离技术的真相是多么可怕的事情。李传钊 2021.7.23 962030(a)qq.com

2 1

request
by 许百茹 21 Jul '21

21 Jul '21

confirm d25587e49e27d9e482d4239111b8ede346c75f07 许百茹行业应用开发部北京思必拓科技有限责任公司 Beijing Speedata Technology Co., Ltd. 电话/Phone：010-8234-6858-609┃手机/Mobile：185-0195-6467 网址/Web：http://www.speedata.cn 邮箱/Email：bairu.xu(a)speedatagroup.com 地址/Address：北京市海淀区中关村南大街18号院北京国际大厦D座801 Room 801, Block D, Beijing International Building, No.18 Zhongguancun South Street, Haidian District, Beijing,China

1 0

SIG项目孵化询问
by Shi Yuhan 21 Jul '21

21 Jul '21

您好，我们在OpenHarmony-SIG仓下有个DLLite Micro组件需要孵化毕业，请问当前孵化合入OpenHarmony的要求有哪些？代码仓地址：dllite_micro: 为了支持AI模型在IoT设备上完成推理功能，使IoT设备具备AI能力，并能够更好的匹配OpenHarmonyOS的各种设备形态，DLLite SIG不仅需要为用户提供基础的推理服务，包括统一的API和 (gitee.com)<https://gitee.com/openharmony-sig/dllite_micro> 祝好！ Yuhan

1 0

【会议通知】 OpenHarmoy PMC Biweekly Meeting，时间：2021-07-22 14:30-16:00，地点：线上会议，请您准时与会：）
by hengting (A) 21 Jul '21

21 Jul '21

会议主题 Subject OpenHarmoy PMC Biweekly Meeting 会议时间 Time 2021-07-22 14:30-16:00(UTC+08:00)Beijing 会议地点 Location 线上会议召集人 Convener 董金光视频会议 Video Meeting 加入会议 : Join (Host) >><http://imeeting.huawei.com/meeting/startzoom?id=99f8191480664ab09125863680d…> Join (Internal) >><http://imeeting.huawei.com/meeting/joinzoom?id=0156054198&app=welink> Join (External) >><https://welink.zhumu.com/j/156054198> 会议ID : 015 605 419 8 与会人 Attendees 李毅；董金光；马占福；万承臻；任革林；王意明；邢文华；肖峰；聂欣外部与会人 External Participants noel@openatom.org,kelei@iscas.ac.cn<mailto:noel@openatom.org,kelei@iscas.ac.cn> 会议议题 Agenda 编号 No. 议题名称 Topic 议题背景介绍 Topic background introduction 时长 Duration 提案人 Proposer 汇报人 Reporter 纪要人 Recorder 议题参与人 Members 1 OpenHamony社区状态审视 20min 董金光邢文华邢文华 2 申请新增SIG：solution-component 将尚未收编到openharmony社区的一些OS公共基础能力通过SIG孵化，更方便快捷去支持南向生态拓展。 15min 李涛李涛李涛李涛、万承臻 3 qemu进展汇报 qemu标准化编译 qemu加入门禁 qemu图形显示和鼠标键盘输入 15min 李开龙李开龙马广耀张凯、朱生乐、马广耀、左永亮柏能 4 方舟JS/TS部分作为OpenHarmony的JS/TS语言编译工具链和运行时子系统开源 1）提供JS/TS编译工具链 2）提供JS语言运行时 15min 蒋晗蒋晗蒋晗龚俊松 5 新增blockchain sig 增加OH区块链功能拓展 5min 尚璇尚璇尚璇尚璇 6 新增python sig 为OH增加python样例 5min 唐佐林唐佐林唐佐林唐佐林 7 新增cicd sig OpenHarmony的CICD能力提升与改进 5min 梁克雷梁克雷梁克雷梁克雷/黄明龙 8 L2对Linux需求讨论L2对Linux的基础需求，便于三方芯片厂家接入 15min 梁克雷梁克雷梁克雷梁克雷、李之琦刘跃华、侯鹏飞候选哲、尹友展徐文方 9 新增 Linkboy sig 为OpenHarmony提供可视化编程能力 5min 王强王强王强王强会议公告 Bulletins 上次会议纪要如下：https://codehub-y.huawei.com/openharmony/mom_for_pmc/files?ref=mas… OpenHarmony Committer清单：https://codehub-y.huawei.com/openharmony/pmc-committer/files?re…

1 0

社区问题答复// openharmony桌面开发
by Lvzhongwei 17 Jul '21

17 Jul '21

默语：你好，你想了解的是在openharmony怎么开发桌面launcher应用本身，还是在桌面上开发一个应用？（1）如果是launcher本身，就关注开源仓，里面有代码实现和架构介绍 https://gitee.com/openharmony/applications_launcher （2）如果是开发应用，见应用开发入门指导 https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/quick-… [cid:image001.png@01D77B46.C3030080] ------------------------------------ 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! 发件人: 默语 [mailto:1101296726@qq.com] 发送时间: 2021年7月9日 9:31 收件人: dev <dev(a)openharmony.io<mailto:dev@openharmony.io>> 主题: [Dev] openharmony桌面开发请问现在有关于openharmony桌面开发的开源资料吗。

1 0

Re: 回复：企业如何参与到RK3399的适配工作
by qinfanzhong＠jlinksz.com 16 Jul '21

16 Jul '21

RK3399的适配工作有哪些进展了？大概什么时间可以释放到OpenHarmony社区 qinfanzhong(a)jlinksz.com 覃凡忠 13631628245 深圳市瑞拓创展科技有限公司深圳市南山区西丽平山一路南山云谷二期14栋6楼602 发件人： ‪noel@openatom.org‬ 发送时间： 2021-06-26 17:21 收件人： SM0387; dongjinguang(a)huawei.com; 梁克雷; 谭小凡抄送： dev(a)openharmony.io 主题： [Dev] 回复：企业如何参与到RK3399的适配工作非常感谢上海商米的同事 OH社区非常希望您这样的团队加入。目前3399的移植是由xzmu@openatom.org，xiaofan@iscas.ac.cn 在推进，请xzmu和xiaofan将上海商米的同事的力量整合起来发自手机 -------- 原始邮件 -------- 发件人： SM0387 <liyang(a)sunmi.com> 日期： 2021年6月24日周四上午10:52 收件人： dongjinguang(a)huawei.com 抄送： dev(a)openharmony.io 主题： [Dev] 企业如何参与到RK3399的适配工作您好, 我们是来自上海的一家企业: 上海商米科技集团股份有限公司, 我们致力于为商用领域提供丰富且优秀的智能IoT硬件及软硬结合的数字化解决方案. 我们的官网: https://www.sunmi.com/index 目前我们在进行Harmony的技术预研, 后续我们希望部分产品可以使用 Harmony OS. 我们从网上了解到 FireFly 在进行 RK3399的移植工作, 并且我们内部也有RK3399的量产项目, 我们团队拥有丰富的软硬件开发能力. 请问, 如何参与到 Harmony 的 RK3399 的移植项目? 李阳 15221450901 上海商米科技集团股份有限公司

1 0

Re: [SIG-Charter-Proposal-申请新增blockchain sig]
by minglong 14 Jul '21

14 Jul '21

金光，已经在石墨里面新增了两个议题。等下次PMC会议上我们推动两个Leader向大家做一下详细的介绍。感谢支持。祝好。 On Jul 14, 2021 17:36，dongjinguang<dongjinguang(a)huawei.com> wrote：明龙请一并参考 https://gitee.com/openharmony/community/blob/master/zh/pmc.md 申报议题，谢谢 From: minglong [mailto:minglong@iscas.ac.cn] Sent: Wednesday, July 14, 2021 4:04 PM To: dev(a)openharmony.io; shangxuan <shangxuan(a)hyperchain.cn> Subject: [Dev] Re: [SIG-Charter-Proposal-申请新增blockchain sig] 尚璇老师您好，我们之前已经收到您的新申请sig 组的申请了。原定于本周一的PMC会议未来得及参加。现将咱们的申请纳入到下周的PMC会议议题中去。请您与我们的工作人员对接，并按照规范提交咱们的相关文档。祝好。 minglong On Jul 14, 2021 15:33，shangxuan<shangxuan(a)hyperchain.cn> wrote：各位老师好：申请新增blockchain sig。sig 中文章程如下。中英文章程md文件见附件。欢迎批评指正！ # SIG Charter模板 ## SIG组工作目标和范围 ### 工作目标致力于探索物联网 + 区块链方向，打造「物链网OpenHarmony OS」，为OpenHarmony OS用户提供原生、友好、通用化的“上链”能力，满足用户在数据隐私服务，设备安全服务，身份保护服务的需求，打造物链网系统生态场景（碳中和、车生态、智慧城市、智慧社区、智能家居），构建万物互联场景下数字化可信基石。 ### 业务范围 - OpenHarmony数据上链功能以及兼容性需求提供OpenHarmony数据上链功能，深度定制可适配OpenHarmony的数据上链组件 - 样例工程创建物联网 + 区块链样例工程，给其他厂商做参考 - 生态拓展积极与物联网设备厂商进行洽谈合作，推动物链网应用场景落地，推广物链网操作系统生态。探索OpenHarmony + Blockchain在碳中和场景下的应用。 ## SIG相关代码仓及描述交付件形式：源码、文档等 - repository1名称： - repository2名称： ## SIG组成员 ### Leader - [Shangxuan](https://gitee.com/shangxuan_hz) ### Committers列表 - [haisong2](https://gitee.com/haisong2) - [Lee](https://gitee.com/www.lee.com) - [platformdepartment](https://gitee.com/platformdepartment) ### 会议 - 会议时间：双周例会，周二下午16:00 - 会议链接：在slack的oh-blockchain channel ### 联系方式(可选) - 邮件列表： - Slack群组：[oh-blockchain](https://oh-blockchain.slack.com/archives/C026W6NT7D… - 微信群：尚璇基础平台部 Mail: shangxuan(a)hyperchain.cn Mobile: +86 15305711806 Address: 浙江省杭州市丹枫路399号2号楼A楼2001室

1 0

harmongOS 是否已经支持图片识别功能
by Zhang,Enzhi 14 Jul '21

14 Jul '21

Harmony开发者：你好，我是软件开发者，想质询一下，现在harmongOS是否已经支持 android 的 tensorflow lite（图片识别）功能。或者有类似的插件吗？

2 1

Re: [SIG-Charter-Proposal-申请新增blockchain sig]
by minglong 14 Jul '21

14 Jul '21

尚璇老师您好，我们之前已经收到您的新申请sig 组的申请了。原定于本周一的PMC会议未来得及参加。现将咱们的申请纳入到下周的PMC会议议题中去。请您与我们的工作人员对接，并按照规范提交咱们的相关文档。祝好。 minglong On Jul 14, 2021 15:33，shangxuan<shangxuan(a)hyperchain.cn> wrote：各位老师好：申请新增blockchain sig。sig 中文章程如下。中英文章程md文件见附件。欢迎批评指正！ # SIG Charter模板 ## SIG组工作目标和范围 ### 工作目标致力于探索物联网 + 区块链方向，打造「物链网OpenHarmony OS」，为OpenHarmony OS用户提供原生、友好、通用化的“上链”能力，满足用户在数据隐私服务，设备安全服务，身份保护服务的需求，打造物链网系统生态场景（碳中和、车生态、智慧城市、智慧社区、智能家居），构建万物互联场景下数字化可信基石。 ### 业务范围 - OpenHarmony数据上链功能以及兼容性需求提供OpenHarmony数据上链功能，深度定制可适配OpenHarmony的数据上链组件 - 样例工程创建物联网 + 区块链样例工程，给其他厂商做参考 - 生态拓展积极与物联网设备厂商进行洽谈合作，推动物链网应用场景落地，推广物链网操作系统生态。探索OpenHarmony + Blockchain在碳中和场景下的应用。 ## SIG相关代码仓及描述交付件形式：源码、文档等 - repository1名称： - repository2名称： ## SIG组成员 ### Leader - [Shangxuan](https://gitee.com/shangxuan_hz) ### Committers列表 - [haisong2](https://gitee.com/haisong2) - [Lee](https://gitee.com/www.lee.com) - [platformdepartment](https://gitee.com/platformdepartment) ### 会议 - 会议时间：双周例会，周二下午16:00 - 会议链接：在slack的oh-blockchain channel ### 联系方式(可选) - 邮件列表： - Slack群组：[oh-blockchain](https://oh-blockchain.slack.com/archives/C026W6NT7D… - 微信群：尚璇基础平台部 Mail: shangxuan(a)hyperchain.cn Mobile: +86 15305711806 Address: 浙江省杭州市丹枫路399号2号楼A楼2001室

2 1

[SIG-Charter-Proposal-申请新增blockchain sig]
by shangxuan 14 Jul '21

14 Jul '21

1 0

openharmony桌面开发
by 默语 09 Jul '21

09 Jul '21

请问现在有关于openharmony桌面开发的开源资料吗。

1 0

[VOTE] New Committer luoboming@huawei.com
by zhengbin (C) 06 Jul '21

06 Jul '21

各位PMC/committer专家：提名luoboming(a)huawei.com<mailto:提名luoboming@huawei.com>为以下模块的committer, zhengbin5(a)huawei.xn--comcommitter-cy4s10mf7jr3ykpzsls9fbu61g1sfiw2e.xn--,-116ax6wca60zda0po5ri8q7hbny5mzs5bja831ck1o +1，不赞成请回复 -1 及不赞成原因。 https://gitee.com/openharmony/third_party_icu https://gitee.com/openharmony/global_i18n_lite luoboming是国际化领域的专家，同时也承担了icu及i18n模块方案设计及初始代码开发，对该模块非常熟悉，可以承担committer职责。

1 0

账号不能同步问题
by lexueye 06 Jul '21

06 Jul '21

我的watch3 pro手表，在和mate 40同步华为账号的时候总是等待，过一段时间之后就提示同步失败，已经同步了很多次了，一直不成功，请问是什么问题？请帮忙一下，谢谢。 15653469100 网易VIP邮箱提醒：安全收发邮件，务必核实往来邮件地址、银行账号等机密信息，请通过电话或视频等多种方式确认信息真实性，提高警惕，请勿轻易透露个人重要信息。 Alert message of Netease Vipmail：Never provide your password, security questions, verification codes, or any other personal important information details to anyone else. You can identify mail message by telephone,video-chat or other ways.You should make sure that your email address, bank account and other confidential information as secure as possible. Thank you for keeping your email account secure.

1 0

开发版Hi3516DV300 烧录失败求助！！！
by Bifeng Zhang 张笔峰 06 Jul '21

06 Jul '21

您好，我买了一块Hi3516DV300的开发板子，使用源码编译后的img文件烧录失败，麻烦大神帮我看看是哪里出了问题，在此衷心感谢您的协助。 1，源码编译结果如下： 2，visual studio code 配置和文件拷贝如下 2.1 我把需要的img都拷贝到了Hi3516下。 2.2 visual studio code 配置如下以上配置都是参照 https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/quick-start… 3，执行下面这步擦除U-Boot成功了。 4.执行下面这步烧录失败了。 4.1 ，失败日志显示如下，详细日志在附件中； The preference.config file was loaded successfully! SerialPort has been connented, Please power off, then power on the device. If it doesn't work, please try to repower on. # ---- 36% # ---- 63% ---- 100% Boot download completed! Failed to wait boot running! There may be no boot on the board. Boot started successfully! Send command: getinfo version Timeout error. Failed to send the command head! Failed to load version info! Failed to Prepare for other partitions! hiburn.jar --burn [-x xmlPath] [-p programmerPath] This command will burn image to the flash according to the partition table xmlPath. First of all, you need to configure the burn.config file. 4.2 ,反复尝试上面的烧录步骤都不成功。 5，此开发版烧录前是正常可使用的。 --------------------------------------------------- bifeng.zhang(a)midea.com 张笔峰 17097236214 地址：深圳市南山区怡化金融科技大厦22层

1 0

visual studio code 报 huawei.deveco-device-tool无法找到
by Bifeng Zhang 张笔峰 06 Jul '21

06 Jul '21

你好，我在ubuntu上使用visual studio code ,它总是在报下面这个错误，这是什么原因？ The 1 extension(s) below, in workspace recommendations have issues: huawei.deveco-device-tool (not found in marketplace) --------------------------------------------------- bifeng.zhang(a)midea.com 张笔峰 17097236214 地址：深圳市南山区怡化金融科技大厦22层 ------------------------------ --------------------------------------------------- bifeng.zhang(a)midea.com 张笔峰 17097236214 地址：深圳市南山区怡化金融科技大厦22层

2 1

[SIG-Charter-Proposal-申请创建mini-solution-component SIG]
by Litao (Tom) 05 Jul '21

05 Jul '21

# SIG组简体中文 | [English](./sig-mini-solution-component.md) 说明：本SIG的内容遵循OpenHarmony的PMC管理章程 [README](/zh/pmc.md)中描述的约定。 ## SIG组工作目标和范围 ### 工作目标为OpenHarmony轻量系统的开发者提供丰富的轻量级组件。 ### 工作范围提供OpenHarmony轻量系统的非官方组件，包括芯片架构支持、开发板支持、三方组件等。 ## 代码仓 - 代码仓地址： - cortex-m33：https://gitee.com/openharmony-sig/cortex-m33 - stm32l552: https://gitee.com/openharmony-sig/stm32l552 - thttpd: https://gitee.com/openharmony-sig/thttpd ## SIG组成员 ### Leader - @LiTao(https://gitee.com/litao33) ### Committers列表 - @harmony_zhangjian(https://gitee.com/harmony_zhangjian) - @xun-g(https://gitee.com/xun-g) - @lyer_hu(https://gitee.com/lyer_hu) - @taiyipei(https://gitee.com/taiyipei) - @pilipala195(https://gitee.com/pilipala195) ### 会议 - 会议时间：每周二 14:00 - 会议链接：Welink ### 联系方式(可选) - 邮件列表：litao33(a)huawei.com; zhangjian112(a)huawei.com; guanxun(a)huawei.com; lyer.hu(a)huawei.com; peitaiyi(a)huawei.com; yangguangzhao1(a)huawei.com - Slack群组：NA - 微信群：NA

2 1

SIG-Charter-Proposal-Notificaion
by 刘威 05 Jul '21

05 Jul '21

新建SIG申请: 事件通知SIG https://gitee.com/openharmony/community/pulls/182

1 0

[PMC] [VOTE]提名distributeddatamgr_datamgr仓新的备份committer: 紫丁花絮 https://gitee.com/purple-ding-gags
by Xuchao (Tom, MBB) 02 Jul '21

02 Jul '21

Hi, 各位PMC成员，提名紫丁花絮 https://gitee.com/purple-ding-gags作为https://gitee.com/openharmony/distribut… https://gitee.com/openharmony/distributeddatamgr_appdatamgr/issues/I3SMI1?f… https://gitee.com/openharmony/utils_native_lite/issues/I3ICH0?from=project-… https://gitee.com/openharmony/utils_native_lite/issues/I3ICGH?from=project-… https://gitee.com/openharmony/utils_native_lite/issues/I3ICG4?from=project-… https://gitee.com/openharmony/utils_native_lite/issues/I3ICFO?from=project-…

1 0