> 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.
You can run the hidebug command to obtain the memory usage of an application, including the static heap memory (native heap) and proportional set size (PSS) occupied by the application process. You can also export VM memory slices and collect VM CPU profiling data.
...
...
@@ -16,7 +17,7 @@ import hidebug from '@ohos.hidebug';
getNativeHeapSize(): bigint
Obtains the total size of the native heap memory.
Obtains the total size of the heap memory of this application.
This API is defined but not implemented in OpenHarmony 3.1 Release.
...
...
@@ -26,84 +27,80 @@ This API is defined but not implemented in OpenHarmony 3.1 Release.
| Type | Description |
| ------ | --------------------------- |
| bigint | Total size of the native heap memory, in kB.|
| bigint | Total size of the heap memory of this application, in kB.|
**Example**
```js
letnativeHeapSize=hidebug.getNativeHeapSize();
```
```js
letnativeHeapSize=hidebug.getNativeHeapSize();
```
## hidebug.getNativeHeapAllocatedSize
getNativeHeapAllocatedSize(): bigint
Obtains the size of the allocated native heap memory.
Obtains the size of the allocated heap memory of this application.
This API is defined but not implemented in OpenHarmony 3.1 Release.
| filename | string | Yes | User-defined heap file name. The `filename.heapsnapshot` file is generated in the `files` directory of the app based on the specified `filename`.|
| filename | string | Yes | User-defined heap file name. The `filename.heapsnapshot` file is generated in the `files` directory of the application based on the specified `filename`.|
**Example**
...
...
@@ -250,7 +246,6 @@ This is a system API and cannot be called by third-party applications.
| serviceid | number | Yes | ID of the system service. |
**Return value**
| Type | Description |
| ------ | -------------------------- |
| string | Absolute path of the file that contains the service information to dump. |
# OTA Update<a name="EN-US_TOPIC_0000001163932574"></a>
# OTA Update
## Introduction<a name="section753413913562"></a>
Over the Air \(OTA\) is a technology that makes it easier for you to remotely update devices, such as IP cameras. Currently, the mini and small systems support update using a full package, but not a differential package. A full package contains all content of a new system, and a differential package contains the differences between the old and new systems.
>Generation of update packages can only be performed on the Linux system.
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.
## Generating a Public/Private Key Pair<a name="section1392711588162135"></a>
1. Download the [OpenSSL](http://slproweb.com/products/Win32OpenSSL.html) tool, install it on a Windows PC, and configure environment variables.
2. 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 upgrade, and it is stored as follows:
### Basic Concepts
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 **./device/hisilicon/hi3516dv300/build/updater\_config/signing\_cert.crt** file.
- Full package: an update package that packs all images of the target version.
4. For the mini and small systems that use the Hi3518E V300 or Hi3516D V300 suite, also 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.
- Differential package: an update package that packs the differential images between the source version and target version.
Example configuration for the public key of the U-Boot module:
```
static unsigned char g_pub_key[PUBKEY_LEN] = {
0x30, 0x82, 0x01, 0x0A, 0x02, 0x82, 0x01, 0x01,
0x00, 0xBF, 0xAA, 0xA5, 0xB3, 0xC2, 0x78, 0x5E,
}
```
## Generating an Update Package<a name="section704519924162135"></a>
### Mini and Small Systems<a name="section527064658162135"></a>
1. Create the **target\_package** folder with the following directory structure:
```
target_package
├── OTA.tag
├── 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.
3. Configure the **updater\_specified\_config.xml** file in the **update\_config** folder.
Example configuration of the **updater\_specified\_config.xml** file:
<td class="cellrowborder" valign="top" width="20%" headers="mcps1.1.6.1.5 "><p id="entry783609139162135p0"><a name="entry783609139162135p0"></a><a name="entry783609139162135p0"></a>Content of this node: head info</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry1810096705162135p0"><a name="entry1810096705162135p0"></a><a name="entry1810096705162135p0"></a>This field is reserved and does not affect the generation of the update package.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry876347577162135p0"><a name="entry876347577162135p0"></a><a name="entry876347577162135p0"></a>This field is reserved and does not affect the generation of the update package.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry1986606994162135p0"><a name="entry1986606994162135p0"></a><a name="entry1986606994162135p0"></a>Software version number, that is, the version number of the update package. The version number must be within the range specified by <strong id="b1587416137107"><a name="b1587416137107"></a><a name="b1587416137107"></a>VERSION.mbn</strong>. Otherwise, an update package will not be generated.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry1898510646162135p0"><a name="entry1898510646162135p0"></a><a name="entry1898510646162135p0"></a>Date when the update package is generated. This field is reserved and does not affect the generation of the update package.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry1952723593162135p0"><a name="entry1952723593162135p0"></a><a name="entry1952723593162135p0"></a>Time when the update package is generated. This field is reserved and does not affect the generation of the update package.</p>
<td class="cellrowborder" valign="top" width="20%" headers="mcps1.1.6.1.5 "><p id="entry1457912275162135p0"><a name="entry1457912275162135p0"></a><a name="entry1457912275162135p0"></a>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.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry2010019875162135p0"><a name="entry2010019875162135p0"></a><a name="entry2010019875162135p0"></a>Name of the partition corresponding to the component, for example, <strong id="b19437823131512"><a name="b19437823131512"></a><a name="b19437823131512"></a>system</strong> or <strong id="b375692501514"><a name="b375692501514"></a><a name="b375692501514"></a>vendor</strong>.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry1193039499162135p0"><a name="entry1193039499162135p0"></a><a name="entry1193039499162135p0"></a>Component ID, which must be unique.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry1005669355162135p0"><a name="entry1005669355162135p0"></a><a name="entry1005669355162135p0"></a>This field is reserved and does not affect the generation of the update package.</p>
<td class="cellrowborder" valign="top" headers="mcps1.1.6.1.3 "><p id="entry894563848162135p0"><a name="entry894563848162135p0"></a><a name="entry894563848162135p0"></a>Image type, which can be a full or differential package. The value <strong id="b16850185911295"><a name="b16850185911295"></a><a name="b16850185911295"></a>0</strong> indicates a full package, and value <strong id="b2095321320305"><a name="b2095321320305"></a><a name="b2095321320305"></a>1</strong> indicates a differential package.</p>
- **./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
- **-nz**: **not zip** mode
- **-nl2**: non-standard system mode
### Standard System<a name="section1291354584162135"></a>
1. Create the **target\_package** folder with the following directory structure:
```
### Implementation Principle
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">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.
- Devices developed based on Hi3518E V300 and Hi3516D V300 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.
## Environment Preparation
- 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
### Development Process
<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="#standard system">2.2 Standard system</a>
<ahref="#uploading-the-update package">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-the-OTA-update-capability">5. Integrate the OTA update capability.
  <ahref="#api-application-scenario-default">5.1 API application scenario (default)</a>
  <ahref="#api-application-scenario-custom">5.2 API application scenario (custom)</a>
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.
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.
Example configuration:
```c
staticunsignedcharg_pub_key[PUBKEY_LEN]={
0x30,0x82,0x01,0x0A,0x02,0x82,0x01,0x01,
0x00,0xBF,0xAA,0xA5,0xB3,0xC2,0x78,0x5E,
}
```
#### Making an Update Package
##### Mini and Small Systems
1. Create the **target\_package** folder with the following directory structure:
```text
target_package
├── OTA.tag
├── config
├── {component_1}
├── {component_2}
├── ...
├── {component_N}
└── updater_config
├── BOARD.list
├── VERSION.mbn
└── 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.
3. Configure the component configuration file in the **update\_config** folder.
4. Configure the list of products supported by the current update package in **BOARD.list** in the **update\_config** folder.
Example configuration:
```
HI3516
HI3518
```
5. Configure the versions supported by the current update package in **VERSION.mbn** in the **update\_config** folder.
Version number format: Hi3516DV300-eng 10 QP1A.XXXXXX.\{Major version number \(6 digits\)\}.XXX\{Minor version number \(3 digits\)\}
For example, Hi3516DV300-eng 10 QP1A.190711.020, where **190711** is the major version number, and **020** is the minor version number.
Example configuration:
```
Hi3516DV300-eng 10 QP1A.190711.001
Hi3516DV300-eng 10 QP1A.190711.020
Hi3518DV300-eng 10 QP1A.190711.021
```
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.
The partition table is generated with the image. The format is as follows:
```
<?xml version="1.0" encoding="GB2312" ?>
<Partition_Info>
<Part Sel="1" PartitionName="Image 1" FlashType="Flash type" FileSystem="File system type" Start="Start address of the partition" Length="Size of the partition" SelectFile="Actual path of the image"/>
<Part Sel="1" PartitionName="Image 2" FlashType="Flash type" FileSystem="File system type" Start="Start address of the partition" Length="Size of the partition" SelectFile="Actual path of the image"/>
</Partition_Info>
```
**Table 2** Description of labels in the partition table
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="entry1588639785162135p0"><a name="entry1588639785162135p0"></a><a name="entry1588639785162135p0"></a>Whether the partition is effective. The value <strong id="b156151453173416"><a name="b156151453173416"></a><a name="b156151453173416"></a>1</strong> indicates that the partition is effective, and value <strong id="b166297633517"><a name="b166297633517"></a><a name="b166297633517"></a>0</strong> indicates the opposite.</p>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="entry218585771162135p0"><a name="entry218585771162135p0"></a><a name="entry218585771162135p0"></a>File system type, for example, <strong id="b63519206383"><a name="b63519206383"></a><a name="b63519206383"></a>ext3/4</strong> or <strong id="b172821252383"><a name="b172821252383"></a><a name="b172821252383"></a>f2fs</strong>. The value can also be <strong id="b63162773815"><a name="b63162773815"></a><a name="b63162773815"></a>none</strong>.</p>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="entry814481339162135p0"><a name="entry814481339162135p0"></a><a name="entry814481339162135p0"></a>Start address of the partition, in MB. The start address of all partitions is <strong id="b1171284398"><a name="b1171284398"></a><a name="b1171284398"></a>0</strong>.</p>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="entry18613946162135p0"><a name="entry18613946162135p0"></a><a name="entry18613946162135p0"></a>Size of the partition, in MB.</p>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="entry1154631273162135p0"><a name="entry1154631273162135p0"></a><a name="entry1154631273162135p0"></a>Actual path of the image or file.</p>
- **./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
- **./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
- **-pf ./partition\_file.xml**: path of the partition table file
## Uploading the Update Package<a name="section1040019352162135"></a>
└── 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.
3. Configure the **updater\_specified\_config.xml** file in the **updater_config** folder.
| 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.|
| 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.|
| Component information (group node)| component| resType | Yes| This field is reserved and does not affect the generation of the update package.|
| Component information (group node)| component| compType | Yes| Image type, which can be a full or differential package. The value **0** indicates a full package, and value **1** indicates a differential package.|
> **NOTE**
> As mini and small systems do not support updating with a differential package, **compType** must be set to **0**, other than **1**.
>
> For mini and small systems, an update package cannot be created by changing partitions.
4. Create the **OTA.tag** file, which contains the magic number of the update package. The magic number is fixed, as shown below:
```text
package_type:ota1234567890qwertw
```
5. Create the **config** file, and configure the **bootargs** and **bootcmd** information in the file.
-**./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
- -**nz**: **not zip** mode
- -**nl2**: non-standard system mode
##### Standard System
1. Create the **target\_package** folder with the following directory structure:
```text
target_package
├── {component_1}
├── {component_2}
├── ...
├── {component_N}
└── updater_config
├── BOARD.list
├── VERSION.mbn
└── 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.
3. Configure the component configuration file in the **updater\_config** folder.
4. Configure the list of products supported by the current update package in **BOARD.list** in the **updater\_config** folder.
Example configuration:
```text
HI3516
HI3518
```
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)}
For example, **Hi3516DV300-eng 10 QP1A.190711.020**, where **190711** is the major version number, and **020** is the minor version number.
Example configuration:
```text
Hi3516DV300-eng 10 QP1A.190711.001
Hi3516DV300-eng 10 QP1A.190711.020
Hi3518DV300-eng 10 QP1A.190711.021
```
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.
The partition table is generated with the image. The format is as follows:
```xml
<?xml version="1.0" encoding="GB2312" ?>
<Partition_Info>
<PartSel="1"PartitionName="Image 1"FlashType="Flash type"FileSystem="File system type"Start="Start address of the partition"Length="Size of the partition"SelectFile="Actual path of the image"/>
<PartSel="1"PartitionName="Image 2"FlashType="Flash type"FileSystem="File system type"Start="Start address of the partition"Length="Size of the partition"SelectFile="Actual path of the image"/>
</Partition_Info>
```
**Table 2** Description of labels in the partition table
| 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**.|
| FileSystem | File system type, for example, **ext3/4** or **f2fs**. The value can also be **none**.|
| Start | Start address of the partition, in MB. The start address of all partitions is **0**.|
-**./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
-**./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
- -**pf ./partition\_file.xml**: path of the partition table file
#### **Uploading the Update Package**
Upload the update package to the vendor's OTA server.
## Downloading the Update Package<a name="section1870792413162135"></a>
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.
#### **Downloading the Update Package**
1. Download the update package from the OTA server.
## Integrating OTA Update Capabilities<a name="section2107348555162135"></a>
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.
1. For mini and small systems
- If a vendor requests OTA capabilities, use the dynamic library **libhota.so** and include the header files **hota\_partition.h** and **hota\_updater.h** in **base\\update\\ota\_lite\\interfaces\\kits**.
#### Integrating OTA Update Capabilities
- The **libhota.so** source code is stored in **base\\update\\ota\_lite\\frameworks\\source**.
1. For mini and small systems
- For details about how to use APIs, see _API Application Scenario_ and OTA APIs in _API Reference_.
- Call the dynamic library **libhota.so**. The corresponding header files **hota\_partition.h** and **hota\_updater.h** are located in **base\update\ota_lite\interfaces\kits**.
- The **libhota.so** source code is located in **base\update\ota_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\ota_lite\hals\hal\_hota\_board.h** file.
- If the development board needs to be adapted, see the **base\\update\\ota\_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.
2. For the standard system, see the [Reference Specifications](../../application-dev/reference/apis/js-apis-update.md) for details.
## API Application Scenario \(Default\)<a name="section1308521557162135"></a>
##### 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**<a name="section2103641927162135"></a>
1. Download the update package for the current device, and then call the **HotaInit** function to initialize the OTA module.
###### How to Develop
2. Call the **HotaWrite** function to verify, parse, and write data streams into the device.
1. Download the update package for the current device, and then call the **HotaInit** function to initialize the OTA module.
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.
2. Call the **HotaWrite** function to verify, parse, and write data streams for the update into the device.
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.
Perform an OTA update using the update package format and verification method provided by OpenHarmony.
###### Sample Code
```
Perform an OTA update using the update package format and verification method provided by OpenHarmony.
```cpp
intmain(intargc,char**argv)
{
printf("this is update print!\r\n");
...
...
@@ -440,30 +389,32 @@ int main(int argc, char **argv)
}
```
## API Application Scenario \(Custom\)<a name="section1332839930162135"></a>
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.
##### API Application Scenario (Custom)
### **How to Develop**<a name="section2120976727162135"></a>
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."
1. Download the update package for the current device, and then call the **HotaInit** function to initialize the OTA module.
2. Call the **HotaSetPackageType** function to set the package type to **NOT\_USE\_DEFAULT\_PKG**.
###### How to Develop
3. Call the **HotaWrite** function to write data streams into the device.
1. Download the update package for the current device, and then call the **HotaInit** function to initialize the OTA module.
4. Call the **HotaRead** function to read data. Vendors can choose whether to verify the data.
2. Call the **HotaSetPackageType** function to set the package type to **NOT\_USE\_DEFAULT\_PKG**.
5.\(Optional\) Call the **HotaSetBootSettings** function to set the startup tag used for entering the U-Boot mode during system restarting.
3. Call the **HotaWrite** function to write data streams into the device.
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.
4. Call the **HotaRead** function to read data. Vendors can choose whether to verify the data.
5. (Optional) Call the **HotaSetBootSettings** function to set the startup tag used for entering the U-Boot mode during system restarting.
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.
Perform an OTA update using the update package format and verification method not provided by OpenHarmony.
```
###### Sample Code
Perform an OTA update using the update package format and verification method not provided by OpenHarmony.
```cpp
intmain(intargc,char**argv)
{
printf("this is update print!\r\n");
...
...
@@ -512,7 +463,7 @@ int main(int argc, char **argv)
@@ -530,15 +481,16 @@ int main(int argc, char **argv)
}
```
## Upgrading the System<a name="section1704276175162135"></a>
Vendor applications call APIs of the OTA module to perform functions such as signature verification of the update package, anti-rollback, burning and data flushing-to-disk. After the update is complete, the system automatically restarts.
###### System Updating
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**.
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.
Example for modification of the local version:
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**.
2. Setting the activation policy (immediate restart, restart at night, and activation on next restart):
```cpp
upgrade(apply)
```
- Invoke update_service to start the system installation service through SAMGR.
1. Start the system installation service and set up an IPC connection.
```cpp
intSysInstallerInit(void*callback)
```
2. Install the A/B update package in the specified path.
```cpp
intStartUpdatePackageZip(stringpath)
```
3. Set the update progress callback.
```cpp
intSetUpdateProgressCallback(void*callback)
```
4. Obtain the installation status of the update package (0: not started; 1: installing; 2: installed).
```cpp
intGetUpdateStatus()
```
- Use HDI APIs to activate the new version.
1. Obtain the current boot slot to determine the partition to be updated.
```cpp
intGetCurrentSlot()
```
2. Upon completion of the update, switch the updated slot and restart the system for the new version to take effect.
```cpp
intSetActiveBootSlot(intslot)
```
3. Upon starting of the update, set the slot of the partition to be updated to the **unbootable** state.
```cpp
intsetSlotUnbootable(intslot)
```
4. Obtain the number of slots. The value **1** indicates a common update, and the value **2** indicates an A/B update.
```cpp
int32GetSlotNum(void)
```
###### FAQs
1. An exception occurs during installation of the update package.
<br>The system keeps running with the current version. It will attempt a new update in the next package search period.
2. An exception occurs during activation of the new version if the update package is installed in a non-boot partition.
<br>Perform a rollback and set the partition to the **unbootable** state so that the system does not boot from this partition.
###### 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.
