diff --git a/contribute/OpenHarmony-c-coding-style-guide.md b/contribute/OpenHarmony-c-coding-style-guide.md index e365d16137017dcbbca54fa4e83f6b7f62266875..609c6f9945e7c7517c0aba272ba84dca90f3ba39 100755 --- a/contribute/OpenHarmony-c-coding-style-guide.md +++ b/contribute/OpenHarmony-c-coding-style-guide.md @@ -666,34 +666,6 @@ int Foo(const char * restrict p); // OK. ### 规则2.12 编译预处理的"#"默认放在行首，嵌套编译预处理语句时，"#"可以进行缩进 编译预处理的"#"统一放在行首；即便编译预处理的代码是嵌入在函数体中的，"#"也应该放在行首。 -```c -#if defined(__x86_64__) && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16) // Good："#"放在行首 -#define ATOMIC_X86_HAS_CMPXCHG16B 1 // Good："#"放在行首 -#else -#define ATOMIC_X86_HAS_CMPXCHG16B 0 -#endif - -int FunctionName(void) -{ - if (someThingError) { - ... -#ifdef HAS_SYSLOG // Good：即便在函数内部，"#"也放在行首 - WriteToSysLog(); -#else - WriteToFileLog(); -#endif - } -} -``` - -嵌套的预处理语句"#"可以按照缩进要求进行缩进对齐，区分层次。 -```c -#if defined(__x86_64__) && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16) - #define ATOMIC_X86_HAS_CMPXCHG16B 1 // Good：区分层次，便于阅读 -#else - #define ATOMIC_X86_HAS_CMPXCHG16B 0 -#endif -``` ## 空格和空行 @@ -850,7 +822,7 @@ int Foo(void) ### 规则3.1 文件头注释必须包含版权许可 /* - * Copyright (c) 2020 Huawei Device Co., Ltd. + * Copyright (c) 2020 XXX * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at @@ -979,19 +951,10 @@ int bar = 200; /* 放右边的注释 */ 这里说的注释掉代码，包括用 /\* \*/ 和 //，还包括 #if 0， #ifdef NEVER_DEFINED 等等。 -### 建议3.1 正式交付的代码不能包含 TODO/TBD/FIXME 注释 - -TODO/TBD 注释一般用来描述已知待改进、待补充的修改点 -FIXME 注释一般用来描述已知缺陷 -它们都应该有统一风格，方便文本搜索统一处理。如： -```c -// TODO(): 补充XX处理 -// FIXME: XX缺陷 -``` 在版本开发阶段，可以使用此类注释用于突出标注；交付前应该全部处理并删除掉。 -### 建议3.2 case语句块结束时如果不加break/return，需要有注释说明(fall-through) +### 建议3.1 case语句块结束时如果不加break/return，需要有注释说明(fall-through) 有时候需要对多个case标签做相同的事情，case语句在结束不加break或return，直接执行下一个case标签中的语句，这在C语法中称之为"fall-through"。 这种情况下，需要在"fall-through"的地方加上注释，清晰明确的表达出这样做的意图；或者至少显式指明是 "fall-through"。 @@ -1470,7 +1433,7 @@ int OtherFunc(void) #define ASSERT(x) do { \ if (!(x)) { \ printk(KERN_EMERG "assertion failed %s: %d: %s\n", \ - __FILE__, __LINE__, #x); \ + __FILE__, __LINE__, #x); \ BUG(); \ } \ } while (0) diff --git a/contribute/OpenHarmony-cpp-coding-style-guide.md b/contribute/OpenHarmony-cpp-coding-style-guide.md index 6705fbb68bee01c7981997b2fa7743f3e75726f3..9eaeb589e8aaa5b757d3672757685777ead3226b 100755 --- a/contribute/OpenHarmony-cpp-coding-style-guide.md +++ b/contribute/OpenHarmony-cpp-coding-style-guide.md @@ -38,7 +38,7 @@ ## 通用命名 __驼峰风格(CamelCase)__ 大小写字母混用，单词连在一起，不同单词间通过单词首字母大写来分开。 -按连接后的首字母是否大写，又分: 大驼峰(UperCamelCase)和小驼峰(lowerCamelCase) +按连接后的首字母是否大写，又分: 大驼峰(UpperCamelCase)和小驼峰(lowerCamelCase) | 类型 | 命名风格 | @@ -60,7 +60,7 @@ __驼峰风格(CamelCase)__ 目前业界还有一些其他的后缀的表示方法： - 头文件： .hh, .hpp, .hxx -- cpp文件：.cc, .cxx, .C +- cpp文件：.cc, .cxx, .c 如果当前项目组使用了某种特定的后缀，那么可以继续使用，但是请保持风格统一。 但是对于本文档，我们默认使用.h和.cpp作为后缀。 @@ -416,7 +416,7 @@ default: // Bad: default 未缩进 // 假设下面第一行已经不满足行宽要求 ```cpp -if (currentValue > threshold && // Good：换行后，逻辑操作符放在行尾 +if ((currentValue > threshold) && // Good：换行后，逻辑操作符放在行尾 someConditionsion) { DoSomething(); ... @@ -475,11 +475,11 @@ const int rank[] = { ### 建议3.12.1 指针类型"`*`"跟随变量名或者类型，不要两边都留有或者都没有空格 指针命名: `*`靠左靠右都可以，但是不要两边都有或者都没有空格。 ```cpp -int* p = NULL; // Good -int *p = NULL; // Good +int* p = nullptr; // Good +int *p = nullptr; // Good -int*p = NULL; // Bad -int * p = NULL; // Bad +int*p = nullptr; // Bad +int * p = nullptr; // Bad ``` 例外：当变量被 const 修饰时，"`*`" 无法跟随变量，此时也不要跟随类型。 @@ -506,35 +506,6 @@ int&p = i; // Bad ### 规则3.13.1 编译预处理的"#"统一放在行首，嵌套编译预处理语句时，"#"可以进行缩进 编译预处理的"#"统一放在行首，即使编译预处理的代码是嵌入在函数体中的，"#"也应该放在行首。 -```cpp -#if defined(__x86_64__) && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16) // Good："#"放在行首 -#define ATOMIC_X86_HAS_CMPXCHG16B 1 // Good："#"放在行首 -#else -#define ATOMIC_X86_HAS_CMPXCHG16B 0 -#endif - - -int FunctionName() -{ - if (someThingError) { - ... -#ifdef HAS_SYSLOG // Good：即便在函数内部，"#"也放在行首 - WriteToSysLog(); -#else - WriteToFileLog(); -#endif - } -} -``` -内嵌的预处理语句"#"可以按照缩进要求进行缩进对齐，区分层次。 - -```cpp -#if defined(__x86_64__) && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16) - #define ATOMIC_X86_HAS_CMPXCHG16B 1 // Good：区分层次，便于阅读 -#else - #define ATOMIC_X86_HAS_CMPXCHG16B 0 -#endif -``` ## 空格和空行 ### 规则3.14.1 水平空格应该突出关键字和重要信息，避免不必要的留白 @@ -794,7 +765,7 @@ MyClass::MyClass(int var) ### 规则3.1 文件头注释必须包含版权许可 /* - * Copyright (c) 2020 Huawei Device Co., Ltd. + * Copyright (c) 2020 XXX * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at @@ -925,17 +896,6 @@ const int ANOTHER_CONST = 200; /* 上下对齐时，与左侧代码保持间 这里说的注释掉代码，包括用 /* */ 和 //，还包括 #if 0， #ifdef NEVER_DEFINED 等等。 -### 建议4.4.1 正式交付给客户的代码不能包含 TODO/TBD/FIXME 注释 -TODO/TBD 注释一般用来描述已知待改进、待补充的修改点 -FIXME 注释一般用来描述已知缺陷 -它们都应该有统一风格，方便文本搜索统一处理。如： - -```cpp -// TODO(): 补充XX处理 -// FIXME: XX缺陷 -``` - - # 5 头文件 ## 头文件职责 头文件是模块或文件的对外接口，头文件的设计体现了大部分的系统设计。 @@ -1145,7 +1105,7 @@ extern "C" { namespace { const int MAX_COUNT = 20; - void InternalFun(){}; + void InternalFun() {}; } void Foo::Fun() @@ -1339,7 +1299,7 @@ message.ProcessOutMsg(); // 后续使用存在隐患 // 因此，有必要定义默认构造函数，如下： class Message { public: - Message() : msgID_(0), msgLength_(0), msgBuffer_(NULL) + Message() : msgID_(0), msgLength_(0), msgBuffer_(nullptr) { } @@ -1364,7 +1324,7 @@ class Message { public: Message() : msgLength_(0) // Good，优先使用初始化列表 { - msgBuffer_ = NULL; // Bad，不推荐在构造函数中赋值 + msgBuffer_ = nullptr; // Bad，不推荐在构造函数中赋值 } private: @@ -1448,7 +1408,7 @@ private: ### 规则7.1.5 移动构造和移动赋值操作符应该是成对出现或者禁止 在C++11中增加了move操作，如果需要某个类支持移动操作，那么需要实现移动构造和移动赋值操作符。 -移动构造函数和移动赋值操作符都是具有移动语义的，应该同时出现或者禁?止。 +移动构造函数和移动赋值操作符都是具有移动语义的，应该同时出现或者禁止。 ```cpp // 同时出现 class Foo { @@ -1524,7 +1484,7 @@ public: ```cpp class Sub : public Base { public: - Sub() : numbers_(NULL) + Sub() : numbers_(nullptr) { } @@ -1538,7 +1498,7 @@ public: { const size_t numberCount = 100; numbers_ = new (std::nothrow) int[numberCount]; - if (numbers_ == NULL) { + if (numbers_ == nullptr) { return -1; } @@ -1738,8 +1698,8 @@ void FooListAddNode(void *node) // Bad: 这里用 void * 类型传递参数 void MakeTheList() { - FooNode *foo = NULL; - BarNode *bar = NULL; + FooNode *foo = nullptr; + BarNode *bar = nullptr; ... FooListAddNode(bar); // Wrong: 这里本意是想传递参数 foo，但错传了 bar，却没有报错 @@ -2097,7 +2057,7 @@ const int MAX_ARRAY_SIZE = 100; int* numberArray = new int[MAX_ARRAY_SIZE]; ... delete numberArray; -numberArray = NULL; +numberArray = nullptr; ``` 正确写法： @@ -2106,7 +2066,7 @@ const int MAX_ARRAY_SIZE = 100; int* numberArray = new int[MAX_ARRAY_SIZE]; ... delete[] numberArray; -numberArray = NULL; +numberArray = nullptr; ``` ### 建议9.4.1 使用 RAII 特性来帮助追踪动态分配 @@ -2206,7 +2166,7 @@ void Fun2() auto_ptr p1(new T); auto_ptr p2 = p1; ``` -当执行完第2行语句后，p1已经不再指向第1行中分配的对象，而是变为NULL。正因为如此，auto_ptr不能被置于各种标准容器中。 +当执行完第2行语句后，p1已经不再指向第1行中分配的对象，而是变为nullptr。正因为如此，auto_ptr不能被置于各种标准容器中。 转移所有权的行为通常不是期望的结果。对于必须转移所有权的场景，也不应该使用隐式转移的方式。这往往需要程序员对使用auto_ptr的代码保持额外的谨慎，否则出现对空指针的访问。 使用auto_ptr常见的有两种场景，一是作为智能指针传递到产生auto_ptr的函数外部，二是使用auto_ptr作为RAII管理类，在超出auto_ptr的生命周期时自动释放资源。 对于第1种场景，可以使用std::shared_ptr来代替。 diff --git "a/contribute/\347\244\276\345\214\272\346\262\237\351\200\232\344\270\216\344\272\244\346\265\201.md" "b/contribute/\347\244\276\345\214\272\346\262\237\351\200\232\344\270\216\344\272\244\346\265\201.md" index 8a03cb750e1b114db14550a2760e89c6867104d4..972a744c7b2f43c5111f2ef85118641f1b657559 100755 --- "a/contribute/\347\244\276\345\214\272\346\262\237\351\200\232\344\270\216\344\272\244\346\265\201.md" +++ "b/contribute/\347\244\276\345\214\272\346\262\237\351\200\232\344\270\216\344\272\244\346\265\201.md" @@ -6,75 +6,64 @@ 如果您以前从未订阅过邮件列表，请参照下面的操作步骤。 -1. 先发一个空邮件到您需要订阅的邮件列表。 -2. 稍后您会收到一封确认邮件，对它进行回复即可完成订阅。 -3. 在订阅成功后，请再发送您的问题到该邮件地址，那么所有订阅该邮件组的其它用户将会收到您的邮件，并做出分享。 +1. 点击您想要订阅的邮件列表的名称。 +2. 浏览器将跳转到该邮件列表的订阅页面，那里将提供有关如何订阅的说明。 +3. 阅读订阅说明，您需要提供一个您希望用来订阅邮件列表的电子邮件地址。 +4. 输入您的电子邮件地址并点击订阅，您将收到一封电子邮件，要求您确认订阅。 +5. 回复您收到的电子邮件以确认您的订阅。 +6. 最后您将收到来自一封来自邮件列表的欢迎邮件。 **表 1** : 邮件列表 - - @@ -87,7 +87,7 @@ To enable the primary device \(smart TV\) to start an FA of the secondary device } ``` -3. Create a **Want** instance. You should first create an **ElementName** object with **deviceID**, **bundleName**, **abilityName** specified and add this object to the **Want** instance. Then, set the multi-device startup flag **Want.FLAG\_ABILITYSLICE\_MULTI\_DEVICE** to the **Want** instance to enable remote FA startup. +3. Create a **Want** instance. You should first create an **ElementName** object with **deviceId**, **bundleName**, **abilityName** specified and add this object to the **Want** instance. Then, set the multi-device startup flag **Want.FLAG\_ABILITYSLICE\_MULTI\_DEVICE** to the **Want** instance to enable remote FA startup. ``` // Import related header files. @@ -101,7 +101,7 @@ To enable the primary device \(smart TV\) to start an FA of the secondary device ElementName name = new ElementName(remote_device_id, "com.huawei.remote_package_name", "remote_class_name"); want.setElement(name); // Add information about the target FA for startup to the Want instance. want.setFlags(Want.FLAG_ABILITYSLICE_MULTI_DEVICE); // Set the multi-device startup flag. If this flag is not set, remote FA startup will be unavailable. - startAbility(want); // Start the specified FA based on the want parameter. If the name of the want parameter is different from that used in the IDE, use the parameter name in the IDE. + startAbility(want); // Start the specified FA based on the want parameter. If the name and type of the want parameter are different from those used in the IDE, use the parameter name and type in the IDE. ``` diff --git a/docs-en/subsystems/overview.md b/docs-en/subsystems/overview.md index 6d35d26553dcae711c4a9a477ad26807d4e90c55..18ba8e6026404d0053d43f766ede3762d1e09c38 100755 --- a/docs-en/subsystems/overview.md +++ b/docs-en/subsystems/overview.md @@ -2,7 +2,7 @@ ## Basic Concepts -Camera is one of the services provided by the OpenHarmony media subsystem. The camera module provides recording, preview, and photographing features and supports concurrent stream reading by multiple users. +Camera is one of the services provided by the OpenHarmony multimedia subsystem. The camera module provides recording, preview, and photographing features and supports concurrent stream reading by multiple users. It is considered good practice that you understand the following concepts before starting development: @@ -21,11 +21,11 @@ It is considered good practice that you understand the following concepts before ## Working Principles -- Media services +- Multimedia services - Media services are started by the **Init** process upon system startup, and media hardware resources \(such as memory, display hardware, image sensors, and codecs\) are initialized and allocated. During the initialization, the configuration file is parsed, which determines the upper limit of capabilities and resources of each service. Generally, the upper limit is configured by original equipment manufacturers \(OEMs\) in the configuration file. The following configuration items are available for the camera service during media service initialization: + Multimedia services are started by the **Init** process upon system startup, and media hardware resources \(such as memory, display hardware, image sensors, and codecs\) are initialized and allocated. During the initialization, the configuration file is parsed, which determines the upper limit of capabilities and resources of each service. Generally, the upper limit is configured by original equipment manufacturers \(OEMs\) in the configuration file. The following configuration items are available for the camera service during multimedia service initialization: - - Memory pool: Memory blocks in the memory pool are accessed and released continuously by all media services. + - Memory pool: Memory blocks in the memory pool are accessed and released continuously by all multimedia services. - Image sensor: sensor type, resolution, ISP, and more - Image processor: resolution, bit rate, image inversion, and more - Image encoder: encoding format, bit rate, resolution, and more diff --git "a/get-code/\346\272\220\347\240\201\350\216\267\345\217\226.md" "b/get-code/\346\272\220\347\240\201\350\216\267\345\217\226.md" index faa0944177d2823ec81b6c58113d86b24780c0ee..4a9dbd455c5876eb87fa60ac32eb9858a0a72127 100755 --- "a/get-code/\346\272\220\347\240\201\350\216\267\345\217\226.md" +++ "b/get-code/\346\272\220\347\240\201\350\216\267\345\217\226.md" @@ -41,7 +41,7 @@ OpenHarmony是HarmonyOS的开源版，由华为捐赠给开放原子开源基金 - @@ -50,7 +50,7 @@ OpenHarmony是HarmonyOS的开源版，由华为捐赠给开放原子开源基金 - @@ -59,7 +59,7 @@ OpenHarmony是HarmonyOS的开源版，由华为捐赠给开放原子开源基金 - @@ -234,13 +234,13 @@ OpenHarmony是HarmonyOS的开源版，由华为捐赠给开放原子开源基金 方式一（推荐）：通过repo下载 ``` -repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify +repo init -u https://gitee.com/openharmony/manifest.git -b master repo sync -c ``` 方式二：通过git clone单个代码仓库 -进入代码仓库主页：https://gitee.com/openharmony，选择需要克隆的代码仓库，执行命令，如： +进入代码仓库主页：[https://gitee.com/openharmony](https://gitee.com/openharmony)，选择需要克隆的代码仓库，执行命令，如： ``` git clone https://gitee.com/openharmony/manifest.git -b master diff --git "a/guide/figures/\344\277\256\346\224\271\346\250\241\346\235\277.png" "b/guide/figures/\344\277\256\346\224\271\346\250\241\346\235\277.png" new file mode 100755 index 0000000000000000000000000000000000000000..9c05b8dd365bf0bad7f46eb526d248dd2116bf98 Binary files /dev/null and "b/guide/figures/\344\277\256\346\224\271\346\250\241\346\235\277.png" differ diff --git "a/guide/figures/\351\200\211\346\213\251\345\267\245\347\250\213\346\250\241\346\235\277.png" "b/guide/figures/\351\200\211\346\213\251\345\267\245\347\250\213\346\250\241\346\235\277.png" new file mode 100755 index 0000000000000000000000000000000000000000..1b48acb2b9e5ac5f73c96f09f72233791289eabb Binary files /dev/null and "b/guide/figures/\351\200\211\346\213\251\345\267\245\347\250\213\346\250\241\346\235\277.png" differ diff --git "a/guide/\345\274\200\345\217\221\345\207\206\345\244\207.md" "b/guide/\345\274\200\345\217\221\345\207\206\345\244\207.md" index e0d166a7b8ca3a6d1e0eedb1c239f311be4b16c7..68d25afb41eac9f2967bca33cbca41620df5e180 100755 --- "a/guide/\345\274\200\345\217\221\345\207\206\345\244\207.md" +++ "b/guide/\345\274\200\345\217\221\345\207\206\345\244\207.md" @@ -6,5 +6,21 @@ ## 创建项目 -参考[《DevEco Studio使用指南》](https://developer.harmonyos.com/cn/docs/documentation/doc-guides/tools_overview-0000001053582387)创建项目章节。 +当前的DevEco Studio提供基本的开发功能，界面预览、代码调测将在下个版本提供，敬请期待。 + +请根据如下步骤创建工程（暂不支持直接创建“smartVision”类型项目）。 + +1. 运行DevEco Studio，点击**File \> Project**，选择“Lite Wearable”下的“Empty Feature Ability”模板。 + + **图 1** 选择工程模板 + ![](figures/选择工程模板.png "选择工程模板") + +2. 创建成功后，修改**entry \> src \> main**目录下的config.json文件。 + 1. 将“deviceType”的取值修改为"smartVision"。 + 2. 在abilities数组内新增“visible”属性，取值设置为“true”。 + + **图 2** 修改模板 + ![](figures/修改模板.png "修改模板") + + diff --git "a/guide/\346\267\273\345\212\240\351\241\265\351\235\242.md" "b/guide/\346\267\273\345\212\240\351\241\265\351\235\242.md" index e61100119cd771ab27aaa26c120178c2b66af414..bc54e1fe33747a0710674ded8ea184e37abd88cd 100755 --- "a/guide/\346\267\273\345\212\240\351\241\265\351\235\242.md" +++ "b/guide/\346\267\273\345\212\240\351\241\265\351\235\242.md" @@ -1,6 +1,6 @@ # 添加页面 -## 创建首页面（创建工程） +## 创建首页面 空气质量监测App包含三个界面，工程创建完成后自带一个Page，工程目录如下图所示： diff --git "a/guide/\347\234\237\346\234\272\350\277\220\350\241\214.md" "b/guide/\347\234\237\346\234\272\350\277\220\350\241\214.md" index 882f6f8d28c39c0e4ee5248e3188e3783e072038..7739cf2a534156485191dbacfa5ca82f814f6ea7 100755 --- "a/guide/\347\234\237\346\234\272\350\277\220\350\241\214.md" +++ "b/guide/\347\234\237\346\234\272\350\277\220\350\241\214.md" @@ -1,20 +1,20 @@ # 真机运行 -开发板介绍及编译烧录、运行镜像基本流程参考对应开发板快速入门手册：[Hi3516快速入门](../quick-start/Hi3516开发板介绍.md)，执行完镜像运行步骤，系统正常启动后，执行如下步骤。 +开发板介绍及编译烧录、运行镜像基本流程参考对应开发板快速入门手册：[Hi3516快速入门](../quick-start/Hi3516开发板介绍.md)，执行完镜像运行步骤，系统正常启动后，执行如下步骤安装或卸载三方应用。 -1. 安装三方应用（仅供debug版本调试使用） +1. IPCamera应用暂时不支持签名模式，将IDE编译的未签名应用安装包和安装工具（镜像文件生成目录中的dev\_tools）放在sdcard中。 +2. 执行./sdcard/dev\_tools/bin/bm set -s disable命令关闭签名校验。 +3. 执行./sdcard/dev\_tools/bin/bm install -p /sdcard/airquality.hap 命令安装应用。 - 将应用安装包（带debug签名）和安装工具（镜像文件生成目录中的dev\_tools）放在sdcard中，安装过程如下： + 其中dev\_tools目录中是安装工具，airquality.hap为应用安装包。 - 1. 执行./sdcard/dev\_tools/bin/bm set -d enable命令开启签名调试模式； - 2. 执行./sdcard/dev\_tools/bin/bm install -p /sdcard/airquality.hap 命令安装应用。其中dev\_tools目录中是安装工具，airquality.hap为应用安装包； - 3. 应用安装完成后，点击桌面应用图标启动应用； +4. 应用安装完成后，点击桌面应用图标启动应用。 **图 1** 桌面 ![](figures/桌面.png "桌面") -2. 卸载应用 +5. 卸载应用（可选）。 - 长按桌面应用图标，在弹出的菜单中点击卸载按钮即可卸载应用； + 长按桌面应用图标，在弹出的菜单中点击“卸载”按钮即可卸载应用。 diff --git "a/quick-start/Hi3861\345\274\200\345\217\221\346\235\277\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" "b/quick-start/Hi3861\345\274\200\345\217\221\346\235\277\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" index f518cf7057f14fc91c2d7e1b60fabec7168b7225..076e5b7d9334ff3373744047e559eaa9ea5d734d 100755 --- "a/quick-start/Hi3861\345\274\200\345\217\221\346\235\277\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" +++ "b/quick-start/Hi3861\345\274\200\345\217\221\346\235\277\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" @@ -4,7 +4,7 @@ ## 源码获取 -开发者需要在Linux服务器上下载一套源代码，获取Hi3861源码（[站点1](http://tools.harmonyos.com/mirrors/os/1.0/wifiiot-1.0.tar.gz)、[站点2](https://mirrors.huaweicloud.com/harmonyos/1.0/wifiiot-1.0.tar.gz)）。更多源码获取方式，请见[源码获取](../get-code/源码获取.md)。 +开发者需要在Linux服务器上下载一套源代码，获取Hi3861源码（[下载链接](http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz)）。更多源码获取方式，请见[源码获取](../get-code/源码获取.md)。 ## 源码编译 diff --git "a/quick-start/\345\274\200\345\217\221Hi3516\347\254\254\344\270\200\344\270\252\345\272\224\347\224\250\347\250\213\345\272\217\347\244\272\344\276\213.md" "b/quick-start/\345\274\200\345\217\221Hi3516\347\254\254\344\270\200\344\270\252\345\272\224\347\224\250\347\250\213\345\272\217\347\244\272\344\276\213.md" index f86f85427a5b4c111f378750fdeea377a7dda022..15801a72dd750930e6f28fd4c962d94e190156e6 100755 --- "a/quick-start/\345\274\200\345\217\221Hi3516\347\254\254\344\270\200\344\270\252\345\272\224\347\224\250\347\250\213\345\272\217\347\244\272\344\276\213.md" +++ "b/quick-start/\345\274\200\345\217\221Hi3516\347\254\254\344\270\200\344\270\252\345\272\224\347\224\250\347\250\213\345\272\217\347\244\272\344\276\213.md" @@ -4,7 +4,7 @@ ## 获取源码 -开发者需要在Linux服务器上下载一套源代码，获取Hi3516源码（[站点1](http://tools.harmonyos.com/mirrors/os/1.0/ipcamera_hi3516dv300-1.0.tar.gz)、[站点2](https://mirrors.huaweicloud.com/harmonyos/1.0/ipcamera_hi3516dv300-1.0.tar.gz)）。更多源码获取方式，请见[源码获取](../get-code/源码获取.md)。 +开发者需要在Linux服务器上下载一套源代码，获取Hi3516源码（[下载链接](http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz)）。更多源码获取方式，请见[源码获取](../get-code/源码获取.md)。 ## 修改应用程序 diff --git "a/quick-start/\345\274\200\345\217\221Hi3518\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" "b/quick-start/\345\274\200\345\217\221Hi3518\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" index 04dc9c1ba0321af8a38745787473098485768c30..1397fff09f0ecb4c98dfd9a2e33dd9c4a6637a32 100755 --- "a/quick-start/\345\274\200\345\217\221Hi3518\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" +++ "b/quick-start/\345\274\200\345\217\221Hi3518\347\254\254\344\270\200\344\270\252\347\244\272\344\276\213\347\250\213\345\272\217.md" @@ -4,7 +4,7 @@ ## 获取源码 -开发者需要在Linux服务器上下载一套源代码，获取Hi3518源码（[站点1](http://tools.harmonyos.com/mirrors/os/1.0/ipcamera_hi3518ev300-1.0.tar.gz)、[站点2](https://mirrors.huaweicloud.com/harmonyos/1.0/ipcamera_hi3518ev300-1.0.tar.gz)）。更多源码获取方式，请见[源码获取](../get-code/源码获取.md)。 +开发者需要在Linux服务器上下载一套源代码，获取Hi3518源码（[下载链接](http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz)）。更多源码获取方式，请见[源码获取](../get-code/源码获取.md)。 ## 修改应用程序 @@ -115,5 +115,5 @@ Hi3518EV300单板请使用串口烧写。 ## 下一步学习 -恭喜您，已完成Hi3518的快速上手！建议您下一步进入[无屏摄像头产品开发](../guide/摄像头控制.md)的学习 。 +恭喜您，已完成Hi3518的快速上手！建议您下一步进入[无屏摄像头产品开发](zh-cn_topic_0000001055366100.md)的学习 。 diff --git "a/readme/ACE\345\274\200\345\217\221\346\241\206\346\236\266README.md" "b/readme/JS\345\272\224\347\224\250\345\274\200\345\217\221\346\241\206\346\236\266README.md" similarity index 69% rename from "readme/ACE\345\274\200\345\217\221\346\241\206\346\236\266README.md" rename to "readme/JS\345\272\224\347\224\250\345\274\200\345\217\221\346\241\206\346\236\266README.md" index a2c4b54a560845c2dd887093ad27995ded1a4530..1d001b0f6763e1d8b98607d75e9cb1bbd2c4b3ed 100755 --- "a/readme/ACE\345\274\200\345\217\221\346\241\206\346\236\266README.md" +++ "b/readme/JS\345\272\224\347\224\250\345\274\200\345\217\221\346\241\206\346\236\266README.md" @@ -1,28 +1,30 @@ -# ACE开发框架 +# JS应用开发框架 ## 简介 -ACE（Ability Cross-platform Environment）开发框架，作为ACE框架的轻量实现，提供了一套跨平台的类web应用开发框架，通过Toolkit将开发者编写的HML、CSS和JS 文件编译打包成JS Bundle，然后再将JS Bundle解析运行成C++ UIKit的View 组件进行渲染。通过支持三方开发者使用声明式的API进行应用开发，以数据驱动视图变化，避免了大量的视图操作，大大降低了应用开发难度，提升开发者开发体验。ACE 框架模块组成如下图所示： +JS应用开发框架，提供了一套跨平台的类web应用开发框架，通过Toolkit将开发者编写的HML、CSS和JS 文件编译打包成JS Bundle，然后再将JS Bundle解析运行成C++ native UI的View 组件进行渲染。通过支持三方开发者使用声明式的API进行应用开发，以数据驱动视图变化，避免了大量的视图操作，大大降低了应用开发难度，提升开发者开发体验。 -![](figures/zh-cn_image_0000001052150927.png) +JS应用框架模块组成如下图所示： + +![](figures/js-framework.png) ## 目录 -轻量ACE 框架源代码在/foundation/ace下，目录结构如下图所示： +JS应用开发框架源代码在/foundation/ace下，目录结构如下图所示： ``` /foundation/ace ├── frameworks #框架代码 │ └── lite │ ├── examples #示例代码目录 -│ ├── include #部分跨子系统但仅部分平台暴露的头文件存放目录 -│ ├── packages #JS-Framework存放目录 +│ ├── include #对外暴露头文件存放目录 +│ ├── packages #框架JS实现存放目录 │ ├── src #源代码存放目录 │ ├── targets #各目标设备配置文件存放目录 │ └── tools #工具代码存放目录 -├── interfaces #头文件存放目录 +├── interfaces #对外接口存放目录 │ └── innerkits #对内部子系统暴露的头文件存放目录 -│ └── builtin # ACE对外暴露JS三方module API接口存放目录 +│ └── builtin # JS应用框架对外暴露JS三方module API接口存放目录 ``` ## 约束 @@ -33,27 +35,27 @@ ACE（Ability Cross-platform Environment）开发框架，作为ACE框架的轻 - 框架运行内存通常分为如下组成部分： - - 1. 运行时引擎的预分配内存，该内存值可调，取决于具体设备应用复杂度，通常建议64K\~512K - - 2. 框架本身内存，在百K级的内存设备上，通常通过预分配一个内存池进行管理，可以和UIKit共用一个内存池，包含了对象和堆内存统一管理 + - 运行时引擎的预分配内存，该内存值可调，取决于具体设备应用复杂度，通常建议64K\~512K + - 框架本身内存，在百K级的内存设备上，通常通过预分配一个内存池进行管理，可以和native UI共用一个内存池，包含了对象和堆内存统一管理 - 框架针对不同的芯片平台和底层OS能力，规格有所区别 - Cortex-M RAM/ROM： - JS引擎内存池: 建议大于48K - - RAM：建议大于80K - - ROM: \> 300K （包含ACE，UIKit及引擎等强相关子系统） + - RAM：建议与native UI共用内存池，大于80K + - ROM: \> 300K （包含JS应用框架，以及native UI和JS引擎等强相关子系统） - Cortex-A RAM/ROM: - JS引擎内存池: 建议大于128K - RAM：建议大于512K - - ROM：\> 2M （包含ACE，UIKit及引擎等强相关子系统） + - ROM：\> 2M （包含JS应用框架，以及native UI和JS引擎等强相关子系统） ## 使用**targets** -ACE框架实现主要包含两部分，native和JavaScript，native部分为C++，为框架的主体实现，JavaScript部分实现提供ACE框架对用户JS文件的运行时支持，并通过向引擎暴露一些全局方法或对象，支撑JS运行时与native框架之间的交互。 +JS应用框架实现主要包含两部分，native和JavaScript，native部分为C++，为框架的主体实现，JavaScript部分实现提供JS应用框架对用户JS文件的运行时支持，并通过向引擎暴露一些全局方法或对象，支撑JS运行时与native框架之间的交互。 -ACE框架通过一些特性宏来定制不同平台上参与编译的功能代码，该部分代码位于 foundation/ace/frameworks/lite/targets 目录下，目录结构如下： +JS应用框架通过一些特性宏来定制不同平台上参与编译的功能代码，该部分特性宏定义在 foundation/ace/frameworks/lite/targets 目录下头文件内，目录结构如下： ``` /foundation/ace/frameworks/lite/targets @@ -126,7 +128,7 @@ simulator/win/acelite\_config.h ## 使用runtime-core -为了实现单向数据绑定机制，轻量ACE 框架使用JavaScript语言实现了一套简单的数据劫持框架，称之为runtime-core，目录结构如下所示： +为了实现单向数据绑定机制，JS应用框架使用JavaScript语言实现了一套简单的数据劫持框架，称之为runtime-core，目录结构如下所示： ``` /foundation/ace/frameworks/lite/packages @@ -139,7 +141,7 @@ simulator/win/acelite\_config.h ├── package.json #NPM包管理文件 ├── package-lock.json #NPM依赖版本锁定文件 ├── .prettierrc #代码格式化规则配置文件 - ├── scripts #编译脚本目录 + ├── scripts #编译脚本存放目录 │ ├── build.js #编译脚本 │ └── configs.js #Rollup配置文件 ├── .size-snapshot.json @@ -162,7 +164,7 @@ simulator/win/acelite\_config.h - npm run build - ACE 所集成的JS 引擎仅支持ES5.1语法，runtime-core源代码是使用ES6源码书写的。因此选择使用rollup做为打包工具，配合babel实现对JavaScript语法进行降级处理。只要命令行中执行命令npm run build，会在build目录下输出打包结果，输出结果如下所示： + JS应用框架所集成的JS 引擎仅支持ES5.1语法，runtime-core源代码是使用ES6源码书写的。因此选择使用rollup做为打包工具，配合babel实现对JavaScript语法进行降级处理。只要命令行中执行命令npm run build，会在build目录下输出打包结果，输出结果如下所示： ``` build/ diff --git a/readme/figures/js-framework.png b/readme/figures/js-framework.png new file mode 100755 index 0000000000000000000000000000000000000000..e1f3e4b5972193d0c40450dcc037821eb78935ec Binary files /dev/null and b/readme/figures/js-framework.png differ diff --git a/readme/figures/zh-cn_image_0000001052150927.png b/readme/figures/zh-cn_image_0000001052150927.png deleted file mode 100755 index 027a675dbefd1aeb96604ff433c4a403d8190223..0000000000000000000000000000000000000000 Binary files a/readme/figures/zh-cn_image_0000001052150927.png and /dev/null differ diff --git a/security/figures/zh-cn_image_0000001054853161.png b/security/figures/zh-cn_image_0000001054853161.png new file mode 100755 index 0000000000000000000000000000000000000000..1d9cf2b90ca56d20923ca31ac2d3906540f48e27 Binary files /dev/null and b/security/figures/zh-cn_image_0000001054853161.png differ diff --git a/security/figures/zh-cn_image_0000001055093076.png b/security/figures/zh-cn_image_0000001055093076.png new file mode 100755 index 0000000000000000000000000000000000000000..7bc99c23098a0015e74dac26b07f92eb0177079d Binary files /dev/null and b/security/figures/zh-cn_image_0000001055093076.png differ diff --git "a/security/figures/\351\232\220\347\247\201\351\200\232\347\237\245-\345\243\260\346\230\216\347\244\272\344\276\213\345\233\276.png" "b/security/figures/\351\232\220\347\247\201\351\200\232\347\237\245-\345\243\260\346\230\216\347\244\272\344\276\213\345\233\276.png" index a370b523268809c1cf12c64d5a8b1661d5379c47..692734f568099c9413351574719970462205925c 100755 Binary files "a/security/figures/\351\232\220\347\247\201\351\200\232\347\237\245-\345\243\260\346\230\216\347\244\272\344\276\213\345\233\276.png" and "b/security/figures/\351\232\220\347\247\201\351\200\232\347\237\245-\345\243\260\346\230\216\347\244\272\344\276\213\345\233\276.png" differ diff --git "a/security/\351\232\220\347\247\201\344\277\235\346\212\244.md" "b/security/\351\232\220\347\247\201\344\277\235\346\212\244.md" index c6861c23539e2fba9cfa0be34cd557f93d180e23..f27edad5e9ae1c6af194f7c39e4e6ca5a8ef3f11 100755 --- "a/security/\351\232\220\347\247\201\344\277\235\346\212\244.md" +++ "b/security/\351\232\220\347\247\201\344\277\235\346\212\244.md" @@ -134,18 +134,18 @@ 根据以上原则，我们设计了正确示例以供参考。隐私通知/声明的参考示例如下： - **图 1** 隐私通知/声明示例图 + **图 1** 隐私通知/声明示例图 ![](figures/隐私通知-声明示例图.png "隐私通知-声明示例图") - 个人数据应当基于具体、明确、合法的目的收集，不应以与此目的不相符的方式作进一步处理。对于收集目的变更和用户撤销同意后再次重新使用的场景都需要用户重新确认。隐私声明变更和撤销的示例如下图： - **图 2** 隐私通知/声明变更示例图 + **图 2** 隐私通知/声明变更示例图 ![](figures/隐私通知-声明变更示例图.png "隐私通知-声明变更示例图") - **图 3** 撤销同意示例图 + **图 3** 撤销同意示例图 - ![](figures/zh-cn_image_0000001054860198.png) + ![](figures/zh-cn_image_0000001054853161.png) ![](figures/zh-cn_image_0000001055093076.png) 对用户系统软件、应用软件的下载或升级，涉及修改用户隐私空间，用户对于这类行为需要有知情权和控制权，必须给用户提示，并提供给用户同意和取消的选项。

