@@ -23,7 +23,7 @@ Process crash detection is implemented based on the Linux signal mechanism. Curr
...
@@ -23,7 +23,7 @@ Process crash detection is implemented based on the Linux signal mechanism. Curr
## Crash Log Collection
## Crash Log Collection
Process crash log is the fault log managed together with the app freeze and JS application crash logs by the FaultLogger module. You can collect process crash logs in any of the following ways:
Process crash log is a type of fault logs managed together with the app freeze and JS application crash logs by the FaultLogger module. You can collect process crash logs in any of the following ways:
1. Determine the faulty module and fault type based on fault logs.
- Determine the faulty module and fault type based on fault logs.
Generally, you can identify the faulty module based on the crash process name and identify the crash cause based on the signal. Besides, you can restore the function call chain of the crash stack based on the method name in the stack.
In the example, **SIGSEGV** is thrown by the Linux kernel because of access to an invalid memory address. The problem occurs in the **TriggerSegmentFaultException** function.
In most scenarios, a crash is caused by the top layer of the crash stack, such as null pointer access and proactive program abort.
Generally, you can identify the faulty module based on the crash process name and identify the crash cause based on the signal. Besides, you can restore the function call chain of the crash stack based on the method name in the stack.\
In the example, **SIGSEGV** is thrown by the Linux kernel because of access to an invalid memory address. The problem occurs in the **TriggerSegmentFaultException** function.\
In most scenarios, a crash is caused by the top layer of the crash stack, such as null pointer access and proactive program abort.\
If the cause cannot be located through the call stack, you need to check for other faults, for example, memory corruption or stack overflow.
If the cause cannot be located through the call stack, you need to check for other faults, for example, memory corruption or stack overflow.
2. Use the addr2line tool of Linux to parse the code line number to restore the call stack at the time of process crash.
- Use the addr2line tool of Linux to parse the code line number to restore the call stack at the time of process crash.
When using the addr2line tool to parse the code line number of the crash stack, make sure that binary files with debugging information is used. Generally, such files are generated during version build or application build.
When using the addr2line tool to parse the code line number of the crash stack, make sure that binary files with debugging information is used. Generally, such files are generated during version build or application build.
In this example, the crash is caused by assignment of a value to an unwritable area. It is in code line 57 in the **dfx_crasher.c** file. You can modify it to avoid the crash.
In this example, the crash is caused by assignment of a value to an unwritable area. It is in code line 57 in the **dfx_crasher.c** file. You can modify it to avoid the crash.\
If the obtained code line number is seemingly incorrect, you can fine-tune the address (for example, subtract the address by 1) or disable some compilation optimization items. It is known that the obtained code line number may be incorrect when Link Time Optimization (LTO) is enabled.
If the obtained code line number is seemingly incorrect, you can fine-tune the address (for example, subtract the address by 1) or disable some compilation optimization items. It is known that the obtained code line number may be incorrect when Link Time Optimization (LTO) is enabled.
The **dragInteraction** module provides the APIs to enable and disable listening for dragging status changes.
> **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.
>
> - The APIs provided by this module are system APIs.
| type | string | Yes | Event type. This field has a fixed value of **drag**.|
| callback | Callback<[DragState](#dragstate)> | No | Callback to be unregistered. If this parameter is not specified, all callbacks registered by the current application will be unregistered.|
@@ -53,7 +53,7 @@ Defines a reverse geocoding request.
...
@@ -53,7 +53,7 @@ Defines a reverse geocoding request.
| locale | string | Yes| Yes| Language used for the location description. **zh** indicates Chinese, and **en** indicates English.|
| locale | string | Yes| Yes| Language used for the location description. **zh** indicates Chinese, and **en** indicates English.|
| latitude | number | Yes| Yes| Latitude information. A positive value indicates north latitude, and a negative value indicates south latitude. The value ranges from **-90** to **90**.|
| latitude | number | Yes| Yes| Latitude information. A positive value indicates north latitude, and a negative value indicates south latitude. The value ranges from **-90** to **90**.|
| longitude | number | Yes| Yes| Longitude information. A positive value indicates east longitude , and a negative value indicates west longitude . The value ranges from **-180** to **180**.|
| longitude | number | Yes| Yes| Longitude information. A positive value indicates east longitude , and a negative value indicates west longitude . The value ranges from **-180** to **180**.|
| maxItems | number | Yes| Yes| Maximum number of location records to be returned. The value must be greater than or equal to **0**. A value smaller than **10** is recommended.|
| maxItems | number | Yes| Yes| Maximum number of location records to be returned. The specified value must be greater than or equal to **0**. A value smaller than **10** is recommended.|
| locale | string | Yes| Yes| Language used for the location description. **zh** indicates Chinese, and **en** indicates English.|
| locale | string | Yes| Yes| Language used for the location description. **zh** indicates Chinese, and **en** indicates English.|
| description | string | Yes| Yes| Location description, for example, **No. xx, xx Road, Pudong New District, Shanghai**.|
| description | string | Yes| Yes| Location description, for example, **No. xx, xx Road, Pudong New District, Shanghai**.|
| maxItems | number | Yes| Yes| Maximum number of location records to be returned. The value must be greater than or equal to **0**. A value smaller than **10** is recommended.|
| maxItems | number | Yes| Yes| Maximum number of location records to be returned. The specified value must be greater than or equal to **0**. A value smaller than **10** is recommended.|
| minLatitude | number | Yes| Yes| Minimum latitude. This parameter is used with **minLongitude**, **maxLatitude**, and **maxLongitude** to specify the latitude and longitude ranges. The value ranges from **-90** to **90**.|
| minLatitude | number | Yes| Yes| Minimum latitude. This parameter is used with **minLongitude**, **maxLatitude**, and **maxLongitude** to specify the latitude and longitude ranges. The value ranges from **-90** to **90**.|
| minLongitude | number | Yes| Yes| Minimum longitude. The value ranges from **-180** to **180**.|
| minLongitude | number | Yes| Yes| Minimum longitude. The value ranges from **-180** to **180**.|
| maxLatitude | number | Yes| Yes| Maximum latitude. The value ranges from **-90** to **90**.|
| maxLatitude | number | Yes| Yes| Maximum latitude. The value ranges from **-90** to **90**.|
| descriptionsSize | number | Yes| No| Total number of additional descriptions. The value must be greater than or equal to **0**. A value smaller than **10** is recommended.|
| descriptionsSize | number | Yes| No| Total number of additional descriptions. The specified value must be greater than or equal to **0**. A value smaller than **10** is recommended.|
| isFromMock | Boolean | Yes| No| Whether the geographical name is from the mock reverse geocoding function.<br>**System API**: This is a system API.|
| isFromMock | Boolean | Yes| No| Whether the geographical name is from the mock reverse geocoding function.<br>**System API**: This is a system API.|
| priority | [LocationRequestPriority](#locationrequestpriority) | Yes| Yes| Priority of the location request. For details about the value range, see [LocationRequestPriority](#locationrequestpriority).|
| priority | [LocationRequestPriority](#locationrequestpriority) | Yes| Yes| Priority of the location request. This parameter is effective only when **scenario** is set to **UNSET**. If this parameter and **scenario** are set to **UNSET**, the attempt to initiate a location request will fail. For details about the value range, see [LocationRequestPriority](#locationrequestpriority).|
| scenario | [LocationRequestScenario](#locationrequestscenario) | Yes| Yes| Scenario of the location request. For details about the value range, see [LocationRequestScenario](#locationrequestscenario).|
| scenario | [LocationRequestScenario](#locationrequestscenario) | Yes| Yes| Scenario of the location request. The **priority** parameter is effective only when this parameter is set to **UNSET**. If this parameter and **priority** are set to **UNSET**, the attempt to initiate a location request will fail. For details about the value range, see [LocationRequestScenario](#locationrequestscenario).|
| timeInterval | number | Yes| Yes| Time interval at which location information is reported, in seconds. The value must be greater than **0**.|
| timeInterval | number | Yes| Yes| Time interval at which location information is reported, in seconds. The specified value must be greater than or equal to **0**. The default value is **1**.|
| distanceInterval | number | Yes| Yes| Distance interval at which location information is reported. The value must be greater than **0**, in meters.|
| distanceInterval | number | Yes| Yes| Distance interval at which location information is reported, in meters. The specified value must be greater than or equal to **0**. The default value is **0**.|
| maxAccuracy | number | Yes| Yes| Location accuracy. This parameter is valid only when the precise location function is enabled, and is invalid when the approximate location function is enabled. The value must be greater than**0**.|
| maxAccuracy | number | Yes| Yes| Location accuracy, in meters. This parameter is valid only when the precise location function is enabled, and is invalid when the approximate location function is enabled. The specified value must be greater than or equal to **0**. The default value is**0**.|
## CurrentLocationRequest
## CurrentLocationRequest
...
@@ -125,10 +125,10 @@ Defines the current location request.
...
@@ -125,10 +125,10 @@ Defines the current location request.
| priority | [LocationRequestPriority](#locationrequestpriority) | Yes| Yes| Priority of the location request. For details about the value range, see [LocationRequestPriority](#locationrequestpriority).|
| priority | [LocationRequestPriority](#locationrequestpriority) | Yes| Yes| Priority of the location request. This parameter is effective only when **scenario** is set to **UNSET**. If this parameter and **scenario** are set to **UNSET**, the attempt to initiate a location request will fail. For details about the value range, see [LocationRequestPriority](#locationrequestpriority).|
| scenario | [LocationRequestScenario](#locationrequestscenario) | Yes| Yes| Scenario of the location request. For details about the value range, see [LocationRequestScenario](#locationrequestscenario).|
| scenario | [LocationRequestScenario](#locationrequestscenario) | Yes| Yes| Scenario of the location request. The **priority** parameter is effective only when this parameter is set to **UNSET**. If this parameter and **priority** are set to **UNSET**, the attempt to initiate a location request will fail. For details about the value range, see [LocationRequestScenario](#locationrequestscenario).|
| maxAccuracy | number | Yes| Yes| Location accuracy, in meters. This parameter is valid only when the precise location function is enabled, and is invalid when the approximate location function is enabled. The value must be greater than**0**.|
| maxAccuracy | number | Yes| Yes| Location accuracy, in meters. This parameter is valid only when the precise location function is enabled, and is invalid when the approximate location function is enabled. The specified value must be greater than or equal to **0**. The default value is**0**.|
| timeoutMs | number | Yes| Yes| Timeout duration, in milliseconds. The minimum value is **1000**. The value must be greater than or equal to **1000**.|
| timeoutMs | number | Yes| Yes| Timeout duration, in milliseconds. The minimum value is **1000**. The specified value must be greater than or equal to **1000**.|
## SatelliteStatusInfo
## SatelliteStatusInfo
...
@@ -139,23 +139,23 @@ Defines the satellite status information.
...
@@ -139,23 +139,23 @@ Defines the satellite status information.
| satellitesNumber | number | Yes| No| Number of satellites. The value must be greater than or equal to **0**.|
| satellitesNumber | number | Yes| No| Number of satellites. The specified value must be greater than or equal to **0**.|
| satelliteIds | Array<number> | Yes| No| Array of satellite IDs. The value must be greater than or equal to **0**.|
| satelliteIds | Array<number> | Yes| No| Array of satellite IDs. The specified value must be greater than or equal to **0**.|
| carrierToNoiseDensitys | Array<number> | Yes| No| Carrier-to-noise density ratio, that is, **cn0**. The value must be greater than **0**.|
| carrierToNoiseDensitys | Array<number> | Yes| No| Carrier-to-noise density ratio, that is, **cn0**. The specified value must be greater than **0**.|
| altitudes | Array<number> | Yes| No| Satellite altitude angle information. The value ranges from **-90** to **90**, in degrees.|
| altitudes | Array<number> | Yes| No| Satellite altitude angle information. The value ranges from **-90** to **90**, in degrees.|
| azimuths | Array<number> | Yes| No| Azimuth information. The value ranges from **0** to **360**, in degrees.|
| azimuths | Array<number> | Yes| No| Azimuth information. The value ranges from **0** to **360**, in degrees.|
| carrierFrequencies | Array<number> | Yes| No| Carrier frequency. The value must be greater than or equal to **0**, in Hz.|
| carrierFrequencies | Array<number> | Yes| No| Carrier frequency, in Hz. The specified value must be greater than or equal to **0**.|
## CachedGnssLocationsRequest
## CachedGnssLocationsRequest
Represents a request for reporting cached GNSS locations.
Defines a request for reporting cached GNSS locations.
| reportingPeriodSec | number | Yes| Yes| Interval for reporting the cached GNSS locations, in milliseconds. The value must be greater than **0**.|
| reportingPeriodSec | number | Yes| Yes| Interval for reporting the cached GNSS locations, in milliseconds. The specified value must be greater than **0**.|
| wakeUpCacheQueueFull | boolean | Yes| Yes | **true**: reports the cached GNSS locations to the application when the cache queue is full.<br>**false**: discards the cached GNSS locations when the cache queue is full.|
| wakeUpCacheQueueFull | boolean | Yes| Yes | **true**: reports the cached GNSS locations to the application when the cache queue is full.<br>**false**: discards the cached GNSS locations when the cache queue is full.|
...
@@ -169,13 +169,13 @@ Defines a GNSS geofence. Currently, only circular geofences are supported.
...
@@ -169,13 +169,13 @@ Defines a GNSS geofence. Currently, only circular geofences are supported.
| scanInterval | number | Yes| Yes| Scanning interval, in ms. The specified value must be greater than **0**. The default value is **10000**.|
| scanTimeout | number | Yes| Yes| Scanning timeout interval, in ms. The value ranges from **0** to **600000**. The default value is **10000**.|
## LocatingRequiredData<sup>10+</sup>
Defines the required data of the location service, including the Wi-Fi or Bluetooth scanning result. After obtaining the data, an application can use the data for services such as network positioning.
| deviceName | string | Yes| No| Name of a Bluetooth device.|
| macAddress | string | Yes| No| MAC address of a Bluetooth device.|
| rssi | number | Yes| No| Signal strength of a Bluetooth device, in dBm.|
| timestamp | number | Yes| No| Scanning timestamp.|
## LocationRequestPriority
## LocationRequestPriority
Sets the priority of the location request.
Sets the priority of the location request.
...
@@ -280,7 +343,7 @@ Sets the priority of the location request.
...
@@ -280,7 +343,7 @@ Sets the priority of the location request.
| Name| Value| Description|
| Name| Value| Description|
| -------- | -------- | -------- |
| -------- | -------- | -------- |
| UNSET | 0x300 | Scenario unspecified.<br>If this option is used, [LocationRequestScenario](#locationrequestscenario) is invalid.|
| UNSET | 0x300 | Scenario unspecified.<br>If this option is used, [LocationRequestScenario](#locationrequestscenario) is invalid.|
| NAVIGATION | 0x301 | Navigation.<br>This option is applicable when your application needs to obtain the real-time location of a mobile device outdoors, such as navigation for driving or walking.<br>In this scenario, GNSS positioning is used to provide location services to ensure the optimal location accuracy of the system.<br>The location result is reported at a minimum interval of 1 second by default.|
| NAVIGATION | 0x301 | Navigation.<br>This option is applicable when your application needs to obtain the real-time location of a mobile device outdoors, such as navigation for driving or walking.<br>In this scenario, GNSS positioning is used to provide location services to ensure the optimal location accuracy of the system.<br>The location result is reported at a minimum interval of 1 second by default.|
| TRAJECTORY_TRACKING | 0x302 | Trajectory tracking.<br>This option is applicable when your application needs to record user trajectories, for example, the track recording function of sports applications. In this scenario, the GNSS positioning technology is mainly used to ensure the location accuracy.<br>The location result is reported at a minimum interval of 1 second by default.|
| TRAJECTORY_TRACKING | 0x302 | Trajectory tracking.<br>This option is applicable when your application needs to record user trajectories, for example, the track recording function of sports applications. In this scenario, the GNSS positioning technology is mainly used to ensure the location accuracy.<br>The location result is reported at a minimum interval of 1 second by default.|
| CAR_HAILING | 0x303 | Ride hailing.<br>This option is applicable when your application needs to obtain the current location of a user who is hailing a taxi.<br>The location result is reported at a minimum interval of 1 second by default.|
| CAR_HAILING | 0x303 | Ride hailing.<br>This option is applicable when your application needs to obtain the current location of a user who is hailing a taxi.<br>The location result is reported at a minimum interval of 1 second by default.|
...
@@ -294,7 +357,7 @@ Defines the privacy statement type.
...
@@ -294,7 +357,7 @@ Defines the privacy statement type.
@@ -376,12 +453,12 @@ Unregisters the listener for location changes with the corresponding location re
...
@@ -376,12 +453,12 @@ Unregisters the listener for location changes with the corresponding location re
| Name| Type| Mandatory| Description|
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
| -------- | -------- | -------- | -------- |
| type | string | Yes| Event type. The value **locationChange** indicates a location change event.|
| type | string | Yes| Event type. The value **locationChange** indicates a location change.|
| callback | Callback<[Location](#location)> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
| callback | Callback<[Location](#location)> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
**Error codes**
**Error codes**
For details about the following error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
@@ -456,12 +533,12 @@ Unregisters the listener for location service status change events.
...
@@ -456,12 +533,12 @@ Unregisters the listener for location service status change events.
| Name| Type| Mandatory| Description|
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
| -------- | -------- | -------- | -------- |
| type | string | Yes| Event type. The value **locationEnabledChange** indicates a location service status change event.|
| type | string | Yes| Event type. The value **locationEnabledChange** indicates a location service status change.|
| callback | Callback<boolean> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
| callback | Callback<boolean> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
**Error codes**
**Error codes**
For details about the following error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
@@ -627,12 +704,12 @@ Unregisters the listener for GNSS satellite status change events.
...
@@ -627,12 +704,12 @@ Unregisters the listener for GNSS satellite status change events.
| Name| Type| Mandatory| Description|
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
| -------- | -------- | -------- | -------- |
| type | string | Yes| Event type. The value **satelliteStatusChange** indicates a GNSS satellite status change event.|
| type | string | Yes| Event type. The value **satelliteStatusChange** indicates a GNSS satellite status change.|
| callback | Callback<[SatelliteStatusInfo](#satellitestatusinfo)> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
| callback | Callback<[SatelliteStatusInfo](#satellitestatusinfo)> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
**Error codes**
**Error codes**
For details about the following error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
Unregisters the listener for GNSS NMEA message change events.
Unsubscribes from GNSS NMEA message change events.
**Required permissions**: ohos.permission.LOCATION and ohos.permission.APPROXIMATELY_LOCATION
**Required permissions**: ohos.permission.LOCATION and ohos.permission.APPROXIMATELY_LOCATION
...
@@ -713,12 +790,12 @@ Unregisters the listener for GNSS NMEA message change events.
...
@@ -713,12 +790,12 @@ Unregisters the listener for GNSS NMEA message change events.
| Name| Type| Mandatory| Description|
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
| -------- | -------- | -------- | -------- |
| type | string | Yes| Event type. The value **nmeaMessage** indicates a GNSS NMEA message change event.|
| type | string | Yes| Event type. The value **nmeaMessage** indicates a GNSS NMEA message change.|
| callback | Callback<string> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
| callback | Callback<string> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
**Error codes**
**Error codes**
For details about the following error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
@@ -913,12 +990,12 @@ Unregisters the listener for country code change events.
...
@@ -913,12 +990,12 @@ Unregisters the listener for country code change events.
| Name| Type| Mandatory| Description|
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
| -------- | -------- | -------- | -------- |
| type | string | Yes| Event type. The value **countryCodeChange** indicates a country code change event.|
| type | string | Yes| Event type. The value **countryCodeChange** indicates a country code change.|
| callback | Callback<[CountryCode](#countrycode)> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
| callback | Callback<[CountryCode](#countrycode)> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
**Error codes**
**Error codes**
For details about the following error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
Subscribes to changes in the required data of the location service, including Wi-Fi and Bluetooth scanning information. An application can then determine whether to enable Wi-Fi and Bluetooth scanning based on the return result.
**Required permissions**: ohos.permission.LOCATION and ohos.permission.APPROXIMATELY_LOCATION
| type | string | Yes| Event type. The value **locatingRequiredDataChange** indicates a change in the required data of the location service.|
| config | [LocatingRequiredDataConfig](#locatingrequireddataconfig10) | Yes| Configuration for obtaining the required data of the location service.|
| callback | Callback<Array<[LocatingRequiredData](#locatingrequireddata10)>> | Yes| Callback used to receive the required data of the location service.|
**Error codes**
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
| type | string | Yes| Event type. The value **locatingRequiredDataChange** indicates a change in the required data of the location service.|
| callback | Callback<Array<[LocatingRequiredData](#locatingrequireddata10)>> | No| Callback to unregister. If this parameter is not specified, all callbacks of the specified event type are unregistered.|
**Error codes**
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
@@ -2106,11 +2265,11 @@ Sets the user confirmation status for the privacy statement of the location serv
...
@@ -2106,11 +2265,11 @@ Sets the user confirmation status for the privacy statement of the location serv
| Name| Type| Mandatory| Description|
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
| -------- | -------- | -------- | -------- |
| type | [LocationPrivacyType](#locationprivacytype) | Yes| Privacy statement type, for example, privacy statement displayed in the startup wizard or privacy statement displayed when the location service is enabled.|
| type | [LocationPrivacyType](#locationprivacytype) | Yes| Privacy statement type, for example, privacy statement displayed in the startup wizard or privacy statement displayed when the location service is enabled.|
| isConfirmed | boolean | Yes| Callback used to return the result, which indicates whether the user agrees with the privacy statement.|
| isConfirmed | boolean | Yes| Whether the user agrees with the privacy statement.|
**Error codes**
**Error codes**
For details about the following error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
| config | [LocatingRequiredDataConfig](#locatingrequireddataconfig10) | Yes| Configuration for obtaining the required data of the location service.|
**Return value**
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
| Promise<Array<[LocatingRequiredData](#locatingrequireddata10)>> | [LocatingRequiredData](#locatingrequireddata10) | NA | Callback used to receive the required data of the location service, such as the Wi-Fi and Bluetooth scanning information.|
**Error codes**
For details about the error codes, see [Location Error Codes](../errorcodes/errorcode-geoLocationManager.md).
| [OH_AI_TensorHandleArray](_o_h___a_i___tensor_handle_array.md) | Defines the tensor array structure, which is used to store the tensor array pointer and tensor array length.|
| [OH_AI_TensorHandleArray](_o_h___a_i___tensor_handle_array.md) | Defines the tensor array structure, which is used to store the tensor array pointer and tensor array length.|
| [OH_AI_ShapeInfo](_o_h___a_i___shape_info.md) | Dimension information. The maximum dimension is set by **MS_MAX_SHAPE_NUM**. |
| [OH_AI_ShapeInfo](_o_h___a_i___shape_info.md) | Defines dimension information. The maximum dimension is set by **MS_MAX_SHAPE_NUM**. |
| [OH_AI_CallBackParam](_o_h___a_i___call_back_param.md) | Defines the operator information passed in a callback. |
| [OH_AI_CallBackParam](_o_h___a_i___call_back_param.md) | Defines the operator information passed in a callback. |
...
@@ -109,18 +109,19 @@ Provides APIs related to MindSpore Lite model inference.
...
@@ -109,18 +109,19 @@ Provides APIs related to MindSpore Lite model inference.
| [OH_AI_DeviceInfoSetFrequency](#oh_ai_deviceinfosetfrequency)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, int frequency) | Sets the NPU frequency type. This function is available only for NPU devices. |
| [OH_AI_DeviceInfoSetFrequency](#oh_ai_deviceinfosetfrequency)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, int frequency) | Sets the NPU frequency type. This function is available only for NPU devices. |
| [OH_AI_DeviceInfoGetFrequency](#oh_ai_deviceinfogetfrequency)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the NPU frequency type. This function is available only for NPU devices. |
| [OH_AI_DeviceInfoGetFrequency](#oh_ai_deviceinfogetfrequency)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the NPU frequency type. This function is available only for NPU devices. |
| [OH_AI_GetAllNNRTDeviceDescs](#oh_ai_getallnnrtdevicedescs)(size_t\*num) | Obtains the descriptions of all NNRt devices in the system. |
| [OH_AI_GetAllNNRTDeviceDescs](#oh_ai_getallnnrtdevicedescs)(size_t\*num) | Obtains the descriptions of all NNRt devices in the system. |
| [OH_AI_DestroyAllNNRTDeviceDescs](#oh_ai_destroyallnnrtdevicedescs)([NNRTDeviceDesc](#nnrtdevicedesc)\*\*desc) | Destroys the array of NNRT descriptions obtained by [OH_AI_GetAllNNRTDeviceDescs](#oh_ai_getallnnrtdevicedescs).|
| [OH_AI_GetElementOfNNRTDeviceDescs](#oh_ai_getelementofnnrtdevicedescs)(NNRTDeviceDesc\*descs, size_t index) | Obtains the pointer to an element in the NNRt device description array.|
| [OH_AI_DestroyAllNNRTDeviceDescs](#oh_ai_destroyallnnrtdevicedescs)([NNRTDeviceDesc](#nnrtdevicedesc)\*\*desc) | Destroys the NNRt device description array obtained by [OH_AI_GetAllNNRTDeviceDescs](#oh_ai_getallnnrtdevicedescs).|
| [OH_AI_GetDeviceIdFromNNRTDeviceDesc](#oh_ai_getdeviceidfromnnrtdevicedesc)(const[NNRTDeviceDesc](#nnrtdevicedesc) \*desc) | Obtains the NNRt device ID from the specified NNRt device description. Note that this ID is valid only for NNRt devices.|
| [OH_AI_GetDeviceIdFromNNRTDeviceDesc](#oh_ai_getdeviceidfromnnrtdevicedesc)(const[NNRTDeviceDesc](#nnrtdevicedesc) \*desc) | Obtains the NNRt device ID from the specified NNRt device description. Note that this ID is valid only for NNRt devices.|
| [OH_AI_GetNameFromNNRTDeviceDesc](#oh_ai_getnamefromnnrtdevicedesc)(const[NNRTDeviceDesc](#nnrtdevicedesc) \*desc) | Obtains the NNRt device name from the specified NNRt device description. |
| [OH_AI_GetNameFromNNRTDeviceDesc](#oh_ai_getnamefromnnrtdevicedesc)(const[NNRTDeviceDesc](#nnrtdevicedesc) \*desc) | Obtains the NNRt device name from the specified NNRt device description. |
| [OH_AI_GetTypeFromNNRTDeviceDesc](#oh_ai_gettypefromnnrtdevicedesc)(const[NNRTDeviceDesc](#nnrtdevicedesc) \*desc) | Obtains the NNRt device type from the specified NNRt device description. |
| [OH_AI_GetTypeFromNNRTDeviceDesc](#oh_ai_gettypefromnnrtdevicedesc)(const[NNRTDeviceDesc](#nnrtdevicedesc) \*desc) | Obtains the NNRt device type from the specified NNRt device description. |
| [OH_AI_CreateNNRTDeviceInfoByName](#oh_ai_creatennrtdeviceinfobyname)(const char \*name) | Searches for the NNRt device with the specified name and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_CreateNNRTDeviceInfoByName](#oh_ai_creatennrtdeviceinfobyname)(const char \*name) | Searches for the NNRt device with the specified name and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_CreateNNRTDeviceInfoByType](#oh_ai_creatennrtdeviceinfobytype)([OH_AI_NNRTDeviceType](#oh_ai_nnrtdevicetype) type) | Searches for the NNRt device with the specified type and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_CreateNNRTDeviceInfoByType](#oh_ai_creatennrtdeviceinfobytype)([OH_AI_NNRTDeviceType](#oh_ai_nnrtdevicetype) type) | Searches for the NNRt device with the specified type and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_DeviceInfoSetDeviceId](#oh_ai_deviceinfosetdeviceid)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, size_t device_id) | Sets the ID of an NNRt device. This API is available only for NNRt devices. |
| [OH_AI_DeviceInfoSetDeviceId](#oh_ai_deviceinfosetdeviceid)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, size_t device_id) | Sets the ID of an NNRt device. This function is available only for NNRt devices. |
| [OH_AI_DeviceInfoGetDeviceId](#oh_ai_deviceinfogetdeviceid)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the ID of an NNRt device. This API is available only for NNRt devices. |
| [OH_AI_DeviceInfoGetDeviceId](#oh_ai_deviceinfogetdeviceid)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the ID of an NNRt device. This function is available only for NNRt devices. |
| [OH_AI_DeviceInfoSetPerformanceMode](#oh_ai_deviceinfosetperformancemode)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, [OH_AI_PerformanceMode](#oh_ai_performancemode) mode) | Sets the performance mode of an NNRt device. This API is available only for NNRt devices. |
| [OH_AI_DeviceInfoSetPerformanceMode](#oh_ai_deviceinfosetperformancemode)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, [OH_AI_PerformanceMode](#oh_ai_performancemode) mode) | Sets the performance mode of an NNRt device. This function is available only for NNRt devices. |
| [OH_AI_DeviceInfoGetPerformanceMode](#oh_ai_deviceinfogetperformancemode)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the performance mode of an NNRt device. This API is available only for NNRt devices. |
| [OH_AI_DeviceInfoGetPerformanceMode](#oh_ai_deviceinfogetperformancemode)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the performance mode of an NNRt device. This function is available only for NNRt devices. |
| [OH_AI_DeviceInfoSetPriority](#oh_ai_deviceinfosetpriority)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, [OH_AI_Priority](#oh_ai_priority) priority) | Sets the priority of an NNRT task. This API is available only for NNRt devices. |
| [OH_AI_DeviceInfoSetPriority](#oh_ai_deviceinfosetpriority)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, [OH_AI_Priority](#oh_ai_priority) priority) | Sets the priority of an NNRt task. This function is available only for NNRt devices. |
| [OH_AI_DeviceInfoGetPriority](#oh_ai_deviceinfogetpriority)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the priority of an NNRT task. This API is available only for NNRt devices. |
| [OH_AI_DeviceInfoGetPriority](#oh_ai_deviceinfogetpriority)(const[OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info) | Obtains the priority of an NNRt task. This function is available only for NNRt devices. |
| [OH_AI_ModelCreate](#oh_ai_modelcreate)() | Creates a model object. |
| [OH_AI_ModelCreate](#oh_ai_modelcreate)() | Creates a model object. |
| [OH_AI_ModelDestroy](#oh_ai_modeldestroy)([OH_AI_ModelHandle](#oh_ai_modelhandle)\*model) | Destroys a model object. |
| [OH_AI_ModelDestroy](#oh_ai_modeldestroy)([OH_AI_ModelHandle](#oh_ai_modelhandle)\*model) | Destroys a model object. |
| [OH_AI_ModelBuild](#oh_ai_modelbuild)([OH_AI_ModelHandle](#oh_ai_modelhandle) model, const void \*model_data, size_t data_size, [OH_AI_ModelType](#oh_ai_modeltype) model_type, const [OH_AI_ContextHandle](#oh_ai_contexthandle) model_context) | Loads and builds a MindSpore model from the memory buffer. |
| [OH_AI_ModelBuild](#oh_ai_modelbuild)([OH_AI_ModelHandle](#oh_ai_modelhandle) model, const void \*model_data, size_t data_size, [OH_AI_ModelType](#oh_ai_modeltype) model_type, const [OH_AI_ContextHandle](#oh_ai_contexthandle) model_context) | Loads and builds a MindSpore model from the memory buffer. |
...
@@ -131,9 +132,10 @@ Provides APIs related to MindSpore Lite model inference.
...
@@ -131,9 +132,10 @@ Provides APIs related to MindSpore Lite model inference.
| [OH_AI_ModelGetOutputs](#oh_ai_modelgetoutputs)(const[OH_AI_ModelHandle](#oh_ai_modelhandle) model) | Obtains the output tensor array structure of a model. |
| [OH_AI_ModelGetOutputs](#oh_ai_modelgetoutputs)(const[OH_AI_ModelHandle](#oh_ai_modelhandle) model) | Obtains the output tensor array structure of a model. |
| [OH_AI_ModelGetInputByTensorName](#oh_ai_modelgetinputbytensorname)(const[OH_AI_ModelHandle](#oh_ai_modelhandle) model, const char \*tensor_name) | Obtains the input tensor of a model by tensor name. |
| [OH_AI_ModelGetInputByTensorName](#oh_ai_modelgetinputbytensorname)(const[OH_AI_ModelHandle](#oh_ai_modelhandle) model, const char \*tensor_name) | Obtains the input tensor of a model by tensor name. |
| [OH_AI_ModelGetOutputByTensorName](#oh_ai_modelgetoutputbytensorname)(const[OH_AI_ModelHandle](#oh_ai_modelhandle) model, const char \*tensor_name) | Obtains the output tensor of a model by tensor name. |
| [OH_AI_ModelGetOutputByTensorName](#oh_ai_modelgetoutputbytensorname)(const[OH_AI_ModelHandle](#oh_ai_modelhandle) model, const char \*tensor_name) | Obtains the output tensor of a model by tensor name. |
| [OH_AI_DeviceInfoAddExtension](#oh_ai_deviceinfoaddextension)([OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) device_info, const char \*name, const char \*value, size_t value_size) | Adds extended configuration in the form of key/value pairs to the device information. This function is available only for NNRt device information.|
| [OH_AI_TensorGetName](#oh_ai_tensorgetname)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the tensor name. |
| [OH_AI_TensorGetName](#oh_ai_tensorgetname)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the tensor name. |
| [OH_AI_TensorSetDataType](#oh_ai_tensorsetdatatype)([OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor, [OH_AI_DataType](#oh_ai_datatype) type) | Sets the data type of a tensor. |
| [OH_AI_TensorSetDataType](#oh_ai_tensorsetdatatype)([OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor, [OH_AI_DataType](#oh_ai_datatype) type) | Sets the data type of a tensor. |
...
@@ -147,7 +149,7 @@ Provides APIs related to MindSpore Lite model inference.
...
@@ -147,7 +149,7 @@ Provides APIs related to MindSpore Lite model inference.
| [OH_AI_TensorGetMutableData](#oh_ai_tensorgetmutabledata)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the pointer to variable tensor data. If the data is empty, memory will be allocated. |
| [OH_AI_TensorGetMutableData](#oh_ai_tensorgetmutabledata)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the pointer to variable tensor data. If the data is empty, memory will be allocated. |
| [OH_AI_TensorGetElementNum](#oh_ai_tensorgetelementnum)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the number of tensor elements. |
| [OH_AI_TensorGetElementNum](#oh_ai_tensorgetelementnum)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the number of tensor elements. |
| [OH_AI_TensorGetDataSize](#oh_ai_tensorgetdatasize)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the number of bytes of the tensor data. |
| [OH_AI_TensorGetDataSize](#oh_ai_tensorgetdatasize)(const[OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor) | Obtains the number of bytes of the tensor data. |
| [OH_AI_TensorSetUserData](#oh_ai_tensorsetuserdata)([OH_AI_TensorHandle](#oh_ai_tensorhandle) tensor, void \*data, size_t data_size) | Sets the tensor as the user data. This function allows you to reuse user data as the model input, which helps to reduce data copy by one time.|
This function allows you to reuse user data as the model input, which helps to reduce data copy by one time.
> **NOTE**<br>The user data is type of external data for the tensor and is not automatically released when the tensor is destroyed. The caller needs to release the data separately. In addition, the caller must ensure that the user data is valid during use of the tensor.
**Parameters**
| Name| Description|
| -------- | -------- |
| tensor | Handle of the tensor object.|
| data | Start address of user data.|
| data_size | Length of the user data length.|
**Returns**
Execution status code. The value **OH_AI_STATUS_SUCCESS** indicates that the operation is successful. If the operation fails, an error code is returned.
Adds extended configuration in the form of key/value pairs to the device information. This function is available only for NNRt device information.
>**NOTE**<br>Key value pairs currently supported include {"CachePath": "YourCachePath"}, {"CacheVersion": "YourCacheVersion"}, and {"QuantParam": "YourQuantConfig"}. Replace the actual value as required.
**Parameters**
| Name| Description|
| -------- | -------- |
| device_info | [OH_AI_DeviceInfoHandle](#oh_ai_deviceinfohandle) that points to a device information instance.|
| name | Key in an extended key/value pair. The value is a C string.|
| value | Start address of the value in an extended key/value pair.|
| value_size | Length of the value in an extended key/value pair.|
**Returns**
Status code enumerated by **OH_AI_Status**. The value **OH_AI_STATUS_SUCCESS** indicates that the operation is successful. If the operation fails, an error code is returned.
**Since**
10
### OH_AI_GetElementOfNNRTDeviceDescs()
```
OH_AI_API NNRTDeviceDesc* OH_AI_GetElementOfNNRTDeviceDescs (NNRTDeviceDesc * descs, size_t index )
```
**Description**
Obtains the pointer to an element in the NNRt device description array.
**Parameters**
| Name| Description|
| -------- | -------- |
| descs | NNRt device description array.|
| index | Index of an array element.|
**Returns**
Pointer to an element in the NNRt device description array.
| [OH_AI_DeviceInfoSetFrequency](_mind_spore.md#oh_ai_deviceinfosetfrequency)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, int frequency) | Sets the NPU frequency type. This function is available only for NPU devices.|
| [OH_AI_DeviceInfoSetFrequency](_mind_spore.md#oh_ai_deviceinfosetfrequency)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, int frequency) | Sets the NPU frequency type. This function is available only for NPU devices.|
| [OH_AI_DeviceInfoGetFrequency](_mind_spore.md#oh_ai_deviceinfogetfrequency)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the NPU frequency type. This function is available only for NPU devices.|
| [OH_AI_DeviceInfoGetFrequency](_mind_spore.md#oh_ai_deviceinfogetfrequency)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the NPU frequency type. This function is available only for NPU devices.|
| [OH_AI_GetAllNNRTDeviceDescs](_mind_spore.md#oh_ai_getallnnrtdevicedescs)(size_t\*num) | Obtains the descriptions of all NNRt devices in the system.|
| [OH_AI_GetAllNNRTDeviceDescs](_mind_spore.md#oh_ai_getallnnrtdevicedescs)(size_t\*num) | Obtains the descriptions of all NNRt devices in the system.|
| [OH_AI_DestroyAllNNRTDeviceDescs](_mind_spore.md#oh_ai_destroyallnnrtdevicedescs)([NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc)\*\*desc) | Destroys the array of NNRT descriptions obtained by [OH_AI_GetAllNNRTDeviceDescs](_mind_spore.md#oh_ai_getallnnrtdevicedescs).|
| [OH_AI_GetElementOfNNRTDeviceDescs](_mind_spore.md#oh_ai_getelementofnnrtdevicedescs)(NNRTDeviceDesc\*descs, size_t index) | Obtains the pointer to an element in the NNRt device description array.|
| [OH_AI_DestroyAllNNRTDeviceDescs](_mind_spore.md#oh_ai_destroyallnnrtdevicedescs)([NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc)\*\*desc) | Destroys the NNRt device description array obtained by [OH_AI_GetAllNNRTDeviceDescs](_mind_spore.md#oh_ai_getallnnrtdevicedescs).|
| [OH_AI_GetDeviceIdFromNNRTDeviceDesc](_mind_spore.md#oh_ai_getdeviceidfromnnrtdevicedesc)(const[NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc) \*desc) | Obtains the NNRt device ID from the specified NNRt device description. Note that this ID is valid only for NNRt devices.|
| [OH_AI_GetDeviceIdFromNNRTDeviceDesc](_mind_spore.md#oh_ai_getdeviceidfromnnrtdevicedesc)(const[NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc) \*desc) | Obtains the NNRt device ID from the specified NNRt device description. Note that this ID is valid only for NNRt devices.|
| [OH_AI_GetNameFromNNRTDeviceDesc](_mind_spore.md#oh_ai_getnamefromnnrtdevicedesc)(const[NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc) \*desc) | Obtains the NNRt device name from the specified NNRt device description.|
| [OH_AI_GetNameFromNNRTDeviceDesc](_mind_spore.md#oh_ai_getnamefromnnrtdevicedesc)(const[NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc) \*desc) | Obtains the NNRt device name from the specified NNRt device description.|
| [OH_AI_GetTypeFromNNRTDeviceDesc](_mind_spore.md#oh_ai_gettypefromnnrtdevicedesc)(const[NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc) \*desc) | Obtains the NNRt device type from the specified NNRt device description.|
| [OH_AI_GetTypeFromNNRTDeviceDesc](_mind_spore.md#oh_ai_gettypefromnnrtdevicedesc)(const[NNRTDeviceDesc](_mind_spore.md#nnrtdevicedesc) \*desc) | Obtains the NNRt device type from the specified NNRt device description.|
| [OH_AI_CreateNNRTDeviceInfoByName](_mind_spore.md#oh_ai_creatennrtdeviceinfobyname)(const char \*name) | Searches for the NNRt device with the specified name and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_CreateNNRTDeviceInfoByName](_mind_spore.md#oh_ai_creatennrtdeviceinfobyname)(const char \*name) | Searches for the NNRt device with the specified name and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_CreateNNRTDeviceInfoByType](_mind_spore.md#oh_ai_creatennrtdeviceinfobytype)([OH_AI_NNRTDeviceType](_mind_spore.md#oh_ai_nnrtdevicetype) type) | Searches for the NNRt device with the specified type and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_CreateNNRTDeviceInfoByType](_mind_spore.md#oh_ai_creatennrtdeviceinfobytype)([OH_AI_NNRTDeviceType](_mind_spore.md#oh_ai_nnrtdevicetype) type) | Searches for the NNRt device with the specified type and creates the NNRt device information based on the information about the first found NNRt device.|
| [OH_AI_DeviceInfoSetDeviceId](_mind_spore.md#oh_ai_deviceinfosetdeviceid)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, size_t device_id) | Sets the ID of an NNRt device. This API is available only for NNRt devices.|
| [OH_AI_DeviceInfoSetDeviceId](_mind_spore.md#oh_ai_deviceinfosetdeviceid)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, size_t device_id) | Sets the ID of an NNRt device. This function is available only for NNRt devices.|
| [OH_AI_DeviceInfoGetDeviceId](_mind_spore.md#oh_ai_deviceinfogetdeviceid)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the ID of an NNRt device. This API is available only for NNRt devices.|
| [OH_AI_DeviceInfoGetDeviceId](_mind_spore.md#oh_ai_deviceinfogetdeviceid)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the ID of an NNRt device. This function is available only for NNRt devices.|
| [OH_AI_DeviceInfoSetPerformanceMode](_mind_spore.md#oh_ai_deviceinfosetperformancemode)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, [OH_AI_PerformanceMode](_mind_spore.md#oh_ai_performancemode) mode) | Sets the performance mode of an NNRt device. This API is available only for NNRt devices.|
| [OH_AI_DeviceInfoSetPerformanceMode](_mind_spore.md#oh_ai_deviceinfosetperformancemode)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, [OH_AI_PerformanceMode](_mind_spore.md#oh_ai_performancemode) mode) | Sets the performance mode of an NNRt device. This function is available only for NNRt devices.|
| [OH_AI_DeviceInfoGetPerformanceMode](_mind_spore.md#oh_ai_deviceinfogetperformancemode)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the performance mode of an NNRt device. This API is available only for NNRt devices.|
| [OH_AI_DeviceInfoGetPerformanceMode](_mind_spore.md#oh_ai_deviceinfogetperformancemode)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the performance mode of an NNRt device. This function is available only for NNRt devices.|
| [OH_AI_DeviceInfoSetPriority](_mind_spore.md#oh_ai_deviceinfosetpriority)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, [OH_AI_Priority](_mind_spore.md#oh_ai_priority) priority) | Sets the priority of an NNRT task. This API is available only for NNRt devices.|
| [OH_AI_DeviceInfoSetPriority](_mind_spore.md#oh_ai_deviceinfosetpriority)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, [OH_AI_Priority](_mind_spore.md#oh_ai_priority) priority) | Sets the priority of an NNRt task. This function is available only for NNRt devices.|
| [OH_AI_DeviceInfoGetPriority](_mind_spore.md#oh_ai_deviceinfogetpriority)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the priority of an NNRT task. This API is available only for NNRt devices.|
| [OH_AI_DeviceInfoGetPriority](_mind_spore.md#oh_ai_deviceinfogetpriority)(const[OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info) | Obtains the priority of an NNRt task. This function is available only for NNRt devices.|
| [OH_AI_DeviceInfoAddExtension](_mind_spore.md#oh_ai_deviceinfoaddextension)([OH_AI_DeviceInfoHandle](_mind_spore.md#oh_ai_deviceinfohandle) device_info, const char \*name, const char \*value, size_t value_size) | Adds extended configuration in the form of key/value pairs to the device information. This function is available only for NNRt device information.|
| [OH_AI_TensorDestroy](_mind_spore.md#oh_ai_tensordestroy)([OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle)\*tensor) | Destroys a tensor object. |
| [OH_AI_TensorDestroy](_mind_spore.md#oh_ai_tensordestroy)(OH_AI_TensorHandle\*tensor) | Destroys a tensor object.|
| [OH_AI_TensorClone](_mind_spore.md#oh_ai_tensorclone)([OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Clones a tensor. |
| [OH_AI_TensorClone](_mind_spore.md#oh_ai_tensorclone)(OH_AI_TensorHandle tensor) | Clones a tensor.|
| [OH_AI_TensorSetName](_mind_spore.md#oh_ai_tensorsetname)([OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor, const char \*name) | Sets the name of a tensor. |
| [OH_AI_TensorGetName](_mind_spore.md#oh_ai_tensorgetname)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Obtains the name of a tensor. |
| [OH_AI_TensorGetName](_mind_spore.md#oh_ai_tensorgetname)(const OH_AI_TensorHandle tensor) | Obtains the tensor name.|
| [OH_AI_TensorSetDataType](_mind_spore.md#oh_ai_tensorsetdatatype)([OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor, [OH_AI_DataType](_mind_spore.md#oh_ai_datatype) type) | Sets the data type of a tensor. |
| [OH_AI_TensorSetDataType](_mind_spore.md#oh_ai_tensorsetdatatype)(OH_AI_TensorHandle tensor, OH_AI_DataType type) | Sets the data type of a tensor.|
| [OH_AI_TensorGetDataType](_mind_spore.md#oh_ai_tensorgetdatatype)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Obtains the data type of a tensor. |
| [OH_AI_TensorGetDataType](_mind_spore.md#oh_ai_tensorgetdatatype)(const OH_AI_TensorHandle tensor) | Obtains the tensor type.|
| [OH_AI_TensorSetShape](_mind_spore.md#oh_ai_tensorsetshape)([OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor, const int64_t \*shape, size_t shape_num) | Sets the shape of a tensor. |
| [OH_AI_TensorGetShape](_mind_spore.md#oh_ai_tensorgetshape)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor, size_t \*shape_num) | Obtains the shape of a tensor. |
| [OH_AI_TensorSetFormat](_mind_spore.md#oh_ai_tensorsetformat)([OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor, [OH_AI_Format](_mind_spore.md#oh_ai_format) format) | Sets the tensor data format. |
| [OH_AI_TensorSetFormat](_mind_spore.md#oh_ai_tensorsetformat)(OH_AI_TensorHandle tensor, OH_AI_Format format) | Sets the tensor data format.|
| [OH_AI_TensorGetFormat](_mind_spore.md#oh_ai_tensorgetformat)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Obtains the tensor data format. |
| [OH_AI_TensorGetFormat](_mind_spore.md#oh_ai_tensorgetformat)(const OH_AI_TensorHandle tensor) | Obtains the tensor data format.|
| [OH_AI_TensorSetData](_mind_spore.md#oh_ai_tensorsetdata)(OH_AI_TensorHandle tensor, void \*data) | Sets the tensor data.|
| [OH_AI_TensorGetData](_mind_spore.md#oh_ai_tensorgetdata)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Obtains the pointer to tensor data. |
| [OH_AI_TensorGetData](_mind_spore.md#oh_ai_tensorgetdata)(const OH_AI_TensorHandle tensor) | Obtains the pointer to tensor data.|
| [OH_AI_TensorGetMutableData](_mind_spore.md#oh_ai_tensorgetmutabledata)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Obtains the pointer to variable tensor data. If the data is empty, memory will be allocated. |
| [OH_AI_TensorGetMutableData](_mind_spore.md#oh_ai_tensorgetmutabledata)(const OH_AI_TensorHandle tensor) | Obtains the pointer to variable tensor data. If the data is empty, memory will be allocated.|
| [OH_AI_TensorGetElementNum](_mind_spore.md#oh_ai_tensorgetelementnum)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Obtains the number of tensor elements. |
| [OH_AI_TensorGetElementNum](_mind_spore.md#oh_ai_tensorgetelementnum)(const OH_AI_TensorHandle tensor) | Obtains the number of tensor elements.|
| [OH_AI_TensorGetDataSize](_mind_spore.md#oh_ai_tensorgetdatasize)(const[OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor) | Obtains the number of bytes of the tensor data. |
| [OH_AI_TensorGetDataSize](_mind_spore.md#oh_ai_tensorgetdatasize)(const OH_AI_TensorHandle tensor) | Obtains the number of bytes of the tensor data.|
| [OH_AI_TensorSetUserData](_mind_spore.md#oh_ai_tensorsetuserdata)([OH_AI_TensorHandle](_mind_spore.md#oh_ai_tensorhandle) tensor, void \*data, size_t data_size) | Sets the tensor as the user data. This function allows you to reuse user data as the model input, which helps to reduce data copy by one time.|
@@ -110,11 +110,11 @@ You can use either the ArtTS or native API to determine whether an API is availa
...
@@ -110,11 +110,11 @@ You can use either the ArtTS or native API to determine whether an API is availa
- Method 2: Import a module using the **import** API. If the current device does not support the module, the import result is **undefined**. Before using an API, you must make sure the API is available.
- Method 2: Import a module using the **import** API. If the current device does not support the module, the import result is **undefined**. Before using an API, you must make sure the API is available.
```ts
```ts
import geolocation from '@ohos.geolocation';
import geolocationManager from '@ohos.geoLocationManager';
| **Source Code of the Latest Release**| **Version**| **Site**| **SHA-256 Checksum**| **Software Package Size**|
| **Source Code of the Latest Release**| **Version**| **Site**| **SHA-256 Checksum**| **Software Package Size**|
| Full code base (for mini, small, and standard systems) | 4.0 Beta1 | [Download](https://repo.huaweicloud.com/openharmony/os/4.0-Beta1/code-v4.0-Beta1.tar.gz)| [Download](https://repo.huaweicloud.com/openharmony/os/4.0-Beta1/code-v4.0-Beta1.tar.gz.sha256)| 26.2 GB |
| Full code base (for mini, small, and standard systems) | 4.0 Beta2 | [Download](https://repo.huaweicloud.com/openharmony/os/4.0-Beta2/code-v4.0-Beta2.tar.gz)| [Download](https://repo.huaweicloud.com/openharmony/os/4.0-Beta2/code-v4.0-Beta2.tar.gz.sha256)| 27.7 GB |
@@ -11,45 +11,45 @@ The following figure shows the context structure of the Startup subsystem.
...
@@ -11,45 +11,45 @@ The following figure shows the context structure of the Startup subsystem.
When the system is powered on, the kernel loads and starts services and applications as follows:
When the system is powered on, the kernel loads and starts services and applications as follows:
1. The kernel loads the init process, which is specified by **cmdline** of the kernel when the bootloader starts the kernel.
1. The kernel loads the init process, which is specified by `cmdline` of the kernel when the bootloader starts the kernel.
2. After the init process is started, **tmpfs** and **procfs** are mounted and basic **dev** nodes are created to establish a basic root file system.
2. After the init process is started, `tmpfs` and `procfs` are mounted and basic `dev` nodes are created to establish a basic root file system.
3. The init process starts the ueventd process to listen for device hot-swap events in the kernel and creates **dev** nodes for related devices as well as partitions for the block device.
3. The init process starts the ueventd process to listen for device hot-swap events in the kernel and creates `dev` nodes for related devices as well as partitions for the block device.
4. After mounting partitions (**system** and **vendor**) of the block device, the init process scans for the init startup script of each system service and starts the respective system ability (SA).
4. After mounting partitions (`system` and `vendor`) of the block device, the init process scans for the init startup script of each system service and starts the respective system ability (SA).
5. Each SA registers with the samgr process, which serves as the service registration center. The samgr process assigns each SA with an ID, which will be used by an application to access the desired SA.
5. Each SA registers with the samgr process, which serves as the service registration center. The samgr process assigns each SA with an ID, which will be used by an application to access the desired SA.
6. The foundation process sends the application startup request to the appspawn process. The foundation implements application lifecycle management. It is a special SA service process that provides the user program management framework and basic services.
6. The foundation process implements application lifecycle management. It is a special SA service process that provides the user program management framework and basic services.
7.The appspawn process directly spawns the application process, eliminating the need for the application to load the JS runtime environment. This reduces the application startup time.
7.For an application, loading of the JS running environment involves a great deal of preparations. To reduce the application startup time, the appspawn process directly spawns an application process once receiving an application startup request from the foundation process.
The Startup subsystem consists of the following modules:
The Startup subsystem consists of the following modules:
- init module
- init Module
This module corresponds to the init process, which is the first user-mode process started after the kernel is initialized. After the init process starts, it reads and parses the **init.cfg** file. Based on the parsing result, the init module executes the commands listed in Table 2 in [Job Management](../subsystems/subsys-boot-init-jobs.md) and starts the key system service processes in sequence with corresponding permissions granted.
This module corresponds to the init process, which is the first user-space process started after the kernel is initialized. After the init process starts, it reads and parses the `init.cfg` file. Based on the parsing result, the init module executes the commands listed in Table 2 in [Job Management](../subsystems/subsys-boot-init-jobs.md#available-apis) and starts the key system service processes in sequence with corresponding permissions granted.
- ueventd module
- ueventd module
This module listens for **netlink** events about hot swap of kernel device drivers and dynamically manages the **dev** node of the corresponding device based on the event type.
This module listens for **netlink** events about hot plug of kernel device drivers and dynamically manages the `dev` node of the corresponding device based on the event type.
- appspawn module
- appspawn Module
This module spawns application processes upon receiving commands from the foundation, configures permissions for new processes, and calls the entry function of the application framework.
This module spawns application processes upon receiving commands from the foundation, configures permissions for new processes, and calls the entry function of the application framework.
- bootstrap module
- bootstrap Module
This module provides entry identifiers for starting services and features. When SAMGR is started, the entry function identified by bootstrap is called and system services are started.
This module provides entry identifiers for starting services and features. When samgr is started, the entry function identified by bootstrap is called and system services are started.
- syspara module
- syspara
This module provides APIs for obtaining device information, such as the product name, brand name, and manufacturer name, based on the OpenHarmony Product Compatibility Specifications (PCS). It also provides APIs for setting and obtaining system attributes.
This module provides APIs for obtaining device information, such as the product name, brand name, and manufacturer name, based on the OpenHarmony Product Compatibility Specifications (PCS). It also provides APIs for setting and obtaining system attributes.
## Constraints
## Constraints
The source code directory of the Startup subsystem varies according to the platform.
The source code directory of the Startup subsystem varies according to the platform.
**Table 1** Directories and applicable platforms of the Startup subsystem
**Table 1** Directories and applicable platforms of the Startup subsystem
| Source Code Directory| Applicable Platform|
| Name| Applicable Platform|
| -------- | -------- |
| -------- | -------- |
| base/startup/appspawn_lite | Small-system devices (reference memory ≥ 1 MiB), for example, Hi3516D V300 and Hi3518E V300|
| base/startup/appspawn_lite | Small-system devices (reference memory ≥ 1 MiB), for example, Hi3516D V300 and Hi3518E V300|
| base/startup/bootstrap_lite | Mini-system devices (reference memory ≥ 128 KiB), for example, Hi3861 V100|
| base/startup/bootstrap_lite | Mini-system devices (reference memory ≥ 128 KiB), for example, Hi3861 V100|
...
@@ -57,14 +57,14 @@ The Startup subsystem consists of the following modules:
...
@@ -57,14 +57,14 @@ The Startup subsystem consists of the following modules:
| base/startup/syspara_lite | - Mini-system devices (reference memory ≥ 128 KiB), for example, Hi3861 V100<br>- Small-system devices (reference memory ≥ 1 MiB), for example, Hi3516D V300 and Hi3518E V300|
| base/startup/syspara_lite | - Mini-system devices (reference memory ≥ 128 KiB), for example, Hi3861 V100<br>- Small-system devices (reference memory ≥ 1 MiB), for example, Hi3516D V300 and Hi3518E V300|
- init module
- init module
- To start a system service, you first need to write a boot script file named **init.cfg**, in which you define the service name, path of executable files, permissions, etc.
- To start a system service, you first need to write a boot script file named `init.cfg`, in which you define the service name, path of executable files, permissions, etc.
- The boot script of each system service is installed in the **/system/etc/init** directory. The init process scans this directory for the boot script to execute.
- The boot script of each system service is installed in the `/system/etc/init` directory. The init process scans this directory for the boot script to execute.
- When porting a new chip platform, you need to add the **/vendor/etc/init/init.{hardware}.cfg** file that contains the platform-level initialization configuration. This file is used to implement platform-level initialization, for example, installing the ko driver and configuring information on the related **/proc** nodes.
- When porting a new chip platform, you need to add the `/vendor/etc/init/init.{hardware}.cfg` file that contains the platform-level initialization configuration. This file is used to implement platform-level initialization, for example, installing the ko driver and configuring information on the related `/proc` nodes.
> **NOTE**
> **NOTE**
>
>
> The configuration file **init.cfg** must be in JSON format.
> The configuration file `init.cfg` must be in JSON format.
- bootstrap module: The zInit code must be configured in the link script.
- bootstrap module: The zInit code must be configured in the link script.
...
@@ -83,67 +83,67 @@ By default, the OpenHarmony standard system supports the images listed in the fo
...
@@ -83,67 +83,67 @@ By default, the OpenHarmony standard system supports the images listed in the fo
On each development board, you need to partition the memory to store the preceding images. When the SoC starts, the bootloader loads the images as follows:
On each development board, you need to partition the memory to store the preceding images. When the SoC starts, the bootloader loads the images as follows:
- Initializes hardware such as the ROM and RAM, and loads the partition table information.
- Initializes hardware such as the ROM and RAM, and loads the partition table information.
- Loads the **boot.img** file based on the partition table and parses and loads the **ramdisk.img** file to the memory.
- Loads the `boot.img` file based on the partition table and parses and loads the `ramdisk.img` file to the memory.
- Prepares the partition table information and ramdisk address and enters the kernel, so that the kernel loads the ramdisk image and starts the init process.
- Prepares the partition table information and ramdisk address and enters the kernel, so that the kernel loads the the ramdisk image and starts the init process.
- Waits until the init process prepares the initial file system and mounts **required.fstab** (including **system.img** and **vendor.img**) to the file system.
- Waits until the init process prepares the initial file system and mounts `required.fstab` (including `system.img` and `vendor.img`) to the file system.
- Scans the boot scripts in the **etc/init** directory in **system.img** and **vendor.img** and runs each boot command.
- Scans the boot scripts in the `etc/init` directory in `system.img` and `vendor.img` and runs each boot command.
### U-Boot Process
### U-Boot Process
[U-Boot](https://elinux.org/U-Boot) is used as an example to describe the key image loading process. When U-Boot starts the system, it passes the boot information to the system by using **bootargs**.
[U-Boot](https://elinux.org/U-Boot) is used as an example to describe the key image loading process. When U-Boot starts the system, it passes the boot information to the system by using `bootargs`.
-**boot.img** loading and parsing
-`boot.img` loading and parsing
-**boot.img** format
-`boot.img` format
**boot.img** building and loading vary depending on the platform. The implementation on mainstream OpenHarmony platforms is as follows:
`boot.img` building and loading varies depending on the platform. The implementation on mainstream OpenHarmony platforms is as follows:
- Hi3516DV300
- Hi3516DV300
On this platform, the **boot.img** file uses the flattened image tree (FIT) format. It is generated by the Mkimage tool by packing the **zImage-dtb** and **cpio** images, which are generated after kernel compilation, based on the information in the **.its** file.
On this platform, the `boot.img` file uses the flattened image tree (FIT) format. It is generated by the Mkimage tool by packing the `ramdisk.img` files, which are packed by using `zImage-dtb` or `cpio` during kernel building, based on the information in the `its` file.
The related files and tool are described as follows:
The related files and tool are described as follows:
1. **.its** file
1. `its` file
An image source file that describes the information about the image to be generated. You need to create the file, for example, the **ohos.its** file on the Hi3516 platform.
An image source file that describes the information about the image to be generated. You need to create the file, for example, the `ohos.its` file on the Hi3516 platform.
2. Mkimage packaging tool
2. Mkimage packaging tool
A tool that parses **its** files and packs the corresponding images based on the image configuration to generate an **itb** file, that is, **boot.img**.
A tool that parses `its` files and packs the corresponding images based on the image configuration to generate an `itb` file, that is, `boot.img`.
3. ramdisk
3. `ramdisk` image
An image file generated by packing **cpio** images.
A `ramdisk.img` file packed by using `cpio`.
4. zImage-dtb
4. `zImage-dtb` image
An image file that contains the compressed kernel image and device description file image.
An image that contains the compressed kernel image and device description file image.
- rk3568
- rk3568
On this platform, the **boot.img** file is named **boot_linux.img**. The packaged files are different from those on the Hi3516D V300 platform.
On this platform, the `boot.img` file is named `boot_linux.img`. The packaged files are different from those on the Hi3516D V300 platform.
1. Image
1. Image
Image file generated after kernel compilation.
Image file generated after kernel building.
2. toybrick.dtb
2. toybrick.dtb
A file that is similar to the device description file image generated after dts compilation.
A file that is similar to the device description file image generated through `dts` building.
3. ramdisk.img
3. ramdisk.img
An image file generated by packing **cpio** images.
A `ramdisk.img` file packed by using `cpio`.
- U-Boot loading
- U-Boot loading
The ramdisk boot process is supported. In this scenario, you need to modify the product configuration file in **productdefine** and enable ramdisk generation by setting **enable_ramdisk**. The ramdisk processing method varies according to the platform. Take the Hi3516D V300 platform as an example. You need to change the original U-Boot parameter to **root=/dev/ram0 initrd=0x84000000,0x292e00**.
The ramdisk boot process is supported. In this scenario, you need to modify the product configuration file in `productdefine` and enable ramdisk generation by setting `enable_ramdisk`. The ramdisk processing method varies according to the platform. Take the Hi3516D V300 platform as an example. You need to change the original U-Boot parameter to `root=/dev/ram0 initrd=0x84000000,0x292e00`.
- Kernel start
- Kernel start
When the U-Boot starts the kernel, it can pass key information to the kernel through **bootargs**. The information varies according to the platform. The main fields are described in the table below.
When U-Boot starts the kernel, it can pass key information to the kernel through `bootargs`. The information varies according to the platform. The main fields are described in the table below.
@@ -151,53 +151,53 @@ On each development board, you need to partition the memory to store the precedi
...
@@ -151,53 +151,53 @@ On each development board, you need to partition the memory to store the precedi
| init | /init | |
| init | /init | |
| blkdevparts | mmcblk0:1M(boot),15M(kernel),200M(system),200M(vendor),<br>2M(misc),20M(updater),-(userdata) | Partition table information. The kernel creates physical partitions based on the information. |
| blkdevparts | mmcblk0:1M(boot),15M(kernel),200M(system),200M(vendor),<br>2M(misc),20M(updater),-(userdata) | Partition table information. The kernel creates physical partitions based on the information. |
| root | /dev/ram0 (Hi3516D V00) , root=PARTUUID=614e0000-0000 rw (rk3568) | Boot device loaded by the kernel.|
| root | /dev/ram0 (Hi3516DV00), root=PARTUUID=614e0000-0000 rw (rk3568) | Boot device loaded by the kernel.|
| rootfstype | ext4 | Type of the root file system.|
| rootfstype | ext4 | Type of the root file system.|
| default_boot_device | soc/10100000.himci.eMMC | (Recommended information) Default boot device. In the first phase of the boot process, a soft link will be created for the required device based on this field.|
| default_boot_device | soc/10100000.himci.eMMC | (Recommended information) Default boot device. In the first phase of the boot process, a soft link will be created for the `required` partition device based on this field.|
| ohos.required_mount.xxx | /dev/block/platform/soc/10100000.himci.eMMC/by-name/xxx@/usr@ext4@ro,barrier=1@wait,required | The fstab information is first read from cmdline. If this fails, the system will try to read the information from the **fstab.required** file.|
| ohos.required_mount.xxx | /dev/block/platform/soc/10100000.himci.eMMC/by-name/xxx@/usr@ext4@ro,barrier=1@wait,required | The fstab information is first read from cmdline. If this fails, the system will try to read the information from the `fstab.required` file.|
- Mounting of required partitions
- Mounting of `required` partitions
A required partition is one that is essential for system boot. It must be mounted before level-2 boot. For mandatory images like system and vendor images, the corresponding block device files must be created before mounting. This is usually done based on UEVENT events reported by the kernel. The init process needs to know the main device directory of the storage device. The bootloader passes the primary device directory of the storage device to the init process through **default_boot_device**.
A `required` partition is one that is essential for system boot. It must be mounted before level-2 boot. For mandatory images like system and vendor images, the corresponding block device files must be created before mounting. This is usually done based on the **uevent** messages reported by the kernel. The init process needs to know the main device directory of the storage device. The bootloader process passes the primary device directory of the storage device to the init process through `default_boot_device`.
Currently, the init process obtains required partition information in two ways. The init process first reads the required partition information through the **bootargs** in **/proc/cmdline**. If the attempt fails, the init process reads the **fstab.required** file in the ramdisk image.
Currently, the init process obtains `required` partition information in two ways. The init process first reads the `required` partition information through `bootargs` in `/proc/cmdline`. If the attempt fails, the init process reads the `fstab.required` file in the ramdisk image.
- Logic of block device creation
- Logic of block device creation
- Preparation
- Preparation
1. The init process reads the required fstab information from **cmdline**. If the attempt fails, the init process reads the **fstab.required** file to obtain **PARTNAME** of the block devices that must be mounted, for example, **system** or **vendor**.
1. The init process reads the `fstab.required` file from `cmdline`. If the attempt fails, the init process reads the `fstab.required` file to obtain `PARTNAME` of the block devices that must be mounted, for example, `system` or `vendor`.
2. Create a socket for receiving uevent messages reported by the kernel and read **default_boot_device** from **/proc/cmdline**.
2. Create a socket for receiving **uevent** messages reported by the kernel and read `default_boot_device` from `/proc/cmdline`.
3. Traverse the **/sys/devices** directory with the fstab information and socket handle to get the kernel prepared for reporting uevent messages.
3. Traverse the `/sys/devices` directory with the fstab information and socket handle to get the kernel prepared for reporting **uevent** messages.
- Event triggering
- Trigger event
1. Use **ueventd** to trigger the kernel to report a uevent message.
1. Use **ueventd** to trigger the kernel to report a **uevent** message.
2. Check whether **partitionName** in the uevent message matches with device information in the required fstab.
2. Check whether `partitionName` in the **uevent** message matches with device information in the `fstab.required` file.
3. If they match, format the device node path and proceed with device node creation.
3. If they match, format the device node path and proceed with device node creation.
- Device node creation
- Creating Nodes
1. Format the path of the soft link to be created for required block device nodes. A soft link helps facilitate access to device nodes in user mode and improve their readability.
1. Format the path of the soft link to be created for required block device nodes. A soft link helps facilitate access to device nodes in user mode and improve their readability.
2. Create device nodes based on the primary and secondary device numbers passed in the uevent message, and the device node path and soft link path obtained in the previous steps. Meanwhile, create a soft link for them.
2. Create device nodes based on the primary and secondary device numbers passed in the **uevent** message, and the device node path and soft link path obtained in the previous steps. Meanwhile, create a soft link for them.
Up to now, the creation of block device nodes is complete.
Up to now, the creation of block device nodes is complete.
- Mapping with **default_boot_device**
- Mapping with `default_boot_device`
The kernel writes **bootargs** information to **/proc/cmdline**. The information includes **default_boot_device**, which specifies the primary device directory required for system boot. The content prefixed with **ohos.required_mount.** is the partition mounting information required for system boot. It should be the same as that in the **fstab.required** file. In addition, the block device node in the partition mounting information should be a device node pointed by the soft link under **by-name** in the **default_boot_device** directory. For example, if the value of **default_boot_device** is **soc/10100000.himci.eMMC**, then the value of **ohos.required_mount.system** contains **/dev/block/platform/soc/10100000.himci.eMMC/by-name/system**, which is the soft link pointing to the system device node.
The kernel writes `bootargs` information to `/proc/cmdline`. The information includes `default_boot_device`, which specifies the primary device directory required for system boot. The content prefixed with `ohos.required_mount.` is the partition mounting information required for system boot. It should be the same as that in the `fstab.required` file. In addition, the block device node in the partition mounting information should be a device node pointed by the soft link under `by-name` in the `default_boot_device` directory. For example, if the value of `default_boot_device` is `soc/10100000.himci.eMMC`, then the value of `ohos.required_mount.system` contains `/dev/block/platform/soc/10100000.himci.eMMC/by-name/system`, which is the soft link pointing to the system device node.
During creation of a block device node, the device path will be matched against the value of **default_boot_device**. If the matching is successful, a soft link pointing to the real block device node will be created in **/dev/block/by-name**. In this way, device node access is made irrelevant to the chip platform.
During creation of a block device node, the device path will be matched against the value of `default_boot_device`. If the matching is successful, a soft link pointing to the real block device node will be created in `/dev/block/by-name`. In this way, device node access is made irrelevant to the chip platform.
- Example
- Example
This example assumes the **system** partition as the required partition on the Hi3516D V300 platform to illustrate the boot process. During this process, the init process reads the required fstab information, creates a block device node, and mounts it to the required partition. The following provides the key code snippets and log information as reference for debugging.
This example assumes the `system` partition as the `required` partition on the Hi3516D V300 platform to illustrate the boot process. During this process, the init process reads the `fstab.required` file, creates a block device node, and mounts it to the `required` partition. The following provides the key code snippets and log information as reference for debugging.
> **NOTE**
> **NOTE**
>
>
> The code snippets below are exhibited in the logical sequence. They are not neighboring to each other in the source code.
> The code snippets below are exhibited in the logical sequence. They are not neighboring to each other in the source code.
@@ -209,20 +209,20 @@ On each development board, you need to partition the memory to store the precedi
...
@@ -209,20 +209,20 @@ On each development board, you need to partition the memory to store the precedi
if (access(fstabFile, F_OK) != 0) {
if (access(fstabFile, F_OK) != 0) {
fstabFile = "/system/etc/fstab.required";
fstabFile = "/system/etc/fstab.required";
}
}
INIT_ERROR_CHECK(access(fstabFile, F_OK) == 0, abort(), "Failed to get fstab.required");
INIT_ERROR_CHECK(access(fstabFile, F_OK) == 0, abort(), "Failed get fstab.required");
fstab = ReadFstabFromFile(fstabFile, false);
fstab = ReadFstabFromFile(fstabFile, false);
}
}
return fstab;
return fstab;
}
}
```
```
The preceding code provides two methods for the init process to obtain the fstab information. First, the init process calls **LoadFstabFromCommandLine()** to read the fstab information from **cmdline**. If the attempt fails, the init process reads the **fstab.required** file to obtain the fstab information.
The preceding code provides two methods for the init process to obtain the fstab information. First, the init process calls `LoadFstabFromCommandLine()` to read the fstab information from `cmdline`. If the attempt fails, the init process outputs log information and continues to read the `fstab.required` file for the fstab information.
For the **system** partition, the key information read from **devices** is as follows:
For the `system` partition, the key information read from `devices` is as follows:
```
```
/dev/block/platform/fe310000.sdhci/by-name/system
/dev/block/platform/fe310000.sdhci/by-name/system
```
```
2. Create a socket and trigger the kernel to report a uevent message.
2. Create a socket and trigger the kernel to report a **uevent** message.
```
```
static int StartUeventd(char **requiredDevices, int num)
static int StartUeventd(char **requiredDevices, int num)
{
{
...
@@ -238,15 +238,15 @@ On each development board, you need to partition the memory to store the precedi
...
@@ -238,15 +238,15 @@ On each development board, you need to partition the memory to store the precedi
}
}
```
```
3. Read information from **cmdline** to obtain **default_boot_device**.
3. Read information from `cmdline` to obtain `default_boot_device`.
```
```
char *buffer = ReadFileData("/proc/cmdline");
char *buffer = ReadFileData("/proc/cmdline");
int ret = GetProcCmdlineValue("default_boot_device", buffer, bootDevice, CMDLINE_VALUE_LEN_MAX);
int ret = GetProcCmdlineValue("default_boot_device", buffer, bootDevice, CMDLINE_VALUE_LEN_MAX);
INIT_CHECK_ONLY_ELOG(ret == 0, "Failed to get default_boot_device value from cmdline");
INIT_CHECK_ONLY_ELOG(ret == 0, "Failed get default_boot_device value from cmdline");
```
```
In this example, the value of **default_boot_device** is **soc/10100000.himci.eMMC**. The value is stored in the global variable **bootDevice** and will be matched with the path of the **system** partition device when a soft link is created.
In this example, the value of `default_boot_device` is `soc/10100000.himci.eMMC`. The value is stored in the global variable `bootDevice` and will be matched with the path of the `system` partition device when a soft link is created.
4. Process the uevent message of the required partition device.
4. Process the **uevent** message of the `required` partition device.
```
```
if (uevent->partitionName == NULL) {
if (uevent->partitionName == NULL) {
INIT_LOGI("Match with %s for %s", devices[i], uevent->syspath);
INIT_LOGI("Match with %s for %s", devices[i], uevent->syspath);
...
@@ -264,11 +264,11 @@ On each development board, you need to partition the memory to store the precedi
...
@@ -264,11 +264,11 @@ On each development board, you need to partition the memory to store the precedi
break;
break;
}
}
```
```
In this step, the device information in **devices** is matched with the uevent message reported by the kernel. The value of **uevent->partitionName** should be **system** for the uevent message of the **system** partition device. If the value matches the **/dev/block/platform/fe310000.sdhci/by-name/system** field in **devices**, the uevent message of the **system** partition device will be processed.
In this step, the device information in `devices` is matched with the **uevent** message reported by the kernel. The value of `uevent -> partitionName` should be `system` for the **uevent** message of the `system` partition device. If the value matches the `/dev/block/platform/fe310000.sdhci/by-name/system` field in `devices`, the **uevent** message of the `system` partition device will be processed.
5. Create the required device node and the corresponding soft link.
5. Create the `required` partition device node and the corresponding soft link.
The first thing is to format the path of the corresponding soft link. In this step, the value of **default_boot_device** in **bootargs** will be matched with the path of the required device node in the uevent message, so as to create a platform-irrelevant soft link that points to the device node. The key code is as follows:
The first thing is to format the path of the corresponding soft link. In this step, the value of `default_boot_device` in `bootargs` will be matched with the path of the required device node in the **uevent** message, so as to create a platform-irrelevant soft link that points to the device node. The key code is as follows:
```
```
if (STRINGEQUAL(bus, "/sys/bus/platform")) {
if (STRINGEQUAL(bus, "/sys/bus/platform")) {
INIT_LOGV("Find a platform device: %s", parent);
INIT_LOGV("Find a platform device: %s", parent);
...
@@ -285,29 +285,28 @@ On each development board, you need to partition the memory to store the precedi
...
@@ -285,29 +285,28 @@ On each development board, you need to partition the memory to store the precedi
```
```
The key variables in the code are as follows:
The key variables in the code are as follows:
- **bus**: a string that saves the path of the bus connected to the current device.
- `bus`: a string that saves the path of the bus connected to the current device.
- **parent**: a string that stores the device path obtained from **syspath** in the uevent message.
- `parent`: a string that stores the device path obtained from `uevent -> syspath` in the **uevent** message.
- **links**: a pointer to the memory that stores the soft link path.
- `links`: a pointer to the memory that stores the soft link path.
- **bootDevice**: a string that stores the value of **default_boot_device** in **bootargs**
- `bootDevice`: a string that stores the value of `default_boot_device` in `bootargs`.
According to the code, the corresponding soft link is created for the device only when the type of the connected bus is `platform`. The path of the soft link is as follows:
According to the code, the corresponding soft link is created for the device only when the type of the connected bus is **platform**. The path of the soft link is as follows:
Therefore, when processing the uevent message of the device, the init process compares the device path with that in **bootDevice**, that is, **soc/10100000.himci.eMMC**. If they match, a soft link will be created as follows:
Therefore, when processing the **uevent** message of the device, the init process compares the device path with that in `bootDevice`, that is, `soc/10100000.himci.eMMC`. If they match, a soft link will be created as follows:
```
```
/dev/block/by-name/system
/dev/block/by-name/system
```
```
After the soft link path is formatted, the init process creates the device node and soft link based on the information in the uevent message. Up to now, the creation of a device node for the system partition is complete.
After the soft link path is formatted, the init process creates the device node and soft link based on the information in the **uevent** message. Up to now, the creation of a device node for the `system` partition is complete.
6. Mount the required partition.
6. Mount the `required` partition.
After a device node is created, mount it to the corresponding partition. The code is as follows:
After a device node is created, mount it to the corresponding partition. The code is as follows:
```
```
...
@@ -320,45 +319,47 @@ On each development board, you need to partition the memory to store the precedi
...
@@ -320,45 +319,47 @@ On each development board, you need to partition the memory to store the precedi
return rc;
return rc;
}
}
```
```
Therefore, when "Mount required partitions" is displayed, the required partition device is ready for mounting. During the mounting process, the following key information is printed:
Therefore, when "Mount required partitions" is displayed, the `required` partition device is ready for mounting. During the mounting process, the following key information is printed:
```
```
BEGET_LOGE("Unsupported file system \" %s \"", item->fsType);
BEGET_LOGE("Unsupported file system \" %s \"", item->fsType);
// The current file system type is not supported.
```
The current file system type is not supported.
```
BEGET_LOGE("Cannot get stat of \" %s \", err = %d", target, errno);
BEGET_LOGE("Cannot get stat of \" %s \", err = %d", target, errno);
// Failed to obtain the mount point directory.
```
The attempt to obtain the mount point directory has failed.
```
BEGET_LOGE("Failed to create dir \" %s \", err = %d", target, errno);
BEGET_LOGE("Failed to create dir \" %s \", err = %d", target, errno);
// Failed to create the mount point directory.
```
The attempt to create the mount point directory has failed.
```
BEGET_LOGI("Mount %s to %s successful", item->deviceName, item->mountPoint);
BEGET_LOGI("Mount %s to %s successful", item->deviceName, item->mountPoint);
// The device is successfully mounted. The output also contains the name of the mounted device and information about the mount point.
```
```
The device is successfully mounted. The output also contains the name of the mounted device and information about the mount point.
- Mounting of the `vendor` partition
- Mounting of vendor partitions
After mounting required partitions, the init process scans each script file in the `vendor` partition. The initialization scripts related to the chip or development board is named in the format of `/vendor/etc/init.{ohos.boot.hardware}.cfg`. Wherein, `/vendor/etc/fstab.{ohos.boot.hardware}` represents the extended mount partition file; `hardware` is sourced from `bootargs`, which is passed from the bootloader to the kernel.
After mounting required partitions, the init process scans each script file in the **vendor** partition. The initialization scripts related to the chip or development board are named in the format of **/vendor/etc/init.{ohos.boot.hardware}.cfg**. Wherein, **/vendor/etc/fstab.{ohos.boot.hardware}** represents the extended mount partition file; **hardware** is sourced from **bootargs**, which is passed from the bootloader to the kernel.
### Boot Loading Without ramdisk
### Boot Loading Without ramdisk
Certain development boards do not use the ramdisk boot mode. For these boards, the boot process is implemented by directly loading the **system.img** file through the kernel. In such case, you need to modify the product configuration file in **productdefine**. Specifically, you need to turn off the **enable_ramdisk** switch to disable ramdisk generation so that the init process does not boot from ramdisk to system.
Certain development boards do not use the ramdisk boot mode. For these boards, the boot process is implemented by directly loading the `system.img` file through the kernel. In such case, you need to modify the product configuration file in `productdefine`. Specifically, you need to turn off the `enable_ramdisk` switch to disable ramdisk generation so that the init process does not boot from ramdisk to system.
Boot loading in this scenario is similar to that in the preceding section. The only difference is as follows: If ramdisk is used, the init process mounts **system.img** to the **/usr** directory and then switches to the **/usr** directory using **chroot**. If ramdisk is not used, the init process directly runs the **init.cfg** file.
The boot loading process in this scenario is similar to that in the preceding section. The only difference is as follows: If ramdisk is used, the init process mounts `system.img` to the `/usr` directory and then switches to the `/usr` directory using `chroot`. If ramdisk is not used, the init process directly runs the `init.cfg` file.
For boot loading without ramdisk (that is, system as root), the block device where the root file system is located is passed to the kernel through **bootargs**, for example, **root=/dev/mmcblk0p5 and rootfstype=ext4**. During initialization of the root file system, the kernel parses the **root** field in **bootargs** to complete mounting of the root file system.
For the boot loading process without ramdisk, that is, system as root, the block device where the root file system is located is passed to the kernel through `bootargs`, for example, `root=/dev/mmcblk0p5, rootfstype=ext4`. During initialization of the root file system, the kernel parses the `root` field in `bootargs` to complete mounting of the root file system.
### Partition A/B Booting
### Partition A/B Booting
Currently, OpenHarmony supports booting from partitions A and B (active and standby system partitions), both of which are configured in the same device storage. During the booting process, the system partition to load is determined based on the slot of the active partition. Partition A/B booting is supported only for the system partition and chipset partition.
Currently, OpenHarmony supports booting from partitions A and B (active and standby system partitions), both of which are configured in the same device storage. During the booting process, the system partition to load is determined based on the slot of the active partition. Partition A/B booting is supported only for the `system` and `chipset` partitions.
- bootslots
- bootslots
Number of the supported boot partitions. If **bootslots** is set to **2**, the system can boot from both system partitions A and B. If **bootslots** is set to **1**, partition A/B booting is not supported and the system can boot only from the default system partition.
Number of the supported boot partitions. If `bootslots` is set to `2`, the system can boot from both system partitions A and B. If `bootslots` is set to `1`, partition A/B booting is not supported and the system can boot only from the default system partition.
In the initial phase of init process startup, the system reads the **bootslots** value to determine whether partition A/B booting is supported. If yes, the system continues to determine the system partition to mount. If not, the system mounts the system partition based on the default fstab. The API for the init process to obtain the **bootslots** value is as follows:
In the initial phase of init process startup, the system reads the `bootslots` value to determine whether partition A/B booting is supported. If yes, the system continues to determine the system partition to mount. If not, the system mounts the system partition based on the default fstab. The API for the init process to obtain the `bootslots` value is as follows:
```
```
int GetBootSlots(void)
int GetBootSlots(void)
{
{
...
@@ -368,16 +369,16 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
...
@@ -368,16 +369,16 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
return GetSlotInfoFromCmdLine("bootslots");
return GetSlotInfoFromCmdLine("bootslots");
}
}
```
```
After normal system startup, you can obtain the **bootslots** value from the system parameter **ohos.boot.bootslots** to check whether the current system supports partition A/B booting. The command for obtaining **ohos.boot.bootslots** is as follows:
After normal system startup, you can obtain the `bootslots` value from the system parameter `ohos.boot.bootslots` to check whether the current system supports partition A/B booting. The command for obtaining `ohos.boot.bootslots` is as follows:
```
```
param get ohos.boot.bootslots
param get ohos.boot.bootslots
```
```
- currentslot
- currentslot
Current system partition, for example, partition A or partition B. The value of **currentslot** is a number. For example, **1** indicates partition A, and **2** indicates partition B.
Current system partition, for example, partition A or partition B. The value of `currentslot` is a number. For example, `1` indicates partition A, and `2` indicates partition B.
In the initial phase of startup, the init process determines whether the system supports partition A/B booting based on **bootslots**. If the system does not support partition A/B booting, the init process directly boots from the default system partition instead of obtaining the **currentslot** value. If the system supports partition A/B booting, the init process obtains the **currentslot** value and determines whether partition A or partition B is the current system partition. The API for the init process to obtain the **currentslot** value is as follows:
In the initial phase of startup, the init process determines whether the system supports partition A/B booting based on `bootslots`. If the system does not support partition A/B booting, the init process directly boots from the default system partition instead of obtaining the `currentslot` value. If the system supports partition A/B booting, the init process obtains the `currentslot` value and determines whether partition A or partition B is the current system partition. The API for the init process to obtain the `currentslot` value is as follows:
```
```
int GetCurrentSlot(void)
int GetCurrentSlot(void)
{
{
...
@@ -396,10 +397,10 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
...
@@ -396,10 +397,10 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
}
}
```
```
- Partition A/B booting process
- Partition A/B Booting Process
1. Obtain the **currentslot** value to determine whether partition A or partition B is the current system partition.
1. Obtain the `currentslot` value to determine whether partition A or partition B is the current system partition.
2. Construct new partition mounting configuration based on the original fstab file, and add the suffix **a** or **b** to the partitions that support partition A/B booting, that is, system and chipset partitions.
2. Construct new partition mounting configuration based on the original `fstab` file, and add the suffix `_a` or `_b` to the partitions that support partition A/B booting, that is, system and chipset partitions.
3. Mount the partition added with the corresponding suffix and enter the second phase of startup. This phase occurs in partition A or B and concludes the partition A/B booting process.
3. Mount the partition added with the corresponding suffix and enter the second phase of startup. This phase occurs in partition A or B and concludes the partition A/B booting process.
The API for constructing new partition mounting configuration is as follows:
The API for constructing new partition mounting configuration is as follows:
...
@@ -420,7 +421,7 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
...
@@ -420,7 +421,7 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
}
}
```
```
- Development example
- Development Example
The following uses the rk3568 platform as an example to illustrate how to change from default partition booting to partition A/B booting.
The following uses the rk3568 platform as an example to illustrate how to change from default partition booting to partition A/B booting.
...
@@ -429,50 +430,51 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
...
@@ -429,50 +430,51 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
Use the original image to construct images of the partitions used for partition A/B booting, and test the partition A/B booting function.
Use the original image to construct images of the partitions used for partition A/B booting, and test the partition A/B booting function.
- Copy the **system** and **vendor** images, and add the suffix **\_b** to them.
- Copy the `system` and `vendor` images, and add the suffix `_b` to them.
- Add partitions **system_b** and **vendor_b** to the partition table in **parameter.txt**.
- Add partitions `system_b` and `vendor_b` to the partition table in the `parameter.txt` file.
2. Burn the images of the partitions used for partition A/B booting.
2. Burn the images of the partitions used for partition A/B booting.
- Import the partition configuration to the rk3568 burning tool, and select the **parameter.txt** file containing the **system_b** and **vendor_b** partitions.
- Import the partition configuration to the rk3568 burning tool, and select the `parameter.txt` file containing the `system_b` and `vendor_b` partitions.
- Select images (including **system_b** and **vendor_b** images) based on the new partition table configuration, and then burn the images.
- Select images (including `system_b` and `vendor_b` images) based on the new partition table configuration, and then burn the images.
3. After the configuration is complete, perform the following:
3. After the configuration is complete, perform the following:
1. Run the **cat /proc/cmdline** command. If the command output contains **bootslot=2**, the system supports partition A/B booting.
1. Run the `cat /proc/cmdline` command. If the command output contains `bootslot=2`, the system supports partition A/B booting.
2. Run the **param get ohos.boot.bootslot** command. If the command output contains **2**, the **bootslot** information is successfully written to the **parameter.txt**.
2. Run the `param get ohos.boot.bootslot` command. If the command output contains `2`, the `bootslot` information is successfully written to the `parameter.txt` file.
3. Run the **ls -l /dev/block/by-name** command. If the command output contains **system_b** and **vendor_b**, device nodes are successfully created in partition B.
3. Run the `ls -l /dev/block/by-name` command. If the command output contains `system_b` and `vendor_b`, device nodes are successfully created in partition B.
4. Run the **df -h** command to check the partitions mounted to the system.
4. Run the `df -h` command to check the partitions mounted to the system.
As shown in the figure, partition **mmcblk0p6** is mounted to the root file system (represented by a slash), and partition **mmcblk0p7** is mounted to **/vendor**. Based on the command output in step 3, **mmcblk0p6** is the **system** partition, and **mmcblk0p7** is the **vendor** partition. That is, the mounted partitions are the default partitions, that is, **system** and **vendor** partitions without suffixes. In other words, partition A is the default partition.
As shown in the figure, partition `mmcblk0p6` is mounted to the root file system (represented by a slash), and partition `mmcblk0p7` is mounted to `/vendor`. Based on the command output in step 3, `mmcblk0p6` is the `system` partition, and `mmcblk0p7` is the `vendor` partition. That is, the mounted partitions are the default partitions, that is, `system` and `vendor` partitions without suffixes. In other words, partition A is the default partition.
Next, let's try booting from partition B.
Next, let's try booting from partition B.
1) Run the **partitionslot setactive 2** command to set the slot of the active partition to **2**, that is, the slot of partition B.
1. Run the `partitionslot setactive 2` command to set the slot of the active partition to `2`, that is, the slot of partition B.
**mmcblk0p11** corresponds to **system_b**, and **mmcblk0p12** corresponds to **vendor_b**. That is, the system is successfully booted from partition B.
`mmcblk0p11` corresponds to `system_b`, and `mmcblk0p12` corresponds to `vendor_b`. That is, the system is successfully booted from partition B.
Deprecated **sendMessage** and replaced it with **sendShortMessage**.
**Change Impact**
**sendMessage** is deprecated since API version 10. **sendShortMessage** should be used to replace **sendMessage** in application development. The API function remains unchanged.
Changed the required permission of **getSimTelephoneNumber** from **ohos.permission.GET_TELEPHONY_STATE** to **ohos.permission.GET_PHONE_NUMBERS**.
**Change Impact**
The required permission of **getSimTelephoneNumber** is from **ohos.permission.GET_TELEPHONY_STATE** to **ohos.permission.GET_PHONE_NUMBERS** since API version 10.
An application needs to be apply for the **ohos.permission.GET_PHONE_NUMBERS** permission. The API function remains unchanged.
In the **module.json** file, add the **ohos.permission.GET_PHONE_NUMBERS** permission or replace the existing permission with it. The sample code is as follows:
