提交 485018dd 编写于 作者: L lvqiang214 提交者: Gitee

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

Signed-off-by: Nlvqiang214 <lvqiang1@huawei.com>
......@@ -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])}`);
}
});
})
......
# Raw File Development
# RawFile Development
## When to Use
This document describes how to use the native Rawfile APIs to manage raw file directories and files in OpenHarmony. You can use Rawfile APIs to perform operations such as traversing the file list, opening, searching for, reading, and closing raw files.
This document describes how to use Native Rawfile APIs to manage the directories and files in the **rawfile** directory in OpenHarmony. You can use the APIs to perform operations, such as traversing a directory and opening, searching for, reading, and closing a file in the the **rawfile** directory.
## Available APIs
| Name | Description |
| :----------------------------------------------------------- | :--------------------------------------- |
| NativeResourceManager *OH_ResourceManager_InitNativeResourceManager(napi_env env, napi_value jsResMgr) | Initializes the native resource manager. |
| RawDir *OH_ResourceManager_OpenRawDir(const NativeResourceManager *mgr, const char *dirName) | Opens a raw file directory. |
| int OH_ResourceManager_GetRawFileCount(RawDir *rawDir) | Obtains the number of raw files in the specified directory.|
| const char *OH_ResourceManager_GetRawFileName(RawDir *rawDir, int index) | Obtains the name of a raw file. |
| RawFile *OH_ResourceManager_OpenRawFile(const NativeResourceManager *mgr, const char *fileName) | Opens a raw file. |
| long OH_ResourceManager_GetRawFileSize(RawFile *rawFile) | Obtains the size of a raw file. |
| int OH_ResourceManager_SeekRawFile(const RawFile *rawFile, long offset, int whence) | Seeks a read/write position in a raw file based on the specified offset. |
| long OH_ResourceManager_GetRawFileOffset(const RawFile *rawFile) | Obtains the offset. |
| int OH_ResourceManager_ReadRawFile(const RawFile *rawFile, void *buf, size_t length) | Reads a raw file. |
| void OH_ResourceManager_CloseRawFile(RawFile *rawFile) | Closes a raw file to release resources. |
| void OH_ResourceManager_CloseRawDir(RawDir *rawDir) | Closes a raw file directory to release resources. |
| bool OH_ResourceManager_GetRawFileDescriptor(const RawFile *rawFile, RawFileDescriptor &descriptor) | Obtains the file descriptor (FD) of a raw file. |
| bool OH_ResourceManager_ReleaseRawFileDescriptor(const RawFileDescriptor &descriptor) | Releases the FD of a raw file. |
| void OH_ResourceManager_ReleaseNativeResourceManager(NativeResourceManager *resMgr) | Releases the native resource manager. |
| API | Description |
| :----------------------------------------------------------- | :----------------------------------------------------------- |
| NativeResourceManager *OH_ResourceManager_InitNativeResourceManager(napi_env env, napi_value jsResMgr) | Initializes a Native resource manager instance. |
| RawDir *OH_ResourceManager_OpenRawDir(const NativeResourceManager *mgr, const char *dirName) | Opens a directory in the **rawfile** directory. |
| int OH_ResourceManager_GetRawFileCount(RawDir *rawDir) | Obtains the number of files in the specified directory. |
| const char *OH_ResourceManager_GetRawFileName(RawDir *rawDir, int index) | Obtains the name of a file in the **rawfile** directory. |
| RawFile *OH_ResourceManager_OpenRawFile(const NativeResourceManager *mgr, const char *fileName) | Opens a file in the **rawfile** directory. |
| long OH_ResourceManager_GetRawFileSize(RawFile *rawFile) | Obtains the size of a file in the **rawfile** directory. |
| int OH_ResourceManager_SeekRawFile(const RawFile *rawFile, long offset, int whence) | Seeks for the read/write position in a file in the **rawfile** directory based on the specified offset. |
| long OH_ResourceManager_GetRawFileOffset(const RawFile *rawFile) | Obtains the offset of a file. |
| int OH_ResourceManager_ReadRawFile(const RawFile *rawFile, void *buf, size_t length) | Reads data from a file in the **rawfile** directory. |
| void OH_ResourceManager_CloseRawFile(RawFile *rawFile) | Closes a file in the **rawfile** directory to release resources. |
| void OH_ResourceManager_CloseRawDir(RawDir *rawDir) | Closes a directory in the **rawfile** directory to release resources. |
| bool OH_ResourceManager_GetRawFileDescriptor(const RawFile *rawFile, RawFileDescriptor &descriptor) | Obtains the file descriptor (FD) of a file in the **rawfile** directory. |
| bool OH_ResourceManager_ReleaseRawFileDescriptor(const RawFileDescriptor &descriptor) | Releases the FD of a file in the **rawfile** directory. |
| void OH_ResourceManager_ReleaseNativeResourceManager(NativeResourceManager *resMgr) | Releases a Native resource manager instance. |
## Functions
1. Call **OH_ResourceManager_OpenRawDir** to obtain a **RawDir** instance based on the **NativeResourceManager** instance.
```c++
RawDir* rawDir = OH_ResourceManager_OpenRawDir(nativeResourceManager, path.c_str());
```
2. Call **OH_ResourceManager_GetRawFileCount** to obtain the total number of files in the directory based on the **RawDir** instance.
```c++
int count = OH_ResourceManager_GetRawFileCount(rawDir);
```
3. Call **OH_ResourceManager_GetRawFileName** to obtain the name of a file based on the specified index.
```c++
for (int index = 0; index < count; index++) {
std::string fileName = OH_ResourceManager_GetRawFileName(rawDir, index);
}
```
4. Call **OH_ResourceManager_OpenRawFile** to open a **RawFile** instance with the specified file name.
```c++
RawFile* rawFile = OH_ResourceManager_OpenRawFile(nativeResourceManager, fileName.c_str());
```
5. Call **OH_ResourceManager_GetRawFileSize** to obtain the size of the file.
```c++
long rawFileSize = OH_ResourceManager_GetRawFileSize(rawFile);
```
6. Call **OH_ResourceManager_SeekRawFile** to seek for the read/write position in the file based on the specified offset.
```c++
int position = OH_ResourceManager_SeekRawFile(rawFile, 10, 0);
int position = OH_ResourceManager_SeekRawFile(rawFile, 0 , 1);
int position = OH_ResourceManager_SeekRawFile(rawFile, -10, 2);
```
7. Call **OH_ResourceManager_GetRawFileOffset** to obtain the file offset.
```c++
long rawFileOffset = OH_ResourceManager_GetRawFileOffset(rawFile)
```
8. Call **OH_ResourceManager_ReadRawFile** to read a file.
```c++
std::unique_ptr<char[]> mediaData = std::make_unique<char[]>(rawFileSize);
long rawFileOffset = OH_ResourceManager_ReadRawFile(rawFile, mediaData.get(), rawFileSize);
```
9. Call **OH_ResourceManager_CloseRawFile** to close the file to release resources.
```c++
OH_ResourceManager_CloseRawFile(rawFile);
```
10. Call **OH_ResourceManager_CloseRawDir** to close the file directory.
```c++
OH_ResourceManager_CloseRawDir(rawDir);
```
11. Call **OH_ResourceManager_GetRawFileDescriptor** to obtain the FD of the file.
```c++
RawFileDescriptor descriptor;
bool result = OH_ResourceManager_GetRawFileDescriptor(rawFile, descriptor);
```
12. Call **OH_ResourceManager_ReleaseRawFileDescriptor** to release the FD of the file.
```c++
OH_ResourceManager_ReleaseRawFileDescriptor(descriptor);
```
13. Call **OH_ResourceManager_ReleaseNativeResourceManager** to release the Native resource manager.
```c++
OH_ResourceManager_ReleaseNativeResourceManager(nativeResourceManager);
```
## How to Develop
The following describes how to obtain the raw file list, raw file content, and raw file descriptor on the JavaScript side as an example.
The following describes how to obtain the file list in the **rawfile** directory, file content, and FD {fd, offset, length} on the JavaScript side as an example.
1. Create a project.
![Creating a C++ application](figures/rawfile1.png)
![Creating a C++ application](figures/rawfile1.png)
2. Add dependencies.
After a project is created, the **cpp** directory is created under the project. The directory contains files such as **libentry/index.d.ts**, **hello.cpp**, and **CMakeLists.txt**.
After the project is created, the **cpp** directory is created under the project. The directory contains files such as **libentry/index.d.ts**, **hello.cpp**, and **CMakeLists.txt**.
1. Open the **src/main/cpp/CMakeLists.txt** file, and add **librawfile.z.so** and **libhilog_ndk.z.so** to **target_link_libraries**.
1. Open the **src/main/cpp/CMakeLists.txt** file, and add **librawfile.z.so** and **libhilog_ndk.z.so** to **target_link_libraries**.
```c++
```
target_link_libraries(entry PUBLIC libace_napi.z.so libhilog_ndk.z.so librawfile.z.so)
```
2. Open the **src/main/cpp/types/libentry/index.d.ts** file, and declare the application functions **getFileList**, **getRawFileContent**, and **getRawFileDescriptor**.
2. Open the **src/main/cpp/types/libentry/index.d.ts** file, and declare the application functions **getFileList**, **getRawFileContent**, and **getRawFileDescriptor**.
```c++
import resourceManager from '@ohos.resourceManager';
......@@ -50,9 +138,11 @@ After a project is created, the **cpp** directory is created under the project.
export const getRawFileDescriptor: (resmgr: resourceManager.ResourceManager, path: string) => resourceManager.RawFileDescriptor;
```
3. Modify the source file.
1. Open the **src/main/cpp/hello.cpp** file. During initialization, the file maps the external JavaScript APIs **getFileList**, **getRawFileContent**, and **getRawFileDescriptor** to C++ native APIs **GetFileList**, **GetRawFileContent**, and **GetRawFileDescriptor**.
1. Open the **src/main/cpp/hello.cpp** file. During initialization, the file maps the external JavaScript APIs **getFileList**, **getRawFileContent**, and **getRawFileDescriptor** to C++ native APIs **GetFileList**, **GetRawFileContent**, and **GetRawFileDescriptor**.
```c++
EXTERN_C_START
......@@ -70,7 +160,9 @@ After a project is created, the **cpp** directory is created under the project.
EXTERN_C_END
```
2. Add the three functions to the **src/main/cpp/hello.cpp** file.
2. Add the three functions to the **src/main/cpp/hello.cpp** file.
```c++
static napi_value GetFileList(napi_env env, napi_callback_info info)
......@@ -78,7 +170,11 @@ After a project is created, the **cpp** directory is created under the project.
static napi_value GetRawFileDescriptor(napi_env env, napi_callback_info info)
```
3. Obtain JavaScript resource objects from the **hello.cpp** file, and convert them to native resource objects. Then, call the native APIs to obtain the raw file list, raw file content, and raw file descriptor {fd, offset, length}. The sample code is as follows:
3. Obtain JavaScript resource objects from the **hello.cpp** file, and convert them to Native resource objects. Then, call the Native APIs to obtain the file list, file content, and FD {fd, offset, length}.
The sample code is as follows:
```c++
// Example 1: Use GetFileList to obtain the raw file list.
......@@ -174,7 +270,7 @@ After a project is created, the **cpp** directory is created under the project.
std::unique_ptr<uint8_t[]> data= std::make_unique<uint8_t[]>(len);
// Read the raw file.
int res = OH_ResourceManager_ReadRawFile(rawFile, data.get(), len);
// Close the raw file pointer object.
// Close the rawDir pointer object.
OH_ResourceManager_CloseRawFile(rawFile);
OH_ResourceManager_ReleaseNativeResourceManager(mNativeResMgr);
// Convert the native object to a JavaScript object.
......@@ -246,7 +342,7 @@ After a project is created, the **cpp** directory is created under the project.
// Obtain the FD of the raw file, that is, RawFileDescriptor {fd, offset, length}.
RawFileDescriptor descriptor;
OH_ResourceManager_GetRawFileDescriptor(rawFile, descriptor);
// Close the raw file pointer object.
// Close the rawDir pointer object.
OH_ResourceManager_CloseRawFile(rawFile);
OH_ResourceManager_ReleaseNativeResourceManager(mNativeResMgr);
// Convert the native object to a JavaScript object.
......@@ -254,13 +350,17 @@ After a project is created, the **cpp** directory is created under the project.
}
```
4. Call APIs on the JavaScript side.
1. Open **src\main\ets\pages\index.ets**, and import **libentry.so**.
2. Obtain the JavaScript resource object, that is, **resourceManager**.
4. Call JavaScript APIs.
1. Open **src\main\ets\pages\index.ets**, and import **libentry.so**.
2. Obtain the JavaScript resource object, that is, **resourceManager**.
3. Call **getFileList**, that is, the native API declared in **src/main/cpp/types/libentry/index.d.ts**. When calling the API, pass the JavaScript resource object and the relative path of the raw file. The sample code is as follows:
3. Call **getFileList**, that is, the Native API declared in **src/main/cpp/types/libentry/index.d.ts**. When calling the API, pass in the JavaScript resource object and the relative path of the file.
The sample code is as follows:
```js
import hilog from '@ohos.hilog';
......@@ -293,88 +393,5 @@ After a project is created, the **cpp** directory is created under the project.
}
```
## Using C++ Functions
1. Call **OH_ResourceManager_OpenRawDir** to obtain a **RawDir** instance based on the **NativeResourceManager** instance.
```c++
RawDir* rawDir = OH_ResourceManager_OpenRawDir(nativeResourceManager, path.c_str());
```
2. Call **OH_ResourceManager_GetRawFileCount** to obtain the total number of raw files in the directory based on the **RawDir** instance.
```c++
int count = OH_ResourceManager_GetRawFileCount(rawDir);
```
3. Call **OH_ResourceManager_GetRawFileName** to obtain the name of the raw file with the specified index.
```c++
for (int index = 0; index < count; index++) {
std::string fileName = OH_ResourceManager_GetRawFileName(rawDir, index);
}
```
4. Call **OH_ResourceManager_OpenRawFile** to obtain a **RawFile** instance with the specified file name.
```c++
RawFile* rawFile = OH_ResourceManager_OpenRawFile(nativeResourceManager, fileName.c_str());
```
5. Call **OH_ResourceManager_GetRawFileSize** to obtain the size of the raw file.
```c++
long rawFileSize = OH_ResourceManager_GetRawFileSize(rawFile);
```
6. Call **OH_ResourceManager_SeekRawFile** to seek a read/write position in the raw file based on the specified offset.
```c++
int position = OH_ResourceManager_SeekRawFile(rawFile, 10, 0);
int position = OH_ResourceManager_SeekRawFile(rawFile, 0 , 1);
int position = OH_ResourceManager_SeekRawFile(rawFile, -10, 2);
```
7. Call **OH_ResourceManager_GetRawFileOffset** to obtain the raw file offset.
```c++
long rawFileOffset = OH_ResourceManager_GetRawFileOffset(rawFile)
```
8. Call **OH_ResourceManager_ReadRawFile** to read the raw file.
```c++
std::unique_ptr<char[]> mediaData = std::make_unique<char[]>(rawFileSize);
long rawFileOffset = OH_ResourceManager_ReadRawFile(rawFile, mediaData.get(), rawFileSize);
```
9. Call **OH_ResourceManager_CloseRawFile** to close the file to release resources.
```c++
OH_ResourceManager_CloseRawFile(rawFile);
```
10. Call **OH_ResourceManager_CloseRawDir** to close the raw file directory.
```c++
OH_ResourceManager_CloseRawDir(rawDir);
```
11. Call **OH_ResourceManager_GetRawFileDescriptor** to obtain the FD of the raw file.
```c++
RawFileDescriptor descriptor;
bool result = OH_ResourceManager_GetRawFileDescriptor(rawFile, descriptor);
```
12. Call **OH_ResourceManager_ReleaseRawFileDescriptor** to release the FD of the raw file.
```c++
OH_ResourceManager_ReleaseRawFileDescriptor(descriptor);
```
13. Call **OH_ResourceManager_ReleaseNativeResourceManager** to release the native resource manager.
```c++
OH_ResourceManager_ReleaseNativeResourceManager(nativeResourceManager);
```
......@@ -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)
......
......@@ -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)
......
# 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.
# 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
# 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)
......
# 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
# 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 |
# 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)
# 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)
# 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)
# zlib
[zlib](https://zlib.net/) is a general data compression library implemented in C/C++.
\ No newline at end of file
......@@ -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)
......
......@@ -96,8 +96,8 @@
| 属性名称 | 备注说明 | 必填 |
| ----------------------- | ---------------------------------------- | ---- |
| uri | 数据使用的URI,是跨应用数据访问的唯一标识。 | 是 |
| requiredReadPermission | 访问数据时需要的权限,不配置默认不允许其他APP访问数据。 | 否 |
| requiredWritePermission | 修改数据时需要的权限,不配置默认不允许其他APP修改数据。 | 否 |
| requiredReadPermission | 标识从该数据代理读取数据时所需要的权限,不配置默认不允许其他APP访问数据。支持权限可参考[权限列表](../security/permission-list.md)。 | 否 |
| requiredWritePermission | 标识从该数据代理修改数据时所需要的权限,不配置默认不允许其他APP修改数据。支持权限可参考[权限列表](../security/permission-list.md) | 否 |
| metadata | 数据源的信息,包含name和resource字段。<br /> name类型固定为"dataProperties",是配置的唯一标识。 <br /> resource类型固定为"$profile:{fileName}",表示配置文件的名称为{fileName}.json。 | 是 |
**module.json5配置样例:**
......@@ -107,7 +107,7 @@
{
"uri": "datashareproxy://com.acts.ohos.data.datasharetest/test",
"requiredReadPermission": "ohos.permission.GET_BUNDLE_INFO",
"requiredWritePermission": "ohos.permission.GET_BUNDLE_INFO",
"requiredWritePermission": "ohos.permission.KEEP_BACKGROUND_RUNNING",
"metadata": {
"name": "dataProperties",
"resource": "$profile:my_config"
......@@ -244,8 +244,8 @@
| 属性名称 | 备注说明 | 必填 |
| ----------------------- | ----------------------------- | ---- |
| uri | 数据使用的URI,是跨应用数据访问的唯一标识。 | 是 |
| requiredReadPermission | 访问数据时需要的权限,不配置默认不允许其他APP访问数据。 | 否 |
| requiredWritePermission | 修改数据时需要的权限,不配置默认不允许其他APP修改数据。 | 否 |
| requiredReadPermission | 标识从该数据代理读取数据时所需要的权限,不配置默认不允许其他APP访问数据。支持权限可参考[权限列表](../security/permission-list.md)。 | 否 |
| requiredWritePermission | 标识从该数据代理修改数据时所需要的权限,不配置默认不允许其他APP访问数据。支持权限可参考[权限列表](../security/permission-list.md)。 | 否 |
**module.json5配置样例:**
......@@ -254,7 +254,7 @@
{
"uri": "datashareproxy://com.acts.ohos.data.datasharetest/weather",
"requiredReadPermission": "ohos.permission.GET_BUNDLE_INFO",
"requiredWritePermission": "ohos.permission.GET_BUNDLE_INFO"
"requiredWritePermission": "ohos.permission.KEEP_BACKGROUND_RUNNING"
}
]
```
......
......@@ -12,6 +12,7 @@ Common模块将二级模块API组织在一起方便开发者进行导出。
```ts
import common from '@ohos.app.ability.common';
```
## 属性
**系统能力**:以下各项对应的系统能力均为SystemCapability.Ability.AbilityBase
......
......@@ -12,6 +12,8 @@
import Configuration from '@ohos.app.ability.Configuration';
```
## 属性
**系统能力**:以下各项对应的系统能力均为SystemCapability.Ability.AbilityBase
| 名称 | 类型 | 可读 | 可写 | 说明 |
......
......@@ -949,10 +949,10 @@ adminManager.unsubscribeManagedEvent(wantTemp, events).then(() => {
**系统API**: 此接口为系统接口。
| 名称 | 类型 | 可读 | 可写 | 说明 |
| ----------- | --------| ---- | ----- | ------------------------------- |
| name | string | 是 | 否 | 表示设备管理员应用所属企业的名称。 |
| description | string | 是 | 否 | 表示设备管理员应用所属企业的描述。 |
| 名称 | 类型 | 必填 | 说明 |
| ----------- | --------| ---- | ------------------------------- |
| name | string | 是 | 表示设备管理员应用所属企业的名称。 |
| description | string | 是 | 表示设备管理员应用所属企业的描述。 |
## AdminType
......
......@@ -12,6 +12,8 @@
import ability from '@ohos.ability.ability';
```
## 属性
**系统能力**:以下各项对应的系统能力均为SystemCapability.Ability.AbilityBase
| 名称 | 可读 | 可写 | 类型 | 必填 | 说明 |
......
......@@ -12,6 +12,8 @@
import common from '@ohos.app.ability.common';
```
## 属性
**系统能力**:以下各项对应的系统能力均为SystemCapability.Ability.AbilityRuntime.Core
| 参数名 | 类型 | 必填 | 说明 |
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册