列表名称

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git "a/contribute/\347\255\276\347\275\262CLA--\344\270\252\344\272\272\347\213\254\347\253\213\350\264\241\347\214\256\350\200\205.md" "b/contribute/\347\255\276\347\275\262CLA--\344\270\252\344\272\272\347\213\254\347\253\213\350\264\241\347\214\256\350\200\205.md" index cacfe4c92b0e2b47a29f42020748ff64d8b34efb..3270e883397957180a65271da123542ec42d5bfb 100755 --- "a/contribute/\347\255\276\347\275\262CLA--\344\270\252\344\272\272\347\213\254\347\253\213\350\264\241\347\214\256\350\200\205.md" +++ "b/contribute/\347\255\276\347\275\262CLA--\344\270\252\344\272\272\347\213\254\347\253\213\350\264\241\347\214\256\350\200\205.md" @@ -2,7 +2,7 @@ 通过签署贡献协议（“本协议”），签署的“贡献者”同意接受“本协议”并受“本协议”约束。“本协议”适用于“贡献者”提交给OpenHarmony区 （“社区”）的全部项目（后称“项目”）的“贡献”，无论“贡献”是在签署日期之前，签署时还是之后提供。 -**“贡献”** 是指受版权法保护的，由“贡献者”有意“提交”以包含在“项目”所分发软件中任何作品。“提交”是指以电子，口头或书面交流的任何形式送给“社区”管理方或其代表，包括但不限于“社区”管理方为管理的为讨论和改进项目所提供的电子邮件列表上的交流，源代码控制系统以及由“社区”管理方或其代表管理的问题跟踪系统，但不包括由“我”明确标记或以书面形式指定为“非贡献”的交流。 +**“贡献”** 是指受版权法保护的，由“贡献者”有意“提交”以包含在“项目”所分发软件中任何作品。“提交”是指以电子，口头或书面交流的任何形式送给“社区”管理方（即开放原子开源基金会）或其代表，包括但不限于“社区”管理方为管理的为讨论和改进项目所提供的电子邮件列表上的交流，源代码控制系统以及由“社区”管理方或其代表管理的问题跟踪系统，但不包括由“我”明确标记或以书面形式指定为“非贡献”的交流。 **“贡献者”或“我”**是指下面签名栏中标明的个人或法人实体。对于法人实体，做出“贡献”的实体以及由该实体控制、受其控制或受其共同控制的所有其他实体均被视为“贡献者”。就本定义而言，“控制”是指有受控方或共同受控方至少50%直接或间接的投票权，资金或其他有价证券。 diff --git "a/contribute/\347\255\276\347\275\262CLA--\346\263\225\345\276\213\345\256\236\344\275\223\350\264\241\347\214\256\350\200\205.md" "b/contribute/\347\255\276\347\275\262CLA--\346\263\225\345\276\213\345\256\236\344\275\223\350\264\241\347\214\256\350\200\205.md" index 02692d96560927ea2655d390ed7f08afa7a785e1..f36025fc4177aa534a30f780c9fa5f2b89b211b5 100755 --- "a/contribute/\347\255\276\347\275\262CLA--\346\263\225\345\276\213\345\256\236\344\275\223\350\264\241\347\214\256\350\200\205.md" +++ "b/contribute/\347\255\276\347\275\262CLA--\346\263\225\345\276\213\345\256\236\344\275\223\350\264\241\347\214\256\350\200\205.md" @@ -2,7 +2,7 @@ 通过签署贡献协议（“本协议”），签署的“贡献者”同意接受“本协议”并受“本协议”约束。“本协议”适用于“贡献者”提交给OpenHarmony区 （“社区”）的全部项目（后称“项目”）的“贡献”，无论“贡献”是在签署日期之前，签署时还是之后提供。 -**“贡献”** 是指受版权法保护的，由“贡献者”有意“提交”以包含在“项目”所分发软件中任何作品。“提交”是指以电子，口头或书面交流的任何形式送给“社区”管理方或其代表，包括但不限于“社区”管理方为管理的为讨论和改进项目所提供的电子邮件列表上的交流，源代码控制系统以及由“社区”管理方或其代表管理的问题跟踪系统，但不包括由“我”明确标记或以书面形式指定为“非贡献”的交流。 +**“贡献”** 是指受版权法保护的，由“贡献者”有意“提交”以包含在“项目”所分发软件中任何作品。“提交”是指以电子，口头或书面交流的任何形式送给“社区”管理方（即开放原子开源基金会）或其代表，包括但不限于“社区”管理方为管理的为讨论和改进项目所提供的电子邮件列表上的交流，源代码控制系统以及由“社区”管理方或其代表管理的问题跟踪系统，但不包括由“我”明确标记或以书面形式指定为“非贡献”的交流。 **“贡献者”或“我”**是指下面签名栏中标明的个人或法人实体。对于法人实体，做出“贡献”的实体以及由该实体控制、受其控制或受其共同控制的所有其他实体均被视为“贡献者”。就本定义而言，“控制”是指有受控方或共同受控方至少50%直接或间接的投票权，资金或其他有价证券。 diff --git "a/contribute/\350\264\241\347\214\256\344\273\243\347\240\201.md" "b/contribute/\350\264\241\347\214\256\344\273\243\347\240\201.md" index 3466ed4c88427bb69a45d0e6cd61f7e0be011aaa..5cb402e6324e28617206fb5397a119004e7d8a3f 100755 --- "a/contribute/\350\264\241\347\214\256\344\273\243\347\240\201.md" +++ "b/contribute/\350\264\241\347\214\256\344\273\243\347\240\201.md" @@ -17,8 +17,8 @@ ## 社区安全问题披露 -- 安全处理流程---待补充 +- 安全处理流程 -- 安全披露信息---待补充 +- 安全披露信息 diff --git "a/contribute/\350\264\241\347\214\256\346\265\201\347\250\213.md" "b/contribute/\350\264\241\347\214\256\346\265\201\347\250\213.md" index d97d24d04598d4d84894ecaf5f192b85e7f1e65c..985ea98861f90e8adc8722c3e3727315ab8f3fdc 100755 --- "a/contribute/\350\264\241\347\214\256\346\265\201\347\250\213.md" +++ "b/contribute/\350\264\241\347\214\256\346\265\201\347\250\213.md" @@ -68,7 +68,7 @@ 2. 下载\(注意没有repo branch参数\)： ``` - repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo init -u https://gitee.com/openharmony/manifest.git -b master repo sync -c ``` diff --git a/docs-en/Readme-EN.md b/docs-en/Readme-EN.md index b7cb59c41db0333f89a9e274e36482355c7d1f99..3ffdd9ed18f369d8c22fceeaf6eb21cbdb1e46f6 100755 --- a/docs-en/Readme-EN.md +++ b/docs-en/Readme-EN.md @@ -6,12 +6,12 @@ This project provides documents including the quick start, development guide, an - quick-start: [Getting Started](quick-start/Readme-EN.md) - get-code: [Source Code Acquisition/Tool Acquisition](get-code/Readme-EN.md) -- driver: [Driver Usage Guidelines](driver/Readme-EN.md) +- driver: [Device Development Guidelines](driver/Readme-EN.md) - kernel: [Kernel Usage Guidelines](kernel/Readme-EN.md) - subsystems: [Subsystem Development Guidelines](subsystems/Readme-EN.md) - bundles: [Bundle Development](bundles/Readme-EN.md) - guide: [Device Development Guidelines](guide/Readme-EN.md) -- security: [Privacy and Securit](security/Readme-EN.md) +- security: [Privacy and Security](security/Readme-EN.md) - api-LinkIoT: [LinkIoT Modules API](api/api-LinkIoT/Readme-EN.md) - api-SmartVision-Devices: [SmartVision Devices API](api/api-SmartVision-Devices/Readme-EN.md) - contribute: [Contribution](contribute/contribution.md) diff --git a/docs-en/contribute/communication-in-community.md b/docs-en/contribute/communication-in-community.md index c1513f5683ebea776e4cbf3965114cd2ac1778a5..431fd79a64d0ec8d5a8cb37b82c2fb3c7f285c18 100755 --- a/docs-en/contribute/communication-in-community.md +++ b/docs-en/contribute/communication-in-community.md @@ -2,87 +2,76 @@ If you encounter any problems when using OpenHarmony, please join the email group for discussion. -## How Do I Subscribe to a Mailing List? +## How Do I Subscribe to a Mail List? -If you have never subscribed to a mailing list before, follow the steps below: +If you have never subscribed to a mail list before, follow the steps below: -1. Send an empty mail to the mailing list you want to subscribe to. You will receive a confirmation email. -2. Reply to the confirmation email. The subscription is successful. -3. Send your question to the email address. All other users who subscribe to the mailing list will receive your email and share it. +1. Click the name of the mail list that you want to subscribe to. +2. Wait until the browser goes to the subscription page of the mail list, which provides instructions on how to subscribe. +3. Read the subscription instructions and provide an email address that you want to use to subscribe to the mail list. +4. Enter your email address and click **Subscribe**. You will receive an email asking you to confirm the subscription. +5. Reply the email to confirm your subscription. +6. At last, you will receive a welcome email from the email list. **Table 1** Email list -

邮件地址

邮件地址

+

简介

类型

-

功能描述

+

功能描述

Community

-

contact.openharmony@openatom.org

+

contact@openharmony.io

Public

+

公用邮箱

OpenHarmony社区公共邮箱。开发者CLA协议签署可以发邮件到此邮箱。

+

OpenHarmony社区公共邮箱。开发者CLA协议签署可以发邮件到此邮箱。

Dev

+

dev@openharmony.io

dev.openharmony@openatom.org

+

开发邮件列表

Public

-

OpenHarmony社区开发讨论邮件列表，任何社区开发相关话题都可以在邮件列表讨论。任何开发者可订阅。

+

OpenHarmony社区开发讨论邮件列表，任何社区开发相关话题都可以在邮件列表讨论。任何开发者可订阅。

CICD

-

cicd.openharmony@openatom.org

+

cicd@openharmony.io

Public

+

CI邮件列表

OpenHarmony社区CI门禁项目邮件列表。

+

OpenHarmony社区CICD构建邮件列表，任何开发者可订阅。

PMC

+

pmc@openharmony.io

pmc.openharmony@openatom.org

+

PMC邮件列表

Private

-

PMC讨论邮件列表，PMC成员可订阅。

+

PMC讨论邮件列表，PMC成员可订阅。

安全漏洞

-

scy.openharmony@openatom.org

+

scy@openharmony.io

Public

+

安全问题邮箱

Public开发者反馈OpenHarmony安全问题邮箱。

+

开发者可反馈OpenHarmony安全问题到此邮箱。

安全讨论

-

scy-priv.openharmony@openatom.org

+

scy-priv@openharmony.io

Private

+

安全组邮件列表

Private安全组成员安全问题处理讨论邮件列表，安全组成员可订阅。

+

安全组成员安全问题处理讨论邮件列表，安全组成员可订阅。
- @@ -50,7 +50,7 @@ You can download the source code or the corresponding solutions from the image l - @@ -59,7 +59,7 @@ You can download the source code or the corresponding solutions from the image l - @@ -234,7 +234,7 @@ Add the bundle \(**@ohos/demo** as an example\) to your project as follows: Method 1 \(recommended\): Use the **repo** tool to download source code. ``` -repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify +repo init -u https://gitee.com/openharmony/manifest.git -b master repo sync -c ``` diff --git a/docs-en/guide/adding-pages.md b/docs-en/guide/adding-pages.md index aa4385d75333d731cc5146e566787d17bdd9a3ad..9c1172182667ffa0a821cdf8664bdf1087856694 100755 --- a/docs-en/guide/adding-pages.md +++ b/docs-en/guide/adding-pages.md @@ -1,6 +1,6 @@ # Adding Pages -## Creating the Home Page \(Creating a Project\) +## Creating the Home Page After the project is created, the **index** page is generated by default. The following figure shows the project directory. @@ -11,7 +11,7 @@ After the project is created, the **index** page is generated by default. The Perform the following steps twice to create the rest two pages: -1. Right-click **pages** and choose **New** \> **JS Page**. +1. Right-click **pages** and choose **New** \> **JS Page** from the shortcut menu. **Figure 2** Adding a page ![](figures/adding-a-page.png "adding-a-page") diff --git a/docs-en/guide/building-the-home-page.md b/docs-en/guide/building-the-home-page.md index fd47684783765436a250215f5d10674d493a2068..86d074a36c3b94d848cc1b927fdd243ea6d6c1ac 100755 --- a/docs-en/guide/building-the-home-page.md +++ b/docs-en/guide/building-the-home-page.md @@ -1,6 +1,6 @@ # Building the Home Page -The application home page displays air quality information of the current city. There are two screens on the home page. Each screen displays the air quality information of a city, including the AQI and city name. The AQI value can be displayed in the form of a ring progress bar with animation. +The application home page displays air quality information of the current city. There are two screens on the home page. Each screen displays air quality information of a city, including the AQI and city name. The AQI value can be displayed in the form of a ring progress bar with animation. 1. The **** component is required to implement the switch between the two screens. @@ -20,7 +20,7 @@ The application home page displays air quality information of the current city. } ``` - This style class sets the height and width of the component. For device-side development, the component height and width must be explicitly specified. Otherwise, the component may fail to be displayed. + This style class sets the height and width of the component. During application development, the component height and width must be explicitly specified. Otherwise, the component may fail to be displayed. - **index="\{\{swiperPage\}\}" duration="500" onchange="swiperChange"** sets the component attribute and event. **duration="500"** indicates that the duration of the swiping animation is 500 ms. @@ -28,7 +28,7 @@ The application home page displays air quality information of the current city. - **onchange="swiperChange"** binds the change event of the **** component to the **swiperChange** function. The JavaScript code is as follows: ``` - // Import the router module for page switch. + // Import the router module for page switching. import router from'@system.router' export default { // Define parameters. @@ -106,7 +106,7 @@ The application home page displays air quality information of the current city. - **index.css** - A **.css** file contains many classes. Each class defines the position, size, font, color, and background color of a component. Each child component is added to the parent component, which means that the style file of the parent component affects how the child component will be displayed. + A **.css** file contains many classes. Each class defines the position, size, font, color, and background color of a component. Each child component is added to its parent component, and the style file of the parent component affects how the child component will be displayed. ``` .pm25-value{ @@ -162,10 +162,10 @@ The application home page displays air quality information of the current city. - **index.js** - A **.js** file is used to implement interaction logic of your application. In the **.js** file of the home page, the following features need to be implemented: Dynamic changes of the text content and progress bar color based on numbers, multiple languages, page switch, and animation playback. + A **.js** file is used to implement interaction logic of your application. In the **.js** file of the home page, the following features need to be implemented: dynamic changes of the text content and progress bar color based on numbers, multiple languages, page switching, and animation playback. ``` - // Import the router module for page switch. + // Import the router module for page switching. import router from'@system.router' export default { // Define parameters. diff --git a/docs-en/guide/faqs.md b/docs-en/guide/faqs.md index 59f0399f38fe359816582ae547f8fbedee9fe38c..2a1fae9ad8e38b57bde45bb63906b41770912d76 100755 --- a/docs-en/guide/faqs.md +++ b/docs-en/guide/faqs.md @@ -2,11 +2,11 @@ 1. Is there a global variable that can be accessed by all pages? - No such global variable is available for all pages. + There is no such a global variable. 2. How do I obtain DOM elements? - You can obtain DOM elements via the **ref** attribute. You can only use methods of the obtained elements and cannot change their attributes. The following figure shows an example. + You can obtain DOM elements via the **ref** attribute. You can use methods of the obtained elements but cannot change their attributes. The sample code is as follows: ``` @@ -47,7 +47,7 @@ ``` router.replace({ - uri:'pages/detail/detail', // URI of the page to be redirected to. + uri:'pages/detail/detail', // URI of the page to switch to. params:{transferData:this.data} // Data to be transferred. You need to define the data amount and name. }); ``` @@ -66,7 +66,7 @@ 5. Does the **** component support multiple lines? - Yes. You can use the Enter key to start a new line. Alternatively, you can choose not to set the height attribute of the text, and the component automatically starts a new line based on the content. + Yes. You can use the Enter key to start a new line. Alternatively, the component automatically starts a new line based on the content, without the need to set the height attribute of the text. 6. Why is a component not displayed? @@ -91,9 +91,9 @@ 8. Why do not the **left** and **top** attributes take effect? - In addition to the root component, **left** and **top** attributes must work with the **** component. + **left** and **top** attributes must work with the **** component in addition to the root component. -9. Why does dynamic binding not take effect? +9. Why does not dynamic binding take effect? The object or its attributes are not defined before dynamic binding. @@ -101,9 +101,9 @@ You can use the **** and **** \(with **top** and **left** attributes\) components. -11. How do I set component transparency? +11. How do I set component opacity? - For the **** component, set the **opacity** attribute to adjust the transparency. For other components, set the alpha value \(in RGBA color channels\) of a component. + For the **** component, set the **opacity** attribute. For other components, set the alpha value \(in RGBA color channels\). 12. How do I display or hide a component? @@ -115,7 +115,7 @@ 14. What are the precautions for event subscription? - Only one page exists when the application is running. Therefore, the **router.replace** function destroys the previous page and then creates a new one. For event subscription pages, the event should be subscribed every time a page is created, and unsubscribed before a page switch. + Only one page exists when the application is running. Therefore, the **router.replace** function destroys the previous page and then creates a new one. For event subscription pages, the event should be subscribed every time a page is created, and unsubscribed before page switching. 15. What are the precautions for using dynamic binding? diff --git a/docs-en/guide/figures/modifying-the-template.png b/docs-en/guide/figures/modifying-the-template.png new file mode 100755 index 0000000000000000000000000000000000000000..9c05b8dd365bf0bad7f46eb526d248dd2116bf98 Binary files /dev/null and b/docs-en/guide/figures/modifying-the-template.png differ diff --git a/docs-en/guide/figures/selecting-project-template.png b/docs-en/guide/figures/selecting-project-template.png new file mode 100755 index 0000000000000000000000000000000000000000..1b48acb2b9e5ac5f73c96f09f72233791289eabb Binary files /dev/null and b/docs-en/guide/figures/selecting-project-template.png differ diff --git a/docs-en/guide/overview-6.md b/docs-en/guide/overview-6.md index 6e3d607832d96704076a9d9157851ca3caeb2c73..3bf99155c726410f9967582c1ec11d6b40f60009 100755 --- a/docs-en/guide/overview-6.md +++ b/docs-en/guide/overview-6.md @@ -1,12 +1,12 @@ # Overview -This section describes how to quickly set up a development environment for the basic head unit running on OpenHarmony and how to create, develop, and debug your application. This section uses an air quality application as an example. +This section describes how to quickly set up a development environment for the basic head unit running on OpenHarmony and how to create, develop, and debug your application. This section uses an air quality monitoring application \(AirQuality\) as an example. ## Display Effects -The application displays air quality information on three pages: **home** page fo overview, **detail** page, and **history** page. The following figure shows the application on the DevEco Studio simulator. +AirQuality displays air quality information on three pages: **home** page fo overview, **detail** page, and **history** page. The following figure shows AirQuality on the DevEco Studio simulator. -**Figure 1** Display effect of the air quality application +**Figure 1** Display effect of the application ![](figures/video_2020-07-25_173141.gif) diff --git a/docs-en/guide/photographing-3.md b/docs-en/guide/photographing-3.md index 05ebce277f75818625ea94e06d13502dc07bf87c..91a18c52d906f99fd132f0e55151abac433cb973 100755 --- a/docs-en/guide/photographing-3.md +++ b/docs-en/guide/photographing-3.md @@ -274,7 +274,7 @@ None ostringstream ss("Capture_"); ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg"; - ofstream pic("/tmp/" + ss.str(), ofstream::out | ofstream::trunc); + ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc); cout << "write " << size << " bytes" << endl; pic.write(p, size); cout << "Saving picture end" << endl; diff --git a/docs-en/guide/photographing.md b/docs-en/guide/photographing.md index 22d172cc85d0eae1bfd60c7a544581593ec731c3..5b26117c1fd6a2aa55b70364bd46e29621ef8b50 100755 --- a/docs-en/guide/photographing.md +++ b/docs-en/guide/photographing.md @@ -274,7 +274,7 @@ None ostringstream ss("Capture_"); ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg"; - ofstream pic("/tmp/" + ss.str(), ofstream::out | ofstream::trunc); + ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc); cout << "write " << size << " bytes" << endl; pic.write(p, size); cout << "Saving picture end" << endl; diff --git a/docs-en/guide/preparations.md b/docs-en/guide/preparations.md index 829ba65f5a6d66d5033551d7cc44e86909914222..f04ff9c31c80f1e647af8ac95a47f46fe0cd3b4f 100755 --- a/docs-en/guide/preparations.md +++ b/docs-en/guide/preparations.md @@ -6,5 +6,21 @@ Set up the environment by performing operations provided in **Environment Setup ## Creating a Project -For details, see section **Creating a Project** in the [DevEco Studio User Guide](https://developer.harmonyos.com/en/docs/documentation/doc-guides/tools_overview-0000001053582387). +The DevEco Studio provides only basic development functions. GUI preview and code commissioning will be provided in the next version. + +Perform the following steps to create a project. Currently, projects of the **smartVision** type cannot be created directly. + +1. Start the DevEco Studio, choose **File** \> **Project** and select **Lite Wearable** for **Device** and **Empty Feature Ability** for **Template**. + + **Figure 1** Selecting project template + ![](figures/selecting-project-template.png "selecting-project-template") + +2. After the creation is successful, modify the **config.json** file in **entry** \> **src** \> **main**. + 1. Change the value of **"deviceType"** to **"smartVision"**. + 2. Add the **"visible"** attribute to the **"abilities"** array and set the attribute value to **true**. + + **Figure 2** Modifying the template + ![](figures/modifying-the-template.png "modifying-the-template") + + diff --git a/docs-en/guide/previewing.md b/docs-en/guide/previewing.md index 50e2cd0b0ce6e5892de4659333c471acdf80eef2..a5bc9225375dddd74f9eeed5e0329021d20c0033 100755 --- a/docs-en/guide/previewing.md +++ b/docs-en/guide/previewing.md @@ -6,7 +6,7 @@ Use the camera module APIs to generate and play video streams. ## Available APIs -For details, see [Available APIs](photographing-3.md#en-us_topic_0000001052170554_section56549532016). +For details, see the available APIs described in development guidelines on photographing. ## Limitations and Constraints @@ -14,7 +14,7 @@ None ## How to Develop -1. Perform step 1 through step 4 provided in [Development Guidelines on Photographing](photographing-3.md#EN-US_TOPIC_0000001054915940). +1. Perform step 1 through step 4 described in development guidelines on photographing. 2. Set the preview area. ``` diff --git a/docs-en/guide/running-on-the-device.md b/docs-en/guide/running-on-the-device.md index eb5aff5f0307ce95a5e81e63eb634bd3c3439553..2c5e514c42b29032295b06a0e986cb55369aad89 100755 --- a/docs-en/guide/running-on-the-device.md +++ b/docs-en/guide/running-on-the-device.md @@ -1,19 +1,19 @@ # Running on the Device -For details about the development board, compilation, burning, and image running process, see [Getting Started with Hi3516](../quick-start/introduction-to-the-hi3516-development-board.md). After running the image and the system is started normally, perform the following steps: +For details about the development board, compilation, burning, and image running process, see [Getting Started with Hi3516](../quick-start/introduction-to-the-hi3516-development-board.md). After image running is executed and the system is started normally, perform the following steps to install or uninstall the third-party application: -1. Install the third-party application for the debug version only. +1. Store the unsigned application installation package and installation tool compiled by the IDE in an SD card. \(IP camera applications currently do not support signature.\) The installation tool is in **idev\_tools** in the directory where the image file is generated. +2. Run the **./sdcard/dev\_tools/bin/bm set -s disable** command to disable signature verification. +3. Run the **./sdcard/dev\_tools/bin/bm install -p /sdcard/airquality.hap** command to install the application. - Store the application installation package \(with the **debug** signature\) and installation tool \(**dev\_tools** in the directory where the image file is generated\) in an SD card. The installation procedure is as follows: + The **dev\_tools** directory stores the installation tool, and **airquality.hap** is the application installation package. - 1. Run the **./sdcard/dev\_tools/bin/bm set -d enable** command to enable the debugging signature. - 2. Run the **./sdcard/dev\_tools/bin/bm install -p /sdcard/airquality.hap** command to install the application. The **dev\_tools** directory stores the installation tool, and **airquality.hap** is the application installation package. - 3. After the application is installed, touch the application icon on the home screen to start the application. +4. After the application is installed, touch the application icon on the home screen to start the application. **Figure 1** Home screen ![](figures/home-screen.png "home-screen") -2. Uninstall the application. +5. \(Optional\) Uninstall the application. Touch and hold the application icon on the home screen, and touch the uninstall button in the displayed menu. diff --git a/docs-en/guide/use-case.md b/docs-en/guide/use-case.md index 95e8f8d5b2b923dc98b7f8f9bfdaf1ba52d29fb3..cb6f45730e725f19a84be5e3c22d3672517dde90 100755 --- a/docs-en/guide/use-case.md +++ b/docs-en/guide/use-case.md @@ -1,6 +1,6 @@ # Use Case -- For details about the development board, compilation, burning, and image running process, see [Getting Started with Hi3518](../quick-start/introduction-to-the-hi3518-development-board.md). The compilation results include that of the **camera\_sample** program. +- For details about the development board, compilation, burning, and image running process, see [Getting Started with Hi3518](en-us_topic_0000001054261054.md). The compilation results include that of the **camera\_sample** program. - The sample code for camera development is stored in **applications/sample/camera/media/camera\_sample.cpp**. >![](public_sys-resources/icon-notice.gif) **NOTICE:** diff --git a/docs-en/guide/video-recording-4.md b/docs-en/guide/video-recording-4.md index 5f417a1d3316889b93c610792529b13e19aca6f5..7bf4ba1076b5d90d8e254a788d6baee572f2e005 100755 --- a/docs-en/guide/video-recording-4.md +++ b/docs-en/guide/video-recording-4.md @@ -6,7 +6,7 @@ Use the camera module APIs to capture video streams. ## Available APIs -For details, see [接口说明](en-us_topic_0000001052170554.md#section56549532016). +For details, see the available APIs described in development guidelines on photographing. ## Limitations and Constraints @@ -14,7 +14,7 @@ None ## How to Develop -1. Perform step 1 through step 4 provided in [拍照开发指导](en-us_topic_0000001052170554.md). +1. Perform step 1 through step 4 described in development guidelines on photographing. 2. Obtain the **FrameConfig** instance for audio recording. ``` diff --git a/docs-en/guide/video-recording.md b/docs-en/guide/video-recording.md index a05bf534ddec24245847c93694ee70104aec07ea..96afe8a9d7a728e705e56b803619f02e95c4be9b 100755 --- a/docs-en/guide/video-recording.md +++ b/docs-en/guide/video-recording.md @@ -6,7 +6,7 @@ Use the camera module APIs to capture video streams. ## Available APIs -For details, see [Available APIs](photographing.md#en-us_topic_0000001052170554_section56549532016). +For details, see the available APIs described in development guidelines on photographing. ## Limitations and Constraints @@ -14,7 +14,7 @@ None ## How to Develop -1. Perform step 1 through step 4 provided in [Development Guidelines on Photographing](photographing.md#EN-US_TOPIC_0000001054954859). +1. Perform step 1 through step 4 described in development guidelines on photographing. 2. Obtain the **FrameConfig** instance for audio recording. ``` diff --git a/docs-en/kernel/Readme-EN.md b/docs-en/kernel/Readme-EN.md index 126206c12aaca559d15d5464e8f6aed660f78e98..f05eded3385c5672bb74fead8f71fa7ce86056d0 100755 --- a/docs-en/kernel/Readme-EN.md +++ b/docs-en/kernel/Readme-EN.md @@ -1,12 +1,12 @@ # Kernel Usage Guidelines -- [OpenHarmony Basic Kernel Functions](openharmony-basic-kernel-functions.md) +- [OpenHarmony Lite Kernel Basic Functions](openharmony-lite-kernel-basic-functions.md) - [Process](process.md) - [Thread](thread.md) - [Memory](memory.md) - [Network](network.md) -- [Kernel File System](kernel-file-system.md) +- [OpenHarmony Lite Kernel File System](openharmony-lite-kernel-file-system.md) - [VFS](vfs.md) - [NFS](nfs.md) - [RAMFS](ramfs.md) diff --git a/docs-en/kernel/fat.md b/docs-en/kernel/fat.md index 002841b021193bf81d187bbae4db429ed0d46285..eb36376193f7a9469e92a03e7043159b6f87c2ac 100755 --- a/docs-en/kernel/fat.md +++ b/docs-en/kernel/fat.md @@ -12,7 +12,7 @@ The OpenHarmony kernel supports multiple partitions on the hard disk. A FAT file ## Important Notes -- A maximum of 256 FATFS files or folders that can be opened simultaneously. +- A maximum of 512 FATFS files or folders that can be opened simultaneously. - After a file is opened in writable mode, the file cannot be opened again before it is closed. To open a file for multiple times, the read-only attribute can be used only. If a file is opened for a long time and is not closed, data loss will occur. The file can be saved only after being closed. diff --git a/docs-en/kernel/openharmony-lite-kernel-basic-functions.md b/docs-en/kernel/openharmony-lite-kernel-basic-functions.md new file mode 100755 index 0000000000000000000000000000000000000000..47fe3fcc44096451a8ace8422b4f970a57307744 --- /dev/null +++ b/docs-en/kernel/openharmony-lite-kernel-basic-functions.md @@ -0,0 +1,11 @@ +# OpenHarmony Lite Kernel Basic Functions + +- **[Process](process.md)** + +- **[Thread](thread.md)** + +- **[Memory](memory.md)** + +- **[Network](network.md)** + + diff --git a/docs-en/kernel/openharmony-lite-kernel-file-system.md b/docs-en/kernel/openharmony-lite-kernel-file-system.md new file mode 100755 index 0000000000000000000000000000000000000000..443fc42c437c4eb5b001c163b4ae4b56355186d5 --- /dev/null +++ b/docs-en/kernel/openharmony-lite-kernel-file-system.md @@ -0,0 +1,54 @@ +# OpenHarmony Lite Kernel File System + +The OpenHarmony lite kernel supports the following file systems: Virtual File System \(VFS\), Network File System \(NFS\), RAM File System \(RAMFS\), File Allocation Table \(FAT\), and Journalling Flash File System Version 2 \(JFFS2\). + +The table below describes the functions of these file systems. + +**Table 1** File system functions + + +

