Checks whether the specified rule exists in the collection of added rules. If the rule is of the thread level, this operation is performed only on the current thread.
> **NOTE**<br>This API is deprecated since API version 9. You are advised to use [hichecker.containsCheckRule](#hicheckercontainscheckrule9) instead.
Checks whether the specified rule exists in the collection of added rules. If the rule is of the thread level, this operation is performed only on the current thread.
| INCLUDE_ASYNC | 1 | Asynchronous call flag. By default, only synchronous calls are traced. If this flag is set, both synchronous and asynchronous calls will be traced. |
The Input Consumer module implements listening for key events.
The Input Consumer module implements listening for combination key events.
> **NOTE**
>
> - The initial APIs of this module are supported since API version 8. Newly added APIs will be marked with a superscript to indicate their earliest API version.
>
> - The APIs of this module are system APIs and cannot be called by third-party applications.
> - The APIs provided by this module are system APIs.
Enables listening for combination key events. When a combination key event that meets the specified conditions occurs, **keyOptions** will be passed as an input parameter to **callback**.
This is a system API.
Enables listening for combination key events. This API uses an asynchronous callback to return the combination key data when a combination key event that meets the specified condition occurs.
| type | string | Yes| Type of the key input event to listen for. Only **key** is supported.|
| keyOptions | [keyOptions](#keyoptions) | Yes| Key option, which specifies the condition for combination key input.|
| callback | Callback<KeyOptions> | Yes| Callback used to return the result.<br> When a key input event that meets the specified options occurs, **keyOptions** will be passed as an input parameter to **callback**.|
| callback | Callback<KeyOptions> | Yes | Callback used to return the combination key data when a combination key event that meets the specified condition occurs.|
| callback | Callback<KeyOptions> | No | Callback for which listening is disabled. If this parameter is not specified, listening will be disabled for all callbacks registered by the current application.|
**Example**
```js
letleftAltKey=2045;
lettabKey=2049;
// Disable listening for a single callback function.
| preKeys | Array | Yes| Array of precedent keys. This parameter can be left empty. There is no requirement on the sequence of precedent keys.|
| finalKey | Number | Yes| Final key in the combination key. This parameter cannot be left blank.|
| isFinalKeyDown | boolean | Yes| Whether the final key is pressed or released. By default, the final key is pressed.|
| finalKeyDownDuration | Number | Yes| Duration for pressing the final key. By default, there is no requirement on the duration.|
| Name | Type | Readable | Writable | Description |
| --------- | ------ | ---- | ---- | ------- |
| preKeys | Array\<number> | Yes | No| Front key set. The number of front keys ranges from 0 to 4. There is no requirement on the sequence of the keys.|
| finalKey | number | Yes | No| Final key. This parameter is mandatory. A callback function is triggered by the final key.|
| isFinalKeyDown | boolean | Yes | No| Whether the final key is pressed.|
| finalKeyDownDuration | number | Yes | No| Duration within which the final key is pressed. If the value is **0**, the callback function is triggered immediately. If the value is greater than **0** and the value of **isFinalKeyDown** is **true**, the callback function is triggered when the key press duration is longer than the value of this parameter. If the value of **isFinalKeyDown** is **false**, the callback function is triggered when the duration from key press to key release is less than the value of this parameter. |
The Key Injection module implements injection of key events.
> **NOTE**<br>
> **NOTE**
>
> - The initial APIs of this module are supported since API version 8. Newly added APIs will be marked with a superscript to indicate their earliest API version.
>
> - The APIs of this module are system APIs and cannot be called by third-party applications.
> - The APIs provided by this module are system APIs.
## Modules to Import
...
...
@@ -21,9 +21,7 @@ import inputEventClient from '@ohos.multimodalInput.inputEventClient';
injectEvent({KeyEvent: KeyEvent}): void
Injects a key event.
This is a system API.
Injects a key event. Currently, key injection is supported only for the **Back** key (key value 2).
The Input Monitor module implements listening for global touch events.
The Input Monitor module implements listening for events of input devices (namely, touchscreen and mouse).
> **NOTE**<br>
> - 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.
> **NOTE**
>
> - The APIs of this module are system APIs and cannot be called by third-party applications.
> - 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.
>
> - The APIs provided by this module are system APIs.
## Modules to Import
...
...
@@ -16,80 +17,73 @@ import inputMonitor from '@ohos.multimodalInput.inputMonitor';
| type | string | Yes | Type of the input device event. The value is **touch**.|
| receiver | [TouchEventReceiver](#toucheventreceiver) | No | Callback for which listening is disabled. If this parameter is not specified, listening will be disabled for all callbacks registered by the current application. |
**Example**
**Example**
```js
// Disable listening globally.
// Disable listening for a single callback function.
functioncallback(touchEvent){
console.log(`Monitor on success ${JSON.stringify(touchEvent)}`);
| type | string | Yes | Type of the input device event. The value is **mouse**.|
| receiver | Callback<MouseEvent> | No | Callback for which listening is disabled. If this parameter is not specified, listening will be disabled for all callbacks registered by the current application.|
**Example**
```js
// Disable listening globally.
// Disable listening for a single callback.
functioncallback(mouseEvent){
console.log(`Monitor on success ${JSON.stringify(mouseEvent)}`);
| Boolean | Result indicating whether the touch event has been consumed by the input monitor. The value **true** indicates that the touch event has been consumed, and the value **false** indicates the opposite.|
| Boolean | Result indicating whether the touch event will be dispatched to the window. The value **true** indicates that the touch event will be dispatched to the window, and the value **false** indicates the opposite.|
**Example**
**Example**
```js
try{
inputMonitor.on("touch",(event)=>{
// If true is returned, all subsequent events of this operation will be consumed by the listener, instead of being distributed to the window.
returnfalse;
inputMonitor.on("touch",touchEvent=>{
if(touchEvent.touches.length==3){// Three fingers are pressed.
The Key Event module provides key events reported by an input device.
Represents key events reported by an input device.
> **NOTE**<br>
> **NOTE**
>
> The initial APIs of this module are supported since API version 9. Newly added APIs will be marked with a superscript to indicate their earliest API version.
Represents mouse events reported by an input device.
> **NOTE**<br>
> **NOTE**
> The initial APIs of this module are supported since API version 9. Newly added APIs will be marked with a superscript to indicate their earliest API version.
## Modules to Import
...
...
@@ -15,75 +15,75 @@ import {Action,Button,Axis,AxisValue,MouseEvent} from '@ohos.multimodalInput.mou
| screenX | number | Yes| No| X coordinate of the mouse pointer on the screen.|
| screenY | number | Yes| No| Y coordinate of the mouse pointer on the screen.|
| windowX | number | Yes| No| X coordinate of the mouse pointer in the window.|
| windowY | number | Yes| No| Y coordinate of the mouse pointer in the window.|
| rawDeltaX | number | Yes| No| X axis offset relative to the previous reported mouse pointer position. When the mouse pointer is at the edge of the screen, the value may be less than the difference of the X coordinate reported twice.|
| rawDeltaY | number | Yes| No| Y axis offset relative to the previous reported mouse pointer position.|
| button | Button | Yes| No| Button that is currently pressed or released.|
| pressedButtons | Button[] | Yes| No| Button that is being pressed.|
| axes | AxisValue[] | Yes| No| All axis data contained in the event.|
| pressedKeys | KeyCode[] | Yes| No| List of pressed keys.|
| ctrlKey | boolean | Yes| No| Whether ctrlKey is being pressed.|
| altKey | boolean | Yes| No| Whether altKey is being pressed.|
| shiftKey | boolean | Yes| No| Whether shiftKey is being pressed.|
| logoKey | boolean | Yes| No| Whether logoKey is being pressed.|
| fnKey | boolean | Yes| No| Whether fnKey is being pressed.|
| callback | AsyncCallback\<boolean\> | Yes | Callback used to return the result.<br>- **true**: The cellular data service is enabled.<br>- **false**: The cellular data service is disabled.|
| callback | AsyncCallback\<boolean\> | Yes | Callback used to return the result.<br>**true**: The cellular data service is enabled.<br>**false**: The cellular data service is disabled.|
**Example**
...
...
@@ -280,7 +273,7 @@ Checks whether the cellular data service is enabled. This API uses a promise to
| Promise\<boolean\> | Promise used to return the result.<br>- **true**: The cellular data service is enabled.<br>- **false**: The cellular data service is disabled.|
| Promise\<boolean\> | Promise used to return the result.<br>**true**: The cellular data service is enabled.<br>**false**: The cellular data service is disabled.|
| callback | AsyncCallback\<boolean\> | Yes | Callback used to return the result.<br>- **true**: The cellular data roaming service is enabled. <br>- **false**: The cellular data roaming service is disabled. |
| 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.|
| Promise\<boolean\> | Promise used to return the result.<br>- **true**: The cellular data roaming service is enabled.<br>- **false**: The cellular data roaming service is disabled.|
| Promise\<boolean\> | Promise 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.|
**Example**
...
...
@@ -585,7 +578,6 @@ promise.then((data) => {
});
```
## DataFlowType
Defines the cellular data flow type.
...
...
@@ -602,14 +594,14 @@ Defines the cellular data flow type.
## DataConnectState
Describes the connection status of a cellular data connection.
Describes the connection status of a cellular data link.
With the rapid development of device systems, it has become a critical challenge for device vendors to help their users to access system updates in a timely manner to experience the new features and improve the system stability and security.
With the rapid development of device systems, it has become a critical challenge for device vendors to help their users to access system updates in a timely manner to experience the new features and improve the system stability and security
Over the Air (OTA) answers this challenge with the support for remote updating of device systems. By providing unified update APIs externally, the update subsystem shields the differences of underlying chips. After secondary development based on the update APIs, device vendors can easily implement remote updating for their devices, such as IP cameras.
...
...
@@ -18,51 +18,48 @@ Over the Air (OTA) answers this challenge with the support for remote updating o
- Differential package: an update package that packs the differential images between the source version and target version.
### Implementation Principle
### Principles
To implement an OTA update, you first need to use the packaging tool to pack the build version into an update package and upload the update package to the OTA server. Devices integrating the OTA update capability can then detect the update package and download it to implement a remote update.
<ahref="#ab-update-scenario">A/B Update</a>: a typical application of OTA update. In this update mode, a device has a backup system B. When system A is running, system B is updated silently. After the update is successful, the device restarts and switches to the new system.
<ahref="#ab-update">A/B Update</a>: a typical application of OTA update. In this update mode, a device has a backup system B. When system A is running, system B is updated silently. After the update is successful, the device restarts and switches to the new system.
### Constraints
- Only the open-source suites for devices powered by Hi3861, Hi3518E V300, and Hi3516D V300 are supported.
- Only the open-source suites for devices powered by Hi3861, Hi3516D V300, and RK3568 are supported.
- Devices developed based on Hi3518E V300 and Hi3516D V300 must support the SD card in the Virtual Festival of Aerobatic Teams (VFAT) format.
- Devices developed based on Hi3516D V300 and RK3568 must support the SD card in the Virtual Festival of Aerobatic Teams (VFAT) format.
- Generation of update packages can only be performed on the Linux system.
- Currently, the mini and small systems support update using a full package, but not a differential package or an update package with partitions changed.
- To implement an A/B update, ensure that the devices running the standard system support booting from partitions A and B.
## Environment Preparation
## Preparations
- On Windows, download and install the OpenSSL tool and configure environment variables.
- Prepare the packaging tool.
- Build version images using the packaging tool.
- On Linux, pack version images to generate the update package.
- To implement an A/B update, ensure that the devices running the standard system support booting from partitions A and B.
## OTA Update Guide
## How to Develop
### Development Procedure
<ahref="#generating-a-publicprivate-key-pair">1. Use the OpenSSL tool to generate a public/private key pair.
<ahref="#generating-a-public/private-key-pair">1. Use the OpenSSL tool to generate a public/private key pair.
<ahref="#making-an-update-package">2. Use the packaging tool to generate an update package.</a>
  <ahref="#mini-and-small-systems">2.1 Mini and small systems</a>
  <ahref="#mini-and-smallsystems">2.1 Mini and small systems</a>
  <ahref="#standard-system">2.2 Standard system</a>
  <ahref="#standardsystem">2.2 Standard system</a>
<ahref="#uploading-the-update-package">3. Upload the update package to the vendor's OTA server.</a>
<ahref="#uploading-the-updatepackage">3. Upload the update package to the vendor's OTA server.</a>
<ahref="#downloading-the-update-package">4. Download the update package from the vendor's OTA server.</a>
<ahref="#integrating-ota-update-capabilities">5. Integrate the OTA update capability.
<ahref="#integrating-the-OTA-update-capability">5. Integrate the OTA update capability.
  <ahref="#api-application-scenario-default">5.1 API application scenario (default)</a>
...
...
@@ -71,31 +68,33 @@ To implement an OTA update, you first need to use the packaging tool to pack the
1. Use the OpenSSL tool to generate a public/private key pair.
3. Keep the private key file properly as this file stores the private key used to sign the update package. You need to specify the private key file in the command used for preparing the update package. The public key is used to verify the signature of the update package during the update. For the mini and small systems, the generated public key is preset in the code. You need to implement the **HotaHalGetPubKey** API to obtain the key. For the standard system, the generated public key is stored in the **./device/hisilicon/hi3516dv300/build/updater_config/signing_cert.crt** file.
3. Keep the private key file properly as this file stores the private key used to sign the update package. You need to specify the private key file in the command used for preparing the update package. The public key is used to verify the signature of the update package during the update. For the mini and small systems, the generated public key is preset in the code. The vendor needs to implement the **HotaHalGetPubKey** API to obtain the key. For the standard system, the generated public key is stored in the **/hisilicon/hi3516dv300/build/updater\_config/signing\_cert.crt** file in the **device** or **vendor** directory.
5. For the mini and small systems that use the Hi3518E V300 or Hi3516D V300 suite, use the content in **public\_arr.txt** to replace the content in **g\_pub\_key** in the **device\hisilicon\third_party\uboot\u-boot-2020.01\product\hiupdate\verify\update\_public\_key.c** file of the U-Boot module.
5. For the mini and small systems that use the Hi3516D V300 suite, use the content in **third\_party\u-boot\u-boot-2020.01\product\hiupdate\verify\update\_public\_key.c** file of the U-Boot module.
Example configuration:
```c
staticunsignedcharg_pub_key[PUBKEY_LEN]={
staticunsignedcharg_pub_key[]={
0x30,0x82,0x01,0x0A,0x02,0x82,0x01,0x01,
0x00,0xBF,0xAA,0xA5,0xB3,0xC2,0x78,0x5E,
}
```
#### Making an Update Package
### Making an Update Package
##### Mini and Small Systems
#### Mini and Small Systems
1. Create the **target\_package** folder with the following directory structure:
OTA.tag and config are not required for lightweight systems and small systems upgraded from AB.
```text
target_package
...
...
@@ -103,16 +102,15 @@ To implement an OTA update, you first need to use the packaging tool to pack the
├── config
├── {component_1}
├── {component_2}
├── ...
├── ......
├── {component_N}
└── updater_config
└── updater_specified_config.xml
```
2. Place the components to be updated, including the image file (for example, **rootfs.img**), as **{component\_N}** in the root directory of the **target\_package** folder.
2. Place the components to be updated, including the image file (for example, **rootfs.img**), as the substitute of **{component\_N}** in the root directory of the **target\_package** folder.
3. Configure the **updater\_specified\_config.xml** file in the **updater_config** folder.
Example configuration:
...
...
@@ -130,17 +128,16 @@ To implement an OTA update, you first need to use the packaging tool to pack the
</package>
```
**Table 1** Description of nodes in the component configuration file
**Table 1** Description of nodes in the component configuration file
| Header information (head node)| info| / | Yes| Content of this node: head info|
| Header information (head node)| info| fileVersion | Yes| This field is reserved and does not affect the generation of the update package.|
| Header information (head node)| info| prdID | Yes| This field is reserved and does not affect the generation of the update package.|
| Header information (head node)| info| softVersion | Yes| Software version number, that is, the version number of the update package. The version number must be within the range specified by **VERSION.mbn**. Otherwise, an update package will not be generated.|
| Header information (head node)| info| date| Yes| Date when the update package is generated. This field is reserved and does not affect the generation of the update package.|
| Header information (head node)| info| time| Yes| Time when the update package is generated. This field is reserved and does not affect the generation of the update package.|
| Header information (head node)| info| softVersion | Yes| Software version number, that is, the version number of the update package. Ensure that the version number is later than the basic version number and OpenHarmony is not followed by any other letter. Otherwise, the update cannot be performed.|
| Header information (head node)| info| *date*| Yes| Date when the update package is generated. This field is reserved and does not affect the generation of the update package.|
| Header information (head node)| info| *time* | Yes| Time when the update package is generated. This field is reserved and does not affect the generation of the update package.|
| Component information (group node)| component| / | Yes| Content of this node: path of the component or image file to be packed into the update package. It is the root directory of the version package by default.|
| Component information (group node)| component| compAddr | Yes| Name of the partition corresponding to the component, for example, **system** or **vendor**.|
| Component information (group node)| component| compId | Yes| Component ID, which must be unique.|
...
...
@@ -180,8 +177,7 @@ To implement an OTA update, you first need to use the packaging tool to pack the
- -**nl2**: non-standard system mode
##### Standard System
#### Standard System
1. Create the **target\_package** folder with the following directory structure:
...
...
@@ -189,7 +185,7 @@ To implement an OTA update, you first need to use the packaging tool to pack the
target_package
├── {component_1}
├── {component_2}
├── ...
├── ......
├── {component_N}
└── updater_config
├── BOARD.list
...
...
@@ -197,7 +193,11 @@ To implement an OTA update, you first need to use the packaging tool to pack the
└── updater_specified_config.xml
```
2. Place the components to be updated, including the image file (for example, **system.img**), as **{component\_N}** in the root directory of the **target\_package** folder.
2. Place the components to be updated, including their image file and **updater_binary** file, as the substitute of **{component\_N}** in the root directory of the **target\_package** folder.
Take RK3568 as an example. Place the image file in the following build directory: out/rk3568/packages/phone/images/.
Place the **updater_binary** file in the following build directory: out/rk3568/packages/phone/system/bin/.
3. Configure the component configuration file in the **updater\_config** folder.
...
...
@@ -208,9 +208,11 @@ To implement an OTA update, you first need to use the packaging tool to pack the
```text
HI3516
HI3518
RK3568
```
Vendors can configure **Local BoardId** by calling **GetLocalBoardId()** in the **base/updater/updater/utils/utils.cpp** file. Ensure that **Local BoardId** configured in the **utils.cpp** file is present in **BOARD.list**. Otherwise, the update cannot be performed.
5. Configure the versions supported by the current update package in **VERSION.mbn** in the **updater\_config** folder.
Version number format: Hi3516DV300-eng 10 QP1A.XXXXXX.{Major version number (6 digits)}.XXX{Minor version number (3 digits)}
...
...
@@ -223,10 +225,11 @@ To implement an OTA update, you first need to use the packaging tool to pack the
```text
Hi3516DV300-eng 10 QP1A.190711.001
Hi3516DV300-eng 10 QP1A.190711.020
Hi3518DV300-eng 10 QP1A.190711.021
```
6. For an update using the incremental (differential) package, also prepare a source version package (source\_package) in the same format as the target version package (target\_package), and then compress it as a **.zip** file, that is, **source\_package.zip**.
Ensure that the basic version number is contained in **VERSION.mbn**.
6. For update using an incremental (differential) package, also prepare a source version package (source\_package) in the same format as the target version package (target\_package), and then compress it as a **.zip** file, that is, **source\_package.zip**.
7. If you create an update package with partitions changed, also provide the partition table file named **partition\_file.xml**. You can specify the file using the **-pf** parameter. For details about the configuration nodes, see the description below.
...
...
@@ -243,8 +246,8 @@ To implement an OTA update, you first need to use the packaging tool to pack the
**Table 2** Description of labels in the partition table
| Name | Description |
| ---- | ----------- |
| Name| Description|
| -------- | -------- |
| Sel | Whether the partition is effective. The value **1** indicates that the partition is effective, and value **0** indicates the opposite.|
| PartitionName | Partition name, for example, **fastboot** or **boot**.|
| FlashType | Flash type, for example, **emmc** or **ufs**.|
...
...
@@ -266,7 +269,7 @@ To implement an OTA update, you first need to use the packaging tool to pack the
-**./target\_package/**: path of **target\_package**
-**./output\_package/**: output path of the update package
- -**pk ./rsa\_private\_key3072.pem**: path of the private key file
- -**pk ./rsa\_private\_key2048.pem**: path of the private key file
**Incremental (differential) package**
...
...
@@ -280,7 +283,7 @@ To implement an OTA update, you first need to use the packaging tool to pack the
-**./target\_package/**: path of **target\_package**
-**./output\_package/**: output path of the update package
- -**s ./source\_package.zip**: path of the **source\_package.zip** file. For update using a differential package, use the **-s** parameter to specify the source version package.
- -**pk ./rsa\_private\_key3072.pem**: path of the private key file
- -**pk ./rsa\_private\_key2048.pem**: path of the private key file
**Update package with partitions changed**
...
...
@@ -291,42 +294,42 @@ To implement an OTA update, you first need to use the packaging tool to pack the
-**./target\_package/**: path of **target_package**
-**./target\_package/**: path of **target\_package**
-**./output\_package/**: output path of the update package
- -**pk ./rsa\_private_key3072.pem**: path of the private key file
- -**pk ./rsa\_private\_key2048.pem**: path of the private key file
- -**pf ./partition\_file.xml**: path of the partition table file
#### **Uploading the Update Package**
### Uploading the Update Package
Upload the update package to the vendor's OTA server.
#### **Downloading the Update Package**
### **Downloading the Update Package**
1. Download the update package from the OTA server.
2. (Optional) Insert an SD card (with a capacity greater than 100 MB) if the device is developed based on Hi3518E V300 or Hi3516D V300.
2. (Optional) Insert an SD card (with a capacity greater than 100 MB) if the device is developed based on Hi3516D V300.
#### Integrating OTA Update Capabilities
### Integrating OTA Update Capabilities
1. For mini and small systems
- Call the dynamic library **libhota.so**. The corresponding header files **hota\_partition.h** and **hota\_updater.h** are located in **base\update\sys_installer_lite\interfaces\kits**.
- The **libhota.so** source code is located in **base\update\sys_installer_lite\frameworks\source**.
- Call the dynamic library **libhota.so**. The corresponding header files **hota\_partition.h** and **hota\_updater.h** are located in **base\update\sys\_installer\_lite\interfaces\kits\**.
- The **libhota.so** source code is located in **base\update\sys\_installer\_lite\frameworks\source**.
- For details about how to use APIs, see *API Application Scenarios* and update APIs in *API Reference*.
- If the development board needs to be adapted, see the **base\update\sys_installer_lite\hals\hal\_hota\_board.h** file.
- If the development board needs to be adapted, see the **base\update\sys\_installer\_lite\hals\hal\_hota\_board.h** file.
2. For the standard system, see the [JS API Reference](../../application-dev/reference/apis/js-apis-update.md) for details.
##### API Application Scenario (Default)
#### API Application Scenario (Default)
The update package is generated by following the instructions provided in Generating a Public/Private Key Pair and Generating an Update Package.
###### How to Develop
##### How to Develop
1. Download the update package for the current device, and then call the **HotaInit** function to initialize the OTA module.
...
...
@@ -335,7 +338,7 @@ The update package is generated by following the instructions provided in Genera
3. Call the **HotaRestart** function to restart the system for the update to take effect. Call the **HotaCancel** function if you want to cancel the update.
###### Sample Code
##### Sample Code
Perform an OTA update using the update package format and verification method provided by OpenHarmony.
...
...
@@ -390,12 +393,12 @@ int main(int argc, char **argv)
```
##### API Application Scenario (Custom)
#### API Application Scenario (Custom)
The update package is generated in other ways instead of following the instructions provided in "Generating a Public/Private Key Pair" and "Generating an Update Package."
###### How to Develop
##### **How to Develop**
1. Download the update package for the current device, and then call the **HotaInit** function to initialize the OTA module.
...
...
@@ -410,7 +413,7 @@ The update package is generated in other ways instead of following the instructi
6. Call the **HotaRestart** function to restart the system for the update to take effect. Call the **HotaCancel** function if you want to cancel the update.
###### Sample Code
##### Sample Code
Perform an OTA update using the update package format and verification method not provided by OpenHarmony.
...
...
@@ -482,11 +485,11 @@ int main(int argc, char **argv)
```
###### System Updating
##### Upgrading the System
An application calls APIs of the OTA module to perform functions such as signature verification of the update package, anti-rollback, as well as burning and flushing to disk. After the update is complete, the system automatically restarts.
For the mini and small systems that use the Hi3518E V300 or Hi3516D V300 open source suite, add the value of **LOCAL\_VERSION** to the version that needs to implement the anti-rollback function. For example, for **"ohos default 1.0"->"ohos default 1.1"**, add the value of **LOCAL\_VERSION** in **device\hisilicon\third\_party\uboot\u-boot-2020.01\product\hiupdate\ota\_update\ota\_local_info.c**.
For the mini and small systems that use the Hi3516D V300 open source suite, add the value of **LOCAL\_VERSION** to the version that needs to implement the anti-rollback function. For example, for **"ohos default 1.0"->"ohos default 1.1"**, add the value of **LOCAL\_VERSION** in **device\hisilicon\third\_party\uboot\u-boot-2020.01\product\hiupdate\ota\_update\ota\_local_info.c**.
Example configuration:
...
...
@@ -494,16 +497,15 @@ For the mini and small systems that use the Hi3518E V300 or Hi3516D V300 open so
<br>Perform a rollback and set the partition to the **unbootable** state so that the system does not boot from this partition.
###### Verification
##### Verification
In normal cases, the device can download the update package from the OTA server in the background, perform a silent update, and then restart according to the preconfigured activation policy for the new version to take effect.
