Merge branch 'master' of gitee.com:openharmony/docs into master

Signed-off-by: Nlvqiang214 <lvqiang1@huawei.com>

en/application-dev/file-management/app-file-upload-download.md

@@ -48,7 +48,7 @@ try {
     .then((uploadTask) => {
       uploadTask.on('complete', (taskStates) => {
         for (let i = 0; i < taskStates.length; i++) {
-          console.info(`upload complete taskState: ${JSON.stringify(taskStates[i])}');
+          console.info(`upload complete taskState: ${JSON.stringify(taskStates[i])}`);
         }
       });
     })

en/application-dev/reference/apis/Readme-EN.md

@@ -301,6 +301,7 @@
   - [@ohos.nfc.controller (Standard NFC)](js-apis-nfcController.md)
   - [@ohos.nfc.tag (Standard NFC Tags)](js-apis-nfcTag.md)
   - [@ohos.rpc (RPC)](js-apis-rpc.md)
+  - [@ohos.secureElement (SE Channel Management)](js-apis-secureElement.md)
   - [@ohos.wifiManager (WLAN) (Recommended)](js-apis-wifiManager.md)
   - [@ohos.wifiManagerExt (WLAN Extension) (Recommended)](js-apis-wifiManagerExt.md)
   - [@ohos.wifi (WLAN) (To Be Deprecated Soon)](js-apis-wifi.md)

en/application-dev/reference/errorcodes/Readme-EN.md

@@ -60,6 +60,7 @@
   - [Bluetooth Error Codes](errorcode-bluetoothManager.md)
   - [Wi-Fi Error Codes](errorcode-wifi.md)  
   - [NFC Error Codes](errorcode-nfc.md)
+  - [SE Error Codes](errorcode-se.md)
   - [RPC Error Codes](errorcode-rpc.md)
 - Basic Features
   - [Accessibility Error Codes](errorcode-accessibility.md)

en/application-dev/reference/errorcodes/errorcode-se.md

+# SE Error Codes
+
+> **NOTE**
+>
+> This topic describes only module-specific error codes. For details about universal error codes, see [Universal Error Codes](errorcode-universal.md).
+
+## 3300101 Abnormal SE Service Status
+
+**Error Message**
+
+Illegal service state exception.
+
+**Description**
+
+The SecureElement (SE) service is abnormal.
+
+**Possible Causes**
+
+1. The SE service is disconnected.
+
+**Solution**
+
+1. Close the SE service.
+
+2. Set up a connection with the SE service again.
+
+## 3300102 No Such SE
+
+**Error Message**
+
+No such element exception.
+
+**Description**
+
+The SE is unavailable.
+
+**Possible Causes**
+
+1. Communication with the SE service is abnormal.
+2. Communication of the SE chip is abnormal.
+
+**Solution**
+
+1. Close the SE service and set up a connection with the SE service again.
+2. Restart the device.
+
+## 3300103 Failed to Obtain the Access Rule
+
+**Error Message**
+
+Illegal access rule exception.
+
+**Description**
+
+The access rule cannot be obtained.
+
+**Possible Causes**
+
+1. There is no access rule for the application on the SE.
+
+**Solution**
+
+1. Write correct access rules to the SE.
+2. Close the SE service and set up a connection with the SE service again.
+
+## 3300104 SE Chip I/O Exception
+
+**Error Message**
+
+Secure element IO exception.
+
+**Description**
+
+The I/O of the SE chip is abnormal.
+
+**Possible Causes**
+
+1. The communication with the SE chip is abnormal.
+2. The SE chip is abnormal.
+
+**Solution**
+
+1. Close the SE service and set up a connection with the SE service again.
+
+2. Restart the device.

en/application-dev/reference/native-api-intro.md

+# Native API Introduction
+
+Native APIs, also called Native Develop Kit (NDK), are a set of native interfaces and tools provided by the OpenHarmony SDK for implementing key application features by using C or C++. Different from JS APIs, the Native APIs provide only part of underlying capabilities of OpenHarmony, such as the libc, graphics library, window system, multimedia, and compression library. The Native APIs will be build as a dynamic library before being packaged into an application.
+
+## Concepts
+
+|Term|Description|
+|--|--|
+|Native API|Native interfaces, build scripts, and compiler toolchains provided by the **native** package in the OpenHarmony SDK for third-party application development. Native APIs include the C runtime libc, 3D graphics library **OpenGL**, and Node-APIs for cross-language programming between JS and C.|
+|NDK|Native Develop Kit (NDK) that provides the Native APIs in OpenHarmony. NDK is the equivalent of Native API. Native API is the official name.|
+|SDK CAPI|C interfaces and toolchains in OpenHarmony Native APIs.<br/>Currently, OpenHarmony Native APIs contain only C interfaces. Therefore, Native API is CAPI. However, you are advised to use CAPI.|
+|Node-API|Native interfaces that implement cross-language invocation between C and JS. Node-API is formerly called napi. Although OpenHarmony Node-APIs are extension of the Node-APIs provided by **Node.js**, they are not fully compatible with the Node-APIs in **Node.js**.|
+|napi|Former name of Node-API. It is not used because it may be interpreted as Native API or Node-API by mistake. Currently, the interfaces in the Node-API header files still start with **napi_**.|
+
+## Native API Composition
+
+### Native API Directory Structure
+
+Native APIs are stored in the **$(SDK_ROOT)/native** directory of the SDK.
+
+|Directory|Description|
+|--|--|
+|build|Provides the toolchain cmake script used to build the dynamic library of an application. The **ohos.toolchain.cmake** file in this directory defines OpenHarmony cross-compilation options.|
+|build-tools|Provides build tools, such as CMake.|
+|docs|Provides Native API reference documents, which are extracted from the header files using Doxgen.|
+|llvm|Provides the LLVM, a cross compiler that supports the OpenHarmony Application Binary Interface (ABI).|
+|sysroot|Provides dependencies of links, including header files and dynamic libraries.|
+
+### Native APIs
+
+|Category|Description|Introduced Since Version|
+|--|--|--|
+|[C standard library](native-lib/third_party_libc/musl.md)|Provides more than 1500 libc interfaces based on musl.|8|
+|[C++ standard library](native-lib/third_party_libc/cpp.md)|Provides the libc++_shared library for C++ runtime. This library must be packed or statically linked to the application during packing.|8|
+|Log|Provides HiLog interfaces for printing logs to the system.|8|
+|Node-API|Provides APIs like Node-APIs (also called napis) for accessing the JS application environment. Node-APIs are provided by ArkUI and are part of Native APIs.|8|
+|XComponent|Provides Surface and touchscreen event interfaces for developing high-performance graphics applications on ArkUI.|8|
+|libuv|Provides a third-party asynchronous I/O library integrated by ArkUI.|8|
+|libz|Provides basic compression and decompression interfaces.|8|
+|Drawing|Provides a 2D graphics library for drawing on Surface.|8|
+|OpenGL|Provides OpenGL 3.0 interfaces.|8|
+|Rawfile|Provides application resource access interfaces for reading various resources packed in applications.|8|
+|OpenSLES|Provides interfaces for 2D and 3D audio acceleration.|8|
+|Mindspore|Provides AI model interfaces.|9|
+|Bundle management|Provides bundle service interfaces for querying bundle information of applications.|8|
+
+### Native API Documents
+
+* [Native API Reference](native-apis/_o_h___native_x_component.md): provides reference for Native APIs.
+* [Standard Libraries Supported by Native APIs](../reference/native-lib/third_party_libc/musl.md): describes the open-source standard libraries supported by Native APIs.
+* [Native API Development](../napi/napi-guidelines.md): describes how to use Native APIs.
+* [Using NDK to Build a CMake C/C++ Project](../faqs/how-to-migrate-cmake-with-ohosndk.md): describes how to use Native APIs to develop a CMake project.
+* [Using Node-APIs in Application Projects](../napi/napi-guidelines.md): describes how to use Node-APIs.
+
+## How to Use
+
+### Recommended Use of Native APIs
+
+Use Native APIs when you want to:
+
+1. Develop performance-sensitive code in computing-intensive scenarios, such as gaming and physical simulation.
+2. Reuse the existing C or C++ library.
+3. Customize libraries related to CPU features, such as neon acceleration.
+
+### Use of Native APIs Not Recommended
+
+Do not use Native APIs when you want to:
+
+1. Develop a pure OpenHarmony application.
+2. Develop an application that is compatible on as many OpenHarmony devices as possible.
+
+## Debugging Capabilities
+
+1. OpenHarmony provides remote code debugging by using the low-level Debugger (LLDB). For details, see [LLDB](https://gitee.com/openharmony/third_party_llvm-project/blob/master/lldb/README_en.md).
+2. OpenHarmony provides the log debugging for the musl library. For details, see "Debugging Capabilities" in [libc](./native-lib/third_party_libc/musl.md).
+
+<!--no_check-->
\ No newline at end of file

en/application-dev/reference/native-lib/Readme-EN.md

-# Standard Libraries Supported by Native APIs
+# Native API Standard Libraries
 - [libc](third_party_libc/musl.md)
+- [libc++](third_party_libc/cpp.md)
 - [Node-API](third_party_napi/napi.md)
 - [libuv](third_party_libuv/libuv.md)
 - [OpenSL ES](third_party_opensles/opensles.md)
+- [OpenGL ES](third_party_opengl/opengles.md)
+- [EGL](third_party_opengl/egl.md)
+- [zlib](third_party_zlib/zlib.md)
 - Appendix
   - [Native API Symbols Not Exported](third_party_libc/musl-peculiar-symbol.md)
   - [Native API Symbols That May Fail to Be Invoked Due to Permission Control](third_party_libc/musl-permission-control-symbol.md)

en/application-dev/reference/native-lib/third_party_libc/cpp.md

+
+# libc++
+
+Currently, OpenHarmony uses the C++ standard library [(libc++)](https://libcxx.llvm.org/) of the LLVM project.
+
+## Version
+
+From OpenHarmony 3.0, libc++ uses Clang/LLVM 10.0.1.
+
+From OpenHarmony 3.2, libc++ is upgraded to Clang/LLVM 12.0.1.
+
+From OpenHarmony 4.0, libc++ is upgraded to Clang/LLVM 15.0.4.
+
+## Supported Capabilities
+
+The C++11 and C++14 standards are supported, and the C++17 and C++20 standards are on the way. For details about the standards supported by language features, see the corresponding Release Notes at [https://libcxx.llvm.org/](https://libcxx.llvm.org/).
+
+## ABI Compatibility
+In OpenHarmony, both the system library and application native library use the libc++. However, the two libc++ are different. The libc++ of the system library is updated with the image version, while the libc++ of the application native library is updated with the SDK version used for compilation. Both the libc++ libraries cross multiple major versions, which may cause Application Binary Interface (ABI) compatibility issues. To solve this problem, OpenHarmony differentiates the libc++ libraries as follows:
+  * System library: uses **libc++.so**, which is released with the system image.
+  * Application native library: uses **libc++_shared.so**, which is released with the application.
+
+The two libc++ libraries use different namespaces. **libc++_shared.so** uses **__n1** as the namespace for C++ symbols, and **libc++.so** uses **__h** as the namespace for C++ symbols.
+
+> **CAUTION**
+>
+> Currently, the Native API supports C only. The system library can use any programming language.
+
+<!--no_check-->
\ No newline at end of file

en/application-dev/reference/native-lib/third_party_libc/musl-permission-control-symbol.md

 # Native API Symbols That May Fail to Be Invoked Due to Permission Control
 
+Before using the following interfaces, ensure that the application entity has the corresponding permission.
+
 | Symbol| Possible Cause|
 | --- | --- |
-| mlockall | User namespace isolation or lack of the CAP_IPC_LOCK privilege.|
-| swapon | User namespace isolation. |
-| swapoff | User namespace isolation. |
-| stime | User namespace isolation or lack of the CAP_SYS_TIME privilege.|
-| settimeofday | User namespace isolation or lack of the CAP_SYS_TIME privilege.|
-| adjtime | User namespace isolation or lack of the CAP_SYS_TIME privilege.|
-| clock_settime | User namespace isolation or lack of the CAP_SYS_TIME privilege.|
-| klogctl | User namespace isolation or lack of the CAP_SYS_ADMIN/CAP_SYSLOG privilege.|
+| mlockall | usr namespace isolation or lack of CAP_IPC_LOCK privilege |
+| swapon | usr namespace isolation |
+| swapoff | usr namespace isolation |
+| stime | usr namespace isolation or lack of CAP_SYS_TIME privilege |
+| settimeofday | usr namespace isolation or lack of CAP_SYS_TIME privilege |
+| adjtime | usr namespace isolation or lack of CAP_SYS_TIME privilege |
+| clock_settime | usr namespace isolation or lack of CAP_SYS_TIME privilege |
+| klogctl | usr namespace isolation or lack of CAP_SYS_ADMIN/CAP_SYSLOG privilege |

en/application-dev/reference/native-lib/third_party_libc/musl.md

-# Native Standard Libraries Supported by OpenHarmony
+# libc
 
 ## Overview
+The C standard library (libc) provides standard header files and common library implementations (such as input/output processing and string handling) in C language programming.
 
-**Table 1** Standard libraries supported by OpenHarmony
+OpenHarmony uses musl as the libc. musl is a lightweight, fast, simple, and free open-source libc. For details, see [musl libc Reference Manual](http://musl.libc.org/manual.html).
 
-| Library     | Description                                                        |
-| :-------- | :----------------------------------------------------------- |
-| C standard library  | C11 standard library implemented by [libc, libm, and libdl](https://en.cppreference.com/w/c/header).      |
-| C++ standard library ([libc++](https://libcxx.llvm.org/))| An implementation of the C++ standard library.  |
-| Open Sound Library for Embedded Systems ([OpenSL ES](https://www.khronos.org/registry/OpenSL-ES/))| An embedded, cross-platform audio processing library.|
-| [zlib](https://zlib.net/)    | A general data compression library implemented in C/C++.|
-| [EGL](https://www.khronos.org/egl/)  | A standard software interface between rendering APIs and the underlying native window system.|
-| Open Graphics Library for Embedded Systems ([OpenGL ES](https://www.khronos.org/opengles/))| A cross-platform software interface for rendering 3D graphics on embedded and mobile systems.|
+For details about the differences between musl and glibc, see [Functional differences from glibc](https://wiki.musl-libc.org/functional-differences-from-glibc.html).
 
-## C Standard Library
+## libc Components
 
-The C standard library is a C11 standard library implemented by:
+C11 is implemented by [libc, libm, and libdl](https://en.cppreference.com/w/c/header). 
 
-- libc: provides thread-related functions and a majority of standard functions.
+libc: provides thread-related interfaces and a majority of standard interfaces.
 
+libm: provides mathematical library interfaces. Currently, OpenHarmony provides a link to libm, and the interfaces are defined in libc.
 
-- libm: provides basic mathematical functions.
+libdl: provides dynamic linker interfaces such as dlopen. Currently, OpenHarmony provides a link to libdl, and the interfaces are defined in libc.
 
-
-- libdl: provides functions related to dynamic linking, such as **dlopen**.
-
-
-**Version**
+## musl Version
 
 1.2.0
 
-**Capabilities**
-
-C standard library includes a set of header files in accordance with standard C and provides common functions, such as the functions related to input/output (I/O) and string control.
-
-**musl**
-
+From OpenHarmony 4.0, musl 1.2.3 is supported.
+
+## Supported Capabilities
+OpenHarmony provides header files and library interfaces that are compatible (not fully compatible) with C99, C11, and POSIX, and supports Armv7-A, Arm64, and x86_64 architectures.
+
+To better adapt to the basic features of OpenHarmony devices, such as high performance, low memory, high security, lightweight, and multi-form support, OpenHarmony has optimized the musl library and removed the interfaces that are not applicable to embedded devices.
+
+### New Capabilities
+1. The dynamic loader supports isolation by namespace. The dynamic libraries that can be loaded by **dlopen()** are restricted by the system namespace. For example, the system dynamic libraries cannot be opened.
+2. **dlclose()** can be used to unload a dynamic library. This capability is not supported by musl.
+3. The symbol-versioning is supported.
+4. **dlopen()** can directly load uncompressed files in a .zip package.
+
+### Debugging Capabilities
+The libc provides dynamic settings of the basic log functions (disabled by default) for developers to view internal exceptions of the libc. You can set the **param** to enable or disable the log functions, without recompiling the libc. However, you are advised not to use the log functions in official release versions because they affect the running performance.
+
+#### 1. musl.log
+Set **musl.log.enable** to **true** to enable the **musl.log** function. To print other logs, you need to enable this function first.
+```
+setparam musl.log.enable true
+```
+
+#### 2. Loader log function
+The loader starts applications and invokes dlopen() and dlclose() in libc. To view exceptions in the dynamic loading process, enable the loader log function.
+* Enable the loader log of all applications (exercise caution when using this function).
+```
+param set musl.log.ld.app true
+```
+* Enable the loader log of the specified application. {app_name} specifies the target application.
+```
+param set musl.log.ld.all false
+param set musl.log.ld.app.{app_name} true
+```
+* Enable the loader log of all applications except the specified application.
+```
+param set musl.log.ld.all true
+param set musl.log.ld.app.{app_name} false
+```
+
+## Interfaces Not Supported by musl
 [Native API Symbols Not Exported](musl-peculiar-symbol.md)
-
 [Native API Symbols That May Fail to Be Invoked Due to Permission Control](musl-permission-control-symbol.md)
 
-## libc++
-
-[libc++](https://libcxx.llvm.org/) is an implementation of the C++ standard library.
-
-**Version**
-
-10.0.1
-
-**Capabilities**
-
-The C++11 and C++14 standards are supported, and the C++17 and C++20 standards are on the way.
-
-## OpenSL ES
-
-[OpenGL ES](https://www.khronos.org/opengles/) is an embedded, cross-platform audio processing library.
-
-**Capabilities**
-
-[OpenSL ES Interfaces Supported by Native APIs](../third_party_opensles/opensles.md)
-
-## zlib
-
-[zlib](https://zlib.net/) is a general data compression library implemented in C/C++.
-
-## EGL
-
-EGL is an interface between Khronos rendering APIs (such as OpenGL ES and OpenVG) and the underlying native window system. OpenHarmony supports EGL.
-
-**Symbols Exported from the Standard Library**
-
-[EGL Symbols Exported from Native APIs](../third_party_opengl/egl-symbol.md)
-
-## OpenGL ES
-
-OpenGL is a cross-platform software interface for 3D graphics processing. [OpenGL ES](https://www.khronos.org/opengles/) is a OpenGL specification for embedded devices. OpenHarmony supports OpenGL ES 3.0.
-
-**Capabilities**
-
-OpenGL ES 3.0
-
-**Symbols Exported from the Standard Library**
-
-[OpenGL ES 3.0 Symbols Exported from Native APIs](../third_party_opengl/openglesv3-symbol.md)

en/application-dev/reference/native-lib/third_party_opengl/egl.md

+
+# EGL
+
+EGL is an interface between Khronos rendering APIs (such as OpenGL ES and OpenVG) and the underlying native window system. OpenHarmony supports EGL.
+
+## **Symbols Exported from the NAPI Library**
+
+[EGL Symbols Exported fom Native APIs](egl-symbol.md)
+

en/application-dev/reference/native-lib/third_party_opengl/opengles.md

+# OpenGL ES
+
+OpenGL is a cross-platform software interface for 3D graphics processing. [OpenGL ES](https://www.khronos.org/opengles/) is a OpenGL specification for embedded devices. OpenHarmony supports OpenGL ES 3.0.
+
+## Supported Capabilities
+
+OpenGL ES 3.0
+
+## **Symbols Exported from the NAPI Library**
+
+[OpenGL ES 3.0 Symbols Exported from Native APIs](openglesv3-symbol.md)
+

en/application-dev/reference/native-lib/third_party_zlib/zlib.md

+# zlib
+
+[zlib](https://zlib.net/) is a general data compression library implemented in C/C++.
\ No newline at end of file

zh-cn/application-dev/application-models/arkts-ui-widget-update-by-proxy.md

@@ -28,7 +28,7 @@
 1. 数据提供方以`key + subscriberId`作为数据的标识，将数据存储到数据库。
 2. 数据管理服务感知到数据库变化，将新的数据发布给当前注册的所有订阅实例。
 3. 卡片管理服务从订阅实例中解析出数据，发送给卡片渲染服务。
-4. 卡片渲染服务运行卡片页面代码widgets.abc，widgets.abc按新数据进行渲染，并将渲染后的数据发送至卡片使用方对应的[卡片组件](https://gitee.com/openharmony/docs/blob/fd489446c497c09d86ffa3beafd73dad90f1adb6/zh-cn/application-dev/reference/arkui-ts/ts-basic-components-formcomponent.md)。
+4. 卡片渲染服务运行卡片页面代码widgets.abc，widgets.abc按新数据进行渲染，并将渲染后的数据发送至卡片使用方对应的[卡片组件](https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/reference/arkui-ts/ts-basic-components-formcomponent.md)。
 
 数据提供方提供的共享数据有两种类型：
 
@@ -177,7 +177,7 @@
   }
   ```
 
-- 在卡片页面代码widgets.abc中，通过LocalStorage变量获取订阅到的数据，LocalStorage绑定了一个字符串，以key:value的键值对格式来刷新卡片订阅数据，其中key必须与卡片提供方订阅的key保持一致。示例中，通过'list'获取订阅的数据，并把第一个元素的值显示在Text组件上。
+- 在卡片页面代码文件（一般为工程中卡片目录下pages目录中的.ets文件）中，通过LocalStorage变量获取订阅到的数据，LocalStorage绑定了一个字符串，以key:value的键值对格式来刷新卡片订阅数据，其中key必须与卡片提供方订阅的key保持一致。示例中，通过'list'获取订阅的数据，并把第一个元素的值显示在Text组件上。
   ```ts
   let storage = new LocalStorage();
   @Entry(storage)