List Name

+ - - - - - - - - - - - - - - - - - - - - - - - - - - -

Email Address

Email Address

+

Introduction

Type

-

Description

+

Description

Community

-

contact@openharmony.io

+

contact@openharmony.io

Public

+

Public mailbox

Public email address of the OpenHarmony community. You can send emails to this email address to sign the Contributor License Agreement (CLA).

+

Public mailbox of the OpenHarmony community. You can send emails to this mailbox to sign the Contributor License Agreement (CLA).

Dev

+

dev@openharmony.io

dev@openharmony.io

+

Development mail list

Public

-

OpenHarmony community development discussion group. Any topics related to community development can be discussed here. Any one can subscribe to it.

+

OpenHarmony community development discussion group. Any topics related to community development can be discussed here. Any one can subscribe to it.

CICD

-

cicd@openharmony.io

+

cicd@openharmony.io

Public

+

CI mail list

This mailing list is used for discussing the OpenHarmony community CI access control.

+

The OpenHarmony community CI/CD builds a mail list that any developer can subscribe to.

PMC

+

pmc@openharmony.io

pmc@openharmony.io

+

PMC mail list

Private

-

Mailing list for PMC discussion. It can be subscribed to by PMC members.

+

Mail list for PMC discussion. It can be subscribed to by PMC members.

Security vulnerabilities

-

scy@openharmony.io

+

scy@openharmony.io

Public

+

Mail list for security issues

Email address for you to report OpenHarmony security issues.

+

Email address for you to report OpenHarmony security issues.

Security discussion

-

scy-priv@openharmony.io

+

scy-priv@openharmony.io

Private

+

Security group mail list

The security group members can subscribe to this email list to discuss security issues.

+

The security group members can subscribe to this email list to discuss security issues.
-## How Do I Send Emails to a Mailing List? +## How Do I Send Emails to a Mail List? -To send an email to a specified mailing list, send your email to the address listed in the table above. +To send an email to a specified mail list, send your email to the address listed in the table above. -In this way, all community members in this mailing list will receive your email. +In this way, all community members in this mail list will receive your email. diff --git a/docs-en/contribute/contributing-code.md b/docs-en/contribute/contributing-code.md index d42260fc19e55d3cf6816b29a37c45354f0ecf27..3a5cc412b00fb052ca140932b894fcdd3559b3cc 100755 --- a/docs-en/contribute/contributing-code.md +++ b/docs-en/contribute/contributing-code.md @@ -17,8 +17,8 @@ For details, see [Contribution Process](contribution-process.md). ## Security Issue Disclosure -- Security handling procedure \(To be supplemented\) +- Security handling procedure -- Security disclosure information \(To be supplemented\) +- Security disclosure information diff --git a/docs-en/contribute/contribution-process.md b/docs-en/contribute/contribution-process.md index 9e5833fbe39a6b728bfa4a30a6d4ad4df6484231..bd5cc0bc198c1b4a9d1cf0951a02bd577e8f8743 100755 --- a/docs-en/contribute/contribution-process.md +++ b/docs-en/contribute/contribution-process.md @@ -68,7 +68,7 @@ Perform the following steps to download the code in the repository to your compu 2. Download code repositories. \(There is no **repo branch** parameter.\) ``` - repo init -u https://gitee.com/openharmony/manifest.git -b master --no-repo-verify + repo init -u https://gitee.com/openharmony/manifest.git -b master repo sync -c ``` diff --git a/docs-en/contribute/signing-cla-as-individual-contributors.md b/docs-en/contribute/signing-cla-as-individual-contributors.md index e6d125d0669490e9c8c57d64a24cf890dc680bbc..f50253379b47c36c8e221572c7bcf4be0d2f1393 100755 --- a/docs-en/contribute/signing-cla-as-individual-contributors.md +++ b/docs-en/contribute/signing-cla-as-individual-contributors.md @@ -2,17 +2,17 @@ By signing this Agreement For Contribution \(this Agreement\), the undersigned Contributor agrees to accept and be legally bound by this Agreement. This Agreement applies to the Contribution submitted by Contributor to all the projects of OpenHarmony Community \(“Project”\), whether provided before, on or after the signing date. -**Contribution** shall mean any work protectable under copyright lawthat is intentionally submitted by Contributor for inclusion in the software distributed by the Project. "submitted" means any form of electronic, verbal, or written communication sent to the hoster of the openEuler Community \(Hoster\) or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Hoster for the purpose of discussing and improving the Project, but excluding communication that is conspicuously marked or otherwise designated in writing by Me as "Not a Contribution." +**Contribution** shall mean any work protectable under copyright lawthat is intentionally submitted by Contributor for inclusion in the software distributed by the Project. "submitted" means any form of electronic, verbal, or written communication sent to the hoster of the OpenHarmony Community \(Hoster, i.e. OPENATOM FOUNDATION\) or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Hoster for the purpose of discussing and improving the Project, but excluding communication that is conspicuously marked or otherwise designated in writing by Me as "Not a Contribution." -**Contributor or I or Me or My** shall mean the individual or legal entity identified in the signature block below. For legal entity, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, ‘control’ means direct or indirect ownership of at least fifty percent \(50%\) of the voting power, capital or other securities of controlled or commonly controlled entity. +**Contributor or I or Me or My** shall mean the individual or legal entity identified in the signature block below. For legal entity, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, 'control' means direct or indirect ownership of at least fifty percent \(50%\) of the voting power, capital or other securities of controlled or commonly controlled entity. Each Contributor hereby grants to the Hoster and the recipients of software distributed by the Project a perpetual, worldwide, royalty-free, non-exclusive, irrevocable, sub-licensable copyright license to reproduce, use, modify, or distribute its Contribution, with modification or not. -Each Contributor hereby grants to the Hoster and recipients of the software distributed by the Project a perpetual, worldwide, royalty-free, non-exclusive, irrevocable patent license to make, have made, use, offer for sale, sell, import or otherwise transfer its Contribution where such patent license is only limited to the patent claims owned or controlled by such Contributor now or in future which will be necessarily infringed by its Contribution alone, or by combination of the Contribution with the Project software to which the Contribution was contributed, excluding of any patent claims solely be infringed by your or others’ modification or other combinations. In case the license adopted by the specific software distributed by the Project has further restriction on the patent license granted to the software recipients, for example, restricts the recipients to file patent litigation or enforcement against Contribution or such software, then the patent license to the recipients of the specific Project license prevails. +Each Contributor hereby grants to the Hoster and recipients of the software distributed by the Project a perpetual, worldwide, royalty-free, non-exclusive, irrevocable patent license to make, have made, use, offer for sale, sell, import or otherwise transfer its Contribution where such patent license is only limited to the patent claims owned or controlled by such Contributor now or in future which will be necessarily infringed by its Contribution alone, or by combination of the Contribution with the Project software to which the Contribution was contributed, excluding of any patent claims solely be infringed by your or others modification or other combinations. In case the license adopted by the specific software distributed by the Project has further restriction on the patent license granted to the software recipients, for example, restricts the recipients to file patent litigation or enforcement against Contribution or such software, then the patent license to the recipients of the specific Project license prevails. Contributor represents that I’m the copyright owner of the Contribution or I’m authorized by the copyright owner to make such Contribution, and I’m legally entitled to grant the rights set out in this Agreement and the License; -Contributor represents that I’ m not aware any of My Contribution has infringed or will infringe any third party's copyrights, trademarks, patents, or other intellectual property rights. +Contributor represents that I’m not aware any of My Contribution has infringed or will infringe any third party's copyrights, trademarks, patents, or other intellectual property rights. Except as otherwise stated in the Agreement, Contribution is provided without warranties of any kind, either express or implied. In no event shall any Contributor or copyright holder be liable to you for any damages, including, but not limited to any direct, or indirect, special or consequential damages arising from your use or inability to use the software or the Contribution in it, no matter how it’s caused or based on which legal theory, even if advised of the possibility of such damages. diff --git a/docs-en/contribute/signing-cla-as-legal-entity-contributors.md b/docs-en/contribute/signing-cla-as-legal-entity-contributors.md index 9e550326529e81b6b9eb175050b89c5439720b2c..bef437162406278c05cc47447e19c2103ef2766d 100755 --- a/docs-en/contribute/signing-cla-as-legal-entity-contributors.md +++ b/docs-en/contribute/signing-cla-as-legal-entity-contributors.md @@ -2,7 +2,7 @@ By signing this Agreement For Contribution \(this Agreement\), the undersigned Contributor agrees to accept and be legally bound by this Agreement. This Agreement applies to the Contribution submitted by Contributor to all the projects of OpenHarmony Community \(“Project”\), whether provided before, on or after the signing date. -**Contribution** shall mean any work protectable under copyright lawthat is intentionally submitted by Contributor for inclusion in the software distributed by the Project. "submitted" means any form of electronic, verbal, or written communication sent to the hoster of the openEuler Community \(Hoster\) or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Hoster for the purpose of discussing and improving the Project, but excluding communication that is conspicuously marked or otherwise designated in writing by Me as "Not a Contribution." +**Contribution** shall mean any work protectable under copyright lawthat is intentionally submitted by Contributor for inclusion in the software distributed by the Project. "submitted" means any form of electronic, verbal, or written communication sent to the hoster of the OpenHarmony Community \(Hoster, i.e. OPENATOM FOUNDATION\) or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Hoster for the purpose of discussing and improving the Project, but excluding communication that is conspicuously marked or otherwise designated in writing by Me as "Not a Contribution." **Contributor or I or Me or My** shall mean the individual or legal entity identified in the signature block below. For legal entity, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, ‘control’ means direct or indirect ownership of at least fifty percent \(50%\) of the voting power, capital or other securities of controlled or commonly controlled entity. @@ -12,7 +12,7 @@ Each Contributor hereby grants to the Hoster and recipients of the software dist Contributor represents that I’m the copyright owner of the Contribution or I’m authorized by the copyright owner to make such Contribution, and I’m legally entitled to grant the rights set out in this Agreement and the License; -Contributor represents that I’ m not aware any of My Contribution has infringed or will infringe any third party's copyrights, trademarks, patents, or other intellectual property rights. +Contributor represents that I’m not aware any of My Contribution has infringed or will infringe any third party's copyrights, trademarks, patents, or other intellectual property rights. Except as otherwise stated in the Agreement, Contribution is provided without warranties of any kind, either express or implied. In no event shall any Contributor or copyright holder be liable to you for any damages, including, but not limited to any direct, or indirect, special or consequential damages arising from your use or inability to use the software or the Contribution in it, no matter how it’s caused or based on which legal theory, even if advised of the possibility of such damages. diff --git a/docs-en/driver/driver-configuration-management.md b/docs-en/driver/driver-configuration-management.md index cacd196f413a1860451c6b7ec5e416ad2f233b6e..f0d120576278cd945d207d7fc7756b95659c68d5 100755 --- a/docs-en/driver/driver-configuration-management.md +++ b/docs-en/driver/driver-configuration-management.md @@ -271,7 +271,7 @@ The following configuration tree is generated: root { module = "sample"; foo { - attribute0 = 0x0; + attr_0 = 0x0; } bar { attr_1 = 0x1; @@ -280,7 +280,7 @@ root { } ``` -In the preceding example, the **bar** node configuration includes both the **attribute0** and **attribute1** values. The modification to **attribute0** in the **bar** node does not affect the **foo** node. +In the preceding example, the **bar** node configuration includes both the **attr\_0** and **attr\_1** values. The modification to **attr\_0** in the **bar** node does not affect the **foo** node. The path of the **foo** node is not required if the **foo** node and the **bar** node are of the same level. Otherwise, the absolute path must be used. For details, see [Modifying a Reference](#section179799204716). diff --git a/docs-en/driver/driver-development.md b/docs-en/driver/driver-development.md index 8962bda6affc42b326f2721ca683f42162ffdb31..9f48e353cc551474d2f5bbe01a09be0eeebbfea3 100755 --- a/docs-en/driver/driver-development.md +++ b/docs-en/driver/driver-development.md @@ -100,28 +100,32 @@ Driver development based on the HDF consists of two parts: driver implementation match_attr = "hdf_manager"; template host { // Host template. If the node (for example, sample_host) that inherits the template uses default values in the template, the values of the node fields can be omitted. hostName = ""; - priority = 100; - template deviceNode { - policy = 0; - priority = 100; - preload = 0; - permission = 0664; - moduleName = ""; - serviceName = ""; - deviceMatchAttr = ""; + priority = 100; + template device { + template deviceNode { + policy = 0; + priority = 100; + preload = 0; + permission = 0664; + moduleName = ""; + serviceName = ""; + deviceMatchAttr = ""; + } } } sample_host :: host{ hostName = "host0"; // Host name. The host node is used to store a certain type of drivers. priority = 100; // Host startup priority (0-200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the host loading sequence is random. - device_sample :: deviceNode { // Node of the sample driver. + device_sample :: device { // Device node of sample + device0 :: deviceNode { // DeviceNode of the sample driver policy = 1; // Driver service release policy. For details, see section Driver Service Management. priority = 100; // Driver startup priority (0–200). A larger value indicates a lower priority. The default value 100 is recommended. If the priorities are the same, the device loading sequence is random. preload = 0; // On-demand driver loading. For details, see "NOTE" at the end of this section. permission = 0664; // Permission for the driver to create device nodes. moduleName = "sample_driver"; // Driver name. The value of this field must be the same as the value of moduleName in the driver entry structure. serviceName = "sample_service"; // Name of the service released by the driver. The name must be unique. - deviceMatchAttr = "sample_config"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver. + deviceMatchAttr = "sample_config"; // Keyword matching the private data of the driver. The value must be the same as that of match_attr in the private data configuration table of the driver. + } } } } diff --git a/docs-en/driver/sdiousage-guidelines.md b/docs-en/driver/sdiousage-guidelines.md index 9aceae8cc2433f70d718dbf850bd9477bae49b93..3dbb2e228237df92e46011e165ab0f739ceaabba 100755 --- a/docs-en/driver/sdiousage-guidelines.md +++ b/docs-en/driver/sdiousage-guidelines.md @@ -63,7 +63,7 @@ if (handle == NULL) { After obtaining the device handle of an SDIO controller, exclusively claim the host before performing subsequent operations on the SDIO device. -void SdioClaimHost\(struct DevHandle\*handle\); +void SdioClaimHost\(struct DevHandle \*handle\); **Table 2** Parameter description of SdioClaimHost diff --git a/docs-en/get-code/source-code-acquisition.md b/docs-en/get-code/source-code-acquisition.md index e045630ec7b2270d5e8612c559ddcbe2693b5f06..fdd4154d06f41b75c26baba33cbebcc75dde7055 100755 --- a/docs-en/get-code/source-code-acquisition.md +++ b/docs-en/get-code/source-code-acquisition.md @@ -41,7 +41,7 @@ You can download the source code or the corresponding solutions from the image l

SHA-256 Verification Code

Hi3861 solutions

+

Hi3861 solutions (binary)

1.0

SHA-256 Verification Code

Hi3518 solutions

+

Hi3518 solutions (binary)

1.0

SHA-256 Verification Code

Hi3516 solutions

+

Hi3516 solutions (binary)

1.0

+ + + + + + + + + + + + + + + + + + + +

File System

+

Function

+

VFS

+

In essence, VFS is not a real file system. It is an abstract layer on top of a heterogeneous file system and provides you with a unified Unix-like file operation interface.

+

NFS

+

NFS allows you to share files across hosts and OSs over a network.

+

RAMFS

+

RAMFS is a RAM-based file system. All files are stored in the RAM, and file read/write operations are performed in the RAM, which reduces the read/write loss of the memory and improves the data read/write speed. It provides a RAM-based storage buffer for dynamic file systems.

+

FAT

+

There are FAT12, FAT16, and FAT32. FAT is often used on removable storage media (such as USB flash drives, SD cards, and portable hard disks) to provide better compatibility between devices and desktop systems such as Windows and Linux.

+

JFFS2

+

JFFS2 is a journal-type file system implemented on Memory Technology Devices (MTDs). It is mainly used to manage files of the NOR flash memory. JFFS2 used in the OpenHarmony kernel supports multiple partitions.

+
+ +- **[VFS](vfs.md)** + +- **[NFS](nfs.md)** + +- **[RAMFS](ramfs.md)** + +- **[FAT](fat.md)** + +- **[JFFS2](jffs2.md)** + + diff --git a/docs-en/quick-start/developing-the-first-example-program-running-on-hi3516.md b/docs-en/quick-start/developing-the-first-example-program-running-on-hi3516.md index 4d9d13b254b7cb7c3a699ce1065c2c2264f78855..024eb2b7153fd47ab2107c191c55a79a3905f870 100755 --- a/docs-en/quick-start/developing-the-first-example-program-running-on-hi3516.md +++ b/docs-en/quick-start/developing-the-first-example-program-running-on-hi3516.md @@ -4,7 +4,7 @@ This section describes how to modify, compile, burn, and run the first program, ## Acquiring Source Code -You need to acquire Hi3516 source code \([http://tools.harmonyos.com/mirrors/os/1.0/ipcamera\_hi3516dv300-1.0.tar.gz](http://tools.harmonyos.com/mirrors/os/1.0/ipcamera_hi3516dv300-1.0.tar.gz) or [https://mirrors.huaweicloud.com/harmonyos/1.0/ipcamera\_hi3516dv300-1.0.tar.gz](https://mirrors.huaweicloud.com/harmonyos/1.0/ipcamera_hi3516dv300-1.0.tar.gz)\) and download it on a Linux server. For more obtaining methods, see [Source Code Acquisition](../get-code/source-code-acquisition.md). +You need to acquire [Hi3516 source code](http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz) and download it on a Linux server. For more obtaining methods, see [Source Code Acquisition](../get-code/source-code-acquisition.md). ## Modifying a Program diff --git a/docs-en/quick-start/developing-the-first-example-program-running-on-hi3518.md b/docs-en/quick-start/developing-the-first-example-program-running-on-hi3518.md index 8515c5adfb88c01487a88ba316b596a09e5e5b6d..9aebee65819eb0cd804e7bd6afd9db8a4c1ac822 100755 --- a/docs-en/quick-start/developing-the-first-example-program-running-on-hi3518.md +++ b/docs-en/quick-start/developing-the-first-example-program-running-on-hi3518.md @@ -4,7 +4,7 @@ This section describes how to modify, compile, burn, and run the first program o ## Acquiring Source Code -You need to acquire Hi3518 source code \([http://tools.harmonyos.com/mirrors/os/1.0/ipcamera\_hi3518ev300-1.0.tar.gz](http://tools.harmonyos.com/mirrors/os/1.0/ipcamera_hi3518ev300-1.0.tar.gz) or [https://mirrors.huaweicloud.com/harmonyos/1.0/ipcamera\_hi3518ev300-1.0.tar.gz](https://mirrors.huaweicloud.com/harmonyos/1.0/ipcamera_hi3518ev300-1.0.tar.gz)\) and download it on a Linux server. For details, see [Source Code Acquisition](../get-code/source-code-acquisition.md). +You need to acquire [Hi3518 source code](http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz) and download it on a Linux server. For details, see [Source Code Acquisition](../get-code/source-code-acquisition.md). ## Modifying a Program @@ -115,5 +115,5 @@ Burn images to the Hi3518EV300 board over the serial port. ## Follow-up Learning -Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](../guide/camera-control.md). +Congratulations! You have finished all steps! You are advised to go on learning how to develop [Cameras with a Screen](en-us_topic_0000001055366100.md). diff --git a/docs-en/quick-start/developing-the-first-example-program-running-on-hi3861.md b/docs-en/quick-start/developing-the-first-example-program-running-on-hi3861.md index 86ba098af1b5750d5bb63d056e98381437f42d94..88734f1912abde6108a7ec38fb6738811a6973b2 100755 --- a/docs-en/quick-start/developing-the-first-example-program-running-on-hi3861.md +++ b/docs-en/quick-start/developing-the-first-example-program-running-on-hi3861.md @@ -4,7 +4,7 @@ This example shows how to use attention \(AT\) commands to complete WLAN module ## Acquiring Source Code -You need to acquire Hi3861 source code \([Site 1](http://tools.harmonyos.com/mirrors/os/1.0/wifiiot-1.0.tar.gz) or [Site 2](https://mirrors.huaweicloud.com/harmonyos/1.0/wifiiot-1.0.tar.gz)\) and download it on a Linux server. For more obtaining methods, see [Source Code Acquisition](../get-code/source-code-acquisition.md). +You need to acquire [Hi3861 source code](http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz) and download it on a Linux server. For more obtaining methods, see [Source Code Acquisition](../get-code/source-code-acquisition.md). ## Compiling Source Code diff --git a/docs-en/readme/application-framework.md b/docs-en/readme/application-framework.md new file mode 100755 index 0000000000000000000000000000000000000000..13bcf46ac37350cee9141ddad6c60eb8924544ad --- /dev/null +++ b/docs-en/readme/application-framework.md @@ -0,0 +1,369 @@ +# Application Framework + +## Overview + +The application framework of OpenHarmony consists of two modules: **ability management framework** and **bundle management framework**. + +**1. Ability management framework**: This framework is provided by OpenHarmony for you to develop OpenHarmony applications. The following figure shows the modules in the ability management framework. + +**Figure 1** Architecture of the Ability management framework +![](figures/architecture-of-the-ability-management-framework.png "architecture-of-the-ability-management-framework") + +- **AbilityKit** is a development kit provided by the ability management framework. You can use this kit to develop applications based on the **Ability** component. There are two types of applications developed based on the **Ability** component: **JS Ability** developed using the JavaScript language and **Native Ability** developed using the C/C++ language. The **ACE** framework encapsulates JavaScript UI components on the basis of the AbilityKit and is used to help you quickly develop JS Ability-based applications. +- **Ability** is the minimum unit for the system to schedule applications. It is a component that can implement an independent functionality. An application can contain one or more **Ability** instances. There are two types of templates that you can use to create an **Ability** instance: Page and Service. + - An **Ability using the Page template** \(Page ability for short\) provides a UI for interacting with users. + - An **Ability using the Service template** does not have a UI and is used for running background tasks. + +- An **AbilitySlice** represents a single screen and its control logic. It is specific to Page abilities. A Page ability may contain one ability slice or multiple ability slices that provide highly relevant capabilities. The following figure shows the relationship between a Page ability and its ability slices. + + **Figure 2** Relationship between a Page ability and its ability slices + ![](figures/relationship-between-a-page-ability-and-its-ability-slices.gif "relationship-between-a-page-ability-and-its-ability-slices") + + +- **Lifecycle** is a general term for all states of an ability, including **UNINITIALIZED**, **INITIAL**, **INACTIVE**, **ACTIVE**, and **BACKGROUND**. The following figure shows the lifecycle state transition of an ability. + + **Figure 3** Lifecycle state transition of a Page ability + ![](figures/lifecycle-state-transition-of-a-page-ability.png "lifecycle-state-transition-of-a-page-ability") + + Description of ability lifecycle states: + + - **UNINITIALIZED**: The ability is not initialized. This state is a temporary state. An ability changes directly to the **INITIAL** state upon its creation. + + - **INITIAL**: This state refers to the initial or stopped state. The ability in this state is not running. The ability enters the **INACTIVE** state after it is started. + + - **INACTIVE**: The ability is visible but does not gain focus. This state is the same as the **ACTIVE** state because the concept of window focus is not supported currently. + + - **ACTIVE**: The ability is in the foreground and has focus. The ability changes from the **ACTIVE** state to the **INACTIVE** state before returning to the background. + + - **BACKGROUND**: The ability returns to the background. After being re-activated, the ability enters the **ACTIVE** state. After being destroyed, the ability enters the **INITIAL** state. + + +- **AbilityLoader** is used to register and load **Ability** classes. After creating an **Ability** class, you should first call the registration API defined in **AbilityLoader** to register the **Ability** class name with the ability management framework so that this **Ability** can be instantiated when being started. +- **AbilityManager** enables inter-process communication \(IPC\) between the AbilityKit and Ability Manager Service. +- **EventHandler** is provided by the AbilityKit to enable inter-thread communication between abilities. +- The **Ability Manager Service** is a system service used to coordinate the running relationships and lifecycle states of **Ability** instances. It consists of the following modules: + - The **service startup module** starts and registers the Ability Manager Service. + - The **service interface management module** manages external capabilities provided by the Ability Manager Service. + - The **process management module** starts and destroys processes where **Ability** instances are running, and maintains the process information. + - The **ability stack management module** maintains the presentation sequence of abilities in the stack. + - The **lifecycle scheduling module** changes an ability to a particular state based on the current operation of the system. + - The **connection management module** manages connections to Service abilities. + +- The **AppSpawn** is a system service used to create the process for running an ability. This service has high permissions. It sets permissions for **Ability** instances and pre-loads some common modules to accelerate application startup. + +**2. Bundle management framework**: This framework is provided by OpenHarmony for you to manage application bundles. The following figure shows the modules in the bundle management framework. + +**Figure 4** Architecture of the bundle management framework +![](figures/architecture-of-the-bundle-management-framework.png "architecture-of-the-bundle-management-framework") + +- **BundleKit**: includes external APIs provided by the Bundle Manager Service, including the APIs for application installation and uninstallation, bundle information query, and bundle state change listeners. +- **Bundle scanning module**: parses pre-installed or installed bundles on the local device and extracts information from them for the bundle management module to manage and make the information persistent for storage. + +- **Bundle installation module**: installs, uninstalls, and updates a bundle. The **Bundle installation service** is an independent process used to create or delete installation directories and has high permissions. + +- **Bundle management module**: manages information related to application bundles and stores persistent bundle information. + +- **Bundle security management module**: verifies signatures, and grants and manages permissions. + +## Directory Structure + +The following table describes the source code directory structure of the application framework. + +**Table 1** Source code directory structure of the application framework + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

foundation/aafwk/frameworks/ability_lite

+

Core code of the ability management framework

+

foundation/aafwk/frameworks/abilitymgr_lite

+

Client code for managing the communication between the AbilityKit and Ability Manager Service

+

foundation/aafwk/frameworks/want_lite

+

Implementation code of the information carrier used for interaction between abilities

+

foundation/aafwk/interfaces/kits/abilitykit_lite

+

External APIs of the ability management framework

+

foundation/aafwk/interfaces/innerkits/abilitymgr_lite

+

APIs provided by the Ability Manager Service to other subsystems

+

