Skip to content

D
Docs

OpenHarmony / Docs
接近 2 年 前同步成功

通知 159
Star 292
Fork 28
D
Docs
提交 5205180c 编写于 作者: S shawn_he
浏览文件
操作

update doc 

Signed-off-by: Nshawn_he <shawn.he@huawei.com>
上级 3fa1dde9
展开全部 隐藏空白更改
内联 并排
Showing with 3041 addition and 1090 deletion
en/application-dev/device/inputdevice-guidelines.md
浏览文件 @ 5205180c
......@@ -29,7 +29,6 @@ When a user enters text, the input method determines whether to launch the virtu
1. Call the **getDeviceList** API to obtain the list of connected input devices. Call the **getKeyboardType** API to traverse all connected devices to check whether a physical keyboard exists. If a physical keyboard exists, mark the physical keyboard as connected. This step ensures that your application detects all inserted input devices before listening for device hot swap events.
2. Call the **on** API to listen for device hot swap events. If a physical keyboard is inserted, mark the physical keyboard as connected. If a physical keyboard is removed, mark the physical keyboard as disconnected.
3. When a user enters text, check whether a physical keyboard is connected. If a physical keyboard is not connected, launch the virtual keyboard.
```js
......@@ -65,6 +64,4 @@ try {
} catch (error) {
console.log(`Execute failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
}
// 3. Determine whether to launch the virtual keyboard based on the value of isPhysicalKeyboardExist.
// TODO
```
en/application-dev/dfx/apprecovery-guidelines.md
浏览文件 @ 5205180c
......@@ -125,12 +125,12 @@ import AbilityConstant from '@ohos.app.ability.AbilityConstant';
#### Actively Saving the Application State and Restoring Data
- Define and register the [ErrorObserver](../reference/apis/js-apis-inner-application-errorObserver.md) callback.
- Define and register the [ErrorObserver](../reference/apis/js-apis-inner-application-errorObserver.md) callback. For details about its usage, see [errorManager](../reference/apis/js-apis-app-ability-errorManager.md).
```ts
var registerId = -1;
var callback = {
onUnhandledException: function (errMsg) {
onUnhandledException(errMsg) {
console.log(errMsg);
appRecovery.saveAppState();
appRecovery.restartApp();
......@@ -142,7 +142,7 @@ import AbilityConstant from '@ohos.app.ability.AbilityConstant';
console.log("[Demo] EntryAbility onWindowStageCreate")
globalThis.registerObserver = (() => {
registerId = errorManager.registerErrorObserver(callback);
registerId = errorManager.on('error', callback);
})
windowStage.loadContent("pages/index", null);
......@@ -158,7 +158,7 @@ After the callback triggers **appRecovery.saveAppState()**, **onSaveState(state,
// Ability has called to save app data
console.log("[Demo] EntryAbility onSaveState")
wantParams["myData"] = "my1234567";
return AbilityConstant.onSaveResult.ALL_AGREE;
return AbilityConstant.OnSaveResult.ALL_AGREE;
}
```
......@@ -188,8 +188,8 @@ onWindowStageDestroy() {
console.log("[Demo] EntryAbility onWindowStageDestroy")
globalThis.unRegisterObserver = (() => {
errorManager.unregisterErrorObserver(registerId, (result) => {
console.log("[Demo] result " + result.code + ";" + result.message)
errorManager.off('error', registerId, (err) => {
console.error("[Demo] err:", err);
});
})
}
......@@ -217,7 +217,7 @@ export default class EntryAbility extends Ability {
// Ability has called to save app data
console.log("[Demo] EntryAbility onSaveState")
wantParams["myData"] = "my1234567";
return AbilityConstant.onSaveResult.ALL_AGREE;
return AbilityConstant.OnSaveResult.ALL_AGREE;
}
}
```
en/application-dev/reference/apis/Readme-EN.md
浏览文件 @ 5205180c
......@@ -412,7 +412,6 @@
- [@ohos.systemParameter (System Parameter)](js-apis-system-parameter.md)
- [@ohos.systemTime (System Time and Time Zone)](js-apis-system-time.md)
- [@ohos.usb (USB Management)](js-apis-usb-deprecated.md)
- [@ohos.usbV9 (USB Management)](js-apis-usb.md)
- [@system.app (Application Context)](js-apis-system-app.md)
- [@system.battery (Battery Information)](js-apis-system-battery.md)
- [@system.bluetooth (Bluetooth)](js-apis-system-bluetooth.md)
......
en/application-dev/reference/apis/js-apis-geolocation.md
浏览文件 @ 5205180c
......@@ -4,7 +4,7 @@ The **geolocation** module provides a wide array of location services, including
> **NOTE**
> The initial APIs of this module are supported since API version 7. Newly added APIs will be marked with a superscript to indicate their earliest API version.
> The APIs provided by this module are no longer maintained since API version 9. You are advised to use [geoLocationManager](js-apis-geoLocationManager.md) instead.
> The APIs provided by this module are no longer maintained since API version 9. You are advised to use [geoLocationManager](js-apis-geoLocationManager.md).
## Applying for Permissions
......@@ -1486,7 +1486,7 @@ Sets the priority of the location request.
Enumerates error codes of the location service.
> **NOTE**<br>
> This API is deprecated since API version 9.
> This API is deprecated since API version 9. You are advised to use [geoLocationManager](../errorcodes/errorcode-geoLocationManager.md).
**Required permissions**: ohos.permission.LOCATION
......
en/application-dev/reference/apis/js-apis-net-mdns.md
浏览文件 @ 5205180c
......@@ -399,7 +399,7 @@ discoveryService.stopSearchingMDNS();
### on('discoveryStart')
on(type: 'discoveryStart', callback: Callback<{serviceInfo: LocalServiceInfo, errorCode?: MDNS_ERR}>): void
on(type: 'discoveryStart', callback: Callback<{serviceInfo: LocalServiceInfo, errorCode?: MdnsError}>): void
Enables listening for **discoveryStart** events.
......@@ -410,7 +410,7 @@ Enables listening for **discoveryStart** events.
| Name | Type | Mandatory| Description |
|-------------|--------------|-----------|-----------------------------------------------------|
| type | string | Yes |Event type. This field has a fixed value of **discoveryStart**.<br>**discoveryStart**: event of starting discovery of mDNS services on the LAN.|
| callback | Callback<{serviceInfo: [LocalServiceInfo](#localserviceinfo), errorCode?: [MDNS_ERR](#mdns_err)}> | Yes | Callback used to return the mDNS service and error information. |
| callback | Callback<{serviceInfo: [LocalServiceInfo](#localserviceinfo), errorCode?: [MdnsError](#mdnserror)}> | Yes | Callback used to return the mDNS service and error information. |
**Example**
......@@ -428,7 +428,7 @@ discoveryService.stopSearchingMDNS();
### on('discoveryStop')
on(type: 'discoveryStop', callback: Callback<{serviceInfo: LocalServiceInfo, errorCode?: MDNS_ERR}>): void
on(type: 'discoveryStop', callback: Callback<{serviceInfo: LocalServiceInfo, errorCode?: MdnsError}>): void
Enables listening for **discoveryStop** events.
......@@ -439,7 +439,7 @@ Enables listening for **discoveryStop** events.
| Name | Type | Mandatory| Description |
|-------------|--------------|-----------|-----------------------------------------------------|
| type | string | Yes |Event type. This field has a fixed value of **discoveryStop**.<br>**discoveryStop**: event of stopping discovery of mDNS services on the LAN.|
| callback | Callback<{serviceInfo: [LocalServiceInfo](#localserviceinfo), errorCode?: [MDNS_ERR](#mdns_err)}> | Yes | Callback used to return the mDNS service and error information. |
| callback | Callback<{serviceInfo: [LocalServiceInfo](#localserviceinfo), errorCode?: [MdnsError](#mdnserror)}> | Yes | Callback used to return the mDNS service and error information. |
**Example**
......@@ -538,7 +538,7 @@ Defines the mDNS service attribute information.
| key | string | Yes| mDNS service attribute key. The value contains a maximum of 9 characters. |
| value | Array\<number> | Yes| mDNS service attribute value. |
## MDNS_ERR
## MdnsError
Defines the mDNS error information.
......
en/application-dev/reference/apis/js-apis-resource-manager.md
浏览文件 @ 5205180c
......@@ -13,7 +13,7 @@ The Resource Manager module provides APIs to obtain information about applicatio
import resourceManager from '@ohos.resourceManager';
```
## Instruction
## How to Use
Since API version 9, the stage model allows an application to obtain a **ResourceManager** object based on **context** and call its resource management APIs without first importing the required bundle. This approach, however, is not applicable to the FA model. For the FA model, you need to import the required bundle and then call the [getResourceManager](#resourcemanagergetresourcemanager) API to obtain a **ResourceManager** object.
For details about how to reference context in the stage model, see [Context in the Stage Model](../../application-models/application-context-stage.md).
......@@ -78,7 +78,7 @@ Obtains the **ResourceManager** object of an application based on the specified
| Name | Type | Mandatory | Description |
| ---------- | ---------------------------------------- | ---- | ----------------------------- |
| bundleName | string | Yes | Bundle name of the application. |
| bundleName | string | Yes | Bundle name of the target application. |
| callback | AsyncCallback&lt;[ResourceManager](#resourcemanager)&gt; | Yes | Callback used to return the result.|
**Example**
......@@ -135,7 +135,7 @@ Obtains the **ResourceManager** object of an application based on the specified
| Name | Type | Mandatory | Description |
| ---------- | ------ | ---- | ------------- |
| bundleName | string | Yes | Bundle name of the application.|
| bundleName | string | Yes | Bundle name of the target application.|
**Return value**
......@@ -171,12 +171,12 @@ Enumerates the device types.
| Name | Value | Description |
| -------------------- | ---- | ---- |
| DEVICE_TYPE_PHONE | 0x00 | Phone |
| DEVICE_TYPE_TABLET | 0x01 | Tablet |
| DEVICE_TYPE_CAR | 0x02 | Head unit |
| DEVICE_TYPE_PC | 0x03 | PC |
| DEVICE_TYPE_TV | 0x04 | TV |
| DEVICE_TYPE_WEARABLE | 0x06 | Wearable |
| DEVICE_TYPE_PHONE | 0x00 | Phone. |
| DEVICE_TYPE_TABLET | 0x01 | Tablet. |
| DEVICE_TYPE_CAR | 0x02 | Head unit. |
| DEVICE_TYPE_PC | 0x03 | PC. |
| DEVICE_TYPE_TV | 0x04 | TV. |
| DEVICE_TYPE_WEARABLE | 0x06 | Wearable. |
## ScreenDensity
......@@ -278,7 +278,7 @@ Defines the capability of accessing application resources.
> **NOTE**
>
> - The APIs involved in **ResourceManager** are applicable only to the TypeScript-based declarative development paradigm.
> - The methods involved in **ResourceManager** are applicable only to the TypeScript-based declarative development paradigm.
>
> - Resource files are defined in the **resources** directory of the project. You can obtain the resource ID using **$r(resource address).id**, for example, **$r('app.string.test').id**.
......@@ -645,7 +645,7 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
getMediaContent(resId: number, callback: AsyncCallback&lt;Uint8Array&gt;): void
Obtains the content of the media file corresponding to the specified resource ID. This API uses an asynchronous callback to return the result.
Obtains the content of the media file corresponding to the specified resource name. This API uses an asynchronous callback to return the result.
**System capability**: SystemCapability.Global.ResourceManager
......@@ -1543,7 +1543,7 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
```
### closeRawFd<sup>8+</sup>
### closeRawFd<sup>9+</sup>
closeRawFd(path: string): Promise&lt;void&gt;
......@@ -1658,7 +1658,7 @@ Obtains the string corresponding to the specified resource name. This API uses a
| Type | Description |
| --------------------- | ---------- |
| Promise&lt;string&gt; | String corresponding to the resource name.|
| Promise&lt;string&gt; | Promise used to return the result.|
For details about the error codes, see [Resource Manager Error Codes](../errorcodes/errorcode-resource-manager.md).
......@@ -1770,7 +1770,7 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
getMediaByName(resName: string, callback: AsyncCallback&lt;Uint8Array&gt;): void
Obtains the content of the media file corresponding to the specified resource ID. This API uses an asynchronous callback to return the result.
Obtains the content of the media file corresponding to the specified resource name. This API uses an asynchronous callback to return the result.
**System capability**: SystemCapability.Global.ResourceManager
......@@ -2036,7 +2036,7 @@ Obtains the string corresponding to the specified resource ID. This API returns
| Type | Description |
| ------ | ----------- |
| string | Promise used to return the result.|
| string | String corresponding to the specified resource ID.|
For details about the error codes, see [Resource Manager Error Codes](../errorcodes/errorcode-resource-manager.md).
......@@ -2057,6 +2057,47 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
}
```
### getStringSync<sup>10+</sup>
getStringSync(resId: number, ...args: Array<string | number>): string
Obtains the string corresponding to the specified resource ID and formats the string based on **args**. This API returns the result synchronously.
**System capability**: SystemCapability.Global.ResourceManager
**Parameters**
| Name | Type | Mandatory | Description |
| ----- | ------ | ---- | ----- |
| resId | number | Yes | Resource ID.|
| args | Array<string \| number> | No | Arguments for formatting strings.<br> Supported arguments:<br> -%d, %f, %s, and %%<br> Note: %% is used to translate %.<br>Example: %%d is translated into the %d string.|
**Return value**
| Type | Description |
| ------ | ---------------------------- |
| string | Formatted string.|
For details about the error codes, see [Resource Manager Error Codes](../errorcodes/errorcode-resource-manager.md).
**Error codes**
| ID| Error Message|
| -------- | ----------------------------------------------- |
| 9001001 | If the resId invalid. |
| 9001002 | If the resource not found by resId. |
| 9001006 | If the resource re-ref too much. |
| 9001007 | If the resource obtained by resId formatting error. |
**Example**
```ts
try {
this.context.resourceManager.getStringSync($r('app.string.test').id, "format string", 10, 98.78);
} catch (error) {
console.error(`getStringSync failed, error code: ${error.code}, message: ${error.message}.`)
}
```
### getStringSync<sup>9+</sup>
getStringSync(resource: Resource): string
......@@ -2075,7 +2116,7 @@ Obtains the string corresponding to the specified resource object. This API retu
| Type | Description |
| ------ | ---------------- |
| string | Promise used to return the result.|
| string | String corresponding to the resource object.|
For details about the error codes, see [Resource Manager Error Codes](../errorcodes/errorcode-resource-manager.md).
......@@ -2101,6 +2142,52 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
}
```
### getStringSync<sup>10+</sup>
getStringSync(resource: Resource, ...args: Array<string | number>): string
Obtains the string corresponding to the specified resource object and formats the string based on **args**. This API returns the result synchronously.
**System capability**: SystemCapability.Global.ResourceManager
**Parameters**
| Name | Type | Mandatory | Description |
| -------- | ---------------------- | ---- | ---- |
| resource | [Resource](#resource9) | Yes | Resource object.|
| args | Array<string \| number> | No | Arguments for formatting strings.<br> Supported arguments:<br> -%d, %f, %s, and %%<br> Note: %% is used to translate %.<br>Example: %%d is translated into the %d string.|
**Return value**
| Type | Description |
| ------ | ---------------------------- |
| string | Formatted string.|
For details about the error codes, see [Resource Manager Error Codes](../errorcodes/errorcode-resource-manager.md).
**Error codes**
| ID| Error Message|
| -------- | ---------------------------------------- |
| 9001001 | If the resId invalid. |
| 9001002 | If the resource not found by resId. |
| 9001006 | If the resource re-ref too much. |
| 9001007 | If the resource obtained by resId formatting error. |
**Example**
```ts
let resource = {
bundleName: "com.example.myapplication",
moduleName: "entry",
id: $r('app.string.test').id
};
try {
this.context.resourceManager.getStringSync(resource, "format string", 10, 98.78);
} catch (error) {
console.error(`getStringSync failed, error code: ${error.code}, message: ${error.message}.`)
}
```
### getStringByNameSync<sup>9+</sup>
getStringByNameSync(resName: string): string
......@@ -2119,7 +2206,7 @@ Obtains the string corresponding to the specified resource name. This API return
| Type | Description |
| ------ | ---------- |
| string | String corresponding to the specified resource name.|
| string | String corresponding to the resource name.|
For details about the error codes, see [Resource Manager Error Codes](../errorcodes/errorcode-resource-manager.md).
......@@ -2140,6 +2227,47 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
}
```
### getStringByNameSync<sup>10+</sup>
getStringByNameSync(resName: string, ...args: Array<string | number>): string
Obtains the string corresponding to the specified resource name and formats the string based on **args**. This API returns the result synchronously.
**System capability**: SystemCapability.Global.ResourceManager
**Parameters**
| Name | Type | Mandatory | Description |
| ------- | ------ | ---- | ---- |
| resName | string | Yes | Resource name.|
| args | Array<string \| number> | No | Arguments for formatting strings.<br> Supported arguments:<br> -%d, %f, %s, and %%<br> Note: %% is used to translate %.<br>Example: %%d is translated into the %d string.|
**Return value**
| Type | Description |
| ------ | ---------------------------- |
| string | Formatted string.|
For details about the error codes, see [Resource Manager Error Codes](../errorcodes/errorcode-resource-manager.md).
**Error codes**
| ID| Error Message|
| -------- | ---------------------------------------- |
| 9001003 | If the resName invalid. |
| 9001004 | If the resource not found by resName. |
| 9001006 | If the resource re-ref too much. |
| 9001008 | If the resource obtained by resName formatting error. |
**Example**
```ts
try {
this.context.resourceManager.getStringByNameSync("test", "format string", 10, 98.78);
} catch (error) {
console.error(`getStringByNameSync failed, error code: ${error.code}, message: ${error.message}.`)
}
```
### getBoolean<sup>9+</sup>
getBoolean(resId: number): boolean
......@@ -2399,7 +2527,7 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
getDrawableDescriptor(resId: number, density?: number): DrawableDescriptor;
Obtains the **DrawableDescriptor** object based on the specified resource ID. This API returns the result synchronously.
Obtains the **DrawableDescriptor** object corresponding to the specified resource ID. This API returns the result synchronously.
**System capability**: SystemCapability.Global.ResourceManager
......@@ -2443,7 +2571,7 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
getDrawableDescriptor(resource: Resource, density?: number): DrawableDescriptor;
Obtains the **DrawableDescriptor** object based on the specified resource. This API returns the result synchronously.
Obtains the **DrawableDescriptor** object corresponding to the specified resource. This API returns the result synchronously.
**System capability**: SystemCapability.Global.ResourceManager
......@@ -2492,7 +2620,7 @@ For details about the error codes, see [Resource Manager Error Codes](../errorco
getDrawableDescriptorByName(resName: string, density?: number): DrawableDescriptor;
Obtains the **DrawableDescriptor** object based on the specified resource name. This API returns the result synchronously.
Obtains the **DrawableDescriptor** object corresponding to the specified resource name. This API returns the result synchronously.
**System capability**: SystemCapability.Global.ResourceManager
......@@ -2666,7 +2794,7 @@ This API is deprecated since API version 9. You are advised to use [getStringArr
getMedia(resId: number, callback: AsyncCallback&lt;Uint8Array&gt;): void
Obtains the content of the media file corresponding to the specified resource ID. This API uses an asynchronous callback to return the result.
Obtains the content of the media file corresponding to the specified resource name. This API uses an asynchronous callback to return the result.
This API is deprecated since API version 9. You are advised to use [getMediaContent](#getmediacontent9) instead.
......
en/device-dev/get-code/sourcecode-acquire.md
浏览文件 @ 5205180c
......@@ -65,9 +65,9 @@ The OpenHarmony source code is open to you as [HPM parts](../hpm-part/hpm-part-a
### How to Use<a name="section429012478331"></a>
> **NOTE**
>
> Download the release code, which is more stable, if you want to develop commercial functionalities. Download the master code if you want to get quick access to the latest features for your development.
>![](../public_sys-resources/icon-note.gif) **NOTE**
>
>Download the release code, which is more stable, if you want to develop commercial functionalities. Download the master code if you want to get quick access to the latest features for your development.
- **Obtaining OpenHarmony release code**
......@@ -168,7 +168,7 @@ You must install **Node.js** and HPM on your local PC. The installation procedur
To ensure the download performance, you are advised to download the source code or the corresponding solution from the image library of the respective site listed in the table below.
The table below provides only the sites for downloading the latest OpenHarmony LTS code. For details about how to obtain the source code of earlier versions, see the [Release Notes](../../release-notes/Readme.md).
The table below provides only the sites for downloading the latest OpenHarmony LTS code. For details about how to obtain the source code of earlier versions, see the [Release Notes](../../release-notes/Readme.md).
**Table 1** Sites for acquiring source code
......@@ -182,19 +182,19 @@ The table below provides only the sites for downloading the latest OpenHarmony L
| Hi3516 solution-Linux (binary)| 3.0 | [Download](https://repo.huaweicloud.com/openharmony/os/3.0/hispark_taurus_linux.tar.gz)| [Download](https://repo.huaweicloud.com/openharmony/os/3.0/hispark_taurus_linux.tar.gz.sha256) | 418.1 MB |
| RELEASE-NOTES | 3.0 | [Download](https://gitee.com/openharmony/docs/blob/OpenHarmony-3.0-LTS/en/release-notes/OpenHarmony-v3.0-LTS.md)| - | - |
| **Source Code of the Latest Release**| **Version**| **Site**| **SHA-256 Checksum**| **Software Package Size**|
| Full code base (for mini, small, and standard systems)| 3.2 Beta5 | [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Beta5/code-v3.2-Beta5.tar.gz) | [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Beta5/code-v3.2-Beta5.tar.gz.sha256) | 21.3 GB |
| Hi3861 solution (binary) | 3.2 Beta5 | [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Beta5/hispark_pegasus.tar.gz) | [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Beta5/hispark_pegasus.tar.gz.sha256) | 22.9 MB |
| Hi3516 solution-LiteOS (binary)| 3.2 Beta5 | [Download](https://repo.huaweicloud.com/openharmony/os/3.2-Beta5/hispark_taurus_LiteOS.tar.gz) | [Download](https://repo.huaweicloud.com/openharmony/os/3.2-Beta5/hispark_taurus_LiteOS.tar.gz.sha256) | 293.6 MB |
| Hi3516 solution-Linux (binary) | 3.2 Beta5 | [Download](hispark_taurus_Linux.tar.gz) | [Download](https://repo.huaweicloud.com/openharmony/os/3.2-Beta5/hispark_taurus_Linux.tar.gz.sha256) | 174.3 MB |
| RK3568 standard system solution (binary) | 3.2 Beta5 | [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Beta5/dayu200_standard_arm32_20230201.tar.gz) | [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Beta5/dayu200_standard_arm32_20230201.tar.gz.sha256) | 3.9 GB |
| RELEASE-NOTES | 3.2 Beta5 | [Download](../../release-notes/OpenHarmony-v3.2-beta5.md)| - | - |
| Full code base (for mini, small, and standard systems)| 3.2 Release | [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Release/code-v3.2-Release.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Release/code-v3.2-Release.tar.gz.sha256)| 21.8 GB |
| Hi3861 solution (binary) | 3.2 Release| [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Release/hispark_pegasus.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Release/hispark_pegasus.tar.gz.sha256)| 22.9 MB |
| Hi3516 solution-LiteOS (binary)| 3.2 Release| [Download](https://repo.huaweicloud.com/openharmony/os/3.2-Release/hispark_taurus_LiteOS.tar.gz)| [Download](https://repo.huaweicloud.com/openharmony/os/3.2-Release/hispark_taurus_LiteOS.tar.gz.sha256)| 294.3 MB |
| Hi3516 solution-Linux (binary) | 3.2 Release| [Download](https://repo.huaweicloud.com/openharmony/os/3.2-Release/hispark_taurus_Linux.tar.gz)| [Download](https://repo.huaweicloud.com/openharmony/os/3.2-Release/hispark_taurus_Linux.tar.gz.sha256)| 174.3 MB |
| RK3568 standard system solution (binary) | 3.2 Release| [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Release//dayu200_standard_arm32.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.2-Release//dayu200_standard_arm32.tar.gz.sha256)| 3.9 GB |
| RELEASE-NOTES | 3.2 Release| [Download](../../release-notes/OpenHarmony-v3.2-release.md)| - | - |
| **Compiler Toolchain**| **Version**| **Site**| **SHA-256 Checksum**| **Software Package Size**|
| Compiler toolchain| - | [Download](https://repo.huaweicloud.com/openharmony/os/2.0/tool_chain/)| - | - |
## Method 4: Acquiring Source Code from the GitHub Image Repository<a name="section23448418360"></a>
> **NOTE**
>
>![](../public_sys-resources/icon-note.gif) **NOTE**
>
> The image repository is synchronized at 23:00 (UTC +8:00) every day.
Method 1 \(recommended\): Use the **repo** tool to download the source code over SSH. \(You must have registered an SSH public key for access to GitHub. For details, see [Adding a new SSH key to your GitHub account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account).\)
......@@ -219,82 +219,19 @@ The following table describes the OpenHarmony source code directories.
**Table 2** Source code directories
<a name="table3815144702820"></a>
<table><thead align="left"><tr id="row198162047192810"><th class="cellrowborder" valign="top" width="50%" id="mcps1.2.3.1.1"><p id="p690319291299"><a name="p690319291299"></a><a name="p690319291299"></a>Name</p>
</th>
<th class="cellrowborder" valign="top" width="50%" id="mcps1.2.3.1.2"><p id="p5903122962918"><a name="p5903122962918"></a><a name="p5903122962918"></a>Description</p>
</th>
</tr>
</thead>
<tbody><tr id="row1981674719280"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p69031429162912"><a name="p69031429162912"></a><a name="p69031429162912"></a>applications</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p090352912914"><a name="p090352912914"></a><a name="p090352912914"></a>Application samples, for example, <strong id="b689814231158"><a name="b689814231158"></a><a name="b689814231158"></a>camera</strong></p>
</td>
</tr>
<tr id="row5816747132817"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p99031129112918"><a name="p99031129112918"></a><a name="p99031129112918"></a>base</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p790472962914"><a name="p790472962914"></a><a name="p790472962914"></a>Basic software service subsystem set and hardware service subsystem set</p>
</td>
</tr>
<tr id="row1134218692910"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p4904112910295"><a name="p4904112910295"></a><a name="p4904112910295"></a>build</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p1090482942911"><a name="p1090482942911"></a><a name="p1090482942911"></a>Bundle-based compilation, build, and configuration scripts</p>
</td>
</tr>
<tr id="row8166154261316"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p1216719425130"><a name="p1216719425130"></a><a name="p1216719425130"></a>docs</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p17167134217134"><a name="p17167134217134"></a><a name="p17167134217134"></a>Reference documents</p>
</td>
</tr>
<tr id="row1841618902919"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p1390462902910"><a name="p1390462902910"></a><a name="p1390462902910"></a>domains</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p1390432914296"><a name="p1390432914296"></a><a name="p1390432914296"></a>Enhanced software service subsystem set</p>
</td>
</tr>
<tr id="row841620912298"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p119041629182919"><a name="p119041629182919"></a><a name="p119041629182919"></a>drivers</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p9904629132911"><a name="p9904629132911"></a><a name="p9904629132911"></a>Driver subsystem</p>
</td>
</tr>
<tr id="row164164992915"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p79042298298"><a name="p79042298298"></a><a name="p79042298298"></a>foundation</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p18904132922915"><a name="p18904132922915"></a><a name="p18904132922915"></a>Basic system capability subsystem set</p>
</td>
</tr>
<tr id="row1441610922915"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p490402916299"><a name="p490402916299"></a><a name="p490402916299"></a>kernel</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p1904112932912"><a name="p1904112932912"></a><a name="p1904112932912"></a>Kernel subsystem</p>
</td>
</tr>
<tr id="row194175972917"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p1904132912910"><a name="p1904132912910"></a><a name="p1904132912910"></a>prebuilts</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p390492919296"><a name="p390492919296"></a><a name="p390492919296"></a>Compiler and toolchain subsystem</p>
</td>
</tr>
<tr id="row841718942913"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p12904929202919"><a name="p12904929202919"></a><a name="p12904929202919"></a>test</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p4904152912297"><a name="p4904152912297"></a><a name="p4904152912297"></a>Testing subsystem</p>
</td>
</tr>
<tr id="row24175915294"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p13904162992916"><a name="p13904162992916"></a><a name="p13904162992916"></a>third_party</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p6904829112917"><a name="p6904829112917"></a><a name="p6904829112917"></a>Open-source third-party software</p>
</td>
</tr>
<tr id="row334210652914"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p1390442918299"><a name="p1390442918299"></a><a name="p1390442918299"></a>utils</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p690412296297"><a name="p690412296297"></a><a name="p690412296297"></a>Commonly used development tools</p>
</td>
</tr>
<tr id="row73421664298"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p7905172920292"><a name="p7905172920292"></a><a name="p7905172920292"></a>vendor</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p290510290293"><a name="p290510290293"></a><a name="p290510290293"></a>Vendor-provided software</p>
</td>
</tr>
<tr id="row734319617292"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p09056291290"><a name="p09056291290"></a><a name="p09056291290"></a>build.py</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p1790542912290"><a name="p1790542912290"></a><a name="p1790542912290"></a>Compilation script file</p>
</td>
</tr>
</tbody>
</table>
| Directory| Description|
| -------- | -------- |
| applications | Application samples, for example, **camera**.|
| base | Basic software service subsystem set and hardware service subsystem set.|
| build | Bundle-based compilation, building, and configuration scripts.|
| docs | Reference documents.|
| domains | Enhanced software service subsystem set.|
| drivers | Driver subsystem.|
| foundation | Basic system capability subsystem set.|
| kernel | Kernel subsystem.|
| prebuilts | Compiler and tool chain subsystem.|
| test | Test subsystem.|
| third_party | Open-source third-party software.|
| utils | Commonly used development utilities.|
| vendor | Vendor-provided software.|
| build.py | Build script file.|
en/device-dev/subsystems/Readme-EN.md
浏览文件 @ 5205180c
......@@ -38,7 +38,9 @@
- [Audio/Video Playback Development](subsys-multimedia-video-play-guide.md)
- [Audio/Video Recording Development](subsys-multimedia-video-record-guide.md)
- [Utils Development](subsys-utils-guide.md)
- [AI Framework Development](subsys-ai-aiframework-devguide.md)
- AI
- [AI Framework Development](subsys-ai-aiframework-devguide.md)
- [NNRt Development](subsys-ai-nnrt-guide.md)
- Data Management
- RDB
- [RDB Overview](subsys-data-relational-database-overview.md)
......@@ -105,6 +107,23 @@
- [hdc](subsys-toolchain-hdc-guide.md)
- [hiperf](subsys-toolchain-hiperf.md)
- [HiDumper](subsys-dfx-hidumper.md)
- Power Management
- Power
- Display Management
- [System Brightness Customization](subsys-power-brightness-customization.md)
- Battery Management
- [Battery Level and LED Color Mapping Customization](subsys-power-level-LED-color.md)
- [Battery Temperature Protection Customization](subsys-power-temperature-protection.md)
- [Battery Level Customization](subsys-power-battery-level-customization.md)
- [Charging Current and Voltage Limit Customization](subsys-power-charge-current-voltage-limit.md)
- [Charging Type Customization](subsys-power-charge-type-customization.md)
- [Power-off Charging Animation Customization](subsys-power-poweroff-charge-animation.md)
- Power Consumption Statistics
- [Power Consumption Statistics Customization](subsys-power-stats-power-average-customization.md)
- Thermal Management
- [Charging Idle State Customization](subsys-thermal_charging_idle_state.md)
- [Thermal Control Customization](subsys-thermal_control.md)
- [Thermal Detection Customization](subsys-thermal_detection.md)
- [Thermal Level Customization](subsys-thermal_level.md)
- [Thermal Log Customization](subsys-thermal_log.md)
- [Thermal Policy Customization](subsys-thermal_policy.md)
- [Thermal Scene Customization](subsys-thermal_scene.md)
\ No newline at end of file
en/device-dev/subsystems/subsys-power-battery-level-customization.md 0 → 100644
浏览文件 @ 5205180c
# Battery Level Customization
## Overview
### Introduction
By default, OpenHarmony provides the battery level based on the current battery power, such as the full battery level, high battery level, low battery level, and extremely low battery level. It can generate an alert or take required service processing based on the current battery level. However, the battery level specifications vary according to products. To address this issue, OpenHarmony provides the function of customizing battery levels.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate battery level customization.
1. Create the `battery` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of battery level configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/battery`. The content is as follows:
```text
profile
├── BUILD.gn
├── battery_config.json
```
3. Write the custom `battery_config.json` file by referring to the `battery_config.json` file in the default folder of battery level configuration. For example:
```json
{
"soc": {
"shutdown": 5,
"critical": 10,
"warning": 15,
"low": 30,
"normal": 60,
"high": 90,
"full": 100
}
}
```
**Table 1** Battery level configuration
| Battery Bevel| Battery Volume| Description|
| -------- | -------- | -------- |
| shutdown | 5 | Power-off battery level|
| critical | 10 | Extremely low battery level|
| warning | 15 | Alarm battery level|
| low | 30 | Low battery level|
| normal | 60 | Normal battery level|
| high | 90 | High battery level|
| full | 100 | Full battery level|
4. Write the `BUILD.gn` file by referring to the `BUILD.gn` in the default folder of battery level configuration to pack the `battery_config.json` file to the `//vendor/etc/battery` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("battery_config") {
source = "battery_config.json"
relative_install_dir = "battery"
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/battery/profile:battery_config" # Add the configuration for building of battery_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/battery/` is the folder path, `profile` is the folder name, and `battery_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```
hdc shell
```
2. Go to the custom battery level configuration directory. The path of DAYU200 is used as an example.
```
cd /data/service/el0/battery/battery/
```
3. Modify the charging status, simulate reporting of the battery power change, and check whether the returned battery level is correct. The following uses the default charging type as an example.
1. Modify the battery power.
```
echo 100 > capacity
```
2. Report the battery power change to obtain the current battery level.
```
hidumper -s 3302 -a -i
```
3. Check whether the battery level is correct.
```
-------------------------------[ability]-------------------------------
----------------------------------BatteryService---------------------------------
Current time: 2017-08-05 17:22:48.589
··· (Only the battery level configuration is displayed here. Other information is omitted.)
batteryLevel: 1
······
```
4. Modify the battery power.
```
echo 90 > capacity
```
5. Report the battery power change to obtain the current battery level.
```
hidumper -s 3302 -a -i
```
6. Check whether the battery level is correct.
```
-------------------------------[ability]-------------------------------
----------------------------------BatteryService---------------------------------
Current time: 2017-08-05 17:24:29.716
··· (Only the battery level configuration is displayed here. Other information is omitted.)
batteryLevel: 2
······
```
7. Modify the battery power.
```
echo 60 > capacity
```
8. Report the battery power change to obtain the current battery level.
```
hidumper -s 3302 -a -i
```
9. Check whether the battery level is correct.
```
-------------------------------[ability]-------------------------------
----------------------------------BatteryService---------------------------------
Current time: 2017-08-05 17:25:09.837
··· (Only the battery level configuration is displayed here. Other information is omitted.)
batteryLevel: 3
······
```
10. Modify the battery power.
```
echo 30 > capacity
```
11. Report the battery power change to obtain the current battery level.
```
hidumper -s 3302 -a -i
```
12. Check whether the battery level is correct.
```
-------------------------------[ability]-------------------------------
----------------------------------BatteryService---------------------------------
Current time: 2017-08-05 17:26:20.495
··· (Only the battery level configuration is displayed here. Other information is omitted.)
batteryLevel: 4
······
```
13. Modify the battery power.
```
echo 15 > capacity
```
14. Report the battery power change to obtain the current battery level.
```
hidumper -s 3302 -a -i
```
15. Check whether the battery level is correct.
```
-------------------------------[ability]-------------------------------
----------------------------------BatteryService---------------------------------
Current time: 2017-08-05 17:27:05.312
··· (Only the battery level configuration is displayed here. Other information is omitted.)
batteryLevel: 5
······
```
16. Modify the battery power.
```
echo 10 > capacity
```
17. Report the battery power change to obtain the current battery level.
```
hidumper -s 3302 -a -i
```
18. Check whether the battery level is correct.
```
-------------------------------[ability]-------------------------------
----------------------------------BatteryService---------------------------------
Current time: 2017-08-05 17:27:56.270
··· (Only the battery level configuration is displayed here. Other information is omitted.)
batteryLevel: 6
······
```
19. Modify the battery power.
```
echo 5 > capacity
```
20. Report the battery power change to obtain the current battery level.
```
hidumper -s 3302 -a -i
```
21. Check whether the battery level is correct.
```
-------------------------------[ability]-------------------------------
----------------------------------BatteryService---------------------------------
Current time: 2017-08-05 17:28:38.066
··· (Only the battery level configuration is displayed here. Other information is omitted.)
batteryLevel: 7
······
```
## Reference
During development, you can refer to the [default battery level configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile/battery_config.json), as shown below:
```json
{
"soc": {
"shutdown": 1,
"critical": 5,
"warning": 10,
"low": 20,
"normal": 90,
"high": 99,
"full": 100
}
}
```
Packing path: /system/etc/battery
en/device-dev/subsystems/subsys-power-brightness-customization.md
浏览文件 @ 5205180c
......@@ -30,9 +30,9 @@ Development board running the standard system, for example, the DAYU200 or Hi351
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/Readme-EN.md).
### How to Develop
### Getting Started with Development
1. In the target directory, create a target folder by referring to the [default brightness value configuration folder](https://gitee.com/openharmony/powermgr_display_manager/tree/master/service/etc). The file format is as follows:
1. In the target directory, create a target folder by referring to the [default brightness value configuration folder](https://gitee.com/openharmony/powermgr_display_manager/tree/master/service/etc). The content is as follows:
```text
etc
......
en/device-dev/subsystems/subsys-power-charge-current-voltage-limit.md 0 → 100644
浏览文件 @ 5205180c
# Charging Current and Voltage Limit Customization
## Overview
### Introduction
By default, OpenHarmony supports setting of charging current and voltage limits. When a device is being charged, the battery temperature may become excessively high due to the impact of ambient environment. In such a case, the charging current or voltage needs to be limited to ensure safety use of the device. However, the impact of charging current or voltage on device safety varies according to product specifications. To address this issue, OpenHarmony provides the function of customizing charging current and voltage limits.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate customization of charging current and voltage limits.
1. Create the `battery` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of charging current and voltage limit configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/battery`. The content is as follows:
```text
profile
├── BUILD.gn
├── battery_config.json
```
3. Write the custom `battery_config.json` file by referring to the `battery_config.json` file in the default folder of charging current and voltage limit configuration. For example:
```json
{
"charger": {
"current_limit":{
"path": "/data/service/el0/battery/current_limit"
},
"voltage_limit":{
"path": "/data/service/el0/battery/voltage_limit"
}
}
}
```
4. Write the `BUILD.gn` file by referring to the `BUILD.gn` in the default folder of charging current and voltage limit configuration to pack the `battery_config.json` file to the `//vendor/etc/battery` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("battery_config") {
source = "battery_config.json"
relative_install_dir = "battery"
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/battery/profile:battery_config" # Add the configuration for building of battery_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/battery/` is the folder path, `profile` is the folder name, and `battery_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. Build the battery-specific hats test cases. For details about the build commands and framework setup, see [XTS Subsystem](https://gitee.com/openharmony/xts_hats).
2. Run the test cases, and check the test report.
![battery_limit_current_test_report](figures/battery_limit_current_test_report.jpg)
## Reference
During development, you can refer to the [default charging current and voltage configuration](https://gitee.com/openharmony/powermgr_battery_manager/blob/master/services/native/profile/battery_config.json), as shown below:
```json
{
"charger": {
"current_limit":{
"path": "/data/service/el0/battery/current_limit"
},
"voltage_limit":{
"path": "/data/service/el0/battery/voltage_limit"
}
}
}
```
Packing path: /system/etc/battery
en/device-dev/subsystems/subsys-power-charge-type-customization.md 0 → 100644
浏览文件 @ 5205180c
# Charging Type Customization
## Overview
### Introduction
By default, OpenHarmony supports multiple charging types. You can charge devices through different types of charging, for example, wired fast charging and wireless fast charging. OpenHarmony can display appropriate animations or take required service processing based on the charging type. However, the supported charging types vary according to products. To address this issue, OpenHarmony provides the charging type customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate charging type customization.
1. Create the `battery` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of charging type configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/battery`. The content is as follows:
```text
profile
├── BUILD.gn
├── battery_config.json
```
3. Write the custom `battery_config.json` file by referring to the `battery_config.json` file in the default folder of charging type configuration. For example:
```shell
{
"charger": {
"type": {
"path": "/data/service/el0/battery/charger_type"
}
}
}
```
4. Write the `BUILD.gn` file by referring to the `BUILD.gn` in the default folder of charging type configuration to pack the `battery_config.json` file to the `//vendor/etc/battery` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("battery_config") {
source = "battery_config.json"
relative_install_dir = "battery"
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/battery/profile:battery_config" # Add the configuration for building of battery_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/battery/` is the folder path, `profile` is the folder name, and `battery_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```
hdc shell
```
2. Go to the custom battery level configuration directory. The path of DAYU200 is used as an example.
```
cd /data/service/el0/battery/
```
3. Modify the charging status, simulate reporting of the charging status, and check whether the displayed animation is correct. The following uses the default charging type and animation mapping as an example.
1. Modify the charging type.
```
echo 1 > charger_type
```
2. Report the charging status change to trigger mapping between the charging type and animation.
```
hidumper -s 3302 -a -r
```
3. Check the output for the charging type.
```
hidumper -s 3302 -a -i
```
```
-------------------------------[ability]----------------------------
------------------------------BatteryService------------------------
capacity: 11
batteryLevel: 4
chargingStatus: 1
healthState: 1
pluggedType: 2
voltage: 4123456
present: 0
technology: Li-ion
nowCurrent: 1000
currentAverage: 1000
totalEnergy: 4000000
remainingEnergy: 4000000
remainingChargeTime: 0
temperature: 222
chargeType: 1
```
![charger_type1](figures/charger_type1.jpg)
## Reference
During development, you can refer to the [default charging type configuration](https://gitee.com/openharmony/powermgr_battery_manager/blob/tree/services/native/profile/battery_config.json), as shown below:
```shell
{
"charger": {
"type": {
"path": "/data/service/el0/battery/charger_type"
}
}
}
```
Packing path: /system/etc/battery
en/device-dev/subsystems/subsys-power-level-LED-color.md 0 → 100644
浏览文件 @ 5205180c
# Battery Level and LED Color Mapping Customization
## Overview
### Introduction
OpenHarmony provides the battery level and LED color mapping by default. Some products, tablets for example, may use LED colors to display the battery level during charging. For example, green indicates a high battery level is high, yellow indicates a low battery level, and red indicates an extremely low battery level. The battery level and LED color mapping varies according to products. To address this issue, OpenHarmony provides the function of customizing the battery level and LED color mapping.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate customization of the battery level and LED color mapping.
1. Create the `battery` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of battery level and LED color mapping configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/battery`. The content is as follows:
```text
profile
├── BUILD.gn
├── battery_config.json
```
3. Write the custom `battery_config.json` file by referring to the `battery_config.json` file in the default folder of battery level and LED color mapping configuration. For example:
```json
{
"light": {
"low": {
"soc": [0, 20],
"rgb": [255, 192, 203]
},
"normal": {
"soc": [20, 95],
"rgb": [255, 0, 255]
},
"high": {
"soc": [95, 100],
"rgb": [0, 0, 255]
}
}
}
```
**Table 1** Description of the battery level and LED color mapping configuration
| Item| Description|
| -------- | -------- |
| low | Low battery level|
| normal | Normal battery level|
| high | High battery level|
| soc | Battery level range|
| rgb | LED RGB combination|
4. Write the `BUILD.gn` file by referring to the `BUILD.gn` in the default folder of battery level and LED color mapping configuration to pack the `battery_config.json` file to the `//vendor/etc/battery` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("battery_config") {
source = "battery_config.json"
relative_install_dir = "battery"
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/battery/profile:battery_config" # Add the configuration for building of battery_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, //vendor/hihope/rk3568/battery/ is the folder path, profile is the folder name, and battery_config is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```
hdc shell
```
2. Go to the custom battery level configuration directory. The path of DAYU200 is used as an example.
```
cd /data/service/el0/battery/battery
```
3. Modify the charging status, simulate reporting of the battery power change, and check whether the LED color is correct. The following uses the default battery level and LED color mapping configuration as an example.
1. Modify the battery power.
```
echo 5 > capacity
```
2. Report the battery power change to trigger the LED mapping.
```
hidumper -s 3302 -a -r
```
![low_power_led](figures/low_power_led.jpg)
3. Modify the battery power.
```
echo 50 > capacity
```
4. Report the battery power change to trigger the LED mapping.
```
hidumper -s 3302 -a -r
```
![normal_power_led](figures/normal_power_led.jpg)
5. Modify the battery power.
```
echo 100 > capacity
```
6. Report the battery power change to trigger the LED mapping.
```
hidumper -s 3302 -a -r
```
![high_power_led](figures/high_power_led.jpg)
4. Customize the battery level and LED color mapping configuration. For example:
```json
{
"light": {
"low": {
"soc": [0, 20],
"rgb": [255, 192, 203]
},
"normal": {
"soc": [20, 95],
"rgb": [255, 0, 255]
},
"high": {
"soc": [95, 100],
"rgb": [0, 0, 255]
}
}
}
```
1. Modify the battery power.
```
echo 15 > capacity
```
2. Report the battery power change to trigger the LED mapping.
```
hidumper -s 3302 -a -r
```
![low_power_led_alter](figures/low_power_led_alter.jpg)
3. Modify the battery power.
```
echo 95 > capacity
```
4. Report the battery power change to trigger the LED mapping.
```
hidumper -s 3302 -a -r
```
![normal_power_led_alter](figures/normal_power_led_alter.jpg)
5. Modify the battery power.
```
echo 99 > capacity
```
6. Report the battery power change to trigger the LED mapping.
```
hidumper -s 3302 -a -r
```
![high_power_led_alter](figures/high_power_led_alter.jpg)
## Reference
During development, you can refer to the [default battery level and LED color mapping configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile/battery_config.json), as shown below:
```json
{
"light": {
"low": {
"soc": [0, 10],
"rgb": [255, 0, 0]
},
"normal": {
"soc": [10, 90],
"rgb": [255, 255, 0]
},
"high": {
"soc": [90, 100],
"rgb": [0, 255, 0]
}
}
}
```
Packing path: /system/etc/battery
en/device-dev/subsystems/subsys-power-poweroff-charge-animation.md 0 → 100644
浏览文件 @ 5205180c
# Power-off Charging Animation Customization
## Overview
### Introduction
By default, the OpenHarmony provides the animation that displays information such as the battery level during power-off charging. However, some vendors may expect to use custom power-off charging animations for their products. To address this requirement, OpenHarmony provides the function of customizing power-off charging animations.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate charging type customization.
1. Create the `animation` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of power-off charging animation configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/charger/sa_profile), and install it in `//vendor/hihope/rk3568/animation`. The content is as follows:
```text
profile
├── BUILD.gn
├── animation.json
```
3. Create the `resources` folder by referring to [default folder of power-off charging animation image resources](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/charger/resources) to store the images that form the animation, and install the folder in `//vendor/hihope/rk3568/animation`. The content is as follows:
```text
animation
├── resources
├── profile
```
4. Write the `BUILD.gn` file by referring to the `BUILD.gn` in the default folder of power-off charging animation configuration, and put it to the `//vendor/hihope/rk3568/animation/resource` directory. The configuration is as follows:
```shell
import("//build/ohos.gni")
ohos_prebuilt_etc("resources_config0") {
source = "loop00000.png" # Image resource
relative_install_dir = "poweroff_charger_animation/resources"
install_images = [ chipset_base_dir ] # Required configuration for installing the resources folder in the vendor directory.
part_name = "product_rk3568"
}
5. Write the custom `animation.json` file by referring to the `animation.json` file in the default folder of power-off charging animation image resources. For example:
```json
{
"id": "Charger",
"screenWidth": 720,
"screenHeight": 1280,
"dir": "/vendor/etc/charger/resources",
"bgColor": "#000000ff",
"subpages": [
{
"id": "Animation",
"coms": [
"Charging_Animation_Image",
"Charging_Percent_Label"
],
"bgColor": "#000000ff"
},
{
"id": "Lackpower_Charging_Prompt",
"coms": [
"LackPower_Charging_Label"
],
"bgColor": "#000000ff"
},
{
"id": "Lackpower_Not_Charging_Prompt",
"coms": [
"LackPower_Not_Charging_Label"
],
"bgColor": "#000000ff"
}
],
"default": {
"Common": {
"visible": false
},
"UILabel": {
"bgColor": "#00000000",
"fontColor": "#ffffffe6",
"align": "center"
},
"UIImageView": {
"imgCnt": 1,
"updInterval": 0,
"filePrefix": ""
}
},
"coms": [
{
"type": "UIImageView",
"id": "Charging_Animation_Image",
"x": 180,
"y": 410,
"w": 400,
"h": 400,
"resPath": "/vendor/etc/charger/resources/",
"imgCnt": 62,
"updInterval": 60,
"filePrefix": "loop"
},
{
"type": "UILabel",
"id": "Charging_Percent_Label",
"text": "",
"x": 365,
"y": 580,
"w": 65,
"h": 43,
"fontSize": 32
},
{
"type": "UILabel",
"id": "LackPower_Charging_Label",
"text": "Low battery level",
"x": 229,
"y": 1037,
"w": 250,
"h": 45,
"fontSize": 42,
"fontColor": "#ff0000ff"
},
{
"type": "UILabel",
"id": "LackPower_Not_Charging_Label",
"text": "Low battery level. Please connect the power supply.",
"x": 110,
"y": 1037,
"w": 500,
"h": 45,
"fontSize": 42,
"fontColor": "#ff0000ff"
}
]
}
```
**Table 1** Description of the power-off charging animation configuration
| Item| Description|
| -------- | -------- |
| id | Unique ID of the charging screen.|
| screenWidth | Width of the charging screen, in pixels.|
| screenHeight | Height of the charging screen, in pixels.|
| dir | Resource path.|
| bgColor | Background color of the charging screen.|
| subpages | Subpage of the charging screen.|
| coms | All components on the charging screen.|
| visible | Whether elements are visible.|
| text | Text content of a component.|
| x | X coordinate of the component.|
| y | Y coordinate of the component.|
| w | Component width, in pixels.|
| h | Component height, in pixels.|
| fontSize | Font size of the component.|
| fontColor | Font color of the text.|
| align | Text alignment mode.|
| imgCnt | Number of images.|
| updInterval | Image updating interval, in ms.|
| filePrefix | Prefix of an image file name.|
| type | Component type.|
| resPath | Resource file path of the component.|
6. Write the `BUILD.gn` file by referring to the `BUILD.gn` in the default folder of power-off charging animation configuration to pack the `animation_config.json` file to the `//vendor/etc/charger` directory. The configuration is as follows:
```shell
import("//build/ohos.gni")
ohos_prebuilt_etc("animation_config") {
source = "animation.json" # Reference build/ohos.gni.
relative_install_dir = "animation/resources"
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
7. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/battery/profile:battery_config",
"//vendor/hihope/rk3568/animation/profile:animation_config" # Add the configuration for building of animation_config.
"//vendor/hihope/rk3568/animation/resource/resources_config0" # Add the configuration for building of image resources.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/animation/` is the folder path, `profile` is the folder name, and `animation_config` is the build target.
8. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
9. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. Modify the code configuration.
Code path: `base/startup/init/services/init/init_config.c`
Function: `ReadConfig`
```
After modification:
void ReadConfig(void)
{
// parse cfg
char buffer[32] = {0}; // 32 reason max leb
uint32_t len = sizeof(buffer);
SystemReadParam("ohos.boot.reboot_reason", buffer, &len);
INIT_LOGV("ohos.boot.reboot_reason %s", buffer);
ParseInitCfg(INIT_CONFIGURATION_FILE, NULL); // New code
ReadFileInDir(OTHER_CHARGE_PATH, ".cfg", ParseInitCfg, NULL); // New code
if (strcmp(buffer, "poweroff_charge") == 0) {
ParseInitCfg(INIT_CONFIGURATION_FILE, NULL);
ReadFileInDir(OTHER_CHARGE_PATH, ".cfg", ParseInitCfg, NULL);
} else if (InUpdaterMode() == 0) {
ParseInitCfg(INIT_CONFIGURATION_FILE, NULL);
ParseInitCfgByPriority();
} else {
ReadFileInDir("/etc", ".cfg", ParseInitCfg, NULL);
}
}
```
2. Use the hdc tool to run the following commands to force the development board to enter the power-off charging state.
```
hdc shell
reboot charger
```
![animation_initial_power](figures/animation_initial_power.jpg)
3. Go to the custom battery level configuration directory. The path of DAYU200 is used as an example.
```
cd /data/service/el0/battery/battery
```
4. Change the battery power, and observe the number change on the charging animation.
```
cat capacity
```
Change the current battery power to **3**.
```
echo 3 > capacity
```
![animation_charing_power](figures/animation_charing_power.jpg)
5. Change the charging status when the battery level is extremely low (1% by default). This can trigger the mapping animation or device shutdown.
1. Go to the custom battery level configuration directory.
```
cd /data/service/el0/battery/battery
```
```
cat capacity
```
2. Change the current battery power to **1**.
```
echo 1 > capacity
```
3. Check the charging status.
```
cat status
```
The current status is **Charging**.
![animation_low_power](figures/animation_low_power.jpg)
4. Change to the **Not charging** state.
```
echo Not charging > status
```
![animation_low_power2](figures/animation_low_power2.jpg)
5. Change to the **Discharging** state. The system enters the power-off state.
```
echo Discharging > status
```
6. Test the power-off animation customization function by changing related images. The procedure is the same as that described above.
1. Initial state
![animation_charging_power2](figures/animation_charging_power2.jpg)
2. %3 battery power
![animation_initial_power2](figures/animation_initial_power2.jpg)
3. 1% battery power, **Charging** state
![animation_low_power](figures/animation_low_power.jpg)
4. 1% battery power, **Not charging** state
![animation_low_power2](figures/animation_low_power2.jpg)
5. 1% battery power, **Discharging** state
The device is powered off.
## Reference
During development, you can refer to the [default power-off animation configuration](https://gitee.com/openharmony/powermgr_battery_manager/blob/master/charger/sa_profile/animation.json), as shown below:
```json
{
"id": "Charger",
"screenWidth": 720,
"screenHeight": 1280,
"dir": "/vendor/etc/charger/resources",
"bgColor": "#000000ff",
"subpages": [
{
"id": "Animation",
"coms": [
"Charging_Animation_Image",
"Charging_Percent_Label"
],
"bgColor": "#000000ff"
},
{
"id": "Lackpower_Charging_Prompt",
"coms": [
"LackPower_Charging_Label"
],
"bgColor": "#000000ff"
},
{
"id": "Lackpower_Not_Charging_Prompt",
"coms": [
"LackPower_Not_Charging_Label"
],
"bgColor": "#000000ff"
}
],
"default": {
"Common": {
"visible": false
},
"UILabel": {
"bgColor": "#00000000",
"fontColor": "#ffffffe6",
"align": "center"
},
"UIImageView": {
"imgCnt": 1,
"updInterval": 0,
"filePrefix": ""
}
},
"coms": [
{
"type": "UIImageView",
"id": "Charging_Animation_Image",
"x": 180,
"y": 410,
"w": 400,
"h": 400,
"resPath": "/vendor/etc/charger/resources/",
"imgCnt": 62,
"updInterval": 60,
"filePrefix": "loop"
},
{
"type": "UILabel",
"id": "Charging_Percent_Label",
"text": "",
"x": 365,
"y": 580,
"w": 65,
"h": 43,
"fontSize": 32
},
{
"type": "UILabel",
"id": "LackPower_Charging_Label",
"text": "Low battery level",
"x": 229,
"y": 1037,
"w": 250,
"h": 45,
"fontSize": 42,
"fontColor": "#ff0000ff"
},
{
"type": "UILabel",
"id": "LackPower_Not_Charging_Label",
"text": "Low battery level. Please connect the power supply.",
"x": 110,
"y": 1037,
"w": 500,
"h": 45,
"fontSize": 42,
"fontColor": "#ff0000ff"
}
]
}
```
Packing path: /system/etc/charger/resource
en/device-dev/subsystems/subsys-power-stats-power-average-customization.md 0 → 100644
浏览文件 @ 5205180c
# Power Consumption Statistics Customization
## Overview
### Introduction
By default, OpenHarmony provides the power consumption statistics feature. However, the power consumption benchmarks vary according to hardware specifications of different products. To address this issue, OpenHarmony provides the power consumption statistics customization function, allowing you to customize power consumption benchmarks depending on your hardware specifications.
### Basic Concepts
Power consumption statistics: When a user uses a device, software and hardware services running on the device report usage events through [HiSysEvent](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/subsys-dfx-hisysevent-overview.md). The usage duration of software and hardware can be calculated based on these reported events. Then, the power consumption of the software and hardware can be calculated based on the hardware power consumption benchmarks.
Power consumption benchmark: baseline power consumption (unit: mA) of the product hardware in various states, for example, the baseline power consumption when the camera is turned on and the baseline power consumption of the CPU at different frequencies.
### Constraints
The configuration path for power consumption statistics customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate power consumption statistics customization.
1. Create the `battery_statistics` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of power consumption statistics configuration](https://gitee.com/openharmony/powermgr_battery_statistics/tree/master/services/profile), and install it in `//vendor/hihope/rk3568/battery_statistics`. The content is as follows:
```shell
profile
├── BUILD.gn # BUILD.gn file
└── power_average.json # Configuration file for power consumption statistics, including the hardware power consumption benchmarks
```
3. Write the custom `power_average.json` file by referring to the [power_average.json](https://gitee.com/openharmony/powermgr_battery_statistics/blob/master/services/profile/power_average.json) file in the default folder of power consumption statistics configuration. The following table describes the configuration items for power consumption benchmarks.
**Table 1** Description of the configuration items for power consumption benchmarks
| Configuration Item| Hardware Type| Data Type| Description|
|----------|------|---------|-------------------------------------------------------------------------|
| alarm_on | - | Double | Power consumption when the timer is triggered by the system or application once; that is, the baseline power consumption.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Number of triggering times x Power consumption benchmark|
| bluetooth_br_on | Bluetooth | Double | Baseline power consumption when Bluetooth is enabled.<br>- Power consumption type: hardware power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| bluetooth_br_scan | Bluetooth | Double | Baseline power consumption for Bluetooth scanning.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| bluetooth_ble_on | Bluetooth | Double | Baseline power consumption when Bluetooth Low Energy (BLE) is enabled.<br>- Power consumption type: hardware power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| bluetooth_ble_scan | Bluetooth | Double | Baseline power consumption for Bluetooth Low Energy (BLE) scanning.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| wifi_on | WIFI | Double | Baseline power consumption when Wi-Fi is enabled.<br>- Power consumption type: hardware power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| wifi_scan | WIFI | Double | Power consumption when Wi-Fi scanning is performed once.<br>- Power consumption type: hardware power consumption<br>- Statistical method: Power consumption = Number of triggering times x Power consumption benchmark|
| radio_on | Phone | Double array| Baseline power consumption when the call service is enabled. The value is in array format and is used to configure the baseline power consumption for different signal strength levels. The default configuration provides the baseline power consumption for four signal strength levels.<br>- Power consumption type: hardware power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| radio_data | Phone | Double array| Baseline power consumption when the network service is enabled. The value is in array format and is used to configure the baseline power consumption for different signal strength levels. The default configuration provides the baseline power consumption for four signal strength levels.<br>- Power consumption type: hardware power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| camera_on | Camera | Double | Baseline power consumption when the camera is enabled.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| flashlight_on | Flashlight | Double | Baseline power consumption when the flashlight is enabled.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| gnss_on | GNSS | Double | Baseline power consumption when the Global Navigation Satellite System (GNSS) is enabled.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| sensor_gravity_on | Gravity Sensor | Double | Baseline power consumption when the gravity sensor is enabled.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| sensor_proximity_on | Proximity Sensor | Double | Baseline power consumption when the proximity sensor is enabled.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| audio_on | Audio | Double | Baseline power consumption when the audio is enabled.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| screen_on<br>screen_brightness | Screen | Double | **screen\_on**: baseline power consumption of the screen in the basic state (excluding power consumption generated by screen brightness).<br>**screen\_brightness**: baseline power consumption additionally required when the screen brightness increases by one level.<br>For example, if **screen_on** is **90**, **screen_brightness** is **2**, and the screen brightness is **100**, then the baseline power consumption is calculated as follows: 90 + 2 x 100 = 290.<br>- Power consumption type: hardware power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| cpu_awake | CPU | Double | Baseline power consumption when the CPU wakes up the lock from the lock holding state.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| cpu_idle | CPU | Double | Baseline power consumption when the CPU is in the idle state.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| cpu_suspend | CPU | Double | Baseline power consumption when the CPU is in the sleep state.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| cpu_active | CPU | Double | Baseline power consumption when the CPU is in the active state.<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
| cpu_clusters<br>cpu_speed_clusterX | CPU | Double array| cpu\_clusters: baseline power consumption of a CPU cluster. The value is in array format and is used to configure the baseline power consumption for different CPU clusters. The default configuration provides the baseline power consumption for three CPU clusters.<br>cpu\_speed\_clusterX: baseline power consumption of a CPU cluster at different frequencies, in array format. **X** indicates the sequence number. By default, its value ranges from **0** to **2**, corresponding to the size of the **cpu_clusters** array. For example, if the default size of the **cpu_clusters** array is **3**, the sequence number corresponds to the configuration items **cpu_speed_cluster0**, **cpu_speed_cluster1**, and **cpu_speed_cluster2**.<br>- Scalability: scalability of CPU clusters<br>- Power consumption type: software power consumption<br>- Statistical method: Power consumption = Usage duration x Power consumption benchmark|
>**NOTE**<br>The hardware type described in the table is the actual hardware name and does not represent the power consumption statistics type. For details about the power consumption statistics type, see [ConsumptionType](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-batteryStatistics.md#consumptiontype).
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_battery_statistics/blob/master/services/profile/BUILD.gn) file in the default folder of power consumption statistics configuration to pack the `power_average.json` file to the `//vendor/etc/profile` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
# Install power_average.json to /vendor/etc/profile/power_average.json
ohos_prebuilt_etc("power_average_config") { # Custom name, for example, power_average_config.
source = "power_average.json"
relative_install_dir = "profile"
install_images = [ chipset_base_dir ] # Required configuration for installing the power_average_config file in the vendor directory, where chipset_base_dir = "vendor". If this field is left unspecified, the power_average_config file is installed in the system directory by default.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/battery_statistics/profile:power_average_config", # Add the configuration for building of power_average_config.
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf"
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/power/battery_statistics/` is the folder path, `profile` is the folder name, and `power_average_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Run the following command to check whether the `power\_average\_config` file is successfully created in the `vendor` directory:
```shell
ls -l /vendor/etc/profile/
```
The `power\_average\_config` file is successfully created if it exists in `/vendor/etc/profile/`.
```shell
# ls -l /vendor/etc/profile/
total 4
-rw-r--r-- 1 root root 1446 2023-03-26 16:47 power_average.json
#
```
3. If the `power_average_config` file is successfully created, run the following command to check whether the information in the `power_average_config` file in the `vendor` directory is consistent with the customized information:
```shell
cat /vendor/etc/profile/power_average.json
```
4. If the information is consistent, run the following command to view the power consumption statistics:
```shell
hidumper -s 3304 -a -poweraverage
```
5. Check the console output for the custom power consumption benchmark information.
For example, the default power consumption benchmark information is as follows:
```shell
# hidumper -s 3304 -a -poweraverage
-------------------------------[ability]-------------------------------
----------------------------------BatteryStatisticsService---------------------------------
POWER AVERAGE CONFIGATION DUMP:
··· (Only the camera configuration is displayed here. Other information is omitted.)
camera_on : 810.000000
······
```
If the power consumption statistics benchmark is set to **camera_on:3000** (default value: **810**), the console output is as follows:
```shell
# hidumper -s 3304 -a -poweraverage
-------------------------------[ability]-------------------------------
----------------------------------BatteryStatisticsService---------------------------------
POWER AVERAGE CONFIGATION DUMP:
··· (Only the camera configuration is displayed here. Other information is omitted.)
camera_on : 3000.000000 # Set the power consumption benchmark to "camera_on": 3000.
······
```
6. Check whether the power consumption statistics are calculated according to the custom power consumption benchmark in the `power_average_config` file.
7. You can use the [JS APIs](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.batteryStatistics.d.ts) or [Inner APIs](https://gitee.com/openharmony/powermgr_battery_statistics/blob/master/interfaces/innerkits/include/battery_stats_client.h) provided by the **batterystatistics** module to obtain detailed power consumption information and verify the custom power consumption benchmark.
## Reference
During development, you can refer to the [default power consumption statistics configuration](https://gitee.com/openharmony/powermgr_battery_statistics/tree/master/services/profile/power_average.json).
Default packing path: /system/etc/profile
Customization path: /vendor/etc/profile
en/device-dev/subsystems/subsys-power-temperature-protection.md 0 → 100644
浏览文件 @ 5205180c
# Battery Temperature Protection Customization
## Overview
### Introduction
OpenHarmony provides battery temperature protection by default. When a device is used in different environments, the battery temperature may become excessively high or low due to the impact of ambient environment. In such a case, the protection measures, for example, device shutdown, must be taken to ensure the device safety. However, the supported temperature range varies according to products. To address this issue, OpenHarmony provides the function of customizing the temperature range for battery protection.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate charging type customization.
1. Create the battery folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of power temperature projection configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/battery`. The content is as follows:
```text
profile
├── BUILD.gn
├── battery_config.json
```
3. Write the custom `battery_config.json` file by referring to the `battery_config.json` file in the default folder of power temperature projection configuration. For example:
```json
{
"temperature": {
"high": 500,
"low": -400
}
}
```
**Table 1** Description of temperature protection configuration
| Temperature Protection Threshold| Temperature (°C)|
| -------- | -------- |
| high | 600 |
| low | -500 |
4. Write the `BUILD.gn` file by referring to the `BUILD.gn` in the default folder of power temperature projection configuration to pack the `battery_config.json` file to the `//vendor/etc/battery` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("battery_config") {
source = "battery_config.json"
relative_install_dir = "battery"
install_images = [ chipset_base_dir ] # Required configuration for installing the battery_config.json file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/battery/profile:battery_config" # Add the configuration for building of battery_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/battery/` is the folder path, `profile` is the folder name, and `battery_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```
hdc shell
```
2. Go to the custom battery temperature configuration directory. The path of DAYU200 is used as an example.
```
cd /data/service/el0/battery/battery
```
3. Modify the battery temperature. The following uses the default power temperature protection configuration as an example.
```
echo 700 > temp
```
4. Report the battery information change to trigger temperature protection.
```
hidumper -s 3302 -a -r
```
The device is powered off.
5. Upon restarting, launch the shell command line, and modify the battery temperature.
```
echo -600 > temp
```
6. Report the battery information change to trigger temperature protection.
```
hidumper -s 3302 -a -r
```
The device is powered off.
7. Customize the temperature protection threshold configuration. For example:
```json
{
"temperature": {
"high": 500,
"low": -400
}
}
```
8. Modify the temperature protection threshold.
```
echo 550 > temp
```
9. Report the battery information change to trigger temperature protection.
```
hidumper -s 3302 -a -r
```
The device is powered off.
10. Upon restarting, launch the shell command line, and modify the temperature protection threshold.
```
echo -450 > temp
```
11. Report the battery information change to trigger temperature protection.
```
hidumper -s 3302 -a -r
```
The device is powered off.
## Reference
During development, you can refer to the [default power temperature protection configuration](https://gitee.com/openharmony/powermgr_battery_manager/tree/master/services/native/profile/), as shown below:
```json
{
"temperature": {
"high": 600,
"low": -500
}
}
```
Packing path: /system/etc/battery
en/device-dev/subsystems/subsys-thermal_charging_idle_state.md 0 → 100644
浏览文件 @ 5205180c
# Charging Idle State Customization
## Overview
### Introduction
By default, OpenHarmony provides the charging idle state feature. It determines whether a device is currently in the idle state according to a thermal level, battery level, charging state, and charging current of the device. A device in this state may execute some background intensive tasks. However, the conditions that determine the charging idle state vary according to product specifications. To address this issue, OpenHarmony provides the charging idle state customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate charging idle state customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default folder of battery idle state configuration](https://gitee.com/openharmony/powermgr_thermal_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
```text
profile
├── BUILD.gn
├── thermal_service_config.xml
```
3. Write the custom `thermal_service_config.xml` file by referring to the [thermal_service_config.xml](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml) file in the default folder of charging idle state configuration. The following table describes the related configuration items.
**Table 1** Configuration items for the charging idle state
| Configuration Item| Description| Data Type| Value Range|
| -------- | -------- | -------- | -------- |
| thermallevel | Thermal level threshold| int | This field is defined based on the thermal level of a device. If the thermal level of a device is less than or equal to the threshold, the device is in the charging idle state.|
| soc | Battery level threshold| int | The value of this field ranges from 0 to 100. If the battery level of the device is greater than or equal to the specified threshold, the device is in the charging idle state.|
| charging | Charging status| int | The value **1** indicates that the battery is being charged, and the value **0** indicates the opposite.|
| current | Battery charging current threshold| int | When the battery charging current is greater than or equal to the specified threshold (in mA), the battery is in the charging idle state.|
```shell
<idle name="charging">
<thermallevel>1</thermallevel>
<soc>90</soc>
<charging>1</charging>
<current>1000</current>
</idle>
```
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/BUILD.gn) file in the default folder of charging idle state configuration to pack the `thermal_service_config.xml` file to the `/vendor/etc/thermal_config` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("thermal_service_config") {
source = "thermal_service_config.xml"
relative_install_dir = "thermal_config"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_service_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/thermal/profile:thermal_service_config", // Add the configuration for building of thermal_service_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` is the folder name, and `thermal_hdf_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Obtain the current charging idle state.
```shell
hidumper -s 3303 -a -i
```
The following is the reference charging idle state after customization:
```shell
-------------------------------[ability]-------------------------------
----------------------------------ThermalService---------------------------------
thermallevel: 1
soc: 100
charging: 1
current: 1000
```
## Reference
During development, you can refer to the [default charging idle state configuration](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml).
Packing path: `/vendor/etc/thermal_config/hdf`
en/device-dev/subsystems/subsys-thermal_control.md 0 → 100644
浏览文件 @ 5205180c
# Thermal Control Customization
## Overview
### Introduction
By default, OpenHarmony provides the thermal control feature. If a device becomes overheated during usage, thermal control measures need to be taken for the device. For example, if the battery temperature is too high during charging, then thermal control needs to be applied to the charging device. However, thermal control varies according to product specifications. To address this issue, OpenHarmony provides the thermal control customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate thermal control customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default thermal control configuration folder](https://gitee.com/openharmony/powermgr_thermal_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
```text
profile
├── BUILD.gn
├── thermal_service_config.xml
```
3. Write the custom `thermal_service_config.xml` file by referring to the [thermal_service_config.xml](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml) file in the default thermal control configuration folder. The following table describes the related configuration items.
**Table 1** Configuration items for thermal control
| Configuration Item| Configuration Item Description| Parameter| Parameter Description| Data Type|Value Range|
| -------- | -------- | -------- | -------- | -------- | -------- |
| name="cpu_big" | Big-core CPU control (big-core CPU frequency)| N/A| N/A| N/A| N/A|
| name="cpu_med" | Medium-core CPU control (medium-core CPU frequency)| N/A| N/A| N/A| N/A|
| name="cpu_lit" | Small-core CPU control (small-core CPU frequency)| N/A| N/A| N/A| N/A|
| name="gpu" | GPU control (GPU frequency)| N/A| N/A| N/A| N/A|
| name="lcd" | LCD control (screen brightness)| N/A| N/A| N/A| N/A|
| name="volume" | Sound control (volume)| uid | User ID| int | Product-specific|
| name="current" | Charging current control (charging current during fast charging and slow charging)| protocol | Supported charging protocols: fast charging (supercharge) and slow charging (buck)| string | sc or buck|
| name="current" | Charging current control | event | - **1**: event sending enabled<br>-**0**: event sending disabled| int | 0 or 1|
| name="voltage" | Charging voltage control (charging voltage during fast charging and slow charging)| protocol | Supported charging protocols: fast charging (supercharge) and slow charging (buck)| string | sc or buck|
| name="voltage" | Charging voltage control | event | - **1**: event sending enabled<br>-**0**: event sending disabled| int | 0 or 1|
| name="process_ctrl" | Process control (survival status of foreground and background processes)| event | - **1**: event sending enabled<br>-**0**: event sending disabled| int | 0 or 1|
| name="shut_down" | Shutdown control (device shutdown)| event | - **1**: event sending enabled<br>-**0**: event sending disabled| int | 0 or 1|
| name="thermallevel" | Thermal level control (thermal level reporting)| event | - **1**: event sending enabled<br>-**0**: event sending disabled| int | 0 or 1|
| name="popup" | Pop-up window control (pop-up window display)| N/A| N/A| N/A| N/A|
```shell
<action>
<item name="cpu_big"/>
<item name="cpu_med"/>
<item name="cpu_lit"/>
<item name="gpu"/>
<item name="lcd"/>
<item name="volume" uid="2001,2002"/>
<item name="current" protocol="sc,buck" event="1"/>
<item name="voltage" protocol="sc,buck" event="1"/>
<item name="process_ctrl" param="32,64,128,256" event=""/>
<item name="shut_down" event="0"/>
<item name="thermallevel" event="0"/>
<item name="popup"/>
</action>
```
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/BUILD.gn) file in the default thermal control configuration folder to pack the `thermal_service_config.xml` file to the `/vendor/etc/thermal_config` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("thermal_service_config") {
source = "thermal_service_config.xml"
relative_install_dir = "thermal_config"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_service_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/thermal/profile:thermal_service_config", // Add the configuration for building of thermal_service_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` is the folder name, and `thermal_hdf_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Obtain the current thermal control information.
```shell
hidumper -s 3303 -a -a
```
The following is the reference thermal control result after customization:
```shell
-------------------------------[ability]-------------------------------
----------------------------------ThermalService---------------------------------
name: cpu_big strict: 0 enableEvent: 0
name: cpu_med strict: 0 enableEvent: 0
name: cpu_lit strict: 0 enableEvent: 0
name: gpu strict: 0 enableEvent: 0
name: boost strict: 0 enableEvent: 0
name: lcd strict: 0 enableEvent: 0
name: volume uid: 2001,2002 strict: 0 enableEvent: 0
name: current protocol: sc,buck strict: 0 enableEvent: 1
name: voltage protocol: sc,buck strict: 0 enableEvent: 1
name: process_ctrl params: 32,64,128,256 strict: 0 enableEvent: 0
name: shut_down strict: 0 enableEvent: 0
name: thermallevel strict: 0 enableEvent: 0
name: popup strict: 0 enableEvent: 0
```
## Reference
During development, you can refer to the [default thermal control configuration](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml).
Packing path: `/vendor/etc/thermal_config/hdf`
en/device-dev/subsystems/subsys-thermal_detection.md 0 → 100644
浏览文件 @ 5205180c
# Thermal Detection Customization
## Overview
### Introduction
By default, OpenHarmony provides the thermal detection feature. A component, for example, the CPU or battery, generates heat while it is running. In this case, the component reports its temperature in real time through the corresponding temperature sensor. The thermal detection feature detects the temperature of components in real time and provides temperature input for the thermal management module. However, thermal detection on components varies according to product specifications. To address this issue, OpenHarmony provides the thermal detection customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate thermal detection customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default thermal detection configuration folder](https://gitee.com/openharmony/drivers_peripheral/tree/master/thermal/interfaces/hdi_service/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
```text
profile
├── BUILD.gn
├── thermal_hdi_config.xml
```
3. Write the custom `thermal_hdi_config.xml` file by referring to the [thermal_hdi_config.xml](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/interfaces/hdi_service/profile/thermal_hdi_config.xml) file in the default thermal detection configuration folder. The following table describes the related configuration items.
**Table 1** Configuration items for thermal detection
|Node| Configuration Item| Description| Value Type|
| -------- | -------- | -------- | -------- |
| item | tag | Temperature flag name of an actual or simulated node.| string |
| item | value | Temperature flag value. Value **1** means to obtain the temperature of a simulated node, and the value **0**, means to obtain the temperature of an actual node.| int |
| group | name | Name of the actual or simulated node group.| string |
| group | interval | Polling interval, in ms (default).| int |
| thermal_zone | type | Thermal zone name.| string |
| thermal_zone | path | Path for obtaining the thermal zone temperature of an actual node.| string |
| thermal_node | type | Thermal node name.| string |
| thermal_node | path | Path for obtaining the thermal node temperature of a simulated node.| string |
```shell
<base>
<item tag="sim_tz" value="0"/>
</base>
<polling>
<group name="actual" interval="30000">
<thermal_zone type="soc-thermal" path="sys/class/thermal/thermal_zone0/temp"/>
<thermal_zone type="gpu-thermal" path="sys/class/thermal/thermal_zone0/temp"/>
</group>
<group name="sim" interval="30000">
<thermal_node type="soc" path="data/service/el0/thermal/sensor/soc/temp"/>
<thermal_node type="cpu" path="data/service/el0/thermal/sensor/cpu/temp"/>
<thermal_node type="ap" path="data/service/el0/thermal/sensor/ap/temp"/>
<thermal_node type="pa" path="data/service/el0/thermal/sensor/pa/temp"/>
<thermal_node type="ambient" path="data/service/el0/thermal/sensor/ambient/temp"/>
<thermal_node type="charger" path="data/service/el0/thermal/sensor/charger/temp"/>
<thermal_node type="battery" path="data/service/el0/thermal/sensor/battery/temp"/>
<thermal_node type="shell" path="data/service/el0/thermal/sensor/shell/temp"/>
</group>
</polling>
```
For details about the path for obtaining the actual node temperature, see the path for obtaining the thermal zone temperature in [Thermal Log](../subsystems/subsys-thermal_log.md). For details about the path for obtaining the simulated node temperature, see [Default Thermal Detection Configuration](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/interfaces/hdi_service/profile/thermal_hdi_config.xml).
5. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/interfaces/hdi_service/profile/BUILD.gn) file in the default thermal detection configuration folder to pack the `thermal_hdi_config.xml` file to the `//vendor/etc/thermal_config/hdf` directory. The configuration is as follows:
```shell
import("//build/ohos.gni")
ohos_prebuilt_etc("thermal_hdf_config") {
source = "thermal_hdi_config.xml"
relative_install_dir = "thermal_config/hdf"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_hdi_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
6. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/thermal/profile:thermal_hdf_config", // Add the configuration for building of thermal_hdf_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` is the folder name, and `thermal_hdf_config` is the build target.
7. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
8. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Obtain the thermal detection result of the thermal zone.
```shell
hidumper -s 3303 -a -t
```
The following is the reference thermal detection result of the thermal zone. The value of **Temperature** is in unit of 0.001°C by default.
```shell
-------------------------------[ability]-------------------------------
----------------------------------ThermalService---------------------------------
········· (Only the thermal detection result is displayed here. Other information is omitted.)
Type: gpu-thermal
Temperature: 35555
Type: soc-thermal
Temperature: 35000
······
```
## Reference
During development, you can refer to the [default thermal detection configuration](https://gitee.com/openharmony/drivers_peripheral/tree/master/thermal/interfaces/hdi_service/profile/thermal_hdf_config.xml).
Packing path: `/vendor/etc/thermal_config/hdf`
en/device-dev/subsystems/subsys-thermal_level.md 0 → 100644
浏览文件 @ 5205180c
# Thermal Level Customization
## Overview
### Introduction
By default, OpenHarmony provides the thermal level feature. Different hardware devices generate different amounts of heat and can tolerate different maximum temperatures. Therefore, for different components, the thermal level standard needs to be defined based on their temperatures to clearly indicate the thermal status and provide input for thermal control. However, the thermal level of components at different temperatures varies according to product specifications. To address this issue, OpenHarmony provides the thermal level customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate thermal level customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default thermal level configuration folder](https://gitee.com/openharmony/powermgr_thermal_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
```text
profile
├── BUILD.gn
├── thermal_service_config.xml
```
3. Write the custom `thermal_service_config.xml` file by referring to the [thermal_service_config.xml](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml) file in the default thermal level configuration folder. The following tables describe the related configuration items.
**Table 1** Description of the base configuration
| Configuration Item| Description| Parameter| Parameter Description| Type| Value Range|
| -------- | -------- | -------- | -------- | -------- | -------- |
| tag="history_temp_count" | Name of the tag indicating the number of historical temperature reporting times.| value | Number of historical temperature reporting times.| int | >0 |
| tag="temperature_query_enum" | Tag name of the device list for obtaining the temperature.| value | Device list for obtaining the temperature.| enum | soc, battery, shell, cpu, charger, ambient, ap, and pa|
**Table 2** Description of the sensor_cluster configuration
| Configuration Item | Description | Data Type | Value Range |
| -------- | -------- | -------- | -------- |
| name | Sensor cluster name | string | None |
| sensor | Sensors in the cluster | string | soc, battery, shell, cpu, charger, ambient, ap, and pa |
| aux_sensor | Auxiliary sensors in the cluster | string | soc, battery, shell, cpu, charger, ambient, ap, and pa |
**Table 3** Description of the item configuration
| Configuration Item | Description | Data Type | Value Range |
| -------- | -------- | -------- | -------- |
| level | Thermal level defined for each sensor cluster | int | >0 |
| threshold | Temperature threshold for each sensor in the cluster to reach the corresponding thermal level. The value is in unit of 0.001°C by default and can be changed as needed. | int | Product-specific |
| threshold_clr | Temperature threshold for each sensor in the cluster to roll back to the previous thermal level. | int | Product-specific |
| temp_rise_rate | Temperature rise frequency. | double | Product-specific |
```shell
<thermal version="0.01" product="lya">
<base>
<item tag="history_temp_count" value="10"/>
<item tag="temperature_query_enum" value="soc,battery,shell,cpu,charger,ambient,ap,pa"/>
</base>
<level>
<sensor_cluster name="base_safe" sensor="battery,charger,cpu,soc">
<item level="1" threshold="42000,40000,30000,40000" threshold_clr="38000,36000,28000,38000"/>
<item level="2" threshold="43000,41000,32000,42000" threshold_clr="41000,39000,30000,40000"/>
<item level="3" threshold="46000,44000,34000,44000" threshold_clr="44000,42000,32000,42000"/>
<item level="4" threshold="48000,46000,36000,46000" threshold_clr="46000,44000,34000,44000"/>
</sensor_cluster>
</level>
```
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/BUILD.gn) file in the default thermal level configuration folder to pack the `thermal_service_config.xml` file to the `/vendor/etc/thermal_config` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("thermal_service_config") {
source = "thermal_service_config.xml"
relative_install_dir = "thermal_config"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_service_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/thermal/profile:thermal_service_config", // Add the configuration for building of thermal_service_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` is the folder name, and `thermal_hdf_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Go to the `data/service/el0/thermal/sensor/soc/` directory.
```shell
cd data/service/el0/thermal/sensor/soc
```
3. Change the SOC temperature.
```shell
echo 42000 > temp
```
4. Obtain the current thermal level information.
```shell
hidumper -s 3303 -a -l
```
The following is the reference thermal level information after customization:
```shell
-------------------------------[ability]-------------------------------
----------------------------------ThermalService---------------------------------
name: base_safe level: 2
name: cold_safe level: 0
name: high_safe level: 0
name: warm_5G level: 0
name: warm_safe level: 1
```
## Reference
During development, you can refer to the [default thermal level configuration](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml).
Packing path: `/vendor/etc/thermal_config/hdf`
en/device-dev/subsystems/subsys-thermal_log.md 0 → 100644
浏览文件 @ 5205180c
# Thermal Log Customization
## Overview
### Introduction
By default, the OpenHarmony provides the thermal log feature. Thermal logs record the temperature of device components during usage. However, the content and path of thermal logs vary according to product specifications. To address this issue, OpenHarmony provides the thermal log customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate thermal log customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default thermal log configuration folder](https://gitee.com/openharmony/drivers_peripheral/tree/master/thermal/interfaces/hdi_service/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
```text
profile
├── BUILD.gn
├── thermal_hdi_config.xml
```
3. Create a target folder by referring to the [default thermal log parameter configuration folder] (https://gitee.com/openharmony/drivers_peripheral/tree/master/thermal/etc) and install it in `//vendor/hihope/rk3568/thermal`. The file format is as follows:
```text
etc
├── BUILD.gn
├── thermal.para
├── thermal.para.dac
```
4. Write the custom `thermal_hdi_config.xml` file by referring to the [thermal_hdi_config.xml](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/interfaces/hdi_service/profile/thermal_hdi_config.xml) file in the default thermal log configuration folder. The following tables describe the related configuration items.
**Table 1** Description of the tracing configuration
| Configuration Item| Description| Data Type| Value Range|
| -------- | -------- | -------- | -------- |
| interval | Interval for recording temperature tracing logs, in ms.| int | >0 |
| width | Width of the temperature tracing log, in characters.| int | >0 |
| outpath | Path for storing temperature tracing logs.| string | N/A|
**Table 2** Description of the node configuration
| Node| Configuration Item| Description|
| -------- | -------- | -------- |
| title | path | Path for obtaining the thermal zone name.|
| title | name | Thermal zone name.|
| value | path | Path for obtaining the thermal zone temperature.|
```shell
<tracing interval="5000" width="20" outpath="/data/log/thermal-log">
<node>
<title path="sys/class/thermal/thermal_zone0/type"/>
<value path="sys/class/thermal/thermal_zone0/temp"/>
</node>
<node>
<title name="gpu-thermal"/>
<value path="sys/class/thermal/thermal_zone1/temp"/>
</node>
</tracing>
```
5. Write the custom `thermal.para` and `thermal.para.dac` files by referring to the [thermal.para](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/etc/thermal.para) and [thermal.para.dac](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/etc/thermal.para.dac) files in the default hot log parameter configuration folder. The custom configuration is as follows:
thermal.para:
```text
persist.thermal.log.enable=true # Enable the thermal log function.
persist.thermal.log.interval=5000 # Set the interval for recording temperature tracing logs, in ms.
persist.thermal.log.width=20 # Set the width of the temperature tracing log, in characters.
```
thermal.para.dac:
```text
persist.thermal.log.="power_host:power_host:600" # Configure access permissions.
```
6. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/interfaces/hdi_service/profile/BUILD.gn) file in the default thermal log configuration folder to pack the `thermal_hdi_config.xml` file to the `//vendor/etc/thermal_config/hdf` directory. The configuration is as follows:
```shell
import("//build/ohos.gni")
ohos_prebuilt_etc("thermal_hdf_config") {
source = "thermal_hdi_config.xml"
relative_install_dir = "thermal_config/hdf"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_hdi_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
7. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/drivers_peripheral/blob/master/thermal/etc/BUILD.gn) file in the default thermal log parameter configuration folder to pack the `thermal.para` and `thermal.para.dac` files to the `//vendor/etc/param/thermal.para` directory. The configuration is as follows:
```shell
import("//build/ohos.gni")
## Install thermal.para to /vendor/etc/param/thermal.para
ohos_prebuilt_etc("thermal.para") {
source = "thermal.para"
relative_install_dir = "param"
install_images = [ chipset_base_dir ]
part_name = "product_rk3568"
}
ohos_prebuilt_etc("thermal.para.dac") {
source = "thermal.para.dac"
relative_install_dir = "param"
install_images = [ chipset_base_dir ]
part_name = "product_rk3568"
}
group("param_files") {
deps = [
":thermal.para",
":thermal.para.dac",
]
}
```
8. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/thermal/profile:thermal_hdf_config", // Add the configuration for building of thermal_hdf_config.
"//vendor/hihope/rk3568/thermal/etc:param_files" // Add the configuration for building of thermal.para and thermal.para.dac.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` and `etc` are folder names, and `thermal_hdf_config` and `param_files` are the build targets.
9. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
10. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Go to the customized directory.
```shell
cd /data/log/thermal/
```
View thermal logs.
```shell
cat thermal.000.20170805-175756
```
The following is the reference thermal log after customization:
```shell
timestamp soc-thermal gpu-thermal
2017-08-05 17:57:56 37777 37222
2017-08-05 17:58:01 38333 37777
2017-08-05 17:58:06 36666 37222
2017-08-05 17:58:11 36666 37222
2017-08-05 17:58:16 36666 37222
2017-08-05 17:58:21 36111 37222
2017-08-05 17:58:26 36111 37222
2017-08-05 17:58:31 36666 37222
2017-08-05 17:58:36 36111 37222
2017-08-05 17:58:41 36111 37222
2017-08-05 17:58:46 36666 36666
```
## Reference
During development, you can refer to the [default thermal log configuration](https://gitee.com/openharmony/drivers_peripheral/tree/master/thermal/interfaces/hdi_service/profile/) and [default thermal log parameter configuration](https://gitee.com/openharmony/drivers_peripheral/tree/master/thermal/etc).
Packing path: `/vendor/etc/thermal_config/hdf`
en/device-dev/subsystems/subsys-thermal_policy.md 0 → 100644
浏览文件 @ 5205180c
# Thermal Policy Customization
## Overview
### Introduction
By default, the OpenHarmony provides the thermal policy feature. Various components on a device can generate heat. Therefore, for different components, the thermal policy needs to be defined based on their thermal levels and thermal scenes. However, thermal control at different thermal levels varies according to product specifications. To address this issue, OpenHarmony provides the thermal policy customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate thermal policy customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default thermal policy configuration folder](https://gitee.com/openharmony/powermgr_thermal_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
```text
profile
├── BUILD.gn
├── thermal_service_config.xml
```
3. Write the custom `thermal_service_config.xml` file by referring to the [thermal_service_config.xml](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml) file in the default thermal policy configuration folder. The following tables describe the related configuration items.
**Table 1** Description of the config configuration
| Configuration Item| Description| Type| Value Range|
| -------- | -------- | -------- | -------- |
| name | Name of the sensor cluster corresponding to the thermal policy.| string | Corresponding to the sensor cluster name defined in [Thermal Level](../subsystems/subsys-thermal_level.md).|
| level | Thermal level corresponding to the thermal policy.| int | Corresponding to the thermal level defined for the sensor cluster in [Thermal Level](../subsystems/subsys-thermal_level.md).|
**Table 2** Description of configuration items
| Configuration Item| Description| Type| Value Range|
| -------- | -------- | -------- | -------- |
| scene | Application scenario.| string | Corresponding to the application scenario defined in [Thermal Scene](../subsystems/subsys-thermal_scene.md).|
| charge | Charging status.| int | The value **1** indicates charging, and the value **0** indicates the opposite.|
| screen | Screen status.| int | The value **1** indicates that the screen is on, and the value **0** indicates the opposite.|
**Table 3** Description of the node configuration
| Node| Value Type| Value Range| Description|
| -------- | -------- | -------- | -------- |
| lcd | double | 0.00~1.00 | Percentage of the screen brightness (represented by a floating point number).|
| cpu_big | int | Product-specific| CPU big core frequency.|
| cpu_med | int | Product-specific| CPU medium-core frequency.|
| cpu_lit | int | Product-specific| CPU small-core frequency.|
| process_ctrl | enum | 1: KILL_FG_PROCESS_APP<br>2: KILL_BG_PROCESS_APP<br>3: KILL_ALL_PROCESS_APP| Process control.|
| gpu | int | Product-specific| GPU frequency.|
| thermallevel | int | Corresponding to **level** defined in the **config** node| Thermal level.|
| current_sc | int | Product-specific| Fast charging current.|
| current_buck | int | Product-specific| Slow charging current.|
| voltage_sc | int | Product-specific| Fast charging voltage.|
| voltage_buck | int | Product-specific| Slow charging voltage.|
| volume | double | 0.00~1.00 | Volume percentage (represented by a floating point number).|
```shell
<policy>
<config name="base_safe" level="1">
<lcd>1.00</lcd>
<lcd scene="cam">0.99</lcd>
<lcd scene="call">0.98</lcd>
<lcd scene="game">0.95</lcd>
<cpu_big>1992000</cpu_big>
<cpu_med>1991500</cpu_med>
<cpu_lit>1991200</cpu_lit>
<process_ctrl>3</process_ctrl>
<cpu_big scene="cam" charge="1">1991800</cpu_big>
<cpu_big scene="cam" charge="0">1991600</cpu_big>
<gpu screen="0">524288</gpu>
<gpu screen="1">512000</gpu>
<thermallevel>1</thermallevel>
<current_sc>1800</current_sc>
<current_sc scene="cam">1200</current_sc>
<current_buck>1200</current_buck>
<voltage_sc>4000</voltage_sc>
<voltage_buck>3000</voltage_buck>
<volume>1.0</volume>
</config>
<policy>
<config name="base_safe" level="2">
<lcd>0.90</lcd>
<lcd scene="cam">0.89</lcd>
<lcd scene="call">0.88</lcd>
<lcd scene="game">0.87</lcd>
<cpu_big>1991000</cpu_big>
<cpu_med>1990500</cpu_med>
<cpu_lit>1990200</cpu_lit>
<process_ctrl>2</process_ctrl>
<cpu_big scene="cam" charge="1">1990800</cpu_big>
<cpu_big scene="cam" charge="0">1990600</cpu_big>
<gpu screen="0">499712</gpu>
<gpu screen="1">487424</gpu>
<thermallevel>2</thermallevel>
<current_sc>1500</current_sc>
<current_sc scene="cam">1000</current_sc>
<current_buck>1000</current_buck>
<voltage_sc>3000</voltage_sc>
<voltage_buck>2000</voltage_buck>
<volume>0.8</volume>
</config>
</policy>
```
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/BUILD.gn) file in the default thermal policy configuration folder to pack the `thermal_service_config.xml` file to the `/vendor/etc/thermal_config` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("thermal_service_config") {
source = "thermal_service_config.xml"
relative_install_dir = "thermal_config"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_service_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/thermal/profile:thermal_service_config", // Add the configuration for building of thermal_service_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` is the folder name, and `thermal_hdf_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Obtain the current thermal policy information.
```shell
hidumper -s 3303 -a -p
```
The following is the reference thermal policy result after customization:
```shell
-------------------------------[ability]-------------------------------
----------------------------------ThermalService---------------------------------
name: base_safe level: 1
actionName: lcd actionValue: 1.00 isProp: 0
actionName: lcd actionValue: 0.99 scene: cam isProp: 1
actionName: lcd actionValue: 0.98 scene: call isProp: 1
actionName: lcd actionValue: 0.95 scene: game isProp: 1
actionName: cpu_big actionValue: 1992000 isProp: 0
actionName: cpu_med actionValue: 1991500 isProp: 0
actionName: cpu_lit actionValue: 1991200 isProp: 0
actionName: process_ctrl actionValue: 3 isProp: 0
actionName: cpu_big actionValue: 1991800 charge: 1 scene: cam isProp: 1
actionName: cpu_big actionValue: 1991600 charge: 0 scene: cam isProp: 1
actionName: gpu actionValue: 524288 screen: 0 isProp: 1
actionName: gpu actionValue: 512000 screen: 1 isProp: 1
actionName: thermallevel actionValue: 1 isProp: 0
actionName: current_sc actionValue: 1800 isProp: 0
actionName: current_sc actionValue: 1200 scene: cam isProp: 1
actionName: current_buck actionValue: 1200 isProp: 0
actionName: voltage_sc actionValue: 4000 isProp: 0
actionName: voltage_buck actionValue: 3000 isProp: 0
actionName: volume actionValue: 1.0 isProp: 0
actionName: boost actionValue: 1 isProp: 0
level: 2
actionName: lcd actionValue: 0.90 isProp: 0
actionName: lcd actionValue: 0.89 scene: cam isProp: 1
actionName: lcd actionValue: 0.88 scene: call isProp: 1
actionName: lcd actionValue: 0.87 scene: game isProp: 1
actionName: cpu_big actionValue: 1991000 isProp: 0
actionName: cpu_med actionValue: 1990500 isProp: 0
actionName: cpu_lit actionValue: 1990200 isProp: 0
actionName: process_ctrl actionValue: 2 isProp: 0
actionName: cpu_big actionValue: 1990800 charge: 1 scene: cam isProp: 1
actionName: cpu_big actionValue: 1990600 charge: 0 scene: cam isProp: 1
actionName: gpu actionValue: 499712 screen: 0 isProp: 1
actionName: gpu actionValue: 487424 screen: 1 isProp: 1
actionName: thermallevel actionValue: 2 isProp: 0
actionName: current_sc actionValue: 1500 isProp: 0
actionName: current_sc actionValue: 1000 scene: cam isProp: 1
actionName: current_buck actionValue: 1000 isProp: 0
actionName: voltage_sc actionValue: 3000 isProp: 0
actionName: voltage_buck actionValue: 2000 isProp: 0
actionName: volume actionValue: 0.8 isProp: 0
actionName: boost actionValue: 1 isProp: 0
```
## Reference
During development, you can refer to the [default thermal policy configuration](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml).
Packing path: `/vendor/etc/thermal_config/hdf`
en/device-dev/subsystems/subsys-thermal_scene.md 0 → 100644
浏览文件 @ 5205180c
# Thermal Scene Customization
## Overview
### Introduction
By default, OpenHarmony provides the thermal scene feature. During device usage, for example, gaming, photographing, or calling, the system will try to balance the performance, temperature, and power consumption. The thermal policy is usually scenario-specific. For example, the thermal policy in the gaming scenario does not decrease the screen brightness. However, the thermal scene definition varies according to product specifications. To address this issue, OpenHarmony provides the thermal scene customization function.
### Constraints
The configuration path for battery level customization is subject to the [configuration policy](https://gitee.com/openharmony/customization_config_policy). In this development guide, `/vendor` is used as an example of the configuration path. During actual development, you need to modify the customization path based on the product configuration policy.
## How to Develop
### Setting Up the Environment
**Hardware requirements:**
Development board running the standard system, for example, the DAYU200 or Hi3516D V300 open source suite.
**Environment requirements:**
For details about the requirements on the Linux environment, see [Quick Start](../quick-start/quickstart-overview.md).
### Getting Started with Development
The following uses [DAYU200](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568) as an example to illustrate thermal scene customization.
1. Create the `thermal` folder in the product directory [/vendor/hihope/rk3568](https://gitee.com/openharmony/vendor_hihope/tree/master/rk3568).
2. Create a target folder by referring to the [default thermal scene configuration folder](https://gitee.com/openharmony/powermgr_thermal_manager/tree/master/services/native/profile), and install it in `//vendor/hihope/rk3568/thermal`. The content is as follows:
```text
profile
├── BUILD.gn
├── thermal_service_config.xml
```
3. Write the custom `thermal_service_config.xml` file by referring to the [thermal_service_config.xml](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml) file in the default thermal scene configuration folder. The following table describes the related configuration items.
**Table 1** Configuration items for the thermal scene
| Configuration Item| Configuration Item Description| Parameter| Parameter Description| Parameter Type| Value Range|
| -------- | -------- | -------- | -------- | -------- | -------- |
| name="scene" | One or more application scenarios specified by enum values.| param | Application scenarios: photographing, calling, and gaming.| enum | cam, call, and game|
**screen** and **charge** indicate the status of the application scenario; and specifically, whether the screen is turned on and whether the battery is being charged.
```shell
<state>
<item name="scene" param="cam,call,game"/>
<item name="screen"/>
<item name="charge"/>
</state>
```
4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/BUILD.gn) file in the default thermal scene configuration folder to pack the `thermal_service_config.xml` file to the `/vendor/etc/thermal_config` directory. The configuration is as follows:
```shell
import("//build/ohos.gni") # Reference build/ohos.gni.
ohos_prebuilt_etc("thermal_service_config") {
source = "thermal_service_config.xml"
relative_install_dir = "thermal_config"
install_images = [ chipset_base_dir ] # Required configuration for installing the thermal_service_config.xml file in the vendor directory.
part_name = "product_rk3568" # Set part_name to product_rk3568 for subsequent build. You can change it as required.
}
```
5. Add the build target to `module_list` in [ohos.build](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/ohos.build) in the `/vendor/hihope/rk3568` directory. For example:
```json
{
"parts": {
"product_rk3568": {
"module_list": [
"//vendor/hihope/rk3568/default_app_config:default_app_config",
"//vendor/hihope/rk3568/image_conf:custom_image_conf",
"//vendor/hihope/rk3568/preinstall-config:preinstall-config",
"//vendor/hihope/rk3568/resourceschedule:resourceschedule",
"//vendor/hihope/rk3568/etc:product_etc_conf",
"//vendor/hihope/rk3568/thermal/profile:thermal_service_config", // Add the configuration for building of thermal_service_config.
]
}
},
"subsystem": "product_hihope"
}
```
In the preceding code, `//vendor/hihope/rk3568/thermal/` is the folder path, `profile` is the folder name, and `thermal_hdf_config` is the build target.
6. Build the customized version by referring to [Quick Start](../quick-start/quickstart-overview.md).
```shell
./build.sh --product-name rk3568 --ccache
```
7. Burn the customized version to the DAYU200 development board.
### Debugging and Verification
1. After startup, run the following command to launch the shell command line:
```shell
hdc shell
```
2. Obtain the current thermal scene information.
```shell
hidumper -s 3303 -a -s
```
The following is the reference thermal scene result after customization:
```shell
-------------------------------[ability]-------------------------------
----------------------------------ThermalService---------------------------------
name: scene params: cam,call,game
name: screen
name: charge
```
## Reference
During development, you can refer to the [default thermal scene configuration](https://gitee.com/openharmony/powermgr_thermal_manager/blob/master/services/native/profile/thermal_service_config.xml).
Packing path: `/vendor/etc/thermal_config/hdf`
en/device-dev/website.md
浏览文件 @ 5205180c
......@@ -387,7 +387,9 @@
- [Audio/Video Playback Development](subsystems/subsys-multimedia-video-play-guide.md)
- [Audio/Video Recording Development](subsystems/subsys-multimedia-video-record-guide.md)
- [Utils Development](subsystems/subsys-utils-guide.md)
- [AI Framework Development](subsystems/subsys-ai-aiframework-devguide.md)
- AI
- [AI Framework Development](subsys-ai-aiframework-devguide.md)
- [NNRt Development](subsys-ai-nnrt-guide.md)
- Data Management
- RDB
- [RDB Overview](subsystems/subsys-data-relational-database-overview.md)
......@@ -452,7 +454,24 @@
- [HiChecker Development](subsystems/subsys-dfx-hichecker.md)
- [FaultLogger Development](subsystems/subsys-dfx-faultlogger.md)
- [Hiview Development](subsystems/subsys-dfx-hiview.md)
- Power
- Power Consumption Statistics
- [Power Consumption Statistics Customization](subsys-power-stats-power-average-customization.md)
- Battery Management
- [Battery Level and LED Color Mapping Customization](subsys-power-level-LED-color.md)
- [Battery Temperature Protection Customization](subsys-power-temperature-protection.md)
- [Battery Level Customization](subsys-power-battery-level-customization.md)
- [Charging Current and Voltage Limit Customization](subsys-power-charge-current-voltage-limit.md)
- [Charging Type Customization](subsys-power-charge-type-customization.md)
- [Power-off Charging Animation Customization](subsys-power-poweroff-charge-animation.md)
- Thermal Management
- [Charging Idle State Customization](subsys-thermal_charging_idle_state.md)
- [Thermal Control Customization](subsys-thermal_control.md)
- [Thermal Detection Customization](subsys-thermal_detection.md)
- [Thermal Level Customization](subsys-thermal_level.md)
- [Thermal Log Customization](subsys-thermal_log.md)
- [Thermal Policy Customization](subsys-thermal_policy.md)
- [Thermal Scene Customization](subsys-thermal_scene.md)
- Featured Topics
- HPM Part
- [HPM Part Overview](hpm-part/hpm-part-about.md)
......
en/release-notes/changelogs/OpenHarmony_4.0.2.1/changelogs-usb.md
浏览文件 @ 5205180c
USB Manager ChangeLog
# USB Subsystem API Changelog
## cl.usb_manager.1 System API Change
......@@ -13,6 +13,16 @@ If your application is developed based on earlier versions, modify the return va
| ohos.usbV9.d.ts | function setCurrentFunctions(funcs: FunctionType): Promise<boolean>; | function setCurrentFunctions(funcs: FunctionType): Promise<void>; |
| ohos.usbV9.d.ts | function setPortRoles(portId: number, powerRole: PowerRoleType, dataRole: DataRoleType): Promise<boolean>; | function setPortRoles(portId: number, powerRole: PowerRoleType, dataRole: DataRoleType): Promise<void>; |
## cl.usb_manager.2 SDK API Deletion
The **@ohos.usbV9.d.ts** file was deleted in OpenHarmony 4.0.5.5.
You need to import **@ohos.usbManager** to use USB service APIs.
```ts
import usbManager from '@ohos.usbManager';
```
**Adaptation Guide**
For details, see the [reference](../../../application-dev/reference/errorcodes/errorcode-universal.md) for each API.
For details about usage of each API, see the [API Reference](../../../application-dev/reference/apis/js-apis-usbManager.md).
en/release-notes/changelogs/OpenHarmony_4.0.6.1/changelogs-usb.md 0 → 100644
浏览文件 @ 5205180c
# USB Subsystem API Changelog
## cl.usb_manager.1 SDK API Deletion
For applications developed based on earlier versions, you need to change the name of the imported bundle. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
The **@ohos.usbV9.d.ts** file is replaced by the **@ohos.usbManager.d.ts** file.
| New Bundle | Original Bundle | Deleted Bundle |
| -------------------- | ------------- | --------------- |
| ohos.usbManager.d.ts | ohos.usb.d.ts | ohos.usbV9.d.ts |
You need to import **@ohos.usbManager** to use USB service APIs.
```ts
import usbManager from '@ohos.usbManager';
```
**Adaptation Guide**
For details about usage of each API, see the [API Reference](../../../application-dev/reference/apis/js-apis-usbManager.md).
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或