@@ -30,7 +30,7 @@ The following table provides only a simple description of the related APIs. For
| on\('dataProgress'\)<sup>10+</sup> | Registers an observer for events indicating progress of receiving HTTP streaming responses. |
| off\('dataProgress'\)<sup>10+</sup> | Unregisters the observer for events indicating progress of receiving HTTP streaming responses.|
## How to Develop
## How to Develop request APIs
1. Import the **http** namespace from **@ohos.net.http.d.ts**.
2. Call **createHttp()** to create an **HttpRequest** object.
...
...
@@ -89,3 +89,80 @@ httpRequest.request(
}
);
```
## How to Develop request2 APIs
1. Import the **http** namespace from **@ohos.net.http.d.ts**.
2. Call **createHttp()** to create an **HttpRequest** object.
3. Depending on your need, call **on()** of the **HttpRequest** object to subscribe to HTTP response header events as well as events indicating receiving of HTTP streaming responses, progress of receiving HTTP streaming responses, and completion of receiving HTTP streaming responses.
4. Call **request2()** to initiate a network request. You need to pass in the URL and optional parameters of the HTTP request.
5. Parse the returned response code as needed.
6. Call **off()** of the **HttpRequest** object to unsubscribe from the related events.
7. Call **httpRequest.destroy()** to release resources after the request is processed.
```js
// Import the http namespace.
importhttpfrom'@ohos.net.http'
// Each httpRequest corresponds to an HTTP request task and cannot be reused.
lethttpRequest=http.createHttp();
// Subscribe to HTTP response header events.
httpRequest.on('headersReceive',(header)=>{
console.info('header: '+JSON.stringify(header));
});
// Subscribe to events indicating receiving of HTTP streaming responses.
letres='';
httpRequest.on('dataReceive',(data)=>{
res+=data;
console.info('res: '+res);
});
// Subscribe to events indicating completion of receiving HTTP streaming responses.
httpRequest.on('dataEnd',()=>{
console.info('No more data in response, data receive end');
});
// Subscribe to events indicating progress of receiving HTTP streaming responses.
// Customize EXAMPLE_URL in extraData on your own. It is up to you whether to add parameters to the URL.
"EXAMPLE_URL",
{
method:http.RequestMethod.POST,// Optional. The default value is http.RequestMethod.GET.
// You can add header fields based on service requirements.
header:{
'Content-Type':'application/json'
},
// This field is used to transfer data when the POST request is used.
extraData:{
"data":"data to send",
},
expectDataType:http.HttpDataType.STRING,// Optional. This field specifies the type of the return data.
usingCache:true,// Optional. The default value is true.
priority:1,// Optional. The default value is 1.
connectTimeout:60000// Optional. The default value is 60000, in ms.
readTimeout:60000,// Optional. The default value is 60000, in ms. If a large amount of data needs to be transmitted, you are advised to set this parameter to a larger value to ensure normal data transmission.
usingProtocol:http.HttpProtocol.HTTP1_1,// Optional. The default protocol type is automatically specified by the system.
- Disabling the privacy flag: hdc_std shell hilog -p off
- Increasing the log buffer to 200 MB: hdc_std shell hilog -G 200M
- Enabling the log function of the specific domain (that is, disabling the global log function): hdc_std shell hilog –b D –D 0xd0xxxxx
After performing the preceding operations, restart the DevEco Studio.
## What should I do if the HAP installed on the development board through the IDE cannot be opened?
Applicable to: OpenHarmony SDK 3.2.5.3, stage model of API version 9
Check whether the SDK version is consistent with the system version on the development board. You are advised to use the SDK version and system version that are released on the same day.
## How do I upload files using the hdc command?
Applicable to: OpenHarmony SDK 3.2.2.5
Run the **hdc_std file send** command.
## How do I prevent the screen of the RK3568 development board from turning off?
Applicable to: OpenHarmony SDK 3.2.5.3, stage model of API version 9
Run the **hdc_std shell "power-shell setmode 602"** command.
## How do I start an ability using the hdc command?
Applicable to: OpenHarmony SDK 3.2.5.3, stage model of API version 9
Run the **hdc\_std shell aa start -a AbilityName -b bundleName -m moduleName** command.
## How do I change the read and write permissions on a file directory on the development board?
Applicable to: OpenHarmony SDK 3.2.5.6, stage model of API version 9
Run the **hdc\_std shell mount -o remount,rw /** command.
## What should I do if the error message "Unknown file option -r" is displayed when hdc_std file recv is run?
Applicable to: OpenHarmony SDK 3.2.5.6, stage model of API version 9
1. Use the the hdc tool in the device image or SDK of the same version.
2. Remove any Chinese characters or spaces from the directory specified for the hdc tool.
## How do I uninstall an application using the hdc command?
Applicable to: OpenHarmony SDK 3.2.2.5
Run the **hdc\_std uninstall [-k] [package_name]** command.
## How do I check whether the system is 32-bit or 64-bit?
Applicable to: OpenHarmony SDK 3.2.5.5
Run the **hdc\_std shell getconf LONG_BIT** command.
If **64** is returned, the system is a 64-bit one. Otherwise, the system is a 32-bit one.
## How do I view the component tree structure?
Applicable to: OpenHarmony SDK 3.2.5.5
1. Run the **hdc\_std shell** command to launch the CLI.
2. Run the **aa dump -a** command to find **abilityID**.
3. Run the **aa dump -i [abilityID] -c -render** command to view the component tree.
The **contact** module provides contact management functions, such as adding, deleting, and updating contacts.
>**NOTE**
>
>The initial APIs of this module are supported since API version 7. Newly added APIs will be marked with a superscript to indicate their earliest API version.
...
...
@@ -7,7 +9,7 @@
## Modules to Import
```js
```
import contact from '@ohos.contact';
```
...
...
@@ -183,7 +185,7 @@ Updates a contact based on the specified contact information. This API uses an a
@@ -513,7 +513,7 @@ Initiates an HTTP request containing specified options to a given URL. This API
>**NOTE**
> For details about the error codes, see [HTTP Error Codes](../errorcodes/errorcode-net-http.md).
> The HTTP error code mapping is in the format of 2300000 + Curl error code. For more common error codes, see:
> The HTTP error code mapping is in the format of 2300000 + Curl error code. For more common error codes, see [Curl Error Codes](https://curl.se/libcurl/c/libcurl-errors.html).
@@ -567,7 +567,7 @@ Unregisters the observer for HTTP Response Header events.
>**NOTE**
>
>1. This API has been deprecated. You are advised to use [off('headersReceive')<sup>8+</sup>](#offheadersreceive8) instead.
>1. This API has been deprecated. You are advised to use [off('headersReceive')<sup>8+</sup>](#offheadersreceive8).
>
>2. You can pass the callback of the **on** function if you want to cancel listening for a certain type of event. If you do not pass the callback, you will cancel listening for all events.
...
...
@@ -839,7 +839,7 @@ Enumerates the response codes for an HTTP request.
Multicast DNS (mDNS) provides functions such as adding, removing, discovering, and resolving local services on a LAN.
> **NOTE**
> The initial APIs of this module are supported since API version 10. Newly added APIs will be marked with a superscript to indicate their earliest API version.
| context | Context | Yes | Application context.<br>For details about the application context of the FA model, see [Context](js-apis-inner-app-context.md).<br>For details about the application context of the stage model, see [Context](js-apis-inner-application-uiAbilityContext.md).|
| callback | AsyncCallback\<[LocalServiceInfo](#localserviceinfo)> | Yes | Callback used to return the result. If the operation is successful, **error** is **undefined** and **data** is the mDNS service information. |
**Error codes**
| ID | Error Message|
|---------|---|
| 401 | Parameter error. |
| 2100002 | Operation failed. Cannot connect to service. |
| 2100003 | System internal error. |
| 2204003 | Callback duplicated. |
| 2204008 | Service instance duplicated. |
| 2204010 | Send packet failed. |
>**NOTE**
> For details about the error codes, see [mDNS Error Codes](../errorcodes/errorcode-net-mdns.md).
| context | Context | Yes | Application context.<br>For details about the application context of the FA model, see [Context](js-apis-inner-app-context.md).<br>For details about the application context of the stage model, see [Context](js-apis-inner-application-uiAbilityContext.md).|
| context | Context | Yes | Application context.<br>For details about the application context of the FA model, see [Context](js-apis-inner-app-context.md).<br>For details about the application context of the stage model, see [Context](js-apis-inner-application-uiAbilityContext.md).|
| callback | AsyncCallback\<[LocalServiceInfo](#localserviceinfo)> | Yes | Callback used to return the result. If the operation is successful, **error** is **undefined** and **data** is the mDNS service information. |
**Error codes**
| ID | Error Message|
|---------|---|
| 401 | Parameter error. |
| 2100002 | Operation failed. Cannot connect to service. |
| 2100003 | System internal error. |
| 2204002 | Callback not found. |
| 2204008 | Service instance duplicated. |
| 2204010 | Send packet failed. |
>**NOTE**
> For details about the error codes, see [mDNS Error Codes](../errorcodes/errorcode-net-mdns.md).
| context | Context | Yes | Application context.<br>For details about the application context of the FA model, see [Context](js-apis-inner-app-context.md).<br>For details about the application context of the stage model, see [Context](js-apis-inner-application-uiAbilityContext.md).|
| context | Context | Yes | Application context.<br>For details about the application context of the FA model, see [Context](js-apis-inner-app-context.md).<br>For details about the application context of the stage model, see [Context](js-apis-inner-application-uiAbilityContext.md).|
| serviceType | string | Yes | Type of the mDNS services to be discovered.|
| context | Context | Yes | Application context.<br>For details about the application context of the FA model, see [Context](js-apis-inner-app-context.md).<br>For details about the application context of the stage model, see [Context](js-apis-inner-application-uiAbilityContext.md).|
| callback | AsyncCallback\<[LocalServiceInfo](#localserviceinfo)> | Yes | Callback used to return the result. If the operation is successful, **error** is **undefined** and **data** is the mDNS service information. |
| context | Context | Yes | Application context.<br>For details about the application context of the FA model, see [Context](js-apis-inner-app-context.md).<br>For details about the application context of the stage model, see [Context](js-apis-inner-application-uiAbilityContext.md).|
| type | string | Yes |Event type. This field has a fixed value of **discoveryStart**.<br>**discoveryStart**: event of starting discovery of mDNS services on the LAN.|
| callback | Callback<{serviceInfo:[LocalServiceInfo](#localserviceinfo),errorCode?:[MDNS_ERR](#mdns_err)}> | Yes | Callback used to return the mDNS service and error information. |
| type | string | Yes |Event type. This field has a fixed value of **discoveryStop**.<br>**discoveryStop**: event of stopping discovery of mDNS services on the LAN.|
| callback | Callback<{serviceInfo:[LocalServiceInfo](#localserviceinfo),errorCode?:[MDNS_ERR](#mdns_err)}> | Yes | Callback used to return the mDNS service and error information. |
| serviceType | string | Yes| Type of the mDNS service. The value is in the format of **\_\<name>.\<tcp/udp>**, where **name** contains a maximum of 63 characters excluding periods (.). |
| serviceName | string | Yes| Name of the mDNS service. |
| port | number | No| Port number of the mDNS server. |
| host | [NetAddress](js-apis-net-connection.md#netaddress) | No| IP address of the device that provides the mDNS service. The IP address is not effective when an mDNS service is added or removed. |
The **power** module provides APIs for rebooting and shutting down the system, as well as querying the screen status.
> **NOTE**<br>
> **NOTE**
>
> The initial APIs of this module are supported since API version 7. Newly added APIs will be marked with a superscript to indicate their earliest API version.
## Modules to Import
...
...
@@ -33,7 +34,7 @@ Shuts down the system.
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
...
...
@@ -69,7 +70,7 @@ Reboots the system.
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
...
...
@@ -95,7 +96,7 @@ Checks whether the current device is active. In the active state, the screen is
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
...
...
@@ -130,7 +131,7 @@ Wakes up a device.
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
...
...
@@ -158,7 +159,7 @@ Hibernates a device.
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
...
...
@@ -190,7 +191,7 @@ Obtains the power mode of this device.
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
...
...
@@ -228,7 +229,7 @@ Sets the power mode of this device. This API uses an asynchronous callback to re
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
...
...
@@ -272,7 +273,7 @@ Sets the power mode of this device. This API uses a promise to return the result
For details about the error codes, see [Power Manager Error Codes](../errorcodes/errorcode-power.md).
| Code | Error Message |
| ID | Error Message |
|---------|---------|
| 4900101 | Operation failed. Cannot connect to service.|
> This API is deprecated since API version 9. You are advised to use [power.reboot](#powerreboot9) instead.
> **NOTE**<br>This API is supported since API version 7 and is deprecated since API version 9. You are advised to use [power.reboot](#powerreboot9). The substitute API is available only for system applications.
| callback | AsyncCallback<boolean> | Yes | Callback used to return the result. If the operation is successful, **err** is **undefined** and **data** is the screen status obtained, where the value **true** indicates on and the value **false** indicates the opposite. Otherwise, **err** is an error object.|
| callback | AsyncCallback<boolean> | Yes | Callback used to return the result. If the operation is successful, **err** is **undefined** and **data** is the screen status obtained, where the value **true** indicates on and the value **false** indicates off. Otherwise, **err** is an error object.|
The **brightness** module provides APIs for querying and adjusting the screen brightness and mode.
> **NOTE**
> - The APIs of this module are no longer maintained since API version 7. It is recommended that you use [`@ohos.brightness`](js-apis-brightness.md) instead.
>
> - The APIs of this module are no longer maintained since API version 7. You are advised to use APIs of [`@ohos.brightness`](js-apis-brightness.md). The substitute APIs are available only for system applications.
> - The initial APIs of this module are supported since API version 3. Newly added APIs will be marked with a superscript to indicate their earliest API version.
The cellular data module provides basic mobile data management functions. You can obtain and set the default slot of the SIM card used for mobile data, and obtain the uplink and downlink connection status of cellular data services and connection status of the packet switched (PS) domain. Besides, you can check whether cellular data services and data roaming are enabled.
The **data** module provides basic mobile data management functions. You can obtain and set the default slot of the SIM card used for mobile data, and obtain the uplink and downlink connection status of cellular data services and connection status of the packet switched (PS) domain. Besides, you can check whether cellular data services and data roaming are enabled.
>**NOTE**
>
...
...
@@ -24,7 +24,7 @@ Obtains the default slot of the SIM card used for mobile data. This API uses an
| callback | AsyncCallback\<boolean\> | Yes | Callback used to return the result.<br>**true**: Roaming is enabled for the cellular data service.<br>**false**: Roaming is disabled for the cellular data service.|
**Error codes**
...
...
@@ -394,7 +394,7 @@ Checks whether roaming is enabled for the cellular data service. This API uses a
Neural Network Runtime (NNRt) functions as a bridge to connect the upper-layer AI inference framework and bottom-layer acceleration chips, implementing cross-chip inference computing of AI models.
With the open APIs provided by NNRt, chip vendors can connect their dedicated acceleration chips to NNRt to access the OpenHarmony ecosystem.
### Basic Concepts
Before you get started, it would be helpful for you to have a basic understanding of the following concepts:
- Hardware Device Interface (HDI): defines APIs for cross-process communication between services in OpenHarmony.
- Interface Description Language (IDL): defines the HDI language format.
### Constraints
- System version: OpenHarmony trunk version.
- Development environment: Ubuntu 18.04 or later.
- Access device: a chip with AI computing capabilities.
### Working Principles
NNRt connects to device chips through HDIs, which implement cross-process communication between services.
The NNRt architecture consists of three layers: AI applications at the application layer, AI inference framework and NNRt at the system layer, and device services at the chip layer. To use a dedicated acceleration chip model for inference, an AI application needs to call the dedicated acceleration chip at the bottom layer through the AI inference framework and NNRt. NNRt is responsible for adapting to various dedicated acceleration chips at the bottom layer. It opens standard and unified HDIs for various chips to access the OpenHarmony ecosystem.
During program running, the AI application, AI inference framework, and NNRt reside in the user process, and the underlying device services reside in the service process. NNRt implements the HDI client and the service side implements HDI Service to fulfill cross-process communication.
## How to Develop
### Application Scenario
Suppose you are connecting an AI acceleration chip, for example, RK3568, to NNRt. The following describes how to connect the RK3568 chip to NNRt through the HDI to implement AI model inference.
> **NOTE**<br>In this application scenario, the connection of the RK3568 chip to NNRt is implemented by utilizing the CPU operator of MindSpore Lite, instead of writing the CPU driver. This is the reason why the following development procedure depends on the dynamic library and header file of MindSpore Lite. In practice, the development does not depend on any library or header file of MindSpore Lite.
### Development Flowchart
The following figure shows the process of connecting a dedicated acceleration chip to NNRt.
**Figure 2** NNRt development flowchart
### Development Procedure
To connect the acceleration chip to NNRt, perform the development procedure below.
#### Generating the HDI Header File
Download the OpenHarmony source code from the open source community, build the `drivers_interface` component, and generate the HDI header file.
1.[Download the source code](../get-code/sourcecode-acquire.md).
> **NOTE**<br>**productname** indicates the product name. In this example, the product name is **RK3568**.
When the build is complete, the HDI header file is generated in `out/rk3568/gen/drivers/interface/nnrt`. The default programming language is C++. To generate a header file for the C programming language, run the following command to set the `language` field in the `drivers/interface/nnrt/v1_0/BUILD.gn` file before starting the build:
```shell
language = "c"
```
The directory of the generated header file is as follows:
├── iprepared_model.h # Header file of the AI model
├── libnnrt_proxy_1.0__notice.d
├── libnnrt_stub_1.0__notice.d
├── model_types.cpp # Implementation file for AI model structure definition
├── model_types.h # Header file for AI model structure definition
├── nnrt_device_driver.cpp # Device driver implementation example
├── nnrt_device_proxy.cpp
├── nnrt_device_proxy.h
├── nnrt_device_service.cpp # Implementation file for device services
├── nnrt_device_service.h # Header file for device services
├── nnrt_device_stub.cpp
├── nnrt_device_stub.h
├── nnrt_types.cpp # Implementation file for data type definition
├── nnrt_types.h # Header file for data type definition
├── node_attr_types.cpp # Implementation file for AI model operator attribute definition
├── node_attr_types.h # Header file for AI model operator attribute definition
├── prepared_model_proxy.cpp
├── prepared_model_proxy.h
├── prepared_model_service.cpp # Implementation file for AI model services
├── prepared_model_service.h # Header file for AI model services
├── prepared_model_stub.cpp
└── prepared_model_stub.h
```
#### Implementing the HDI Service
1. Create a development directory in `drivers/peripheral`. The structure of the development directory is as follows:
```text
drivers/peripheral/nnrt
├── BUILD.gn # Code build script
├── bundle.json
└── hdi_cpu_service # Customized directory
├── BUILD.gn # Code build script
├── include
│ ├── nnrt_device_service.h # Header file for device services
│ ├── node_functions.h # Optional, depending on the actual implementation
│ ├── node_registry.h # Optional, depending on the actual implementation
│ └── prepared_model_service.h # Header file for AI model services
└── src
├── nnrt_device_driver.cpp # Implementation file for the device driver
├── nnrt_device_service.cpp # Implementation file for device services
├── nnrt_device_stub.cpp # Optional, depending on the actual implementation
├── node_attr_types.cpp # Optional, depending on the actual implementation
├── node_functions.cpp # Optional, depending on the actual implementation
├── node_registry.cpp # Optional, depending on the actual implementation
└── prepared_model_service.cpp # Implementation file for AI model services
```
2. Implement the device driver. Unless otherwise required, you can directly use the `nnrt_device_driver.cpp` file generated in step 1.
3. Implement service APIs. For details, see the `nnrt_device_service.cpp` and `prepared_model_service.cpp` implementation files. For details about the API definition, see [NNRt HDI Definitions](https://gitee.com/openharmony/drivers_interface/tree/master/nnrt).
4. Build the implementation files for device drivers and services as shared libraries.
Create the `BUILD.gn` file with the following content in `drivers/peripheral/nnrt/hdi_cpu_service/`. For details about how to set related parameters, see [Compilation and Building](https://gitee.com/openharmony/build).
In the uhdf directory, declare the user-mode driver and services in the **.hcs** file of the corresponding product. For example, for the RK3568 chip, add the following configuration to the `vendor/hihope/rk3568/hdf_config/uhdf/device_info.hcs` file:
```text
nnrt :: host {
hostName = "nnrt_host";
priority = 50;
uid = "";
gid = "";
caps = ["DAC_OVERRIDE", "DAC_READ_SEARCH"];
nnrt_device :: device {
device0 :: deviceNode {
policy = 2;
priority = 100;
moduleName = "libnnrt_driver.z.so";
serviceName = "nnrt_device_service";
}
}
}
```
> **NOTE**<BR>After modifying the `.hcs` file, you need to delete the `out` directory and build the file again for the modification to take effect.
#### Configuring the User ID and Group ID of the Host Process
In the scenario of creating an nnrt_host process, you need to configure the user ID and group ID of the corresponding process. The user ID is configured in the `base/startup/init/services/etc/passwd` file, and the group ID is configured in the `base/startup/init/services/etc/group` file.
```text
# Add the user ID in base/startup/init/services/etc/passwd.
nnrt_host:x:3311:3311:::/bin/false
# Add the group ID in base/startup/init/services/etc/group.
nnrt_host:x:3311:
```
#### Configuring SELinux
The SELinux feature has been enabled for the OpenHarmony. You need to configure SELinux rules for the new processes and services so that they can run the host process to access certain resources and release HDI services.
1. Configure the security context of the **nnrt_host** process in the `base/security/selinux/sepolicy/ohos_policy/drivers/adapter/vendor/type.te` file.
```text
# Add the security context configuration.
type nnrt_host, hdfdomain, domain;
```
> **NOTE**<br>In the preceding command, **nnrt_host** indicates the process name previously configured.
2. Configure access permissions because SELinux uses the trustlist access permission mechanism. Upon service startup, run the `dmesg` command to view the AVC alarm,
which provides a list of missing permissions. For details about the SELinux configuration, see [security_selinux] (https://gitee.com/openharmony/security_selinux/blob/master/README-en.md).
The test report below shows that all 47 test cases are successful, indicating that the service has passed the compatibility test.
```text
...
[----------] Global test environment tear-down
Gtest xml output finished
[==========] 47 tests from 3 test suites ran. (515 ms total)
[ PASSED ] 47 tests.
```
### Development Example
For the complete demo code, see [NNRt Service Implementation Example](https://gitee.com/openharmony/ai_neural_network_runtime/tree/master/example/drivers).
1. Copy the `example/driver/nnrt` directory to `drivers/peripheral`.
```shell
cp-r example/driver/nnrt drivers/peripheral
```
2. Add the `bundle.json` file to `drivers/peripheral/nnrt`. For details about the `bundle.json` file, see [Development Procedure](#development-procedure).
3. Add the dependency files of MindSpore Lite because the demo depends on the CPU operator of MindSpore Lite.
- Download the header file of [MindSpore Lite 1.5.0](https://ms-release.obs.cn-north-4.myhuaweicloud.com/1.5.0/MindSpore/lite/release/linux/mindspore-lite-1.5.0-linux-x64.tar.gz).
1. Create the `mindspore` directory in `drivers/peripheral/nnrt`.
```shell
mkdir drivers/peripheral/nnrt/mindspore
```
2. Decompress the `mindspore-lite-1.5.0-linux-x64.tar.gz` file, and copy the `runtime/include` directory to `drivers/peripheral/nnrt/mindspore`.
3. Create and copy the `schema` file of MindSpore Lite.
HiCollie provides the software watchdog function. It provides a unified framework for fault detection and fault log generation to help you locate software timeout faults resulting from system service deadlock, application main thread blocking, and service process timeout.
## Available APIs<a name="section139261151145116"></a>
<tdclass="cellrowborder"valign="top"width="44.47555244475552%"headers="mcps1.2.4.1.3 "><pid="p18700175062115"><aname="p18700175062115"></a><aname="p18700175062115"></a>Provides the callback of the suspension detection result.</p>
<tdclass="cellrowborder"valign="top"width="44.47555244475552%"headers="mcps1.2.4.1.3 "><pid="p127630177475"><aname="p127630177475"></a><aname="p127630177475"></a>Provides the callback of the thread suspension detection result.</p>
<tdclass="cellrowborder"valign="top"width="35.82641735826417%"headers="mcps1.2.4.1.2 "><pid="p16289114074812"><aname="p16289114074812"></a><aname="p16289114074812"></a>void RegisterXCollieChecker(const sptr<XCollieChecker>&checker, unsigned int type)</p>
</td>
<tdclass="cellrowborder"valign="top"width="44.47555244475552%"headers="mcps1.2.4.1.3 "><pid="p186437319482"><aname="p186437319482"></a><aname="p186437319482"></a>Registers the callback of the thread suspension detection result.</p>
<aname="ul7783192181413"></a><aname="ul7783192181413"></a><ulid="ul7783192181413"><li><strongid="b64637561712"><aname="b64637561712"></a><aname="b64637561712"></a>checker</strong>: Indicates the pointer to the XCollieChecker instance.</li><li><strongid="b1947711661711"><aname="b1947711661711"></a><aname="b1947711661711"></a>type</strong>: Indicates the suspension detection type. Set it to <strongid="b259214119717"><aname="b259214119717"></a><aname="b259214119717"></a>XCOLLIE_THREAD</strong>.</li></ul>
<aname="ul845512153147"></a><aname="ul845512153147"></a><ulid="ul845512153147"><li><strongid="b44651010141715"><aname="b44651010141715"></a><aname="b44651010141715"></a>name</strong>: Indicates the timer name.</li><li><strongid="b266981221717"><aname="b266981221717"></a><aname="b266981221717"></a>timeout</strong>: Indicates the timeout duration, in seconds.</li><li><strongid="b17158171421710"><aname="b17158171421710"></a><aname="b17158171421710"></a>func</strong>: Indicates the timeout callback.</li><li><strongid="b1950162581810"><aname="b1950162581810"></a><aname="b1950162581810"></a>arg</strong>: Indicates the pointer to the timeout callback.</li><li><strongid="b4949151521714"><aname="b4949151521714"></a><aname="b4949151521714"></a>flag</strong>: Indicates the timer operation type.<pid="p1242762435310"><aname="p1242762435310"></a><aname="p1242762435310"></a>XCOLLIE_FLAG_DEFAULT // Indicates the default flag, which is the combination of the other three options.</p>
<pid="p1542712435312"><aname="p1542712435312"></a><aname="p1542712435312"></a>XCOLLIE_FLAG_NOOP // Calls only the timeout callback.</p>
<pid="p15427112416531"><aname="p15427112416531"></a><aname="p15427112416531"></a>XCOLLIE_FLAG_LOG // Generates a timeout fault log.</p>
<pid="p242762455314"><aname="p242762455314"></a><aname="p242762455314"></a>XCOLLIE_FLAG_RECOVERY // Exits the process.</p>
<pid="p144271424155316"><aname="p144271424155316"></a><aname="p144271424155316"></a>Return value: Returns the timer ID if the operation is successful; returns <strongid="b2229713291"><aname="b2229713291"></a><aname="b2229713291"></a>-1</strong> otherwise.</p>
<aname="ul1628783221411"></a><aname="ul1628783221411"></a><ulid="ul1628783221411"><li><strongid="b61651021161710"><aname="b61651021161710"></a><aname="b61651021161710"></a>id</strong>: Indicates the timer ID.</li><li><strongid="b24661423141717"><aname="b24661423141717"></a><aname="b24661423141717"></a>timeout</strong>: Indicates the timeout duration, in seconds.</li></ul>
<pid="p38311853105716"><aname="p38311853105716"></a><aname="p38311853105716"></a>Return value: Returns <strongid="b95701352192819"><aname="b95701352192819"></a><aname="b95701352192819"></a>true</strong> if the operation is successful; returns <strongid="b175761652152814"><aname="b175761652152814"></a><aname="b175761652152814"></a>false</strong> otherwise.</p>
<pid="p9311488283"><aname="p9311488283"></a><aname="p9311488283"></a><strongid="b9666749171816"><aname="b9666749171816"></a><aname="b9666749171816"></a>id</strong>: Indicates the timer ID.</p>
This function requires you to implement two callback functions: **CheckBlock** and **CheckThreadBlock** of the **XCollieChecker** class. After the callbacks are implemented, you need to use the **RegisterXCollieChecker** function of the **XCollie** class to register their instances. The suspension monitoring thread periodically executes all successfully registered callbacks, checks the thread logic completion flag, and determines whether the service logic of any registered thread is suspended.
1. Develop the source code.
Include the **xcollie** header file in the source file.
```
#include "xcollie.h"
```
Add the following code to the service code:
```
void MyXCollieChecker::CheckLock()
{
/* time consuming job */
}
void MyXCollieChecker::CheckThreadBlock()
{
/* time consuming job */
}
sptr<XCollieChecker> checker = new MyXCollieChecker("MyXCollieChecker");
You can add a maximum of 128 timers for a single process by using the **SetTimer** function. Adding timers will fail if the number of timers has reached the upper limit.
1. Develop the source code.
Include the **xcollie** header file in the source file.
int id = XCollie::GetInstance().SetTimer("MyXCollieTimer", 10, callback ,nullptr, XCOLLIE_FLAG_LOG);
/* time consuming job */
XCollie::GetInstance().UpdateTimer(id, 5);
/* time consuming job */
XCollie::GetInstance().CancelTimer(id);
...
```
## Overview
2. Configure compilation information. Specifically, add the subsystem SDK dependency to **BUILD.gn**.
```
external_deps = [ "hiviewdfx:libxcollie" ]
```
HiCollie provides the software watchdog function. It provides a unified framework for fault detection and fault log generation to help you locate software timeout faults resulting from system service deadlock, application main thread blocking, and service process timeout.
## Available APIs
**Table 1** Description of XCollieChecker APIs
| API| Description|
| -------- | -------- |
| virtual void CheckBlock() | Provides the callback of the suspension detection result.<br>Input arguments: none<br>Output arguments: none<br>Return value: none|
| virtual void CheckThreadBlock() | Provides the callback of the thread suspension detection result.<br>Input arguments: none<br>Output arguments: none<br>Return value: none|
**Table 2** Description of XCollie APIs
| API| Description|
| -------- | -------- |
| void RegisterXCollieChecker(const sptr<XCollieChecker>&checker, unsigned int type) | Registers the callback of the thread suspension detection result.<br>Input arguments:<br>- **checker**: pointer to the XCollieChecker instance.<br>- **type**: suspension detection type. Set it to **XCOLLIE_THREAD**.<br>Output arguments: none<br>Return value: none|
| int SetTimer(const std::string &name, unsigned int timeout, std::function<void(void*)> func, void *arg, unsigned int flag) | Adds timers.<br>Input arguments:<br>- **name**: timer name.<br>- **timeout**: timeout duration, in seconds.<br>- **func**: timeout callback.<br>- **arg**: pointer to the timeout callback.<br>- **flag**: timer operation type.<br> - **XCOLLIE_FLAG_DEFAULT**: default flag, which is the combination of the other three options.<br> - **XCOLLIE_FLAG_NOOP**: Calls only the timeout callback.<br> - **XCOLLIE_FLAG_LOG**: Generates a timeout fault log.<br> - **XCOLLIE_FLAG_RECOVERY**: Exits the process.<br>Output arguments: none<br>Return value: timer ID if the operation is successful; **-1** otherwise.|
| bool UpdateTimer(int id, unsigned int timeout) | Updates timers.<br>Input arguments:<br>- **id**: timer ID.<br>- **timeout**: timeout duration, in seconds.<br>Output arguments: none<br>Return value: **true** if the operation is successful; **false** otherwise.|
This function requires you to implement two callback functions: **CheckBlock** and **CheckThreadBlock** of the **XCollieChecker** class. After the callbacks are implemented, you need to use the **RegisterXCollieChecker** function of the **XCollie** class to register their instances. The suspension monitoring thread periodically executes all successfully registered callbacks, checks the thread logic completion flag, and determines whether the service logic of any registered thread is suspended.
1. Develop the source code.
Include the **xcollie** header file in the source file.
```
#include "xcollie.h"
```
Add the following code to the service code:
```
void MyXCollieChecker::CheckLock()
{
/* time consuming job */
}
void MyXCollieChecker::CheckThreadBlock()
{
/* time consuming job */
}
sptr<XCollieChecker> checker = new MyXCollieChecker("MyXCollieChecker");
2. Configure compilation information. Specifically, add the subsystem SDK dependency to **BUILD.gn**.
```
external_deps = [ "hiviewdfx:libxcollie" ]
```
### Timeout Monitoring
You can add a maximum of 128 timers for a single process by using the **SetTimer** function. Adding timers will fail if the number of timers has reached the upper limit.
1. Develop the source code.
Include the **xcollie** header file in the source file.
HiDumper is a tool provided by OpenHarmony for developers, testers, and IDE tool engineers to obtain system information necessary for analyzing and locating faults. This section applies only to the standard system.
### Source Code Directories
## Source Code Directories
```
/base/hiviewdfx/hidumper
├── frameworks # Framework code
│ ├── native # Core function code
│ │ │── include # Header files
│ │ │── include # Header files
│ │ │── src # Source files
│ │ │── common # Common function code
│ │ │── executor # Process executor code
...
...
@@ -34,14 +31,14 @@ HiDumper is a tool provided by OpenHarmony for developers, testers, and IDE tool
```
## Usage
# Usage
### Command-Line Options
## Command-Line Options
**Table 1** HiDumper command-line options
| Option| Description|
| Option| **Description**|
| -------- | -------- |
| -h | Shows the help Information.|
| -t [timeout] | Specifies the timeout period, in seconds. The default value is **30**. Value **0** indicates no timeout limit.|
...
...
@@ -56,14 +53,14 @@ HiDumper is a tool provided by OpenHarmony for developers, testers, and IDE tool
| --net | Exports network information.|
| --storage | Exports storage information.|
| -p | Exports the process list and all process information.|
| -p [pid] | Exports all information about a specified process.|
| --cpuusage [pid] | Exports the CPU usage information based on **pid**.|
| -p [pid] | Exports all information about the specified process.|
| --cpuusage [pid] | Exports the CPU usage information. If **pid** is specified, the CPU usage of the corresponding process is exported.|
| --cpufreq | Exports the actual CPU frequency.|
| --mem [pid] | Exports the memory usage information based on **pid**.|
| --mem [pid] | Export memory usage information. If **pid** is specified, the memory usage of the corresponding process is exported.|
| --zip | Compresses the exported information to a specified folder.|
### Development Example
## Development Example
HiDumper helps you export basic system information to locate and analyze faults. Complex parameters passed to sub-services and abilities must be enclosed in double quotation marks.
...
...
@@ -118,7 +115,7 @@ The procedure is as follows:
hidumper -s 3008
```
9. Run the **hidumper -e** command to obtain the crash information generated by the FaultLogger module.
9. Run the **hidumper -e** command to obtain the crash information generated by the FaultLoger module.
```
hidumper -e
...
...
@@ -148,7 +145,7 @@ The procedure is as follows:
hidumper -p 1024
```
14. Run the **hidumper --cpuusage [pid]** command to obtain the CPU usage information of the process whose PID has been specified.
14. Run the **hidumper --cpuusage [pid]** command to obtain the CPU usage information. If the PID of a process is specified, only the CPU usage of the process is returned.
```
hidumper --cpuusage
...
...
@@ -161,7 +158,7 @@ The procedure is as follows:
hidumper --cpufreq
```
16. Run the **hidumper --mem [pid]** command to obtain all memory usage information of the process whose PID has been specified.
16. Run the **hidumper --mem [pid]** command to obtain all memory usage information. If the PID of a process is specified, only the memory usage of the process is returned.
@@ -146,9 +146,7 @@ Some built-in communication mechanisms (such as ZIDL) of OpenHarmony already sup
The following figure shows the process of transferring **traceid** in synchronous call. The process of transferring **traceid** in asynchronous call is similar.
Extended communication mechanisms can also follow this implementation.
**Figure 5** Call chain trace in synchronous communication