foundation/aafwk/interfaces/kits/want_lite

+

External APIs of the information carrier used for interaction between abilities

+

foundation/aafwk/services/abilitymgr_lite

+

Implementation code of the Ability Manager Service

+

foundation/appexecfwk/interfaces/kits/bundle_lite

+

External bundle management APIs provided by the bundle management framework

+

foundation/appexecfwk/interfaces/innerkits/bundlemgr_lite

+

APIs provided by the Bundle Manager Service to other subsystems

+

foundation/appexecfwk/frameworks/bundle_lite

+

Client code for managing the communication between the BundleKit and Bundle Manager Service

+

foundation/appexecfwk/utils/bundle_lite

+

Tool code used in the implementation of the Bundle Manager Service

+

foundation/appexecfwk/services/bundlemgr_lite

+

Implementation code of the Bundle Manager Service

+
+ +## Constraints + +- Language version + - C++11 or later + +- The specifications of the application framework vary depending on the System-on-a-Chip \(SoC\) and underlying OS capabilities. + - Cortex-M RAM and ROM: + - RAM: greater than 20 KB \(recommended\) + - ROM: greater than 300 KB \(for the ACE framework and related subsystems, such as UIKit and engine\) + + - Cortex-A RAM and ROM + - RAM: greater than 2 MB \(recommended\) + - ROM: greater than 2 MB \(for the ACE framework and related subsystems, such as UIKit and engine\) + + + +## Compiling the Application Framework + +- Add the configuration for application framework compilation. The following section uses **hi3516dv300\_liteos\_a** as an example: + + - Add the configuration of **appexecfwk** and **aafwk** under the **subsystem\_list** field in the **build/lite/platform/hi3516dv300\_liteos\_a/platform.json** file. The sample code is as follows: + + ``` + { + "name":"aafwk", + "project":"hmf/aafwk/services/abilitymgr_lite", + "path":"build/lite/config/subsystem/aafwk", + "dir":"foundation/aafwk/services/abilitymgr_lite", + "desc":"Ability Services Manager", + "requirement":"yes", + "default":"yes", + "selected":"yes" + }, + { + "name":"appexecfwk", + "project": "hmf/appexecfwk/services/bundlemgr_lite", + "path": "build/lite/config/subsystem/appexecfwk", + "dir": "foundation/appexecfwk/services/bundlemgr_lite", + "desc":"Bundle Services Manager", + "requirement":"yes", + "default":"yes", + "selected":"yes" + }, + ``` + + - Add the configuration of **appexecfwk** and **aafwk** under the **template\_subsystem\_list** field in the **build/lite/platform/hi3516dv300\_liteos\_a/template/ipcamera.json** file. The sample code is as follows: + + ``` + "template_subsystem_list" : [ + ...... + "distributedschedule", + "aafwk", + "appexecfwk", + "communication", + ...... + ], + ``` + + - Add the configuration of particular application framework components for compilation in **build/lite/config/subsystem/aafwk/BUILD.gn** and **/build/lite/config/subsystem/appexecfwk/BUILD.gn**. The sample code is as follows: + + ``` + import("//build/lite/config/subsystem/lite_subsystem.gni") + + lite_subsystem("aafwk") { + subsystem_components = [ + "//foundation/aafwk/frameworks/kits/ability_lite:aafwk_abilitykit_lite", + "//foundation/aafwk/frameworks/kits/ability_lite:aafwk_abilityMain_lite", + "//foundation/aafwk/services/abilitymgr_lite:aafwk_services_lite", + "//foundation/aafwk/frameworks/kits/tools_lite:tools_lite", + "//foundation/aafwk/frameworks/kits/ability_lite/test:aafwk_testapp_lite", + ] + } + ``` + + ``` + import("//build/lite/config/subsystem/lite_subsystem.gni") + + lite_subsystem("appexecfwk") { + subsystem_components = [ + "//foundation/appexecfwk/kits/appkit_lite:appexecfwk_kit_lite", + "//foundation/appexecfwk/services/bundlemgr_lite:appexecfwk_services_lite", + ] + } + ``` + + - Add the configuration of service modules for compilation in **foundation/aafwk** and **foundation/appexecfwk**. Each module has its own **BUILD.gn** file. + +- After the preceding configurations are complete, run the following command to compile the entire system: + +``` +python build.py ipcamera -p hi3516dv300_liteos_a -b debug +``` + +## Running the Two Services in the Application Framework + +- The application framework has two system services **Ability Manager Service** and **Bundle Manager Service**. They are running in the foundation process. +- **Ability Manager Service** and **Bundle Manager Service** are registered with **sa\_manager**. **sa\_manager** runs in the foundation process and sets up a thread runtime environment for the two services. For details about how to create and use **Ability Manager Service** and **Bundle Manager Service**, see [Service Framework](en-us_topic_0000001051589563.md). +- Add the configuration of **abilityms** and **bundlems** for compilation in **foundation/distributedschedule/services/safwk\_lite/BUILD.gn**. The sample code is as follows: + +``` +deps = [ + "//foundation/distributedschedule/services/samgr_lite/samgr_server:server", + "//base/dfx/lite/liteos-a/source/log:hilog_a_shared", + "//foundation/aafwk/services/abilitymgr_lite:abilityms", + "//foundation/appexecfwk/services/bundlemgr_lite:bundlems", + "//base/security/services/iam_lite:pms_target", + "//foundation/distributedschedule/services/dtbschedmgr_lite:dtbschedmgr", +] +``` + +## Running an Ability Developed Based on AbilityKit + +- The demo code of the ability developed based on AbilityKit is stored in the **foundation/aafwk/frameworks/kits/ability\_lite/test** directory. If you need to modify the functionality, modify the code in the **unittest** file or add a code file, and update the configuration in **BUILD.gn** accordingly. +- Run the following command in the shell to compile the demo. After the compilation is successful, the **libLauncher.so** file is generated in **out/ipcamera\_hi3516dv300\_liteos\_a**. + + ``` + python build.py ipcamera -p hi3516dv300_liteos_a -T //foundation/aafwk/frameworks/kits/ability_lite/test:Launcher + ``` + +- Modify the **config.json** file. The example content is as follows: + +``` +{ + "app": { + "bundleName": "com.huawei.launcher", + "vendor": "huawei", + "version": { + "code": 1, + "name": "1.0" + }, + "apiVersion": { + "compatible": 3, + "target": 3 + } + }, + "deviceConfig": { + "default": { + "keepAlive": false + }, + }, + "module": { + "deviceType": [ + "smartVision" + ], + "distro": { + "deliveryWithInstall": true, + "moduleName": "Launcher", + "moduleType": "entry" + }, + "abilities": [{ + "name": "MainAbility", + "icon": "assets/entry/resources/base/media/icon.png", + "label": "test app 1", + "launchType": "standard", + "type": "page", + "visible": true + }, + { + "name": "SecondAbility", + "icon": "assets/entry/resources/base/media/icon.png", + "label": "test app 2", + "launchType": "standard", + "type": "page", + "visible": true + }, + { + "name": "ServiceAbility", + "icon": "", + "label": "test app 2", + "launchType": "standard", + "type": "service", + "visible": true + } + ] + } +} +``` + +- Generate a HAP. + - Add resource files to the **assets/entry/resources/base/media** directory based on the following directory structure. + + ![](figures/en-us_image_0000001055712348.png) + + - Compress the preceding files into a ZIP package and change the file name extension to **.hap**, for example, **Launcher.hap**. + +- Install the HAP. + + - Place the preceding HAP file in a particular directory \(**/nfs/hap/** in this example\). + - Run the following command to install the HAP: + + ``` + ./bin/bm install -p /nfs/hap/Launcher.hap + ``` + +- After the installation is complete, run the following command to run the demo: + +``` +./bin/aa start -p com.huawei.launcher -n MainAbility +``` + +## Repositories Involved + +aafwk\_frameworks\_kits\_ability\_lite + +aafwk\_interfaces\_innerkits\_abilitykit\_lite + +aafwk\_frameworks\_kits\_content\_lite + +aafwk\_interfaces\_innerkits\_abilitymgr\_lite + +aafwk\_interfaces\_innerkits\_intent\_lite + +aafwk\_interfaces\_kits\_ability\_lite + +aafwk\_services\_abilitymgr\_lite + +appexecfwk\_frameworks\_bundle\_lite + +appexecfwk\_interfaces\_innerkits\_bundlemgr\_lite + +appexecfwk\_interfaces\_innerkits\_appexecfwk\_lite + +appexecfwk\_services\_bundlemgr\_lite + +appexecfwk\_kits\_appkit\_lite + diff --git a/docs-en/readme/compilation-and-building-subsystem.md b/docs-en/readme/compilation-and-building-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..b5ce1a49c7a4662d0995a0f3228f49b1a43f4442 --- /dev/null +++ b/docs-en/readme/compilation-and-building-subsystem.md @@ -0,0 +1,277 @@ +# Compilation and Building Subsystem + +## Overview + +The compilation and building subsystem provides a compilation and building framework based on GN and Ninja. Using this subsystem, you can perform the following operations: + +1. Build products with different chip platforms. For example, you can build IP camera products on the Hi3518EV300 and Hi3516DV300 development boards and WLAN module product on the Hi3861 development board. +2. Build a customized product generated by HPM configurations. + +## Directory Structure + +``` +build/lite # Compile and build a primary directory. +├── config # Compile related configuration items. +│ ├── boards # Define variables related to a development board, including its name, target architecture, and target CPU. +│ ├── component # Define templates related to OpenHarmony components, including static libraries, dynamic libraries, extended components, and simulator libraries. +│ ├── kernel # Define compilation variables of OpenHarmony kernel and configuration parameters. +│ └── subsystem # OpenHarmony subsystem lists +├── ndk # Define NDK-related compilation scripts and configuration parameters. +├── platform # Platform-related configuration files +│ ├── hi3516dv300_liteos_a # HI3516DV300 and LiteOS_A platforms, including the platform full configuration table and boot file. +│ ├── hi3518ev300_liteos_a # HI3518EV300 and LiteOS_A platforms, including the platform full configuration table and boot file. +│ └── hi3861v100_liteos_riscv # HI3861V100 and LiteOS_RISCV platforms, including the platform full configuration table and boot file. +├── product # Product full configuration table, including the configuration unit, subsystem list, and compiler +├── toolchain # Compilation toolchain, including the compiler path, compilation options, and link options. +└── tools # Tools on which compilation and building depend, including mkfs. +``` + +## Constraints + +You must preinstall GN and Ninja and add them to environment variables. + +## Usage + +- Compile an existing product. + +``` +# Compile the WLAN platform. +python build.py wifiiot + +# Compile the IP camera based on Hi3518EV300. +python build.py ipcamera_hi3518ev300 + +# Compile the IP camera based on Hi3516DV300. +python build.py ipcamera_hi3516dv300 +``` + +- Compile components. + + This section uses a customized component as an example to describe how to compile a component, a library, and an executable file. + + The example component consists of two functions: **feature1** and **feature2**. **feature1** is a dynamic library, and **feature2** is an executable file. + + The complete directory structure of the example component is as follows: + + ``` + example # Customized component + ├── BUILD.gn # GN script of a customized component. BUILD.gn is a fixed name. + ├── feature1 # Customized unit 1 + │ ├── BUILD.gn # GN script of the customized unit 1. BUILD.gn is a fixed name. + │ ├── include # Header file folder + │ │ └── helloworld1.h # Header file 1 + │ └── src # Source file folder + │ └── helloworld1.c # Source file 1 + ├── feature2 # Customized unit 2 + │ ├── BUILD.gn # GN script of the customized unit 2. BUILD.gn is a fixed name. + │ ├── include # Header file folder + │ │ └── helloworld2.h # Header file 2 + │ └── src # Source file folder + │ └── helloworld2.c # Source file 2 + ├── build.sh # build.sh script of the customized component, which is optional + └── Makefile # Makefile script of the customized component, which is optional + ``` + + Step 1: Compile the **BUILD.gn** script of a dynamic library in the **example/feature1** directory. + + The **lite\_library** template can be used to compile dynamic and static libraries. The following is an example: + + ``` + # Example of compiling the helloworld dynamic library + # Build.gn file of helloworld + lite_library("helloworld_lib") { + target_type = "shared_library" # Compile a dynamic library. + #target_type = "static_library" # Compile a static library. + sources = [ + "src/helloworld1.c" + ] + include_dirs = [ + "include", + "../feature2_example/include" # If feature2_example is required, add it to this include. + ] + } + ``` + + Step 2: Compile the **BUILD.gn** script of an executable file in the **example/feature2** directory. + + The executable template provided by GN can be used to compile an executable file. The following is an example: + + ``` + # Compile the executable .bin file. + executable("hello_world_bin") { + sources = [ + "src/helloworld.c" + ] + include_dirs = [ + "include", + #"../feature2_example/include" # If feature2_example is required, add it to this include. + ] + # If feature1_example is required, add it to this deps. + #deps = [ + # "../feature1_example:helloworld1" + #] + } + ``` + + Step 3: Compile the **BUILD.gn** script of a component in the **example/BUILD.gn** directory. + + ``` + import("//build/lite/config/component/lite_component.gni") + # Use the BUILD.gn script to compile the entire project. + lite_component("example_gn") { + features = [ + "feature_example1:helloworld_lib", + "feature_example2:hello_world_bin", + ] + } + # Integrate the built-in build.sh or Makefile project and use the gn script to call the hybrid compilation. + build_ext_component("example_mk") { + exec_path = rebase_path(rebase_path(".", root_build_dir)) + outdir = rebase_path(get_path_info(".", "out_dir")) + prebuilts = "sh build.sh" + command = "make clean && make" + } + ``` + +- Available compilation and building variables + + The variables that can be referenced globally are defined in **//build/lite/ohos\_var.gni**. + + [Table 1](#table3296103714372) describes the common variables of users. + + **Table 1** + + + + + + + + + + + + + + + + + + + + +

Variable

+

Value Range

+

Description

+

ohos_kernel_type

+

"liteos_a", "liteos_riscv"

+

Kernel type

+

board_name

+

"hi3516dv300", "hi3518ev300", "hi3861v100"

+

Development board type

+

ohos_build_compiler

+

"gcc", "clang"

+

Compilation toolchain type

+
+ + Example: Ohos\_kernel\_type usage, component\_example/feature2\_example/BUILD.gn + + ``` + lite_library("helloworld") { + if (ohos_kernel_type == "liteos_a") { + target_type = "shared_library" + } + else if (ohos_kernel_type == "liteos_riscv") { + target_type = "static_library" + } + sources = [ + "src/helloworld1.c" + ] + include_dirs = [ + "include" + ] + } + ``` + + +- Solution + + After a template is downloaded from HPM, the customized full template is stored in the **//build/lite/product** directory. + + For example, ipcamera\_hi3516dv300.json. This file that contains the configurations of all customized subsystems and components is read. + + +- Compilation output + + All files generated during compilation are stored in the **out** directory. + + In the directory where the code is located, run **python build.py wifiiot**. After the WLAN compilation is complete, the following results are generated. + + ``` + out/ + └── wifiiot # Product name + ├── args.gn # Customized variable for gn compilation + ├── build.log # Compilation log + ├── build.ninja + ├── build.ninja.d + ├── gen + ├── Hi3861_boot_signed_B.bin # Signed bootloader backup file + ├── Hi3861_boot_signed.bin # Signed bootloader file + ├── Hi3861_loader_signed.bin # Loading file used by the burning tool + ├── Hi3861_wifiiot_app_allinone.bin # Production line tool burning file, including the independent burning program and loader program + ├── Hi3861_wifiiot_app.asm # Kernel asm file + ├── Hi3861_wifiiot_app_burn.bin # Burning file + ├── Hi3861_wifiiot_app_flash_boot_ota.bin # Flash boot upgrade file + ├── Hi3861_wifiiot_app.map # Kernel map file + ├── Hi3861_wifiiot_app_ota.bin # Kernel upgrade file + ├── Hi3861_wifiiot_app.out # Kernel output file + ├── Hi3861_wifiiot_app_vercfg.bin # The boot and kernel version numbers are configured for secure boot to prevent version rollback. + ├── libs # Library folder + ├── NOTICE_FILE + ├── obj + ├── suites + └── toolchain.ninja + Note: You are advised to use Hi3861_wifiiot_app_allinone.bin to burn files. + ``` + + +Run **python build.py ipcamera\_hi3518ev300**. After IP camera\_HI3518EV300 is compiled, the following result is generated \(the same as IP camera\_HI3516DV300\). + +``` +out/ +└── ipcamera_hi3518ev300 # Product name + ├── args.gn # Customized variable for gn compilation + ├── bin # Link to the folder where the bin file is located. + ├── bm_tool.map # map file + ├── build.log # Compilation log + ├── build.ninja + ├── build.ninja.d + ├── bundle_daemon_tool.map # map file + ├── data # Configuration file of underlying resources on which the media camera depends. + ├── dev_tools # R&D self-testing + ├── foundation.map # map file + ├── gen + ├── libaudio_api.so + ├── libs # Library files contained in an image + ├── liteos.bin # bin file of the LiteOS basic kernel + ├── media_server.map # map file + ├── NOTICE_FILE + ├── obj # Binary file, which is the compilation result folder + ├── OHOS_Image # .bin file for the LiteOS package without strip + ├── OHOS_Image.asm # Assembly code + ├── OHOS_Image.bin # Burning the .bin file for the LiteOS package + ├── OHOS_Image.map # map file + ├── rootfs.img # Compiled library and app image + ├── rootfs.tar # Compress rootfs.tar. + ├── suites # xts compilation result + ├── test # Test case compilation result + ├── toolchain.ninja + ├── userfs # User-readable and writable partition + ├── userfs.img # User-readable and writable partition in .img format, corresponding to the /storage directory after startup + └── vendor # Firmware file and configuration file of the chip +``` + +## Repositories Involved + +build\_lite + diff --git a/docs-en/readme/dfx.md b/docs-en/readme/dfx.md new file mode 100755 index 0000000000000000000000000000000000000000..90b3da09d6bed2bd66b1963480e1c3e148285640 --- /dev/null +++ b/docs-en/readme/dfx.md @@ -0,0 +1,361 @@ +# DFX + +## Introduction + +This repository is used to store the code of Design for X \(DFX\) frameworks, including Design for Reliability \(DFR\) and Design for Testability \(DFT\). + +As chip resources are limited and hardware platforms are diversified, component-based and customizable DFX frameworks need to be provided for different hardware architectures and resources. Two types of lightweight DFX frameworks \(mini and featured\) are available for hardware platforms powered by RISC-V, Cortex-M, and Cortex-A. + +- mini: This framework is intended for hardware platforms with Cortex-M or equivalent processing capabilities. The system memory is generally less than 512 KB. There is only one lightweight file system that can be used in limited scenarios, or no file system at all. The mini framework complies with the Cortex Microcontroller Software Interface Standard \(CMSIS\). + +- featured: This framework is intended for hardware platforms with Cortex-A or equivalent processing capabilities. The system memory is greater than 512 KB. There is a comprehensive file system for storing a large amount of data. The featured framework complies with the Portable Operating System Interface \(POSIX\) specifications. + + +## Directory Structure + +**Table 1** Directory structure of the source code for lightweight DFX + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

interface

+

Stores all header files for open APIs.

+

interfaces/kits/hilog

+

Defines open APIs available for logs in the featured framework.

+

interfaces/kits/hilog_lite

+

Defines open APIs available for logs in the mini framework.

+

interfaces/innerkits/hievent_lite

+

Defines open APIs available for event printing in the mini framework.

+

services/hilogcat_lite

+

Stores services and commands related to logs.

+

services/hilogcat_lite/apphilogcat

+

Provides the log flushing to disk service in the featured framework.

+

services/hilogcat_lite/command

+

Provides DFX commands specific to the mini framework.

+

services/hilogcat_lite/hilogcat

+

Provides commands to output logs in the featured framework.

+

services/hiview_lite

+

Registers the DFX service specific to the mini framework.

+

frameworks/ddrdump_lite

+

Dumps Double Data Rate (DDR) memory in the mini framework.

+

frameworks/hievent_lite

+

Records event printing in the DFX-mini framework.

+

frameworks/hilog_lite

+

Defines APIs for logging.

+

frameworks/hilog_lite/featured

+

Defines APIs for logging in the featured framework.

+

frameworks/hilog_lite/mini

+

Defines APIs for logging in the mini framework.

+

utils/lite

+

Stores utils. It contains the configuration items of the mini framework.

+
+ +## Constraints + +The overall code of the mini framework is developed based on the C standard library. + +## Usage \(mini Framework\) + +The mini framework is a simple and compact DFX design that provides the logging function. + +- **The following takes Module A as an example to describe how to add a module and print logs.** + 1. **Step 1: Add the module ID.** + + Define **HILOG\_MODULE\_A** in **HiLogModuleDef** of **interfaces/kits/hilog\_lite/hiview\_log.h**. + + ``` + typedef enum { + /** DFX */ + HILOG_MODULE_HIVIEW = 0, + /** System Module A */ + HILOG_MODULE_A, + /** Maximum number of modules */ + HILOG_MODULE_MAX + } HiLogModuleType; + ``` + + + 1. **Step 2: Register the module.** + + Add the following code to the initialization process of Module A to register it with the logging framework: + + ``` + HiLogRegisterModule(HILOG_MODULE_SAMGR, "A"); + ``` + + + 1. **Step 3: Modify the static configuration of the DFX framework.** + + Modify **g\_hiviewConfig** in the following file as required \(By default, modification is not required and logs are output to the serial port\): + + ``` + utils/lite/hiview_config.c + ``` + + + + + + + + + + + + + + + + + + + + + + +

Configuration Item

+

Description

+

outputOption

+

Log output mode. The value can be:

+

OUTPUT_OPTION_DEBUG: Logs are directly output to the serial port without cross-task scheduling. This value is used only for temporary debugging.

+

OUTPUT_OPTION_FLOW (default value): Logs are output as data flow to the serial port.

+

OUTPUT_OPTION_TEXT_FILE: Logs are output as text files.

+

OUTPUT_OPTION_BIN_FILE (to be supported): Logs are output as binary files.

+

level

+

Log level for output. Only the logs whose levels are higher than or equal to the level specified by this parameter can be output. The value can be:

+

HILOG_LV_DEBUG, HILOG_LV_INFO, HILOG_LV_WARN, HILOG_LV_ERROR, or HILOG_LV_FATAL

+

logSwitch

+

Logging switch. The log component can be successfully initialized even if this switch is turned off before compilation. By default, this switch is turned on. The value can be:

+

HIVIEW_FEATURE_ON or HIVIEW_FEATURE_OFF

+

dumpSwitch

+

Dumping switch. If this switch is turned off before compilation, the DUMP component will not be initialized. By default, this switch is turned off. The value can be:

+

HIVIEW_FEATURE_ON or HIVIEW_FEATURE_OFF

+

eventSwitch

+

Event output switch. If this switch is turned off before compilation, the Event component will not be initialized. By default, this switch is turned off. The value can be:

+

HIVIEW_FEATURE_ON or HIVIEW_FEATURE_OFF

+
+ + 2. **Step 4: Print logs.** + + Include **\#include "log.h"** in the **.c** file where logs need to be printed, call the following function: + + HILOG\_INFO\(HILOG\_MODULE\_SAMGR, "log test: %d", 88\); + + Parameter description: + + + + + + + + + + + + + + + + + + + + + + + + +

Parameter

+

Mandatory

+

Data Type

+

Description

+

mod

+

Yes

+

uint8

+

Module or service ID.

+

IDs are planned and allocated in a unified manner. A maximum of 64 IDs are supported. Third-party applications use HILOG_MODULE_APP as their module ID.

+

fmt

+

Yes

+

char *

+

Format specifier for output.

+

1. A maximum of six variable parameters are supported. %s is not supported.

+

2. The maximum length of a formatted log record is 128 bytes. If the length of a log exceeds 128 bytes, the log cannot be printed.

+

Variable parameters

+

No

+

int32

+

Only numeric types are supported. A maximum of six variable parameters are allowed.

+
+ + + +## Usage \(featured Framework\) + +The featured framework provides comprehensive DFX features and logging APIs. + +**Native C/C++** APIs + +Available hilog APIs: + +``` +HILOGD(fmt,...) HILOGI(fmt,...) HILOGW(fmt,...) HILOGE(fmt,...) +``` + +Usage guidelines: + +1. Define the log tag. + +2. Perform local debugging. \(The domain value **0** can be used.\) + +3. Include the header file: \#include + +4. Add the dependent library **libhilog** to **BUILD.gn**. + +API rules: + +1. The format specifier is labeled public by default, for example, **HILOGI\("Hello World\\n"\); \>\> Hello World**. + +2. The formatted parameter is labeled private by default, for example, **HILOGI\("Age is %d\\n", 10\); \>\> Age is **. + +3. Parameters labeled **%\{private\}** are private data, for example, **HILOGI\("Age is %\{private\}d\\n", 10\); \>\> Age is **. + +4. Parameters labeled **%\{public\}** are public data, for example, **HILOGI\("Age is %\{public\}d\\n", 10\); \>\>Age is 10**. + +Parameter description: + + + + + + + + + + + + + + + + + + + + + + +

Parameter

+

Description:

+

domain

+

Domain ID

+

tag

+

Log tag

+

isFmtPrivate

+

Whether the format specifier is private

+

fmt

+

Format specifier

+

args

+

Parameters to be displayed using the format specifier

+
+ +**Viewing logs** + +1. Go to the **/storage/data/log/hilogs** directory to view hilog logs for debugging purpose. + +2. Run the **hilogcat** command to view hilog logs in real time. + + +**Logging system architecture** + +![](figures/en-us_image_0000001054762887.png) + +1. hilogtask: kernel task for logging + - This is a task or thread of the Linux kernel. It is initialized during system startup. + - When a module in the kernel calls its logging API, it transfers the formatted log content to the task and stores it in a ringbuffer. + - When the logging API is called in user space, the formatted log content is written into the driver node by calling **ioctl**. The driver node then sends the log content to hilogtask, and hilogtask stores the log content in the ringbuffer. + +2. hilogcatd: storing logs in user space + - This is a user-space process. It periodically reads the log content from the ringbuffer and stores it in the log file. + - Log files can be compressed in **gzip** format by using **zlib**. + - The size of a single file and the number of files can be configured during compilation. + +3. hilogcat: command line tool for viewing logs + + This tool reads the content in the ringbuffer content via the kernel driver API, and then outputs the content to **stdout**. + +4. ringbuffer: configurable + - The ringbuffer size can be configured during compilation. + + +## Repositories Involved + +hiviewdfx\_frameworks\_hievent\_lite + +hiviewdfx\_frameworks\_ddrdump\_lite + +hiviewdfx\_frameworks\_hilog\_lite + +hiviewdfx\_interfaces\_innerkits\_hilog + +hiviewdfx\_interfaces\_innerkits\_hievent\_lite + +hiviewdfx\_interfaces\_kits\_hilog + +hiviewdfx\_interfaces\_kits\_hilog\_lite + +hiviewdfx\_services\_hiview\_lite + +hiviewdfx\_services\_hilogcat\_lite + +hiviewdfx\_utils\_lite + diff --git a/docs-en/readme/distributed-communication-subsystem.md b/docs-en/readme/distributed-communication-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..deba9b51a53bc51cc8e1a8b9410034fdca05fc85 --- /dev/null +++ b/docs-en/readme/distributed-communication-subsystem.md @@ -0,0 +1,183 @@ +# Distributed Communication Subsystem + +## Overview + +The use of different communication modes \(such as USB, WLAN, and Bluetooth\) varies greatly and is complex. In addition, the convergence, sharing, and conflicts between communication links cannot be resolved, and communication security is difficult to guarantee. The distributed communication subsystem manages unified distributed communication between near-field devices and provides device discovery and data transmission APIs that apply to all links. Currently, the following features are available: + +- Service publishing: After a service is published, peripheral devices can discover and use it. +- Data transmission: A session is established based on the service name and device ID to transmit data between services. +- Security: Communication data is encrypted. + +You can use APIs of the distributed communication subsystem to implement fast and secure communication between devices without caring about management of communication details, thereby achieving cross-platform development. + +## Directory Structure + +The following figure shows the softbus\_lite source code directory structure. + +**Table 1** softbus\_lite source code directory structure + + + + + + + + + + + + + + + + +

Name

+

Description

+

authmanager

+

Provides the device authentication mechanism and manages device knowledge libraries.

+

discovery

+

Provides a device discovery mechanism that is based on the Constrained Application Protocol (CoAP).

+

trans_service

+

Provides authentication and transmission channels.

+
+ +## Constraints + +- Language: C +- Networking: Devices must be in the same LAN. + +## Usage + +1. Discover devices. + +When using device discovery, ensure that the device to perform a discovery and the discovered device are in the same LAN and the devices can receive packets from each other. + +a. After a device sends a discovery request, it uses CoAP to send a broadcast packet in the LAN. The following figure shows the request packet. + +![](figures/1.png) + +b. The discovered device uses the **PublishService** API to publish services. After receiving the broadcast packet, the device sends a CoAP unicast packet to the device that performs the discovery. The following figure shows the packet example. + +![](figures/2.png) + +c. After receiving the packet, the device that performs the discovery updates device information. + +The following is an example of how to use device discovery: + +``` +// Declare the callback function. +void onSuccess(int publishId) +{ + printf("public success,publishId = %d\r\n", publishId); +} +void onFail(int publishId, PublishFailReason reason) +{ + printf("publish failed, publishId = %d, reason = %d\r\n", publishId, reason); +} +// Publish services. +PublishInfo info = {0}; +IPublishCallback cb = {0}; +cb.onPublishSuccess = onSuccess; +cb.onPublishFail = onFail; +char a[] = "456"; +info.capabilityData = a; +info.capability = "ddmpCapability"; +info.dataLen = strlen("456"); +info.medium = 2; +info.publishId = 1; +PublishService("cxx", &info, &cb); +``` + +2. Transmit data. + +The soft bus provides unified session-based transmission. Services can receive and send data or obtain basic attributes through **sessionId**. Currently, services can determine whether to accept a received session based on the service requirements and session attributes. Currently, sessions cannot be enabled. + +The sample code for data transmission is as follows: + +``` +// Define the service name, session name, and related callback. +const char *g_pkgName = "BUSINESS_NAME"; +const char *g_sessionName = "SESSION_NAME"; +struct ISessionListener * g_sessionCallback= NULL; + +// Implement the callback: After receiving data sent by the peer end using SendBytes, return a fixed message. +void OnBytesReceivedTest(int sessionId, const void* data, unsigned int dataLen) +{ + printf("OnBytesReceivedTest\n"); + printf("Recv Data: %s\n", (char *)data); + printf("Recv Data dataLen: %d\n", dataLen); + char *testSendData = "Hello World, Hello!"; + SendBytes(sessionId, testSendData, strlen(testSendData)); + return; +} + +// Implement the callback: Perform relevant operations after the session is closed, for example, releasing service resources related to the current session. The session does not need to be released by the service. +void OnSessionClosedEventTest(int sessionId) +{ + printf("Close session successfully, sessionId=%d\n", sessionId); +} + +// Implement the callback: Perform relevant operations after a session is opened. The return value 0 means to accept the session, and other values mean to reject the session. In the following example, only sessions with the same name from other devices are accepted. +int OnSessionOpenedEventTest(int sessionId) +{ + if (strcmp(GetPeerSessionName(sessionId), SESSION_NAME) != 0) { + printf("Reject the session which name is different from mine, sessionId=%d\n", sessionId); + return -1; + } + printf("Open session successfully, sessionId=%d\n", sessionId); + return 0; +} + +// Register the service session service and its callbacks with the soft bus. +int StartSessionServer() +{ + if (g_sessionCallback != NULL) { + g_sessionCallback = (struct ISessionListener*)malloc(sizeof(struct ISessionListener)); + } + if (g_sessionCallback == NULL) { + printf("Failed to malloc g_sessionCallback!\n"); + return -1; + } + g_sessionCallback->onBytesReceived = OnBytesReceivedTest; + g_sessionCallback->onSessionOpened = OnSessionOpenedEventTest; + g_sessionCallback->onSessionClosed = OnSessionClosedEventTest; + int ret = CreateSessionServer(g_pkgName, g_sessionName, g_sessionCallback); + if (ret < 0) { + printf("Failed to create session server!\n"); + free(g_sessionCallback); + g_sessionCallback = NULL; + } + return ret; +} + +// Delete the service session service and its callbacks from the soft bus. +void StopSessionServer() +{ + int ret = RemoveSessionServer(g_pkgName, g_sessionName); + if (ret < 0) { + printf("Failed to remove session server!\n"); + return; + } + if (g_sessionCallback != NULL) { + free(g_sessionCallback); + g_sessionCallback = NULL; + } +} +``` + +## Repositories Involved + +communication\_frameworks\_wifi\_lite + +communication\_frameworks\_ipc\_lite + +communication\_hals\_wifi\_lite + +communication\_interfaces\_kits\_ipc\_lite + +communication\_interfaces\_kits\_softbuskit\_lite + +communication\_interfaces\_kits\_wifi\_lite + +communication\_services\_softbus\_lite + diff --git a/docs-en/readme/distributed-scheduler.md b/docs-en/readme/distributed-scheduler.md new file mode 100755 index 0000000000000000000000000000000000000000..799453b3065a685d200f972d83d30265e97473c9 --- /dev/null +++ b/docs-en/readme/distributed-scheduler.md @@ -0,0 +1,139 @@ +# Distributed Scheduler + +## Overview + +The Distributed Scheduler sets up a distributed service platform in OpenHarmony by using a proxy between the primary and secondary devices. With the distributed scheduler, the primary device \(OpenHarmony-powered smart TV\) can start a Feature Ability \(FA\) deployed on the secondary device \(a memory-constrained OpenHarmony device such as a lite wearable\). The following figure shows the components of the Distributed Scheduler. + +![](figures/en-us_image_0000001055199362.png) + +## Directory Structure + +The following table describes the directory structure of the Distributed Scheduler. + +**Table 1** Directory structure of the major source code + + + + + + + + + + + + + + + + +

