- dev - lists.openatom.io

刷新会议时间为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