Directory

+

Description

+

dtbschedmgr_lite

+

Implementation logic of the Distributed Scheduler

+

safwk_lite

+

Implementation logic of system service processes

+

samgr_lite

+

Implementation logic of local service management

+
+ +The source code directory structure of the Distributed Scheduler is as follows: + +``` +├── BUILD.gn +├── include +│ ├── distributed_schedule_service.h # Header file for the open APIs provided by the Distributed Scheduler +│ ├── dmslite_check_remote_permission.h # Header file for the permission management module of the Distributed Scheduler +│ ├── dmslite_famgr.h # Header file for the FA management module of the Distributed Scheduler +│ ├── dmslite_inner_common.h # Header file for the service files of the Distributed Scheduler +│ ├── dmslite.h # Header file for the implementation of the Distributed Scheduler +│ ├── dmslite_log.h # Header file for the log module +│ ├── dmslite_msg_parser.h # Header file for communication data deserialization +│ ├── dmslite_tlv_common.h # Header file for the TLV data parsing module +│ └── dmslite_session.h # Header file for enabling cross-device communication +├── README.md +├── LICENSE +├── source + ├── distributed_schedule_service.c + ├── dmslite.c + ├── dmslite_check_remote_permission.c + ├── dmslite_famgr.c + ├── dmslite_msg_parser.c + ├── dmslite_tlv_common.c + └── dmslite_session.c +``` + +## Constraints + +- Language: C +- Networking: Devices must be on the same LAN. +- Operating system: OpenHarmony + +**Limitations and constraints on remote startup**: + +- Only FAs can be started remotely. Remote startup is unavailable to abilities using the Service template. +- Before the remote startup, ensure that the primary and secondary devices are on the same network segment and can ping each other. Otherwise, the remote startup fails. + +## Usage + +**Compiling the Distributed Scheduler** + +The distributed scheduler uses some feature macros to customize the function code to be compiled on different platforms. The function code is stored in **build\\lite\\config\\subsystem\\distributedschedule\\**. The directory structure is as follows: + +``` +build/lite/config/subsystem/distributedschedule +├── BUILD.gn +``` + +Modify the **BUILD.gn** file when compiling code for different platforms. The following code snippet uses code compilation for the Hi3518EV300 and Hi3516DV300 development boards as an example: + +``` +zlite_subsystem("distributedschedule") { + subsystem_components = [ + "//foundation/distributedschedule/services/samgr_lite:samgr", + ] + if (board_name == "hi3518ev300" || board_name == "hi3516dv300") { + subsystem_components += [ + "//foundation/distributedschedule/services/safwk_lite:safwk_lite", + "//foundation/distributedschedule/services/dtbschedmgr_lite:dtbschedmgr", // Configure the distributed scheduler. + ] + } +} +``` + +**\* Primary device development** \(taking FA startup as an example\) + +Create a **Want** instance. You should first create an **ElementName** object with **deviceId**, **bundleName**, and **abilityName** specified and add this object to the **Want** instance. Then, set the multi-device startup flag **Want.FLAG\_ABILITYSLICE\_MULTI\_DEVICE** to the **Want** instance to enable remote FA startup. + +``` +// Import related header files. +import ohos.aafwk.ability.Ability; +import ohos.aafwk.content.Want; +import ohos.bundle.ElementName; + +// Start the remote FA on the secondary device. +Want want = new Want(); // Create a Want instance that encapsulates information about the remote FA to start. +ElementName name = new ElementName("remote_device_id", "com.huawei.remote_package_name", "remote_class_name"); +want.setElement(name); // Add information about the target FA for startup to the Want instance. +want.setFlags(Want.FLAG_ABILITYSLICE_MULTI_DEVICE); // Set the multi-device startup flag. If this flag is not set, remote FA startup will be unavailable. +startAbility(want); // Start the specified FA based on the want parameter. If the name and type of the want parameter are different from those used in the IDE, use the parameter name and type in the IDE. +``` + +**\* Prerequisites** + +**Networking between the primary and secondary devices**: Before the remote startup, ensure that the two devices are on the same network segment and can ping each other. Otherwise, the remote startup fails. + +**FA installation on the secondary device**: Before the remote startup, ensure that the target FA has been installed on the secondary device. + +**\* Execution** \(taking FA startup as an example\) + +Call **startAbility** on the primary device \(smart TV\) to start the FA of the secondary device \(memory-constrained device such as a lite wearable\). + +## Repositories Involved + +distributedschedule\_interfaces\_kits\_samgr\_lite + +distributedschedule\_services\_dtbschedmgr\_lite + +distributedschedule\_services\_safwk\_lite + diff --git a/docs-en/readme/driver-subsystem.md b/docs-en/readme/driver-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..25b63a72dd2a9e5a74edf553b21948ce89c31d4e --- /dev/null +++ b/docs-en/readme/driver-subsystem.md @@ -0,0 +1,255 @@ +# Driver Subsystem + +## Overview + +The OpenHarmony driver subsystem is constructed using the C object-oriented programming \(OOP\). It provides a unified driver platform through platform decoupling, kernel decoupling, and compatible kernels. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you develop a driver that can be deployed on different systems supporting HDF. + +The OpenHarmony driver subsystem provides the following key features and capabilities to shorten the driver development period and make third-party device driver integration much easier: + +- Flexible framework capabilities + + Based on the traditional driver framework, the OpenHarmony driver subsystem builds flexible framework capabilities to deploy terminal products with the capacity ranging from hundreds KB to hundreds MB of memory. + + +- Standardized driver APIs + + The OpenHarmony driver subsystem provides you with abundant and stable driver APIs, which are compatible with those of future-proof smartphones, tablets, smart TVs. + + +- Component-based driver models + + The OpenHarmony driver subsystem supports component-based driver models. It provides more refined driver management to dismantle components, enabling you to focus on the interaction between the hardware and driver. + + The subsystem also presets some template-based driver model components, such as the network device models. + + +- Normalized configuration GUIs + + The OpenHarmony driver subsystem provides a unified configuration GUI and a cross-platform tool for configuration conversion and generation to implement seamless switchover across platforms. + + +You can use DevEco to manage driver projects, generate driver templates, and manage settings to make the development of OpenHarmony drivers easier. + +## Architecture + +The OpenHarmony driver framework adopts the primary/secondary mode and is developed based on the framework, model, competence library, and tool. + +**Figure 1** Interaction between the driver and framework + + +![](figures/en-us_image_0000001053805078.png) + +- Driver framework stored in the **frameworks/core** directory + - Loads and starts drivers. + - Deploys and expands the driver framework flexibly through the object manager. + +- Driver models stored in the **frameworks/model** directory + - Provides model-based driving capabilities, such as network device models. + +- Driver capability library stored in the **frameworks/ability** directory + - Provides basic driver models, such as the I/O communication model. + +- Driver tools stored in the **frameworks\\tools** directory + - Provides tools for HDI API conversion, and driver configuration and driver compilation. + +- Driver APIs stored in the **lite\\hdi** directory + - Provides normalized driver APIs. + +- Support stored in the **frameworks/support** directory + - Provides platform driver APIs and system APIs with normalized abstraction capabilities. + + +## Directory Structures + +**Table 1** Directory structure of the OpenHarmony driver framework + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

hdf

+

Indicates the OpenHarmony driver framework.

+

hdf\frameworks

+

Provides the source code to develop the driver frameworks, driver models, and capability model libraries.

+

hdf\frameworks\ability

+

Provides functional capabilities for the driver development, such as the message model libraries.

+

hdf\frameworks\core

+

Provides the core code to implement the OpenHarmony driver framework.

+

hdf\frameworks\core\host

+

Provides functions of the driver host environment framework, including:

+

1. Loading and starting a driver, and dispatching device nodes.

+

2. Dispatching events.

+

3. Managing the internal power status.

+

4. Managing the common driver resource configurations.

+

hdf\frameworks\core\manager

+

Provides the management modules of the driver framework, including:

+

1. Driver API management module.

+

2. Driver configuration management module.

+

3. Device node management module.

+

4. Security management module.

+

5. Fault management module.

+

hdf\frameworks\core\shared

+

Provides shared code for the host and manager.

+

hdf\frameworks\model

+

Provides a universal framework model for drivers.

+

hdf\frameworks\model\network

+

Provides network device models for drivers.

+

hdf\frameworks\support\

+

Provides drivers with system APIs and hardware, such as GPIO, I2C, and SPI capabilities.

+

Some interfaces can be migrated across platforms.

+

hdf\frameworks\support\osal

+

Provides platforms with common adaptation interfaces, such as memory, thread, and mutex.

+

hdf\frameworks\support\platform

+

Provides APIs that support the common hardware of platforms, such as GPIO, I2C, and SPI capabilities.

+

hdf\frameworks\tools

+

Provides the driver capability libraries, such as the tool that configures and compiles the HCS (HDF Configuration Source).

+

hdf\frameworks\utils

+

Provides basic data structures and algorithms.

+

hdf\lite\adapter

+

Adapts to kernel operation APIs and provides abstract APIs.

+

hdf\lite\include

+

Provides driver APIs for lightweight devices.

+

hdf\lite\hdi

+

Provides APIs of the OpenHarmony driver.

+
+ +## Constraints + +None + +## Use + +**Figure 2** Interaction between the driver and framework + + +![](figures/en-us_image_0000001052764349.png) + +Driver loading is mostly done by the driver framework, and you only need to register and configure required APIs. The driver framework will load and initialize the driver based on the parsing result. + +Driver development based on the HDF consists of the following three parts: + +1. Driver: develop the functions. + +2. Information configuration: present the loading information of the driver. + +3. Resource configuration: configure the hardware information of the driver. + +The driver mainly aims to develop the functions. + +The first part that catches your eyes is the driver entry, which is described through **DriverEntry** alignment. + +Three APIs are available, namely **bind**, **init**, and **release**. + +``` +struct HdfDriverEntry g_deviceSample = { + .moduleVersion = 1, + .moduleName = "sample_driver", + .Bind = SampleDriverBind, + .Init = SampleDriverInit, + .Release = SampleDriverRelease, +}; +``` + +**Bind**: This API is used to bind driver devices and its functions. + +``` +int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject) +{ + // TODO: Bind device service to device object. + // And you can also initialize device resources here. + return HDF_SUCCESS; +} +``` + +**Init**: When devices are successfully bound, the framework calls **Init** to initialize the driver. After initialization is complete, the driver framework will determine whether to create external service APIs based on the configuration file. + +If the driver fails to be initialized, the driver framework will automatically release the created device API. + +``` +int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject) +{ + // TODO: Init hardware or other resources here. + return HDF_SUCCESS; +} +``` + +**Release**: When you need to uninstall a driver, the drive framework calls this function to release the driver resources. Then, other internal resources will be released. + +``` +void SampleDriverRelease(struct HdfDeviceObject *deviceObject) +{ + // Release all resources. + return; +} +``` + +## Installation + +The OpenHarmony driver is mainly deployed in the kernel space using the static link mode. It is compiled and packed with the kernel subsystem and system image. + +**Figure 3** OpenHarmony driver installation + + +![](figures/en-us_image_0000001053044331.png) + +## Repositories Involved + +drivers\_hdf\_frameworks + +drivers\_hdf\_lite + diff --git a/docs-en/readme/figures/1.png b/docs-en/readme/figures/1.png new file mode 100755 index 0000000000000000000000000000000000000000..85b66cb7f38a629f1be914dd10c87c66c6acc45e Binary files /dev/null and b/docs-en/readme/figures/1.png differ diff --git a/docs-en/readme/figures/2.png b/docs-en/readme/figures/2.png new file mode 100755 index 0000000000000000000000000000000000000000..55c0567ab2d9d70555dd07ca050bae228ef46752 Binary files /dev/null and b/docs-en/readme/figures/2.png differ diff --git a/docs-en/readme/figures/access-policy-structure.png b/docs-en/readme/figures/access-policy-structure.png new file mode 100755 index 0000000000000000000000000000000000000000..19042a9bd4da73c5640e9006b1ba23911bc2e932 Binary files /dev/null and b/docs-en/readme/figures/access-policy-structure.png differ diff --git a/docs-en/readme/figures/architecture-of-the-ability-management-framework.png b/docs-en/readme/figures/architecture-of-the-ability-management-framework.png new file mode 100755 index 0000000000000000000000000000000000000000..0a54bd695996186eb7e806abed508dfaaf26807d Binary files /dev/null and b/docs-en/readme/figures/architecture-of-the-ability-management-framework.png differ diff --git a/docs-en/readme/figures/architecture-of-the-bundle-management-framework.png b/docs-en/readme/figures/architecture-of-the-bundle-management-framework.png new file mode 100755 index 0000000000000000000000000000000000000000..6f7e3e730e20598be87ce8191b20af9ed33977a8 Binary files /dev/null and b/docs-en/readme/figures/architecture-of-the-bundle-management-framework.png differ diff --git a/docs-en/readme/figures/declaring-permissions.png b/docs-en/readme/figures/declaring-permissions.png new file mode 100755 index 0000000000000000000000000000000000000000..cb34dac621d30de96efeef18f8b5d4519ab3de8e Binary files /dev/null and b/docs-en/readme/figures/declaring-permissions.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001051282241.png b/docs-en/readme/figures/en-us_image_0000001051282241.png new file mode 100755 index 0000000000000000000000000000000000000000..3f88603e64db4a055e0862aa3e4d134e31491ddf Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001051282241.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001051351505.png b/docs-en/readme/figures/en-us_image_0000001051351505.png new file mode 100755 index 0000000000000000000000000000000000000000..82ecf5d03a518987429deff0461e9fc4e9c4c583 Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001051351505.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001051562162.png b/docs-en/readme/figures/en-us_image_0000001051562162.png new file mode 100755 index 0000000000000000000000000000000000000000..d5480f2b75138ead68e798c6cdd9311be7c3c8ad Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001051562162.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001051990283.png b/docs-en/readme/figures/en-us_image_0000001051990283.png new file mode 100755 index 0000000000000000000000000000000000000000..a6e066359edea0cadab2a0a30b2d2becd268e2f5 Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001051990283.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001052278423.png b/docs-en/readme/figures/en-us_image_0000001052278423.png new file mode 100755 index 0000000000000000000000000000000000000000..cb77c5ed78f92292559fadbbbd4d3734056f9a33 Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001052278423.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001052584330.png b/docs-en/readme/figures/en-us_image_0000001052584330.png new file mode 100755 index 0000000000000000000000000000000000000000..592f295b2c056d5a0ec4df8fe87f76217fcb74bf Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001052584330.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001052764349.png b/docs-en/readme/figures/en-us_image_0000001052764349.png new file mode 100755 index 0000000000000000000000000000000000000000..e4c9a55609841fcf1d8f9171ceba02682003619d Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001052764349.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001053044331.png b/docs-en/readme/figures/en-us_image_0000001053044331.png new file mode 100755 index 0000000000000000000000000000000000000000..86c79b27c6bdda3439edcb612b837af464b56fbc Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001053044331.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001053805078.png b/docs-en/readme/figures/en-us_image_0000001053805078.png new file mode 100755 index 0000000000000000000000000000000000000000..3036ff8a5aedd4ad8573797ab94df3858791c94e Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001053805078.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001054501634.png b/docs-en/readme/figures/en-us_image_0000001054501634.png new file mode 100755 index 0000000000000000000000000000000000000000..1be8c087486aae1f25b5687fc2d83f1479e1104d Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001054501634.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001054762887.png b/docs-en/readme/figures/en-us_image_0000001054762887.png new file mode 100755 index 0000000000000000000000000000000000000000..7c48bb04154d50efe7c6bdfb6e001093f63379d7 Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001054762887.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001055193731.png b/docs-en/readme/figures/en-us_image_0000001055193731.png new file mode 100755 index 0000000000000000000000000000000000000000..c4de94624a352170d7924faa71f986e2be16eed5 Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001055193731.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001055193837.png b/docs-en/readme/figures/en-us_image_0000001055193837.png new file mode 100755 index 0000000000000000000000000000000000000000..576287a860b46bcb21017e8a73cf7f6197320661 Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001055193837.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001055199362.png b/docs-en/readme/figures/en-us_image_0000001055199362.png new file mode 100755 index 0000000000000000000000000000000000000000..91ee8f2b429c045f5f3fc57a09c76bb9c6c8bc14 Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001055199362.png differ diff --git a/docs-en/readme/figures/en-us_image_0000001055712348.png b/docs-en/readme/figures/en-us_image_0000001055712348.png new file mode 100755 index 0000000000000000000000000000000000000000..fa3b3160f094a3dddfa8d46047dfc9da2bb96fcc Binary files /dev/null and b/docs-en/readme/figures/en-us_image_0000001055712348.png differ diff --git a/docs-en/readme/figures/example-feature-policy.png b/docs-en/readme/figures/example-feature-policy.png new file mode 100755 index 0000000000000000000000000000000000000000..257a2c2f27bf509820566feb43c7d92b632c2649 Binary files /dev/null and b/docs-en/readme/figures/example-feature-policy.png differ diff --git a/docs-en/readme/figures/js-framework.png b/docs-en/readme/figures/js-framework.png new file mode 100755 index 0000000000000000000000000000000000000000..f39aa861bcad95e8e7917ddc5688216956c7ca72 Binary files /dev/null and b/docs-en/readme/figures/js-framework.png differ diff --git a/docs-en/readme/figures/lifecycle-state-transition-of-a-page-ability.png b/docs-en/readme/figures/lifecycle-state-transition-of-a-page-ability.png new file mode 100755 index 0000000000000000000000000000000000000000..b64f5cb67b7838095c757d419f72b3f7d4e9ee11 Binary files /dev/null and b/docs-en/readme/figures/lifecycle-state-transition-of-a-page-ability.png differ diff --git a/docs-en/readme/figures/registering-a-feature-policy.png b/docs-en/readme/figures/registering-a-feature-policy.png new file mode 100755 index 0000000000000000000000000000000000000000..9a4c306a5f8247805f21e2f054e62693874a8086 Binary files /dev/null and b/docs-en/readme/figures/registering-a-feature-policy.png differ diff --git a/docs-en/readme/figures/relationship-between-a-page-ability-and-its-ability-slices.gif b/docs-en/readme/figures/relationship-between-a-page-ability-and-its-ability-slices.gif new file mode 100755 index 0000000000000000000000000000000000000000..dd5af6fa52800c0d7fad7dbc8ae6e21149ae9897 Binary files /dev/null and b/docs-en/readme/figures/relationship-between-a-page-ability-and-its-ability-slices.gif differ diff --git a/docs-en/readme/globalization-subsystem.md b/docs-en/readme/globalization-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..adbb26a93f8f3b7dcbf16d2cd6f1e1abb25a6d46 --- /dev/null +++ b/docs-en/readme/globalization-subsystem.md @@ -0,0 +1,18 @@ +# Globalization Subsystem + +## Overview + +Users can set the locale regarding about 68 languages and regions on OpenHarmony devices. As the locale settings are synchronized from one OpenHarmony device to another during interconnection, multi-language resource backtracking and multi-language preference support should be taken into account. + +The global resource manager mainly provides the following capabilities: + +- Multi-language resource backtracking: Users in different regions have their own cultural background and use their respective native languages. During resource loading, it is critical to support multi-language locale settings, specifically, to use as few languages as possible to match users' particular cultural background. + +- Multi-language preference support: One of users' multiple preferred languages is selected and displayed for users \(for example, the Swiss\) who have multiple native languages. + +## Repositories Involved + +global\_frameworks\_resmgr\_lite + +global\_interfaces\_innerkits\_resmgr\_lite + diff --git a/docs-en/readme/graphics-subsystem.md b/docs-en/readme/graphics-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..a42a8dfbab0bf7f4507a8be1d5584be8c0119519 --- /dev/null +++ b/docs-en/readme/graphics-subsystem.md @@ -0,0 +1,107 @@ +# Graphics Subsystem + +## Overview + +The graphics subsystem mainly includes user interface \(UI\) components, layout, animator, font, input event, window management, rendering and drawing modules. It builds an application framework based on the LiteOS to develop applications on Internet of Things \(IoT\) devices with small hardware resources. + +Module description: + +- Components: provides application components, including the UIView, UIViewGoup, UIButton, UILabel, UILabelButton, UIList, and UISlider. +- Layout: lays out components, including Flexlayout, GridLayout, and ListLayout. +- Animator: defines functions for customizing animators. +- Fonts: defines functions related to fonts. +- Event: processes basic events, including click, press, drag, and long press. +- Tasks: manages tasks. +- Input: processes input events. +- Display: processes display events. +- Render: renders and draws components. +- Draw2d: draws lines, rectangles, circles, arcs, images, and texts, and interconnects with software rendering and hardware acceleration. +- Surface: applies for and releases shared memory. +- Window: manages windows, including creating, showing, hiding a window, and combining windows. +- Adapter: interconnects with underlying interfaces of the adaptation layer. + +## Directory Structure + +**Table 1** Directory structure of source code for the graphics subsystem + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

config

+

Configuration files

+

frameworks/surface

+

Shared memory

+

frameworks/ui

+

UI module, which defines functions related to UI components, animators and fonts.

+

hals

+

Hardware abstraction layer (HAL) logic

+

interfaces/ui

+

Header files of open APIs related to the UI module

+

interfaces/utils

+

Header files of utils for the graphics subsystem

+

services/ims

+

Input event management, including processing and distributing input events such as click and press.

+

services/wms

+

Window management, including creating, managing, and combining windows.

+

utils

+

Public library of the graphics subsystem

+
+ +## Constraints + +- Language version + - C++ 11 or later + +- The specifications of the application framework vary depending on the System-on-a-Chip \(SoC\) and underlying OS capabilities. + - Cortex-M RAM and ROM: + - RAM: greater than 100 KB \(recommended\) + - ROM: greater than 300 KB + + - Cortex-A RAM/ROM: + - RAM: greater than 1 MB \(recommended\) + - ROM: greater than 1 MB + + + +## Adding a UI Component + +All components inherit from the base class UIView and share common attributes and styles. UI components are classified into common and container ones. You can add child components for a container component, but not for a common component. + +Store new header files in the **interfaces/ui/components** directory and .cpp files in the **frameworks/ui/src/components** directory. Override **OnDraw** function to draw this UI component. Add the new file to the **frameworks/ui/BUILD.gn** directory and it will be compiled to **libui.so** during building. + +## Repositories Involved + +graphic\_lite + diff --git a/docs-en/readme/js-application-framework.md b/docs-en/readme/js-application-framework.md new file mode 100755 index 0000000000000000000000000000000000000000..d1e8b4a14c903554c38f434ff468db3281286f67 --- /dev/null +++ b/docs-en/readme/js-application-framework.md @@ -0,0 +1,187 @@ +# JS Application Framework + +## Introduction + +The JS application framework allows you to develop web-like applications across platforms. The framework uses Toolkit to pack your **.hml**, **.css**, and **.js** files to a JavaScript bundle, parses the bundle, and renders it with view components of the C++ native UI. You can use the declarative APIs to develop applications. This allows data to drive view changes and avoids a large number of view operations, greatly simplifying application development. + +The following figure shows the framework modules. + +![](figures/js-framework.png) + +## Directory Structure + +The source code of the framework is stored in **/foundation/ace**. The following shows the directory structure. + +``` +/foundation/ace +├── frameworks #Framework code +│ └── lite +│ ├── examples #Sample code +│ ├── include #Exposed header files +│ ├── packages #JavaScript implementation + │ ├── src #Source code +│ ├── targets #Configuration file of each target device + │ └── tools #Tool code +├── interfaces #APIs exposed externally +│ └── innerkits #Header files of internal subsystems +│ └── builtin #JavaScript third-party module APIs exposed by the JS application framework +``` + +## Constraints + +- Language version + - C++11 or later + - JavaScript ES5.1 or later + + +- Framework runtime memory consists of: + - Pre-allocated memory for running the JavaScript engine. The memory size is adjustable and depends on the complexity of the device application. Generally, 64 KB to 512 KB is recommended. + - Memory for the framework itself. For devices whose memory capacity exceeds 100 KB, the framework memory can be managed by a pre-allocated memory pool, which can be shared with the native UI framework. The memory pool manages objects and heap memory in a unified manner. + +- The framework provides different specifications for various chip platforms and underlying OS capabilities. + - Cortex-M RAM and ROM + - JavaScript engine memory pool: greater than 48 KB \(recommended\) + - RAM: memory pool shared with the native UI \(recommended\). The size must be greater than 80 KB. + - ROM: greater than 300 KB \(for the JS application framework and related subsystems, such as native UI and JavaScript engine\) + + - Cortex-A RAM and ROM + - JavaScript engine memory pool: greater than 128 KB \(recommended\) + - RAM: greater than 512 KB \(recommended\) + - ROM: greater than 2 MB \(for the JS application framework and related subsystems, such as native UI and JavaScript engine\) + + + +## Using targets + +The implementation of the JS application framework consists of two parts: native and JavaScript. The native part is developed by C++ and is the main body of the framework. The JavaScript part supports the runtime environment of JavaScript files, and supports the interaction between the JavaScript runtime and native framework through some global functions or objects exposed to the JavaScript engine. + +The framework uses feature macros to customize function code to be compiled on different platforms. The feature macros are stored in header files in **foundation/ace/frameworks/lite/targets**. The directory structure is as follows: + +``` +/foundation/ace/frameworks/lite/targets +├── default/ +│ └── acelite_config.h +├── linux/ #Linux environment configuration files +│ └── acelite_config.h +├── liteos_a/ #Environment configuration files for LiteOS Cortex-A +│ └── acelite_config.h +├── liteos_m/ #Environment configuration files for LiteOS Cortex-M +│ └── acelite_config.h +├── platform_adapter.cpp +├── platform_adapter.h +└── simulator/ #Simulator environment configuration files + └── win/ + └── acelite_config.h* +``` + +When compiling for different platform targets, use the **acelite\_config.h** file in the corresponding platform directory. You can configure the header file searching path for compilation to locate the file to use. The following takes **ninja** and **cmake** build tools as examples: + +ninja: + +``` + if (hos_kernel_type == "liteos_a" || hos_kernel_type == "liteos_m" || + hos_kernel_type == "liteos_riscv") {// Select different header file searching paths based on the target kernel platform. + include_dirs += [ "targets/liteos-a" ] + } else if (hos_kernel_type == "linux") { + include_dirs += [ "targets/linux" ] + } +``` + +cmake: + +``` +...... +set(ACE_LITE_CONFIG_PATH "${CMAKE_CURRENT_SOURCE_DIR}/targets/simulator/win") +set(JSFWK_INCLUDE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/include") +set(JSFWK_SOURCE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/src/core") +set(UIKIT_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../ui") +set(THIRTY_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../third_party") +set(JSFWK_SIMULATOR_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../tools/simulator") +set(JS_API_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../api/emui_band/MoltenCore/application/framework/ace/api") +set(JSFWK_SIMULATOR_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../tools/simulator") +set(AAFWK_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../aafwk") + +# header files +include_directories( + ${ACE_LITE_CONFIG_PATH} + ${JSFWK_INCLUDE_PATH}/async + ${JSFWK_INCLUDE_PATH}/base + ${JSFWK_INCLUDE_PATH}/context + ${JSFWK_INCLUDE_PATH}/jsi + ${JSFWK_SOURCE_PATH} + ...... +``` + +The **acelite\_config.h** file is used to enable or disable the feature macros of different platforms. It can also be used to define constants for shielding platform differences. For example, platform file systems are different, and the names of some fixed directories might be different. These constants can be defined as follows: + +**liteos-a/acelite\_config.h** + +``` +#define JS_FRAMEWORK_PATH "//system/ace/bin/" +``` + +**simulator/win/acelite\_config.h** + +``` +#define JS_FRAMEWORK_PATH "..\\..\\..\\jsfwk\\packages\\runtime-core\\build" +``` + +## Using Runtime-core + +Runtime-core is a JavaScript-based simple data hijacking framework provided by the JS application framework to implement unidirectional data binding. The directory structure is as follows: + +``` +/foundation/ace/frameworks/lite/packages +└── runtime-core + ├── .babelrc #Babel configuration file + ├── .editorconfig #IDE configuration file + ├── .eslintignore #Configuration file of the ESLint tool. You can set a directory or files that will not be scanned by the ESLint tool. + ├── .eslintrc.js #ESLint configuration file for scanning rules. + ├── .gitignore + ├── package.json #NPM file + ├── package-lock.json #NPM dependency lock file + ├── .prettierrc #Configuration file for code formatting rules + ├── scripts #Directory for compilation scripts + │ ├── build.js #Compilation script + │ └── configs.js #Rollup configuration file + ├── .size-snapshot.json + └── src #Source code + ├── core #ViewModel core implementation code + │ └── index.js + ├── index.js + ├── observer #Data hijacking implementation code + │ ├── index.js + │ ├── observer.js + │ ├── subject.js + │ └── utils.js + ├── profiler #profiler directory + │ └── index.js + └── __test__ #Test cases + └── index.test.js +``` + +The following NPM commands are supported: + +- **npm run build** + + The JavaScript engine integrated in the JS application framework supports ES5.1 syntax only. However, the runtime-core is implemented using JavaScript ES6. Therefore, you should use Babel for ES6 code degradation and use Rollup to package the code. Run the **npm run build** command, and the packaged files are output to the **build** directory. + + ``` + build/ + ├── framework-dev.js // Framework code used by the development environment (uncompressed and obfuscated) + ├── framework-dev.min.js // Framework code used in the development environment (compressed and obfuscated) + ├── framework-dev.js // Framework code used by the production environment (uncompressed and obfuscated) + ├── framework-dev.min.js // Framework code used in the production environment (compressed and obfuscated) + ``` + +- **npm run test** + + Runtime-core uses Jest for unit testing. Run the **npm run test** command to start the unit test. + + +## Repositories Involved + +ace\_lite\_jsfwk + +ace\_interfaces\_innerkits\_builtin + diff --git a/docs-en/readme/kernel-subsystem.md b/docs-en/readme/kernel-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..fde225081036b99385f32746a9b7a1c097af4e0f --- /dev/null +++ b/docs-en/readme/kernel-subsystem.md @@ -0,0 +1,105 @@ +# Kernel Subsystem + +## Overview + +The OpenHarmony kernel is a real-time OS kernel developed by Huawei for IoT devices. It is as lightweight as RTOS and as easy-to-use as Linux. + +The kernel repository is used to store the source code of the OpenHarmony kernel components, including process and thread scheduling, memory management, IPC mechanism, and timer management, as well as the version package compilation information. + +## Directory Structure + +**Table 1** Directory structure of the OpenHarmony lightweight kernel source code + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

apps

+

User-space init and shell application program

+

arch

+

System architecture, such as ARM

+

bsd

+

Code of the driver and adaptation layer module related to the FreeBSD, such as the USB module

+

compat

+

Compatibility with the kernel POSIX interfaces

+

fs

+

File system module, which mainly derives from the NuttX open-source project

+

kernel

+

Kernel modules including the process, memory, and IPC modules

+

lib

+

Kernel library

+

net

+

Network module, which mainly derives from the lwip open-source project

+

platform

+

Code for supporting different systems on a chip (SOCs), such as Hi3516DV300

+

security

+

Code related to security features, including process permission management and virtual ID mapping management

+

syscall

+

System calls

+

test

+

Kernel and user-space test cases

+

tools

+

Code related to compilation configuration and menuconfig

+
+ +## Constraints + +By default, the JFFS2 file system is used during system startup. This file system is read-write. If other file systems need to be used, the configurations of the file systems must be added accordingly. + +## Usage + +For details, see [en-us\_bookmap\_0000001050030794.md\#en-us\_topic\_0000001050032743](en-us_bookmap_0000001050030794.md#en-us_topic_0000001050032743). + +## Repositories Involved + +drivers\_liteos + +kernel\_liteos\_a + +kernel\_liteos\_a\_huawei\_proprietary\_fs\_proc + +kernel\_liteos\_m + diff --git a/docs-en/readme/media-subsystem.md b/docs-en/readme/media-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..438ddd7605260326eddbf5843ebfc4bc4e21a5a6 --- /dev/null +++ b/docs-en/readme/media-subsystem.md @@ -0,0 +1,457 @@ +# Media Subsystem + +## Overview + +This repository stores source code information of the multimedia subsystem. It provides unified interfaces for you to develop media applications. With this repository, you can easily obtain media resources and focus on service development. + +Based on code information about this repository, the device configuration file is stored in **test\\lite\\devini**. When using the configuration file, you can place it in the **/data** directory of the development board in use. You use the configuration file for the adaption to the sensor, resolution, frame rate, and more. + +Subsystem architecture + +![](figures/en-us_image_0000001055193837.png) + +Service process + +![](figures/en-us_image_0000001055193731.png) + +As shown in these figures, the multimedia subsystem consists of camera, recorder, and player modules. The camera module provides YUV or RGB, JPEG, and H.264 or H.265 data, which is stored in the surface \(shared memory\); the recorder module packs H.264 or H.265 and AAC data in the surface into MP4 files; the player module demultiplexes the MP4 files into audio and video data, sends the data to corresponding decoders, and then plays the audio and video. + +## Directory Structure + +**Table 1** Directory structure of multimedia source code \(native APIs\) + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

foundation\multimedia\frameworks

+

Internal framework implementation, including Audio, Camera, and Player.Recorder

+

foundation\multimedia\interfaces\kits

+

External header files

+

foundation\multimedia\services\media_lite

+

Underlying service implementation

+

foundation\multimedia\utils\lite

+

Common module implementation

+

foundation\multimedia\test\lite

+

API testing code

+
+ +## Constraints + +- C++11 or later +- Currently, Hi3516DV300 and Hi3518EV300 are supported, and only Hi3516DV300 supports the playback function. + +## Installation + +- Load the kernel and related drivers before installing the repository. For details, see readme files of kernel and driver subsystems. +- Modify required configuration files, such as those in **test/devini**. For details, see the _Configuration File Description_. Currently, only IMX335 and IMX327 sensors are supported. For other sensors, seek help from the open source community. +- For details about how to invoke native APIs, see the demonstration in the **test** directory. + +## Use Case + +You can use media APIs to record, preview, and play audios and videos. Before using these resources, create a **CameraKit** object and register various callbacks to respond to many events in the media module. You create a **Camera** object to operate camera resources, for example, to start preview, recording, and stream capturing, and set related parameters. + +The following example overrides the event class: + +``` +/* + * Copyright (c) 2020 Huawei Device Co., Ltd. + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +#include "camera_kit.h" +#include "recorder.h" + +#include +#include +#include +#include +#include + +using namespace std; +using namespace OHOS; +using namespace OHOS::Media; + +static void SampleSaveCapture(const char *p, uint32_t size) +{ + cout << "Start saving picture" << endl; + struct timeval tv; + gettimeofday(&tv, NULL); + struct tm *ltm = localtime(&tv.tv_sec); + if (ltm != nullptr) { + ostringstream ss("Capture_"); + ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg"; + + ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc); + cout << "write " << size << " bytes" << endl; + pic.write(p, size); + cout << "Saving picture end" << endl; + } +} + +Recorder *SampleCreateRecorder() +{ + int ret = 0; + int32_t sampleRate = 48000; + int32_t channelCount = 1; + AudioCodecFormat audioFormat = AAC_LC; + AudioSourceType inputSource = AUDIO_MIC; + int32_t audioEncodingBitRate = sampleRate; + VideoSourceType source = VIDEO_SOURCE_SURFACE_ES; + int32_t frameRate = 30; + float fps = 30; + int32_t rate = 4096; + int32_t sourceId = 0; + int32_t audioSourceId = 0; + int32_t width = 1920; + int32_t height = 1080; + VideoCodecFormat encoder; + encoder = HEVC; + width = 1920; + height = 1080; + Recorder *recorder = new Recorder(); + if ((ret = recorder->SetVideoSource(source, sourceId)) != SUCCESS) { + cout << "SetVideoSource failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetVideoEncoder(sourceId, encoder)) != SUCCESS) { + cout << "SetVideoEncoder failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetVideoSize(sourceId, width, height)) != SUCCESS) { + cout << "SetVideoSize failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetVideoFrameRate(sourceId, frameRate)) != SUCCESS) { + cout << "SetVideoFrameRate failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetVideoEncodingBitRate(sourceId, rate)) != SUCCESS) { + cout << "SetVideoEncodingBitRate failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetCaptureRate(sourceId, frameRate)) != SUCCESS) { + cout << "SetCaptureRate failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetAudioSource(inputSource, audioSourceId)) != SUCCESS) { + cout << "SetAudioSource failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetAudioEncoder(audioSourceId, audioFormat)) != SUCCESS) { + cout << "SetAudioEncoder failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetAudioSampleRate(audioSourceId, sampleRate)) != SUCCESS) { + cout << "SetAudioSampleRate failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetAudioChannels(audioSourceId, channelCount)) != SUCCESS) { + cout << "SetAudioChannels failed." << ret << endl; + delete recorder; + return nullptr; + } + if ((ret = recorder->SetAudioEncodingBitRate(audioSourceId, audioEncodingBitRate)) != SUCCESS) { + cout << "SetAudioEncodingBitRate failed." << ret << endl; + delete recorder; + return nullptr; + } + return recorder; +} + +class SampleFrameStateCallback : public FrameStateCallback { + void OnFrameFinished(Camera &camera, FrameConfig &fc, FrameResult &result) override + { + cout << "Receive frame complete inform." << endl; + if (fc.GetFrameConfigType() == FRAME_CONFIG_CAPTURE) { + cout << "Capture frame received." << endl; + list surfaceList = fc.GetSurfaces(); + for (Surface *surface : surfaceList) { + SurfaceBuffer *buffer = surface->AcquireBuffer(); + if (buffer != nullptr) { + char *virtAddr = static_cast(buffer->GetVirAddr()); + if (virtAddr != nullptr) { + SampleSaveCapture(virtAddr, buffer->GetSize()); + } + surface->ReleaseBuffer(buffer); + } + delete surface; + } + delete &fc; + } + } +}; + +class SampleCameraStateMng : public CameraStateCallback { +public: + SampleCameraStateMng() = delete; + SampleCameraStateMng(EventHandler &eventHdlr) : eventHdlr_(eventHdlr) {} + ~SampleCameraStateMng() + { + if (recorder_ != nullptr) { + recorder_->Release(); + delete recorder_; + } + } + void OnCreated(Camera &c) override + { + cout << "Sample recv OnCreate camera." << endl; + auto config = CameraConfig::CreateCameraConfig(); + config->SetFrameStateCallback(&fsCb_, &eventHdlr_); + c.Configure(*config); + cam_ = &c; + } + void OnCreateFailed(const std::string cameraId, int32_t errorCode) override {} + void OnReleased(Camera &c) override {} + + void StartRecord() + { + int ret; + if (isRecording_) { + cout << "Camera is already recording." << endl; + return; + } + if (recorder_ == nullptr) { + recorder_ = SampleCreateRecorder(); + } + if (recorder_ == nullptr) { + cout << "Recorder not available" << endl; + return; + } + string path = "/sdcard"; + ret = recorder_->SetOutputPath(path); + if (ret != SUCCESS) { + cout << "SetOutputPath fialed :" << ret << std::endl; + return; + } + ret = recorder_->Prepare(); + if (ret != SUCCESS) { + cout << "Prepare failed.=" << ret << endl; + return; + } + Surface *surface = (recorder_->GetSurface(0)).get(); + surface->SetWidthAndHeight(1920, 1080); + surface->SetQueueSize(3); + surface->SetSize(1024 * 1024); + FrameConfig *fc = new FrameConfig(FRAME_CONFIG_RECORD); + fc->AddSurface(*surface); + ret = recorder_->Start(); + if (ret != SUCCESS) { + delete fc; + cout << "recorder start failed. ret=" << ret << endl; + return; + } + ret = cam_->TriggerLoopingCapture(*fc); + if (ret != 0) { + delete fc; + cout << "camera start recording failed. ret=" << ret << endl; + return; + } + isRecording_ = true; + cout << "camera start recording succeed." << endl; + } + void StartPreview() + { + if (isPreviewing_) { + cout << "Camera is already previewing." << endl; + return; + } + FrameConfig *fc = new FrameConfig(FRAME_CONFIG_PREVIEW); + Surface *surface = Surface::CreateSurface(); + if (surface == nullptr) { + delete fc; + cout << "CreateSurface failed" << endl; + return; + } + surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */ + surface->SetUserData("region_position_x", "0"); + surface->SetUserData("region_position_y", "0"); + surface->SetUserData("region_width", "480"); + surface->SetUserData("region_height", "480"); + fc->AddSurface(*surface); + int32_t ret = cam_->TriggerLoopingCapture(*fc); + if (ret != 0) { + delete fc; + cout << "camera start preview failed. ret=" << ret << endl; + return; + } + delete surface; + isPreviewing_ = true; + cout << "camera start preview succeed." << endl; + } + void Capture() + { + if (cam_ == nullptr) { + cout << "Camera is not ready." << endl; + return; + } + FrameConfig *fc = new FrameConfig(FRAME_CONFIG_CAPTURE); + Surface *surface = Surface::CreateSurface(); + if (surface == nullptr) { + delete fc; + cout << "CreateSurface failed" << endl; + return; + } + surface->SetWidthAndHeight(1920, 1080); /* 1920:width,1080:height */ + fc->AddSurface(*surface); + cam_->TriggerSingleCapture(*fc); + } + void Stop() + { + if (cam_ == nullptr) { + cout << "Camera is not ready." << endl; + return; + } + if (recorder_ != nullptr) { + recorder_->Stop(false); + } + cam_->StopLoopingCapture(); + isPreviewing_ = false; + isRecording_ = false; + } + +private: + bool isPreviewing_ = false; + bool isRecording_ = false; + EventHandler &eventHdlr_; + Camera *cam_ = nullptr; + Recorder *recorder_ = nullptr; + SampleFrameStateCallback fsCb_; +}; + +class SampleCameraDeviceCallback : public CameraDeviceCallback {}; + +void SampleHelp() +{ + cout << "*******************************************" << endl; + cout << "Select the behavior of avrecorder." << endl; + cout << "1: Capture" << endl; + cout << "2: Record(Press s or S to stop)" << endl; + cout << "3: Preview(Press s or S to stop)" << endl; + cout << "q: quit the sample." << endl; + cout << "*******************************************" << endl; +} + +int main() +{ + cout << "Camera sample begin." << endl; + SampleHelp(); + CameraKit *camKit = CameraKit::GetInstance(); + if (camKit == nullptr) { + cout << "Can not get CameraKit instance" << endl; + return 0; + } + list camList = camKit->GetCameraIds(); + string camId; + for (auto &cam : camList) { + cout << "camera name:" << cam << endl; + const CameraAbility *ability = camKit->GetCameraAbility(cam); + /* Find the camera that fits your ability. */ + list sizeList = ability->GetSupportedSizes(0); + if (find(sizeList.begin(), sizeList.end(), CAM_PIC_1080P) != sizeList.end()) { + camId = cam; + break; + } + } + + if (camId.empty()) { + cout << "No available camera.(1080p wanted)" << endl; + return 0; + } + + EventHandler eventHdlr; // Create a thread to handle callback events + SampleCameraStateMng CamStateMng(eventHdlr); + + camKit->CreateCamera(camId, CamStateMng, eventHdlr); + + char input; + while (cin >> input) { + switch (input) { + case '1': + CamStateMng.Capture(); + break; + case '2': + CamStateMng.StartRecord(); + break; + case '3': + CamStateMng.StartPreview(); + break; + case 's': + CamStateMng.Stop(); + break; + case 'q': + CamStateMng.Stop(); + goto EXIT; + default: + SampleHelp(); + break; + } + } +EXIT: + cout << "Camera sample end." << endl; + return 0; +} +``` + +## Repositories Involved + +multimedia\_frameworks\_camera\_lite + +multimedia\_frameworks\_audio\_lite + +multimedia\_frameworks\_player\_lite + +multimedia\_frameworks\_recorder\_lite + +multimedia\_hals\_camera\_lite + +multimedia\_interfaces\_kits\_recorder\_lite + +multimedia\_interfaces\_kits\_audio\_lite + +multimedia\_interfaces\_kits\_camera\_lite + +multimedia\_interfaces\_kits\_player\_lite + +multimedia\_services\_media\_lite + +multimedia\_utils\_lite + diff --git a/docs-en/readme/overview.md b/docs-en/readme/overview.md new file mode 100755 index 0000000000000000000000000000000000000000..d0029cf1cee1b4caad845dd38a9ab3ad5c3f5d1f --- /dev/null +++ b/docs-en/readme/overview.md @@ -0,0 +1,18 @@ +# Overview + +## Globalization Subsystem + +Users can set the locale regarding about 68 languages and regions on OpenHarmony devices. As the locale settings are synchronized from one OpenHarmony device to another during interconnection, multi-language resource backtracking and multi-language preference support should be taken into account. + +The global resource manager mainly provides the following capabilities: + +- Multi-language resource backtracking: Users in different regions have their own cultural background and use their respective native languages. During resource loading, it is critical to support multi-language locale settings, specifically, to use as few languages as possible to match users' particular cultural background. + +- Multi-language preference support: One of users' multiple preferred languages is selected and displayed for users \(for example, the Swiss\) who have multiple native languages. + +## Repositories Involved + +global\_frameworks\_resmgr\_lite + +global\_interfaces\_innerkits\_resmgr\_lite + diff --git a/docs-en/readme/public_sys-resources/icon-caution.gif b/docs-en/readme/public_sys-resources/icon-caution.gif new file mode 100755 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/docs-en/readme/public_sys-resources/icon-caution.gif differ diff --git a/docs-en/readme/public_sys-resources/icon-danger.gif b/docs-en/readme/public_sys-resources/icon-danger.gif new file mode 100755 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/docs-en/readme/public_sys-resources/icon-danger.gif differ diff --git a/docs-en/readme/public_sys-resources/icon-note.gif b/docs-en/readme/public_sys-resources/icon-note.gif new file mode 100755 index 0000000000000000000000000000000000000000..6314297e45c1de184204098efd4814d6dc8b1cda Binary files /dev/null and b/docs-en/readme/public_sys-resources/icon-note.gif differ diff --git a/docs-en/readme/public_sys-resources/icon-notice.gif b/docs-en/readme/public_sys-resources/icon-notice.gif new file mode 100755 index 0000000000000000000000000000000000000000..86024f61b691400bea99e5b1f506d9d9aef36e27 Binary files /dev/null and b/docs-en/readme/public_sys-resources/icon-notice.gif differ diff --git a/docs-en/readme/public_sys-resources/icon-tip.gif b/docs-en/readme/public_sys-resources/icon-tip.gif new file mode 100755 index 0000000000000000000000000000000000000000..93aa72053b510e456b149f36a0972703ea9999b7 Binary files /dev/null and b/docs-en/readme/public_sys-resources/icon-tip.gif differ diff --git a/docs-en/readme/public_sys-resources/icon-warning.gif b/docs-en/readme/public_sys-resources/icon-warning.gif new file mode 100755 index 0000000000000000000000000000000000000000..6e90d7cfc2193e39e10bb58c38d01a23f045d571 Binary files /dev/null and b/docs-en/readme/public_sys-resources/icon-warning.gif differ diff --git a/docs-en/readme/security-subsystem.md b/docs-en/readme/security-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..a0908cdfd7f270bb108d7a4302c36bc065c68a3b --- /dev/null +++ b/docs-en/readme/security-subsystem.md @@ -0,0 +1,279 @@ +# Security Subsystem + +## Overview + +This section provides samples about how to use existing security mechanisms to improve system security features, including secure boot, application permission management, inter-process communication \(IPC\) authentication, Huawei Universal Keystore Service \(HUKS\), HiChain, and application signature verification. + +## Directory Structure + +**Directory 1** + +``` +security +├── framework +│ ├── appverify Application signature verification +│ ├── crypto_lite Encryption and decryption +│ ├── hichainsdk_lite Device authentication +│ ├── huks_lite Key and certificate management +│ ├── secure_os Secure OS +├── interface Interface directory +│ ├── innerkits Internal kit directory +│ │ ├── appverify Application signature verification +│ │ ├── crypto_lite Encryption and decryption +│ │ ├── hichainsdk_lite Device authentication +│ │ ├── huks_lite Key and certificate management +│ │ ├── iam_lite Application permission management +│ │ ├── secure_os Secure OS +│ ├── kits External kit directory +│ │ ├── iam_lite Application permission management +├── services Implementation +│ ├── iam_lite Application permission management +│ ├── secure_os Secure OS +``` + +**Directory 2** + +``` +kernel/liteos-a/security/ +├── cap Capability mechanism +│ ├── BUILD.gn +│ ├── capability_api.h +│ ├── capability.c +│ ├── capability_type.h +│ └── Makefile +``` + +## Constraints + +C programming language is used. The preceding security features are mainly used on Cortex-A or devices with equivalent processing capabilities. On Cortex-M or devices with equivalent processing capabilities, only HUKS and HiChain are available. + +## Secure Boot + +To generate a x509 image package, perform compilation to generate the required binary images, including kernel images **kernel.bin** \(liteos/OHOS\_Image\) and **rootfs.img**. If the Hi3516DV300 chip is used, the generated images are stored in the **out\\ipcamera\_hi3516dv300\_liteos\_a** directory. Copy the binary images and the secure uboot private keys \(in the **vendor\\hisi\\hi35xx\\hi3516dv300\\uboot\\secureboot\_release** directory\) to the **secureboot\_ohos** directory \(in the **vendor\\hisi\\hi35xx\\hi3516dv300\\uboot** directory\). Go to the **x509\_creater** directory, run the **./creater.sh** command, and generate the x509 certificate as prompted. Return to the **secureboot\_ohos** directory and run **./sec\_os.sh** to generate the x509 image package. + +## Application Permission Management + +Application permissions are used to control access to system resources and features. These include personal privacy-related features or data in some scenarios, for example, hardware features of personal devices such as cameras and microphones, and personal data such as contacts and calendar data. OpenHarmony protects such data and features through application permission management. + +To declare the permissions required by an application, edit **req-permissions** in the **HarmonyProfile.json** file in the installation bundle. The following figure shows an example. + +**Figure 1** Declaring permissions +![](figures/declaring-permissions.png "declaring-permissions") + +Field descriptions + + + + + + + + + + + + + + + + + + + + +

Field

+

Value

+

Description

+

name

+

String

+

Permission name

+

reason

+

Multi-language string ID

+

Purpose of requesting the permission.

+

The purposes include reviewing requests for publishing applications, pop-up authorization, and permission management by users.

+

used-scene{

+

ability,

+

when

+

}

+

ability: string of the component class name

+

when: inuse and always

+

Scene where the APIs controlled by this permission are called.

+

This field declares the components that call the APIs controlled by this permission and whether the APIs are called from the foreground or from both the foreground and background.

+
+ +## IPC Authentication + +- If system services registered with Samgr provide APIs for other processes to access the services through IPC, access control policies must be configured; otherwise, access to the system services will be denied. +- You can configure access control policies in **base/security/services/iam\_lite/include/policy\_preset.h**. You need to configure the policy for each feature and then add the policies of features to the global policy. + +For example, to configure an access policy for the BMS service, whose service registered with Samgr is **bundlems** and whose registered feature is **BmsFeature**, perform the following operations: + +1. Define the feature policy. You can configure multiple features and configure multiple access policies for each feature. + +**Figure 2** Example feature policy +![](figures/example-feature-policy.png "example-feature-policy") + +There are three types of access policies: + +**Figure 3** Access policy structure +![](figures/access-policy-structure.png "access-policy-structure") + +- **RANGE**: Processes with a UID within a specified range are allowed to access **BmsFeature**. **uidMin** and **uidMax** need to be specified. +- **FIXED**: Processes with specified UIDs are allowed to access **BmsFeature**. **fixedUid** needs to be specified. A maximum number of eight UIDs can be configured. +- **BUNDLENAME**: Only a specified application is allowed to access **BmsFeature**. **bundleName** needs to be specified. + +2. Add the defined feature policy to the global policy. You need to configure the number of features. + +**Figure 4** Registering a feature policy +![](figures/registering-a-feature-policy.png "registering-a-feature-policy") + +UID allocation rules: + +Init/foundation process: 0 + +appspawn process: 1 + +Shell process: 2 + +kitfw process: 3 + +Other built-in services: 4–99 + +System applications \(such as settings\): 100–999 + +Preset applications \(such as Wallet and Taobao\): 1000–9999 + +Common third-party applications: 10000 to **INT\_MAX** + +## HUKS + +In distributed scenarios, trust relationships need to be established between devices with varied hardware capabilities and system environments. A typical application is HiChain for trusted interconnection between devices. In this case, a unified key management service is required to ensure consistent APIs and key data formats, and provide industry-standard encryption/decryption algorithms. HUKS is such a service that provides unified key management and encryption/decryption. + +HUKS consists of native APIs, the hardware abstraction layer \(HAL\), and Core Module. + +1. Native APIs are implemented using the C language to ensure consistency among all devices, and include the APIs for key generation, encryption, and decryption. +2. Core Module depends on the HAL and provides core functions such as encryption and decryption, signature verification, and key storage. +3. HAL shields differences between hardware and OSs and defines the unified APIs for HUKS. It contains platform algoIOrithm libraries, file systems, and logs. + +## HiChain + +**Device Interconnection Security** + +To transmit user data securely between devices, ensure that the devices are trusted by each other. A trust relationship and a secure data transmission channel must be established between the devices. This section describes how an IoT controller and IoT device establish a trust relationship. + +![](figures/en-us_image_0000001052584330.png) + +- **IoT device interconnection security** + + +A trust relationship can be established between an IoT device that runs OpenHarmony \(such as the AI speaker, smart home device, and wearable device\) and an IoT controller \(such as the smartphone and tablet\). Encrypted user data can be transmitted between the IoT device and IoT controller through a secure connection. + +- **IoT service identifier of the IoT controller** + + +An IoT controller generates different identifiers for different IoT device management services to isolate these services. The identifier can be used for authentication and communication between an IoT controller and an IoT device. It is an Ed25519 public/private key pair generated using the elliptic curve cryptography. + +- **IoT device identifier** + + +An IoT device can generate its own device identifier for communicating with the IoT controller. It is also an Ed25519 public/private key pair generated using elliptic curve cryptography, with the private key stored on the IoT device. Each time the device is restored to factory settings, the public/private key pair will be reset. + +The identifier can be used for secure communication between the IoT controller and IoT device. After the devices exchange the service identifier or device identifier, they can negotiate the key and establish a secure communication channel. + +- **P2P trusted binding between devices** + + +When an IoT controller and an IOT device establish a trust relationship, they exchange identifiers. + +During this process, the user needs to enter or scan the PIN provided by the IoT device on the IoT controller. PIN is either dynamically generated if the IoT device has a screen, or preset by the manufacturer if it does not have a screen. A PIN can be a number or a QR code. Then the IoT controller and IoT device perform authentication and session key exchange based on password authenticated key exchange \(PAKE\), and use the session key to encrypt the channel for exchanging identity public keys. + +**Secure communication between the IoT controller and IoT device** + +When an IoT controller and an IoT device communicate with each other after establishing a trust relationship, they authenticate each other by using the locally stored identity public key of the peer. Bidirectional identity authentication and session key exchange are performed using the Station-to-Station \(STS\) protocol during each communication. The session key is used to encrypt the data transmission channel between the devices. + +## Application Signature Verification + +To ensure the integrity of application content, HarmonyOS uses application signatures and profiles to manage application sources. Only pre-installed applications and applications from HUAWEI AppGallery can be installed on devices. + +**Basic Concepts** + +- **Developer certificate** + + +Identity digital certificate of a developer, which is used to sign local debugging software + +- **Application debugging profile** + + +Application debugging authorization file that allows you to install and debug an application on a specified device + +- **Application publishing certificate** + + +Identity digital certificate of an application publisher, which is used to sign an application to be published or preset + +- **Application publishing profile** + + +Description file of an application, which is used for reviewing an application to be published or preset + +- **APPID** + + +Unique identifier of an application, which consists of the application bundle name and the public key of the application publishing certificate + +**How Application Signature Verification Works** + +1. Apply for becoming an authorized application developer on HUAWEI AppGallery. +2. Install and debug an application on a specified device. +3. Publish the application. + +## **Signature of an Application Published on HUAWEI AppGallery** + +- **Application debugging scenario** + +To develop and debug applications for HarmonyOS devices, you need to apply for becoming an authorized application developer on HUAWEI AppGallery. You need to generate a public/private key pair and upload the public key to HUAWEI AppGallery. HUAWEI AppGallery creates a developer certificate based on your identity information and the uploaded public key, and issues the certificate through the developer certificate CA. You also need to upload the application information and debugging device ID for creating an application debugging profile, which contains the HUAWEI AppGallery signature and cannot be tampered with. Upon obtaining the developer certificate and application debugging profile, you can install and debug applications signed with the private key on a specified HarmonyOS device. + +The application installation service of HarmonyOS verifies the application signature to ensure application integrity. In addition, the service verifies the developer certificate, application debugging profile, and the mapping between them to ensure the validity of your identity and the application. + +![](figures/en-us_image_0000001051282241.png) + +- **Application publishing** + + To publish applications in HUAWEI AppGallery, you need to use the application publishing certificate and profile issued by HUAWEI AppGallery to sign the applications. As shown in the following figure, the procedure of applying for the application publishing certificate and profile is similar to that of applying for the developer certificate and application debugging profile \(you can use the same public/private key pair\). Applications signed by the application publishing certificate cannot be directly installed on devices. Instead, the applications must be published in HUAWEI AppGallery for review. After the applications are reviewed and approved, HUAWEI AppGallery uses the publishing certificate to re-sign the applications. The re-signed applications can be downloaded and installed by users. + + The application installation service of HarmonyOS verifies the application signature to ensure application integrity. In addition, the service checks whether the signature certificate is from HUAWEI AppGallery to ensure that the application is trusted. + + ![](figures/en-us_image_0000001051562162.png) + + +## Repositories Involved + +security\_services\_app\_verify + +security\_frameworks\_crypto\_lite + +security\_services\_hichainsdk\_lite + +security\_services\_huks\_lite + +security\_frameworks\_secure\_os + +security\_interfaces\_innerkits\_hichainsdk\_lite + +security\_interfaces\_innerkits\_iam\_lite + +security\_interfaces\_innerkits\_huks\_lite + +security\_interfaces\_innerkits\_app\_verify + +security\_interfaces\_innerkits\_crypto\_lite + +security\_interfaces\_innerkits\_secure\_os + +security\_interfaces\_kits\_iam\_lite + +security\_services\_iam\_lite + +security\_services\_secure\_os + diff --git a/docs-en/readme/service-framework-subsystem.md b/docs-en/readme/service-framework-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..6bd50c3a76cebfab33b6d72cf1fee8324c8b1755 --- /dev/null +++ b/docs-en/readme/service-framework-subsystem.md @@ -0,0 +1,622 @@ +# Service Framework Subsystem + +## Introduction + +Due to limited platform resources, a unified service framework is provided to harmonize differences of hardware architectures \(for example, RISC-V, Cortex-M, and Cortex-A\), resources, and running modes. Two types of hardware platforms \(M- and A-core\) are defined. + +M-core: Hardware platforms with Cortex-M or equivalent processing capabilities. The system memory is generally less than 512 KB. There is only a lightweight file system that can be used in limited scenarios, or no file system at all. M-core platforms comply with the Cortex Microcontroller Software Interface Standard \(CMSIS\). + +A-core: Hardware platforms with Cortex-A or equivalent processing capabilities. The system memory is greater than 512 KB. There is a comprehensive file system for storing a large amount of data. A-core platforms comply with the Portable Operating System Interface \(POSIX\) specifications. + +This service-oriented service framework enables you to develop services, features, and external APIs, and implement multi-service process sharing and service invoking for inter-process communication \(IPC\). + +- M core provides services, features, external APIs, and multi-service process sharing development. +- In addition to the capabilities provided by M-core, A-core provides capabilities such as IPC service invoking, permission control for IPC service invoking, and IPC service API development. + +Service-oriented architecture + +![](figures/en-us_image_0000001051351505.png) + +Provider: a service provider that provides capabilities \(external APIs\) for the system + +Consumer: a service consumer that invokes the features \(external APIs\) provided by the service + +Samgr: an agency that manages capabilities provided by providers and helps consumers discover providers' capabilities + +Main objects of the service framework: + +![](figures/en-us_image_0000001051990283.png) + +- SamgrLite: provides service registration and discovery. +- Service: implements lifecycle APIs of the service during service development. +- Feature: implements lifecycle APIs of the feature during feature development. +- IUnknown: implements external APIs for services or features based on **IUnknown**. +- IClientProxy: implements the consumer's proxy to send messages during IPC invoking. +- IServerProxy: implements the provider's proxy during IPC invoking, which needs to be implemented by developers. + +## Directory + +**Table 1** Structure of the source code directory of the service framework subsystem + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

interfaces/kits/samgr_lite/samgr

+

External APIs of the M- and A-core service frameworks

+

interfaces/kits/samgr_lite/registry

+

External APIs for service invocation between A-core processes

+

interfaces/kits/samgr_lite/communication/broadcast

+

External APIs of the event broadcast service within M- and A-core processes

+

services/samgr_lite/samgr/adapter

+

POSIX and CMSIS interface adaptation layer, which is used to harmonize the differences between the APIs of M- and A-core

+

services/samgr_lite/samgr/registry

+

Stub functions for M-core service registration and discovery

+

services/samgr_lite/samgr/source

+

Basic code for the M- and A-core service frameworks

+

services/samgr_lite/samgr_client

+

Registration and discovery for service invocation between A-core processes

+

services/samgr_lite/samgr_server

+

IPC address management and access control for service invocation between A-core processes

+

services/samgr_lite/samgr_endpoint

+

Packet RX/TX management for A-core IPC

+

services/samgr_lite/communication/broadcast

+

Event broadcast service for M- and A-core processes

+
+ +## Restrictions + +The service framework is developed using the C programming language. + +Services in the same process use **IUnknown** for invoking. Messages are passed to the service through **IUnknown**. + +The service name and feature name must be constant character strings and the length must be less than 16 bytes. + +More-core depends on the Bootstrap service and calls the **OHOS\_SystemInit\(\)** function in the system startup function. + +A-core depends on the Samgr library and calls the **SAMGR\_Bootstrap\(\)** function in the **main** function. + +## Developing a Service + +- Inherit and redefine a service. + + ``` + typedef struct ExampleService { + INHERIT_SERVICE; + INHERIT_IUNKNOWNENTRY(DefaultFeatureApi); + Identity identity; + } ExampleService; + ``` + +- Implement the lifecycle function of the service. + + ``` + static const char *GetName(Service *service) + { + return EXAMPLE_SERVICE; + } + + static BOOL Initialize(Service *service, Identity identity) + { + ExampleService *example = (ExampleService *)service; + // Save the unique ID of the service, which is used when IUnknown is used to send messages to the service. + example->identity = identity; + return TRUE; + } + static BOOL MessageHandle(Service *service, Request *msg) + { + ExampleService *example = (ExampleService *)service; + switch (msg->msgId) { + case MSG_SYNC: + // Process the service. + break; + default:break; + } + return FALSE; + } + static TaskConfig GetTaskConfig(Service *service) + { + TaskConfig config = {LEVEL_HIGH, PRI_BELOW_NORMAL, + 0x800, 20, SHARED_TASK}; + return config; + } + ``` + +- Create a service object. + + ``` + static ExampleService g_example = { + .GetName = GetName, + .Initialize = Initialize, + .MessageHandle = MessageHandle, + .GetTaskConfig = GetTaskConfig, + SERVER_IPROXY_IMPL_BEGIN, + .Invoke = NULL, + .SyncCall = SyncCall, + IPROXY_END, + }; + ``` + +- Register the service and API with Samgr. + + ``` + static void Init(void) + { + SAMGR_GetInstance()->RegisterService((Service *)&g_example); + SAMGR_GetInstance()->RegisterDefaultFeatureApi(EXAMPLE_SERVICE, GET_IUNKNOWN(g_example)); + } + ``` + +- Define the initializer of the service. + + ``` + SYSEX_SERVICE_INIT(Init); + ``` + + +## Developing a Feature of a Service + +- Inherit and redefine a feature. + + ``` + typedef struct DemoFeature { + INHERIT_FEATURE; + INHERIT_IUNKNOWNENTRY(DemoApi); + Identity identity; + Service *parent; + } DemoFeature; + ``` + +- Implement the lifecycle function of the feature. + + ``` + static const char *FEATURE_GetName(Feature *feature) + { + return EXAMPLE_FEATURE; + } + + static void FEATURE_OnInitialize(Feature *feature, Service *parent, Identity identity) + { + DemoFeature *demoFeature = (DemoFeature *)feature; + demoFeature->identity = identity; + demoFeature->parent = parent; + } + + static void FEATURE_OnStop(Feature *feature, Identity identity) + { + g_example.identity.queueId = NULL; + g_example.identity.featureId = -1; + g_example.identity.serviceId = -1; + } + + static BOOL FEATURE_OnMessage(Feature *feature, Request *request) + { + if (request->msgId == MSG_PROC) { + Response response = {.data = "Yes, you did!", .len = 0}; + SAMGR_SendResponse(request, &response); + return TRUE; + } else { + if (request->msgId == MSG_TIME_PROC) { + LOS_Msleep(WAIT_FEATURE_PROC * 10); + if (request->msgValue) { + SAMGR_PrintServices(); + } else { + SAMGR_PrintOperations(); + } + AsyncTimeCall(GET_IUNKNOWN(g_example)); + return FALSE; + } + } + return FALSE; + } + ``` + +- Create a feature object. + + ``` + static DemoFeature g_example = { + .GetName = FEATURE_GetName, + .OnInitialize = FEATURE_OnInitialize, + .OnStop = FEATURE_OnStop, + .OnMessage = FEATURE_OnMessage, + DEFAULT_IUNKNOWN_ENTRY_BEGIN, + .AsyncCall = AsyncCall, + .AsyncTimeCall = AsyncTimeCall, + .SyncCall = SyncCall, + .AsyncCallBack = AsyncCallBack, + DEFAULT_IUNKNOWN_ENTRY_END, + .identity = {-1, -1, NULL}, + }; + ``` + +- Register the feature and API with Samgr. + + ``` + static void Init(void){ + SAMGR_GetInstance()->RegisterFeature(EXAMPLE_SERVICE, (Feature *)&g_example); + SAMGR_GetInstance()->RegisterFeatureApi(EXAMPLE_SERVICE, EXAMPLE_FEATURE, GET_IUNKNOWN(g_example)); + } + ``` + +- Define the initializer of the feature. + + ``` + SYSEX_FEATURE_INIT(Init); + ``` + + +## Developing an External API for Intra-process Communication + +- Define the **IUnknown** API. + + ``` + typedef struct DemoApi { + INHERIT_IUNKNOWN; + BOOL (*AsyncCall)(IUnknown *iUnknown, const char *buff); + BOOL (*AsyncTimeCall)(IUnknown *iUnknown); + BOOL (*SyncCall)(IUnknown *iUnknown, struct Payload *payload); + BOOL (*AsyncCallBack)(IUnknown *iUnknown, const char *buff, Handler handler); + } DemoApi; + ``` + +- Define the reference object of **IUnknown**. + + ``` + typedef struct DemoRefApi { + INHERIT_IUNKNOWNENTRY(DemoApi); + } DemoRefApi; + ``` + +- Initialize the object of **IUnknown**. + + ``` + static DemoRefApi api = { + DEFAULT_IUNKNOWN_ENTRY_BEGIN, + .AsyncCall = AsyncCall, + .AsyncTimeCall = AsyncTimeCall, + .SyncCall = SyncCall, + .AsyncCallBack = AsyncCallBack, + DEFAULT_IUNKNOWN_ENTRY_END, + }; + ``` + +- Register the feature API. + + ``` + SAMGR_GetInstance()->RegisterFeatureApi(EXAMPLE_SERVICE, EXAMPLE_FEATURE, GET_IUNKNOWN(api)); + ``` + + +## Invoking a Service in the Same Process + +- Obtain the external API of the service. + + ``` + DemoApi *demoApi = NULL; + IUnknown *iUnknown = SAMGR_GetInstance()->GetFeatureApi(EXAMPLE_SERVICE, EXAMPLE_FEATURE); + if (iUnknown == NULL) { + return NULL; + } + int result = iUnknown->QueryInterface(iUnknown, DEFAULT_VERSION, (void **)&demoApi); + if (result != 0 || demoApi == NULL) { + return NULL; + } + ``` + +- Call the API. + + ``` + if (demoApi->AsyncCallBack == NULL) { + return NULL; + } + demoApi->AsyncCallBack((IUnknown *)demoApi, "I wanna async call callback good result!", AsyncHandler); + ``` + +- Release the API. + + ``` + int32 ref = demoApi->Release((IUnknown *)demoApi); + ``` + + +## Developing an External API for IPC + +- Inherit **IServerProxy** to replace **IUnknown**: INHERIT\_SERVER\_IPROXY + + ``` + typedef struct DemoFeatureApi { + INHERIT_SERVER_IPROXY; + BOOL (*AsyncCall)(IUnknown *iUnknown, const char *buff); + BOOL (*AsyncTimeCall)(IUnknown *iUnknown); + BOOL (*SyncCall)(IUnknown *iUnknown, struct Payload *payload); + BOOL (*AsyncCallBack)(IUnknown *iUnknown, const char *buff, IOwner notify, INotifyFunc handler); + } DemoFeatureApi; + ``` + +- Initialize the **IServerProxy** object. + + ``` + static DemoFeature g_example = { + SERVER_IPROXY_IMPL_BEGIN, + .Invoke = Invoke, + .AsyncCall = AsyncCall, + .AsyncTimeCall = AsyncTimeCall, + .SyncCall = SyncCall, + .AsyncCallBack = AsyncCallBack, + IPROXY_END, + }; + ``` + +- Implement the **Invoke** function to process IPC messages. + + ``` + static int32 Invoke(IServerProxy *iProxy, int funcId, void *origin, IpcIo *req, IpcIo *reply) + { + DemoFeatureApi *api = (DemoFeatureApi *)iProxy; + BOOL ret; + size_t len = 0; + switch (funcId) { + case ID_ASYNCALL: + ret = api->AsyncCall((IUnknown *)iProxy, (char *)IpcIoPopString(req, &len)); + IpcIoPushBool(reply, ret); + break; + case ID_ASYNTIMECALL: + ret = api->AsyncTimeCall((IUnknown *)iProxy); + IpcIoPushBool(reply, ret); + break; + case ID_SYNCCALL: { + struct Payload payload; + payload.id = IpcIoPopInt32(req); + payload.value = IpcIoPopInt32(req); + payload.name = (char *)IpcIoPopString(req, &len); + ret = api->SyncCall((IUnknown *)iProxy, &payload); + IpcIoPushString(reply, ret ? "TRUE" : "FALSE"); + } + break; + case ID_ASYNCCALLBACK: { // convert to sync proxy + IpcIoPushString(reply, "Yes, you did!"); + IpcIoPushBool(reply, TRUE); + } + break; + default: + IpcIoPushBool(reply, FALSE); + break; + } + return EC_SUCCESS; + } + ``` + +- Register the API. This step is same as the API registration for intra-process communication. + + ``` + SAMGR_GetInstance()->RegisterFeatureApi(EXAMPLE_SERVICE, EXAMPLE_FEATURE, GET_IUNKNOWN(g_example)); + ``` + + +## Invoking a Service in Another Process + +- Obtain the external API of the service in another process. + + ``` + IClientProxy *demoApi = NULL; + IUnknown *iUnknown = SAMGR_GetInstance()->GetFeatureApi(EXAMPLE_SERVICE, EXAMPLE_FEATURE); + if (iUnknown == NULL) { + return NULL; + } + int result = iUnknown->QueryInterface(iUnknown, CLIENT_PROXY_VER, (void **)&demoApi); + if (result != 0 || demoApi == NULL) { + return NULL; + } + ``` + +- Invoke the API for sending IPC messages. + + ``` + IpcIo request;char data[250]; + IpcIoInit(&request, data, sizeof(data), 0); + demoApi->Invoke(demoApi, 0, &request, NULL, NULL); + ``` + +- Release the API. + + ``` + int32 ref = demoApi->Release((IUnknown *)demoApi); + ``` + + +## Developing a Client Proxy for Inter-Process Service Invocation + +- Define a client proxy for the IPC API. + + ``` + typedef struct DemoClientProxy { + INHERIT_CLIENT_IPROXY; + BOOL (*AsyncCall)(IUnknown *iUnknown, const char *buff); + BOOL (*AsyncTimeCall)(IUnknown *iUnknown); + BOOL (*SyncCall)(IUnknown *iUnknown, struct Payload *payload); + BOOL (*AsyncCallBack)(IUnknown *iUnknown, const char *buff, IOwner notify, INotifyFunc handler); + } DemoClientProxy; + typedef struct DemoClientEntry { + INHERIT_IUNKNOWNENTRY(DemoClientProxy); + } DemoClientEntry; + ``` + +- Enable the client proxy to encapsulate the IPC message API. + + ``` + static BOOL AsyncCall(IUnknown *iUnknown, const char *buff) + { + DemoClientProxy *proxy = (DemoClientProxy *)iUnknown; + IpcIo request; + char data[MAX_DATA_LEN]; + IpcIoInit(&request, data, MAX_DATA_LEN, 0); + IpcIoPushString(&request, buff); + int ret = proxy->Invoke((IClientProxy *)proxy, ID_ASYNCALL, &request, NULL, NULL); + return ret == EC_SUCCESS; + } + + static BOOL AsyncTimeCall(IUnknown *iUnknown) + { + DemoClientProxy *proxy = (DemoClientProxy *)iUnknown; + IpcIo request; + char data[MAX_DATA_LEN]; + IpcIoInit(&request, data, MAX_DATA_LEN, 0); + int ret = proxy->Invoke((IClientProxy *)proxy, ID_ASYNTIMECALL, &request, NULL, NULL); + return ret == EC_SUCCESS; + } + + static int Callback(IOwner owner, int code, IpcIo *reply) + { + size_t len = 0; + return strcpy_s(owner, MAX_DATA_LEN, (char *)IpcIoPopString(reply, &len)); + } + + static BOOL SyncCall(IUnknown *iUnknown, struct Payload *payload) + { + DemoClientProxy *proxy = (DemoClientProxy *)iUnknown; + IpcIo request; + char data[MAX_DATA_LEN]; + IpcIoInit(&request, data, MAX_DATA_LEN, 0); + IpcIoPushInt32(&request, payload->id); + IpcIoPushInt32(&request, payload->value); + IpcIoPushString(&request, payload->name); + int ret = proxy->Invoke((IClientProxy *)proxy, ID_SYNCCALL, &request, data, Callback); + data[MAX_DATA_LEN - 1] = 0; + HILOG_INFO(HILOG_MODULE_APP, "[TID:0x%lx]Remote response is %s!", pthread_self(), data); + return ret == EC_SUCCESS; + } + + struct CurrentNotify { + IOwner notify; + INotifyFunc handler; + }; + + static int CurrentCallback(IOwner owner, int code, IpcIo *reply) + { + struct CurrentNotify *notify = (struct CurrentNotify *)owner; + size_t len = 0; + char *response = (char *)IpcIoPopString(reply, &len); + HILOG_INFO(HILOG_MODULE_APP, "[TID:0x%lx]Notify Remote response is %s!", pthread_self(), response); + notify->handler(notify->notify, response); + return EC_SUCCESS; + } + + static BOOL AsyncCallBack(IUnknown *iUnknown, const char *buff, IOwner notify, INotifyFunc handler) + { + struct CurrentNotify owner = {notify, handler}; + DemoClientProxy *proxy = (DemoClientProxy *)iUnknown; + IpcIo request; + char data[MAX_DATA_LEN]; + IpcIoInit(&request, data, MAX_DATA_LEN, 0); + IpcIoPushString(&request, buff); + int ret = proxy->Invoke((IClientProxy *)proxy, ID_ASYNCCALLBACK, &request, &owner, CurrentCallback); + return ret == EC_SUCCESS; + } + ``` + +- Implement the factory method for creating the client proxy. + + ``` + void *DEMO_CreatClient(const char *service, const char *feature, uint32 size) + { + (void)service; + (void)feature; + uint32 len = size + sizeof(DemoClientEntry); + uint8 *client = malloc(len); + (void)memset_s(client, len, 0, len); + DemoClientEntry *entry = (DemoClientEntry *)&client[size]; + entry->ver = ((uint16)CLIENT_PROXY_VER | (uint16)DEFAULT_VERSION); + entry->ref = 1; + entry->iUnknown.QueryInterface = IUNKNOWN_QueryInterface; + entry->iUnknown.AddRef = IUNKNOWN_AddRef; + entry->iUnknown.Release = IUNKNOWN_Release; + entry->iUnknown.Invoke = NULL; + entry->iUnknown.AsyncCall = AsyncCall; + entry->iUnknown.AsyncTimeCall = AsyncTimeCall; + entry->iUnknown.SyncCall = SyncCall; + entry->iUnknown.AsyncCallBack = AsyncCallBack; + return client; + } + void DEMO_DestroyClient(const char *service, const char *feature, void *iproxy) + { + free(iproxy); + } + ``` + +- Register the factory method of the client proxy with Samgr. + + ``` + SAMGR_RegisterFactory(EXAMPLE_SERVICE, EXAMPLE_FEATURE, DEMO_CreatClient, DEMO_DestroyClient); + ``` + +- Obtain the external API of the service in another process. + + ``` + DemoClientProxy *demoApi = NULL; + IUnknown *iUnknown = SAMGR_GetInstance()->GetFeatureApi(EXAMPLE_SERVICE, EXAMPLE_FEATURE); + if (iUnknown == NULL) { + return NULL; + } + int result = iUnknown->QueryInterface(iUnknown, DEFAULT_VERSION, (void **)&demoApi); + if (result != 0 || demoApi == NULL) { + return NULL; + } + ``` + +- Invoke the client proxy API of the service in another process. + + ``` + if (demoApi->AsyncCallBack == NULL) { + return NULL; + } + demoApi->AsyncCallBack((IUnknown *)demoApi, + "I wanna async call callback good result!", NULL, AsyncHandler); + ``` + +- Release the API. + + ``` + int32 ref = demoApi->Release((IUnknown *)demoApi); + ``` + + +## Repositories Involved + +distributedschedule\_interfaces\_kits\_samgr\_lite + +distributedschedule\_services\_samgr\_lite + diff --git a/docs-en/readme/startup.md b/docs-en/readme/startup.md new file mode 100755 index 0000000000000000000000000000000000000000..0526c696429c6df06ace4fd8e22a979c7a3b7fea --- /dev/null +++ b/docs-en/readme/startup.md @@ -0,0 +1,327 @@ +# Startup + +## Introduction + +The startup subsystem is responsible for starting key system processes and services after the kernel is started and before applications are started. This subsystem has the following modules: + +- **init** for starting system service processes + +This module can be used on the Hi3516DV300 and Hi3518EV300 platforms powered by LiteOS Cortex-A. + +It starts system service processes from the time the kernel loads the first user-space process to the time the first application program is started. In addition to loading key system processes, the startup subsystem needs to configure required permissions during the startup, and keeps the specified process alive after sub-processes are started. If a process exits abnormally, the startup subsystem needs to restart it, and to perform system reset for a special process. + +- **appspawn** for spawning applications + + This module can be used on the Hi3516DV300 and Hi3518EV300 platforms powered by LiteOS Cortex-A. + + It spawns application processes upon receiving commands from the application framework, configures required permissions, and invokes the entry of the application framework. + +- **bootstrap** for starting service modules + + This module can be used on the Hi3861 platform powered by LiteOS Cortex-M. + + It provides identifiers for starting services and functions. When the SAMGR is started, the entry function identified by **boostrap** is invoked and system services are started. + +- **Syspara** + + This module can be used on the Hi3861, Hi3516DV300 and Hi3518EV300 platforms powered by LiteOS Cortex-M and LiteOS Cortex-A. + + It obtains and sets system attributes for the operating system. + + System attributes consist of default, OEM-specified, and custom system attributes. OEM-specified system attributes provide only default values. The specific values need to be adjusted as required. For details, see [Usage](#section674513182447). + + +## Directory Structure + +**Table 1** Directory structure of the source code for the Startup subsystem + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directory

+

Description

+

Applicable Platform

+

base/startup/services/appspawn_lite

+

appspawn module for spawning application processes. It receives AMS messages via lightweight IPC, parses the messages, starts application processes based on the parsing result, and grants permissions to them.

+

Hi3516DV300

+

Hi3518EV300

+

base/startup/services/bootstrap_lite

+

bootstrap module for starting all services except core system services.

+

Hi3861

+

base/startup/services/init_lite

+

init module for the init process, which is the first user-space process loaded after the kernel is initialized. After the startup, the configuration file in /etc/init.cfg is parsed. Based on the parsing result, other key system processes are started and granted required permissions.

+

Hi3516DV300

+

Hi3518EV300

+

base/startup/interfaces

+

Open APIs provided by the bootstrap module. The main function directs the calls to these APIs to start the service framework.

+

Hi3861

+

Hi3516DV300

+

Hi3518EV300

+

base/startup/frameworks/syspara_lite

+

syspara module. It provides APIs to obtain device information, including the product name, brand name, category name, and manufacturer name.

+
+ +``` +base +├──startup Root directory of the startup subsystem +├──── frameworks +│ └── syspara_lite +│ ├── LICENSE License file for open-source code +│ ├── parameter Source files for the syspara module +│ │ ├── BUILD.gn +│ │ └── src +│ │ ├── BUILD.gn +│ │ ├── param_impl_hal syspara module implemented based on LiteOS Cortex-M +│ │ └── param_impl_posix syspara module implemented based on LiteOS Cortex-A +│ └── token +│ ├── BUILD.gn +│ └── src +│ ├── token_impl_hal +│ └── token_impl_posix +├──── hals +│ └── syspara_lite Header files at the hardware abstraction layer of the syspara module +├──── interfaces +│ └── kits +│ └── syspara_lite Open APIs related to the syspara module +└──── services + ├── appspawn_lite appspawn module + │ ├── BUILD.gn Compilation and configuration of the appspawn module + │ ├── include Header files for the appspawn module + │ ├── LICENSE License file for open-source code + │ ├── moduletest Self-testing code for the appspawn module + │ └── src Source files for the appspawn module + ├── bootstrap_lite bootstrap module + │ ├── BUILD.gn Compilation and configuration of the bootstrap module + │ ├── LICENSE License file for open-source code + │ └── source Source files for the bootstrap module + └── init_lite init module + ├── BUILD.gn Compilation and configuration of the init module + ├── include Header files for the init module + ├── LICENSE License file for open-source code + ├── moduletest Self-testing code for the init module + └── src Sources for the init module +vendor +└──huawei + └──camera + └──init_configs Configuration file of the init module (in JSON format, in the /etc/ directory) +``` + +## Constraints + +- The startup subsystem is developed using the C language. +- OEM-specified system attributes provide only default values. The specific values need to be adjusted as required. + +## Usage + +- Configuration file of the init module + +The configuration file **init.cfg** of the **init** module contains service names, executable file paths, permissions, and other attributes of all key system services that need to be started by the init process. The file is stored in **/vendor/huawei/camera/init\_configs/** under **/etc/**. It is in JSON format, and its size cannot exceed 100 KB. + +After the init process starts, it reads the **/etc/init.cfg** file, parses the JSON content, and loads system services in sequence based on the parsing result. The format and content of the configuration file are described as follows: + +``` +{ + "jobs" : [{ + "name" : "pre-init", -------- Job executed before the initialization. It can be used to store some pre-operations (for example, creating a folder) before the init process is started. + "cmds" : [ + "mkdir /testdir", -------- Command for creating a folder. mkdir and the target folder must be separated by only one space. + "chmod 0700 /testdir", -------- Command for modifying the permission, which must be in the 0xxxx format. chmod, permission, and the target folder must be separated by only one space. + "chown 99 99 /testdir",-------- Command for modifying the owner group. chown, UID, GID, and the target folder must be separated by only one space. + "mkdir /testdir2", + "mount vfat /dev/mmcblk0p0 /testdir2 noexec nosuid" -------- mount command in the following format: mount file system type source target flags data + -------- flags currently supports only nodev, noexec, nosuid, and rdonly, which are separated by a space. + ] + }, { + "name" : "init", -------- Job name supported by the init process. Ensure that an extended job name contains a maximum of 32 bytes. + "cmds" : [ -------- Command set supported by the current job. Only one space is allowed between the command name (less than 10 bytes) and the following parameter (less than 32 bytes). + "start service1", -------- First command of the current job + "start service2" -------- Second command of the current job (You can adjust the sequence of commands in the array as required. The init process executes the commands in the same order as they are parsed.) + ] + }, { + "name" : "post-init", -------- Job executed after the initialization. It can be used to store some operations performed after the init process is started. + "cmds" : [] + } + ], + "services" : [{ -------- service set (in an array), including all system services that need to be started by the init process + "name" : "service1", -------- Name of the current service. A maximum of 32 bytes must be specified for the name. + "path" : "/bin/process1" -------- Full path of the executable file of the current service. A maximum of 64 bytes must be specified for the path. + "uid" : 1, -------- UID of the current service process + "gid" : 1, -------- GID of the current service process + "once" : 0, -------- Whether the current service process is a one-off process + 0 --- The current service process is not a one-off process. If the process exits due to any reason, the init module restarts the service process upon receiving the SIGCHLD signal. + non-0 --- The current service is a one-off process. If the process exits due to any reason, the init module does not restart the service process. + "importance" : 1, -------- Whether the current service is a key system process + 0 --- The current service is not a key system process. If the process exits due to any reason, the init module does not reset the system. + non-0 --- The current service is a key system process. If the process exits due to any reason, the init module resets and restarts the system upon receiving the SIGCHLD signal. + "caps" : [0, 1, 2, 5] -------- Capabilities required by the current service. They are evaluated based on the capabilities supported by the security subsystem and configured in accordance with the principle of least permission. + }, { + "name" : "service2", -------- Next service that needs to be started by the init module. The service sequence is irrelevant to the startup sequence, which is determined by the cmd sequence in the previous job. + "path" : "/bin/process2", + "uid" : 2, + "gid" : 2, + "once" : 1, + "importance" : 0, + "caps" : [ ] + } + ] +} +``` + +**Table 2** Supported commands + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

+

Syntax

+

Description

+

start

+

start ServiceName

+

Only one space is allowed.

+

Starts a service. The service name must be the same as that in the services array in the file.

+

mkdir

+

mkdir /xxxx/xxx

+

Only one space is allowed.

+

Creates a directory.

+

chmod

+

chmod 0xxx /xxx/xx

+

Only one space is allowed.

+

Changes the permission. The permission value must be in 0xxx format, for example, 0755 and 0600. This configuration must comply with the principle of least permission.

+

chown

+

chown uid gid /xxx/xx

+

Only one space is allowed.

+

Changes the owner group.

+

mount

+

mount fileSysType source target flags data

+

Only one space is allowed.

+

Mounts data. Currently, flags supports only nodev, noexec, nosuid, and rdonly, and other strings are considered as data.

+
+ +It is worth noting that the modified **init.cfg** file must be in JSON format. Otherwise, the init process fails to parse the file, and no service will be started. The configured service permission **uid/gid/capability** must meet the requirements imposed by the security subsystem and comply with the principle of least permission. In addition, if the values of **once** and **importance** of a service are both **0** and the service exits for more than four consecutive times within four minutes, the init process will stop restarting the service. + +- System parameters + + - OEM-specific system attributes + + For Hi3516DV300 and Hi3518EV300 development boards, you need to modify the source files in the **vendor/huawei/camera/hals/utils/sys\_param** directory. + + ``` + static const char HOS_PRODUCT_TYPE[] = {"****"}; + static const char HOS_MANUFACTURE[] = {"****"}; + static const char HOS_BRAND[] = {"****"}; + static const char HOS_MARKET_NAME[] = {"****"}; + static const char HOS_PRODUCT_SERIES[] = {"****"}; + static const char HOS_PRODUCT_MODEL[] = {"****"}; + static const char HOS_SOFTWARE_MODEL[] = {"****"}; + static const char HOS_HARDWARE_MODEL[] = {"****"}; + static const char HOS_HARDWARE_PROFILE[] = {"aout:true,display:true"}; + static const char HOS_BOOTLOADER_VERSION[] = {"bootloader"}; + static const char HOS_SECURE_PATCH_LEVEL[] = {"2020-6-5"}; + static const char HOS_ABI_LIST[] = {"****"}; + ``` + + For Hi3861 development boards, you need to modify the source files in the **vendor/huawei/wifi-iot/hals/utils/sys\_param** directory. + + ``` + static const char HOS_PRODUCT_TYPE[] = {"****"}; + static const char HOS_MANUFACTURE[] = {"****"}; + static const char HOS_BRAND[] = {"****"}; + static const char HOS_MARKET_NAME[] = {"****"}; + static const char HOS_PRODUCT_SERIES[] = {"****"}; + static const char HOS_PRODUCT_MODEL[] = {"****"}; + static const char HOS_SOFTWARE_MODEL[] = {"****"}; + static const char HOS_HARDWARE_MODEL[] = {"****"}; + static const char HOS_HARDWARE_PROFILE[] = {"aout:true,display:true"}; + static const char HOS_BOOTLOADER_VERSION[] = {"bootloader"}; + static const char HOS_SECURE_PATCH_LEVEL[] = {"2020-6-5"}; + static const char HOS_ABI_LIST[] = {"****"}; + ``` + + - Obtaining default system attributes + + ``` + char* value1 = GetProductType(); + printf("Product type =%s\n", value1); + free(value1); + char* value2 = GetManufacture(); + printf("Manufacture =%s\n", value2); + free(value2); + char* value3 = GetBrand(); + printf("GetBrand =%s\n", value3); + free(value3); + ``` + + - Obtaining custom system attributes + + ``` + const char* defSysParam = "data of sys param ***..."; + char key[] = "rw.parameter.key"; + char value[] = "OEM-hisi-10.1.0"; + int ret = SetParameter(key, value); + char valueGet[128] = {0}; + ret = GetParameter(key, defSysParam, valueGet, 128); + printf("value = %s\n", valueGet); + ``` + + +## Repositories Involved + +startup\_frameworks\_syspara\_lite + +startup\_hals\_syspara\_lite + +startup\_interfaces\_kits\_syspara\_lite + +startup\_appspawn\_lite + +startup\_services\_bootstrap\_lite + +startup\_init\_lite + diff --git a/docs-en/readme/testing-subsystem.md b/docs-en/readme/testing-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..bb2f779f1cf101b84231dbcad536c875cd9d7a40 --- /dev/null +++ b/docs-en/readme/testing-subsystem.md @@ -0,0 +1,435 @@ +# Testing Subsystem + +## Overview + +The test-driven development mode is used during the development process. You can develop new cases or modify existing cases to test new or enhanced system features. The self-test helps you develop high-quality code in the development phase. + +## Directory Structure + +**Table 1** Directory structure of the source code for self-test tools + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name

+

Description

+

developertest

+

Development self-test framework

+

developertest/src

+

Test framework source code

+

developertest/src/core

+

Test executor

+

developertest/src/core/build

+

Test case compilation

+

developertest/src/core/command

+

Processing of command lines entered by users

+

developertest/src/core/config

+

Test framework configuration management

+

developertest/src/core/driver

+

Test framework driver executor

+

developertest/src/core/resource

+

Test framework configuration file

+

developertest/src/core/testcase

+

Test case management

+

developertest/src/core/common.py

+

Common operations on the test framework

+

developertest/src/core/constants.py

+

Global constants of the test framework

+

developertest/src/core/exception.py

+

Test framework exceptions

+

developertest/src/core/utils.py

+

Test framework tools and methods

+

developertest/src/main

+

Test framework platform

+

developertest/src/main/__main__.py

+

Internal entrance of the test framework

+

developertest/example

+

Test framework demo cases

+

developertest/third_party

+

Third-party components

+

developertest/BUILD.gn

+

Compilation configuration of the test subsystem

+

developertest/start.bat

+

Developer self-test entry (Windows)

+

developertest/start.sh

+

Developer self-test entry (Linux)

+
+ +## Constraints + +Test tool environment dependency + +1. Python version: 3.7.5 or later +2. NFS version: V4 or later +3. Windows: Windows 10 or later; Linux: Ubuntu 18.04 + +## Installation + +Depend on the Python environment. + +Install the serial port plugins **pyserial** and **readline** on the local Python, and run the **pip intall pyserial** and **sudo apt-get install libreadline-dev** commands on the shell. The following figure is displayed when the installation is complete. + +![](figures/en-us_image_0000001052278423.png) + +## Compiling Test Cases + +- Self-test case specifications + - Naming rules + + The source file name of the test case must be consistent with the test suite content. The relationship between the test suite and the test case is 1:N and the test suite and the test source file is 1:1. Each source file is globally unique and named in the format of \[Feature\]\_\[Function\]\_\[Subfunction 1\]\_\[Subfunction 1.1\]. Subfunctions can be further divided. + + The file name consists of lowercase letters and underscores \(\_\) and ends with test, for example, **developertest/example/cxx\_demo**. + + - Test case coding specifications + + The self-test cases must comply with the feature code coding specifications. In addition, necessary case description information must be added. For details, see [\#li2069415903917](#li2069415903917). + + - Test case compilation and configuration specifications + + The test cases are compiled in GN mode. The configuration must comply with the compilation guide of the open source project. For details, see [en-us\_topic\_0000001051580775.md](en-us_topic_0000001051580775.md). + + +- Self-test case template + + For details, see the test case **demo** developertest/example/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp. + + >![](public_sys-resources/icon-note.gif) **NOTE:** + >Feature: Description of the tested feature + >Function: Function of the tested feature + >SubFunction: Subfunction of the tested feature + >FunctionPoints: Function points to test + >EnvConditions: Environment and conditions of the feature to test + >CaseDescription: Test case description + >step: Procedure for executing the test case when the complex logic is tested + +- Directory plan for self-test cases + + ``` + subsystem (subsystem, system component) + ├── module (module) + │ └── test (module test directory) + │ └── unittest (unit test) + │ ├── common (common test cases) + │ ├── liteos (only for LiteOS core test cases) + │ └── linux (only for Linux core test cases) + │ └── moduletest (module test) + │ ├── common + │ ├── liteos + │ └── linux + └── test (subsystem test directory) + └── unittest (unit test) + ├── common + ├── liteos + ├── linux + └── moduletest (module test) + ├── common + ├── liteos + ├── linux + + ``` + + >![](public_sys-resources/icon-note.gif) **NOTE:** + >The LiteOS and Linux are used as examples only for different device models. For the same feature on different development boards, if the test cases are the same, they are stored in the **common** directory. For the same feature, if the test cases are used to distinguish different device models and may include kernel differences and chip platform differences, the test cases are distinguished by directory. + +- Procedure for compiling self-test cases + 1. Add the comment information of the case header file. + 2. Reference the **gtest** header file and **ext** namespace. + 3. Add the header file to test. + 4. Define test suites \(test classes\). + 5. Implement specific test cases of the test suite, including test case comments and logic implementation. + 6. Compile the test case compilation configuration. + + >![](public_sys-resources/icon-note.gif) **NOTE:** + >\* Example: developertest/example/cxx\_demo/test/unittest/common/calc\_subtraction\_test.cpp + >Notes: + >- **SetUp** and **TearDown** are the processing logic before and after each test case in the test suite is executed. + >- **SetUpTestCase** and **TearDownTestCase** are the processing logic before and after all cases in the test suite are executed. + >- HWTEST usage: This method is applicable only to simple tests \(not depending on **Setup** and **Teardown**\). This method is not applicable to the scenario where multiple test scenarios require the same data configuration. The test cases may affect each other and are not independent. + >- Use the **printf** function to print logs. + + +- Compile a test case compilation file. + - Define test case compilation and building objectives. + 1. Add comments to the case compilation header file. + 2. Import the test case compilation template file. + 3. Specify the output path of the test case file. + 4. Configure the directory contained in the test case compilation dependency. + 5. Specify the name of the case execution file generated by the case compilation target. + 6. Compile a specific test case compilation script and add the source files, configurations, and dependencies involved in the compilation. + 7. Group the target case files by condition. The group name is fixed to **unittest/moduletest**. + + - If there are multiple test suites, define the common compilation configuration. + - Add test cases to the build system. + + >![](public_sys-resources/icon-note.gif) **NOTE:** + >\* Example: developertest/example/cxx\_demo/test/unittest/common/BUILD.gn + + +- Test case level definition + - Basic \(Level 1\): < 1s + - Major \(Level 2\): < 10s + - Minor \(Level 3\): < 5 min + - Uncommon \(Level 4\): \> 5 min + + +## Using Test Framework + +- Install the basic framework **xdevice**. + 1. Open the **xdevice** installation directory, for example, **test/xdevice** in Windows. + 2. Open the console window and run the following command: + + ``` + python setup.py install + ``` + + 3. The following figure is displayed when the installation is complete. + + ![](figures/en-us_image_0000001054501634.png) + + +- Modify the configuration of the basic framework **xdevice**. + + File: xdevice/config/user\_config.xml + + 1. \[device\] \# Configure the serial port information with the label IP camera, COM port, and baud rate. Example: + + ``` + + + COM1 + cmd + 115200 + 8 + 1 + 1 + + + ``` + + +- Modify the configuration of the **developertest** component. + + File: resource/config/user\_config.xml + + 1. \[test\_cases\] \# Specify the output path of the test case and the compilation output directory. Example: + + ``` + + S:\out\ipcamera_hi3518ev300_liteos_a\test + + ``` + + 2. \[NFS\] \# Specify the NFS mapping path. **host\_dir** is the NFS directory on the PC, and **board\_dir** is the directory created on the board. Example: + + ``` + + D:\nfs + user + + ``` + + +- Check the environment before executing the self-test cases. + - The system image and file system have been burnt to a development board and are running properly on the development board. In system mode, for example, the device prompt **OHOS\#** is displayed during shell login. + - The development host is properly connected to the serial port of the development board, and the development host is properly connected to the serial port of the development board. + - The IP addresses of the development host and development board are in the same network segment and can ping each other. + - An empty directory is created on the development host for mounting test cases through NFS, and the NFS service is started properly. + +- Run test suites. + - Start the test framework and go to the **test/developertest** directory. + 1. Start the test framework on Windows. + + ``` + start.bat + ``` + + 2. Start the test framework on Linux. + + ``` + ./strat.sh + ``` + + + - Select a device mode. + + Configure device models based on the actual development board, for example, **developertest/src/core/resource/config/framework\_config.xml**. + + - Run the test command. + 1. The following example shows how to run the test command. **-t ut** is mandatory, and **-ss** and **-tm** are optional. + + ``` + run -t ut -ss test -tm example + ``` + + 2. Specify the parameters that can be used to execute the test suite corresponding to a specific feature or module. + + ``` + usage: __main__.py [-h] [-p PRODUCTFORM] [-t [TESTTYPE [TESTTYPE ...]]] + [-ss SUBSYSTEM] [-tm TESTMODULE] [-ts TESTSUIT] + [-tc TESTCASE] [-tl TESTLEVEL] [-os TARGET_OS_NAME] + [-bv BUILD_VARIANT] [-b [BUILD [BUILD ...]]] + [-cov COVERAGE] [-tf TESTFILE] [-res RESOURCE] + [-sn DEVICE_SN] [-c CONFIG] [-rp REPORTPATH] [-e EXECTYPE] + [-td TEST_DRIVER] + action Specify test para.positional arguments: + action Specify action + + optional arguments: + -h, --help show this help message and exit + -p PRODUCTFORM, --productform PRODUCTFORM Specified product form + -t [TESTTYPE [TESTTYPE ...]], --testtype [TESTTYPE [TESTTYPE ...]] + Specify test type(UT,MST,ST,PERF,ALL) + -ss SUBSYSTEM, --subsystem SUBSYSTEM Specify test subsystem + -tm TESTMODULE, --testmodule TESTMODULE Specified test module + -ts TESTSUIT, --testsuit TESTSUIT Specify test suit + -tc TESTCASE, --testcase TESTCASE Specify test case + -tl TESTLEVEL, --testlevel TESTLEVEL Specify test level + -bv BUILD_VARIANT, --build_variant BUILD_VARIANT Specify build variant(release,debug) + -b [BUILD [BUILD ...]], --build [BUILD [BUILD ...]] + Specify build values(version,testcase) + -tf TESTFILE, --testfile TESTFILE Specify test suites list file + -res RESOURCE, --resource RESOURCE Specify test resource + -sn DEVICE_SN, --device_sn DEVICE_SN Specify device serial number + -c CONFIG, --config CONFIG Specify test config file + -rp REPORTPATH, --reportpath REPORTPATH Specify test report path + -e EXECTYPE, --exectype EXECTYPE Specify test execute type + -td TEST_DRIVER, --testdriver TEST_DRIVER Specify test driver id + ``` + + + +- See the test framework help if needed. + - The help command is used to query test commands that are supported by the test platform. + + ``` + help + ``` + + + +- Exit the self-test platform. + - Run the following command to exit the self-test platform: + + ``` + quit + ``` + + + +## Test Result and Log + +- Test logs and test reports are generated after you execute test instructions in the test framework. +- Test result + - The test result is displayed on the console. The root path of the test result is as follows: + + ``` + reports/xxxx-xx-xx-xx-xx-xx + ``` + + - Test case formatting result + + ``` + result/ + ``` + + - Test case log + + ``` + log/plan_log_xxxx-xx-xx-xx-xx-xx.log + ``` + + - Test report summary + + ``` + summary_report.html + ``` + + - Test report details + + ``` + details_report.html + ``` + + +- Test framework log + + ``` + reports/platform_log_xxxx-xx-xx-xx-xx-xx.log + ``` + +- Latest test report + + ``` + reports/latest + ``` + + +## Repositories Involved + +test\_developertest + +test\_xdevice + diff --git a/docs-en/readme/utils-library.md b/docs-en/readme/utils-library.md new file mode 100755 index 0000000000000000000000000000000000000000..f1a779ea0fbeb6ecc7f7f36055058385d47360fc --- /dev/null +++ b/docs-en/readme/utils-library.md @@ -0,0 +1,151 @@ +# Utils Library + +## Overview + +The Utils library stores basic components of OpenHarmony. These basic components are used by OpenHarmony service subsystems and upper-layer applications. + +The Utils library provides the following capabilities on different platforms: + +- LiteOS-M platform: KV stores, file operations, timers, and IoT peripheral control +- LiteOS-A platform: KV stores, timers, and ACE JavaScript APIs + +## Directory Structure + +``` +utils/native/lite/ # Root directory of the Utils library +├── file # Implementation of the file interface +├── hals # HAL directory +│ └── file # Header files of the hardware abstraction layer for file operations +├── include # Files of external interfaces provided by the Utils library +├── js # ACE JavaScript API directory +│ └── builtin +│ ├── common +│ ├── deviceinfokit # Device information kit +│ ├── filekit # File kit +│ └── kvstorekit # KV store kit +├── kal # KAL directory +│ └── timer # KAL implementation of the timer + ├── kv_store # KV store implementation +│ ├── innerkits # Internal KV store interfaces +│ └── src # KV store source file +└── timer_task # Timer implementation + +base/iot_hardware # IoT peripheral control +├── frameworks +│ └── wifiiot_lite # Implementation of the IoT peripheral control module +├── hals +│ └── wifiiot_lite # HAL interfaces +└── interfaces + └── kits # Interfaces of the IoT peripheral control module + +vendor/hisi/hi3861/hi3861_adapter/hals/iot_hardware # HAL for IoT peripheral control +└── wifiiot_lite # Implementation of the interfaces at the HAL +``` + +## Constraints + +The Utils library is developed using the C language. + +**Table 1** Capabilities and constraints of the Utils library + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Component

+

Platform

+

Description

+

Constraint

+

KV store

+

LiteOS-M and LiteOS-A platforms

+

Provides KV storage for applications.

+

N/A

+

File operation

+

LiteOS-M platform

+

Provides unified file operation interfaces that can be used on different underlying chip components.

+

N/A

+

Timer

+

LiteOS-M and LiteOS-A platforms

+

Provides unified timer operation interfaces that can be used on different underlying chip components.

+

N/A

+

IoT peripheral control

+

LiteOS-M platform

+

Provides the capability of performing operations for peripherals.

+		  
+ +## Usage + +- **KV store** + + Obtaining an interface + + ``` + char key1[] = "rw.sys.version"; + char value1[32] = {0}; + int ret = UtilsGetValue(key1, value1, 32); + Setting the interface + char key14[] = "key_14"; + ret = UtilsSetValue(key14, defValue); + ``` + +- **File operation** + + ``` + // open && write + char fileName[] = "testfile"; + int fd = UtilsFileOpen(fileName, O_RDWR_FS | O_CREAT_FS | O_TRUNC_FS, 0); + printf("file handle = %d\n", fd); + int ret = UtilsFileWrite(fd, def, strlen(def)); + printf("write ret = %d\n", ret); + // stat + int fileLen = 0; + ret = UtilsFileStat(fileName, &fileLen); + printf("file size = %d\n", fileLen); + // seek + int fd1 = UtilsFileOpen(fileName, O_RDWR_FS, 0); + ret = UtilsFileSeek(fd1, 5, SEEK_SET_FS); + printf("lseek ret = %d\n", ret); + char buf[32] = {0}; + int readLen = UtilsFileRead(fd1, buf, 32); + ret = UtilsFileClose(fd1); + printf("read len = %d : buf = %s\n", readLen, buf); + // delete + ret = UtilsFileDelete(fileName); + printf("delete ret = %d\n", ret); + ``` + + +## Repositories Involved + +iothardware\_frameworks\_wifiiot\_lite + +iothardware\_hals\_wifiiot\_lite + +iothardware\_interfaces\_kits\_wifiiot\_lite + +utils\_native\_lite + diff --git a/docs-en/readme/x-test-suite-certification-subsystem.md b/docs-en/readme/x-test-suite-certification-subsystem.md new file mode 100755 index 0000000000000000000000000000000000000000..909dd514696a1599243b843f665e37402f3d673d --- /dev/null +++ b/docs-en/readme/x-test-suite-certification-subsystem.md @@ -0,0 +1,425 @@ +# X Test Suite Certification Subsystem + +## Overview + +X test suite is a set of OpenHarmony certification test suites, including the currently supported application compatibility test suite \(ACTS\) and the device compatibility test suite \(DCTS\) that will be supported in the future. + +The **test/xts** repository contains the **acts** directory and **tools** software package. + +- The **acts** directory stores the source code and configuration files of ACTS test cases. The ACTS helps device vendors detect the software incompatibility as early as possible and ensures that the software is compatible to OpenHarmony during the entire development process. +- The **tools** software package provides the test case development framework where ACTS code is compiled. + +## Directory Structure + +The directory structure of the **test/xts** repository is as follows: + +├── acts + +│ ├── BUILD.gn \#Compilation configuration of test cases + +│ └── testing\_subsystem\_A\_lite \#Test case source code of A + +│ └── testing\_subsystem\_B\_lite \#Test case source code of B + +└── tools + +│ └── build \#Templates and scripts related to test cases compilation + +│ └── hcpptest \#Source code of the development framework for SmartVision device \(IP camera\) test cases + +│ └── hctest \#Source code of the development framework for IoTLink module test cases + +│ └── BUILD.gn \#Compilation configuration + +│ └── build.sh \#Compiling entry + +## Constraints + +You must use the C language to develop IoTLink module ACTS cases, and C++ for SmartVision device \(IP camera\) ACTS cases. + +## ACTS Cases for the IoTLink Module + +The HCTest framework is used. + +The HCTest framework supports the C language and allows you to execute your test cases on the connecting module. The framework is enhanced and adapted based on the open-source test framework Unity. + +1. Store test cases in the **test/xts/acts** repository. + +├── acts + +│ ├── BUILD.gn + +│ └── Testing\_subsystem\_lite + +│ │ └── Testing\_module\_hal + +│ │ │ └── BUILD.gn + +│ │ │ └── src \#Test case source code + +2. Write the test case stored in the **src** directory. + +\(1\) Import the test framework. + +``` +#include "hctest.h" +``` + +\(2\) Use the **LITE\_TEST\_SUIT** macro to define names of the subsystem, module, and test suite. + +``` +/** +* @brief register a test suit named "IntTestSuite" +* @param test subsystem name +* @param example module name +* @param IntTestSuite test suit name +*/ +LITE_TEST_SUIT(test, example, IntTestSuite); +``` + +\(3\) Define Setup and TearDown. + +Format: test suite name+Setup, test suite name+TearDown. + +The Setup and TearDown functions must exist, but function bodies can be empty. + +\(4\) Use the **LITE\_TEST\_CASE** macro to write the test case. + +Three parameters are involved: test suite name, test case name, and test case level. + +The case level can be one of the following: + +**Level0**, **Level1**, **Level2**, **Level3**, and **Level4**. + +``` +LITE_TEST_CASE(IntTestSuite, TestCase001, Level0) +{ + // Do something. +}; +``` + +The following table describes the case levels. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Level

+

Definition

+

Testing Scope

+

Level0

+

Smoke

+

Verifies basic functionalities of key features and basic DFX attributes with the most common input. The pass result indicates that the features are runnable.

+

Level1

+

Basic

+

Verifies basic functionalities of key features and basic DFX attributes with common input. The pass result indicates that the features are testable.

+

Level2

+

Major

+

Verifies basic functionalities of key features and basic DFX attributes with common input and errors. The pass result indicates that the features are functional and ready for beta testing.

+

Level3

+

Regular

+

Verifies functionalities of all key features, and all DFX attributes with common and uncommon input combinations or normal and abnormal preset conditions.

+

Level4

+

Rare

+

Verifies functionalities of key features under extremely abnormal presets and uncommon input combinations.

+
+ +\(5\) Use the **RUN\_TEST\_SUITE** macro to register the test suite. + +``` +RUN_TEST_SUITE(IntTestSuite); +``` + +3. Create the configuration file of the test module. + +Create a **BUILD.gn** \(example\) compilation file in each test module directory. Specify the name of the compiled static library and its dependent header file and library in the compilation file. The format is as follows: + +``` +import("//test/xts/tools/build/suite_lite.gni") +hctest_suite("ActsDemoTest") { + suite_name = "acts" + sources = [ + "src/test_demo.c", + ] + include_dirs = [ ] + cflags = [ "-Wno-error" ] +} +``` + +4. Add compilation options to the **BUILD.gn** file in the **acts** directory. + +To add test code to the compilation file, you need to add the test module to the **test/xts/acts/BUILD.gn** script in the **acts** directory. + +``` +lite_component("acts") { + ... + if(board_name == "liteos_riscv") { + features += [ + ... + "//xts/acts/testing_subsystem_lite/testing_module_hal:ActsDemoTest" + ] + } +} +``` + +5. Run compilation commands. + +\(1\) **python build.py wifiiot -b debug** + +\(2\) **out/wifiiot** + +Note: The ACTS compilation middleware used for IoTLink modules is a static library, which will be linked to the version image **Hi3861\_wifiiot\_app\_allinone.bin**. + +## ACTS Cases for the SmartVision Device \(IP Camera\) + +The HCPP Test framework is enhanced and adapted based on the open-source googletest framework. + +1. Store test cases in the **test/xts/acts** repository. + +├── acts + +│ ├── BUILD.gn + +│ └── Testing\_subsystem\_lite + +│ │ └── Testing\_module\_posix + +│ │ │ └── BUILD.gn + +│ │ │ └── src \(Test case source code\) + +2. Write the test case stored in the **src** directory. + +\(1\) Import the test framework. + +The following statement imports **gtest.h**. + +``` +#include "gtest/gtest.h" +``` + +\(2\) Define Setup and TearDown. + +``` +class TestSuite: public testing::Test { +protected: +// Preset action of the test suite, which is executed before the first test case +static void SetUpTestCase(void){ +} +// Test suite cleanup action, which is executed after the last test case +static void TearDownTestCase(void){ +} +// Preset action of the test case +virtual void SetUp() +{ +} +// Cleanup action of the test case +virtual void TearDown() +{ +} +}; +``` + +\(3\) Use the **HWTEST** or **HWTEST\_F** macro to write the test case. + +**HWTEST**: definition of common test cases, including the test suite name, test case name, and case marking. + +**HWTEST\_F**: definition of SetUp and TearDown test cases, including the test suite name, test case name, and case marking. + +A macro definition contains three parameters: test suite name, test case name, and test case level. + +The case level can be one of the following: + +**Level0**, **Level1**, **Level2**, **Level3**, and **Level4**. + +``` +HWTEST_F(TestSuite, TestCase_0001, Level0) { +// Do something. +} +``` + +The following table describes the case levels. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Level

+

Definition

+

Testing Scope

+

Level0

+

Smoke

+

Verifies basic functionalities of key features and basic DFX attributes with the most common input. The pass result indicates that the features are runnable.

+

Level1

+

Basic

+

Verifies basic functionalities of key features and basic DFX attributes with common input. The pass result indicates that the features are testable.

+

Level2

+

Major

+

Verifies basic functionalities of key features and basic DFX attributes with common input and errors. The pass result indicates that the features are functional and ready for beta testing.

+

Level3

+

Regular

+

Verifies functionalities of all key features, and all DFX attributes with common and uncommon input combinations or normal and abnormal preset conditions.

+

Level4

+

Rare

+

Verifies functionalities of key features under extremely abnormal presets and uncommon input combinations.

+
+ +3. Create the configuration file of the test module. + +Create a **BUILD.gn** \(example\) compilation file in each test module directory. Specify the name of the compiled static library and its dependent header file and library in the compilation file. Each test module is independently compiled into a **.bin** executable file, which can be directly mounted to the development board for testing. + +The following is an example: + +``` +import("//test/xts/tools/build/suite_lite.gni") + +hcpptest_suite("ActsDemoTest") { + suite_name = "acts" + sources = [ + "src/TestDemo.cpp" + ] + + include_dirs = [ + "src", + ... + ] + deps = [ + ... + ] + cflags = [ "-Wno-error" ] +} + +``` + +4. Add compilation options to the **BUILD.gn** file in the **acts** directory. + +To add the test code to the version compilation, you need to add the test module to the **test/xts/acts/BUILD.gn** script in the **acts** directory. + +``` + lite_component("acts") { +... +else if(board_name == "liteos_a") { + features += [ + ... + "//xts/acts/testing_subsystem_lite/testing_module_posix:ActsDemoTest" + ] + } +} +``` + +5. Run compilation commands. + +1.1 Hi3518EV300 + +\(1\) **python build.py ipcamera\_hi3518ev300 -b debug** + +\(2\) **out/ipcamera\_hi3518ev300** + +1.2 Hi3516DV300 + +\(1\) **python build.py ipcamera\_hi3516dv300 -b debug** + +\(2\) **out/ipcamera\_hi3516dv300** + +Note: The ACTS for the SmartVision device \(IP camera\) is independently compiled to a **.bin** executable file, which can be directly mounted to the development board for testing. + +## Executing ACTS Cases for the IoTLink Module + +1. Obtain the testing software package. + +Obtain the image from the **out\\wifiiot\\Hi3861\_wifiiot\_app\_allinone.bin** directory. + +Note: To check whether the ACTS is integrated into the current image, go to **out\\wifiiot\\Hi3861\_wifiiot\_app.map** to check whether the corresponding **.a** file is compiled. + +2. Burn the image into the development board. + +3. Perform testing. + +\(1\) Use a serial port tool to log in to the development board and save information about the serial port. + +\(2\) Restart the device and view serial port logs. + +4. Analyze the test result. + +View the serial port logs, and the format is as follows: + +The log for each test suite starts with **Start to run test suite:** and ends with **xx Tests xx Failures xx Ignored**. + +## Executing ACTS Cases for the SmartVision Device \(IP Camera\) + +Currently, test cases are shared by the NFS and mounted to the development board for execution. + +1. Set up the environment. + +1. Use a network cable or wireless network to connect the IP camera development board to your personal computer \(PC\). +2. Configure the IP address, subnet mask, and gateway for the IP camera development board. Ensure that the development board and the PC are in the same network segment. +3. Install and register the NFS server on the PC and start the NFS service. +4. Run the **mount** command for the IP camera development board to ensure that the development board can access NFS shared files on the PC. + + Format: **mount **_NFS server IP address_**:/**_NFS shared directory_**/**_IP camera development board directory_** nfs** + + Example: + + ``` + mount 192.168.1.10:/nfs /nfs nfs + ``` + + +2. Execute test cases. + +\(1\) Analyze serial port logs. + +\(2\) Run the **./**_Test module_**.bin** command to execute test cases of each test suite. + +## Repositories Involved + +xts\_acts + +xts\_tools\_lite + diff --git a/docs-en/security/figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement-0.png b/docs-en/security/figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement-0.png new file mode 100755 index 0000000000000000000000000000000000000000..a444e5e3ef1891fb41538ed78f59d0fa27673674 Binary files /dev/null and b/docs-en/security/figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement-0.png differ diff --git a/docs-en/security/figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement.png b/docs-en/security/figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement.png index 9461b7c217cc3b25946f63775f98bc735300051b..53440f88d155ad32d40870a82b83bf50205f3ed5 100755 Binary files a/docs-en/security/figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement.png and b/docs-en/security/figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement.png differ diff --git a/docs-en/security/figures/example-of-a-dialog-box-showing-consent-withdrawal.png b/docs-en/security/figures/example-of-a-dialog-box-showing-consent-withdrawal.png new file mode 100755 index 0000000000000000000000000000000000000000..2670e0368826b485b32085dd5abd84adb9e6ad13 Binary files /dev/null and b/docs-en/security/figures/example-of-a-dialog-box-showing-consent-withdrawal.png differ diff --git "a/docs-en/security/figures/\351\232\220\347\247\201\345\243\260\346\230\216\350\257\246\346\203\205\351\241\265\351\235\242-\345\274\271\347\252\22702.png" "b/docs-en/security/figures/\351\232\220\347\247\201\345\243\260\346\230\216\350\257\246\346\203\205\351\241\265\351\235\242-\345\274\271\347\252\22702.png" new file mode 100755 index 0000000000000000000000000000000000000000..ba2ad52a075d7cc88a8169d1987e9462b66b45dd Binary files /dev/null and "b/docs-en/security/figures/\351\232\220\347\247\201\345\243\260\346\230\216\350\257\246\346\203\205\351\241\265\351\235\242-\345\274\271\347\252\22702.png" differ diff --git a/docs-en/security/privacy-protection.md b/docs-en/security/privacy-protection.md index e20f1571ff4c59de867e6cd45aa73cf3b1df0a68..01d415310049169f1e68ddc7e9ffa74bbd004140 100755 --- a/docs-en/security/privacy-protection.md +++ b/docs-en/security/privacy-protection.md @@ -134,18 +134,18 @@ When collecting personal data, clearly and explicitly notify users of the data t Adhering to the preceding principles, we have designed some examples for your reference. The figure below shows an example of a privacy notice or statement. - **Figure 1** Example of a dialog box showing a privacy notice or statement + **Figure 1** Example of a dialog box showing a privacy notice or statement ![](figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement.png "example-of-a-dialog-box-showing-a-privacy-notice-or-statement") - Personal data shall be collected for specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with those purposes. If the purposes are changed or an individual withdraws the consent, you shall obtain user consent again before using the data. The figures below show examples of a privacy statement change and content withdrawal, respectively. - **Figure 2** Example of a dialog box showing a privacy notice or statement change - ![](figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement-change.png "example-of-a-dialog-box-showing-a-privacy-notice-or-statement-change") + **Figure 2** Example of a dialog box showing a privacy notice or statement + ![](figures/example-of-a-dialog-box-showing-a-privacy-notice-or-statement-0.png "example-of-a-dialog-box-showing-a-privacy-notice-or-statement-0") - **Figure 3** Example of a dialog box showing consent withdrawal - + **Figure 3** Example of a dialog box showing consent withdrawal + ![](figures/example-of-a-dialog-box-showing-consent-withdrawal.png "example-of-a-dialog-box-showing-consent-withdrawal") - ![](figures/en-us_image_0000001054860198.png) + ![](figures/隐私声明详情页面-弹窗02.png) The download or upgrade of user system software or application software may involve the modification of users' private space. Users shall have the right to know and control such behavior. They shall be informed of such behavior and be given the option to agree or disagree with such behavior. diff --git a/docs-en/subsystems/development-guidelines-on-photographing.md b/docs-en/subsystems/development-guidelines-on-photographing.md index 2e653583d21b174dede48e7ef5db408cc149b45d..bd918edf08c5a45cce701c992d80284fd1ebdab5 100755 --- a/docs-en/subsystems/development-guidelines-on-photographing.md +++ b/docs-en/subsystems/development-guidelines-on-photographing.md @@ -274,7 +274,7 @@ None ostringstream ss("Capture_"); ss << "Capture" << ltm->tm_hour << "-" << ltm->tm_min << "-" << ltm->tm_sec << ".jpg"; - ofstream pic("/tmp/" + ss.str(), ofstream::out | ofstream::trunc); + ofstream pic("/sdcard/" + ss.str(), ofstream::out | ofstream::trunc); cout << "write " << size << " bytes" << endl; pic.write(p, size); cout << "Saving picture end" << endl; diff --git a/docs-en/subsystems/development-guidelines-on-previewing.md b/docs-en/subsystems/development-guidelines-on-previewing.md index 326e5bb4009e64dfd5e9007c7fbcf8dee0dd28ec..381697174c2824f79d5216ac7017e7b1345eb385 100755 --- a/docs-en/subsystems/development-guidelines-on-previewing.md +++ b/docs-en/subsystems/development-guidelines-on-previewing.md @@ -6,7 +6,7 @@ Use the camera module APIs to generate and play video streams. ## Available APIs -For details, see [Available APIs](development-guidelines-on-photographing.md#section56549532016). +For details, see the available APIs described in development guidelines on photographing. ## Limitations and Constraints @@ -14,7 +14,7 @@ None ## How to Develop -1. Perform step 1 through step 4 provided in [Development Guidelines on Photographing](development-guidelines-on-photographing.md). +1. Perform step 1 through step 4 described in development guidelines on photographing. 2. Set the preview area. ``` diff --git a/docs-en/subsystems/development-guidelines-on-video-recording.md b/docs-en/subsystems/development-guidelines-on-video-recording.md index 131f442b01371c2747608c329b5f3e4ba4e8363b..eb938a26e85fd2a57e5460c0998e0eb0762acff8 100755 --- a/docs-en/subsystems/development-guidelines-on-video-recording.md +++ b/docs-en/subsystems/development-guidelines-on-video-recording.md @@ -6,7 +6,7 @@ Use the camera module APIs to capture video streams. ## Available APIs -For details, see [Available APIs](development-guidelines-on-photographing.md#section56549532016). +For details, see the available APIs described in development guidelines on photographing. ## Limitations and Constraints @@ -14,7 +14,7 @@ None ## How to Develop -1. Perform step 1 through step 4 provided in [Development Guidelines on Photographing](development-guidelines-on-photographing.md). +1. Perform step 1 through step 4 described in development guidelines on photographing. 2. Obtain the **FrameConfig** instance for audio recording. ``` diff --git a/docs-en/subsystems/distributed-remote-startup.md b/docs-en/subsystems/distributed-remote-startup.md index 02cd1c67f9606152859c96cc3efe3d7a1fc2b23a..2c3b0e4d5866b238e62f7c488d1033d0f0565027 100755 --- a/docs-en/subsystems/distributed-remote-startup.md +++ b/docs-en/subsystems/distributed-remote-startup.md @@ -33,7 +33,7 @@ The following table describes the API that can be used by smart TVs to remotely

void startAbility(Want want)

Remotely starts an FA based on the specified Want information. If the name of the want parameter is different from that used in the integrated development environment (IDE), use the parameter name in the IDE.

+

Remotely starts an FA based on the specified Want information. If the name and type of the want parameter are different from those used in the integrated development environment (IDE), use the parameter name and type in the IDE.

SHA256 校验码

Hi3861解决方案

+

Hi3861解决方案（二进制）

1.0

SHA256 校验码

Hi3518解决方案

+

Hi3518解决方案（二进制）

1.0

SHA256 校验码

Hi3516解决方案

+

Hi3516解决方案（二进制）

1.0