diff --git a/en/application-dev/reference/apis/js-apis-pointer.md b/en/application-dev/reference/apis/js-apis-pointer.md
index 49ed81e115de6345453c93441b68cda2a132021b..61bac1ec1ef7b02115705e7e5e34b600faedca60 100644
--- a/en/application-dev/reference/apis/js-apis-pointer.md
+++ b/en/application-dev/reference/apis/js-apis-pointer.md
@@ -258,6 +258,386 @@ try {
}
```
+## pointer.setHoverScrollState10+
+
+setHoverScrollState(state: boolean, callback: AsyncCallback<void>): void
+
+Sets the status of the mouse hover scroll switch. This API uses an asynchronous callback to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| -------- | ------------------------- | ---- | ------------------------------------- |
+| state | boolean | Yes | Status of the mouse hover scroll switch. |
+| callback | AsyncCallback<void> | Yes | Callback used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.setHoverScrollState(true, (error) => {
+ if (error) {
+ console.log(`Set the mouse hover scroll failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+ return;
+ }
+ console.log(`Set the mouse hover scroll success`);
+ });
+} catch (error) {
+ console.log(`Set the mouse hover scroll failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.setHoverScrollState10+
+
+setHoverScrollState(state: boolean): Promise<void>
+
+Sets the status of the mouse hover scroll switch. This API uses a promise to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| ----- | ------ | ---- | ----------------------------------- |
+| state | boolean | Yes | Status of the mouse hover scroll switch.|
+
+**Return value**
+
+| Name | Description |
+| ------------------- | ---------------- |
+| Promise<void> | Promise used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.setHoverScrollState(true).then(() => {
+ console.log(`Set the mouse hover scroll success`);
+ });
+} catch (error) {
+ console.log(`Set the mouse hover scroll failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.getHoverScrollState10+
+
+getHoverScrollState(callback: AsyncCallback<boolean>): void
+
+Obtains the status of the mouse hover scroll switch. This API uses an asynchronous callback to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| -------- | --------------------------- | ---- | -------------- |
+| callback | AsyncCallback<boolean> | Yes | Callback used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.getHoverScrollState((error, state) => {
+ console.log(`Get the mouse hover scroll success, state: ${JSON.stringify(state)}`);
+ });
+} catch (error) {
+ console.log(`Get the mouse hover scroll failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.getHoverScrollState10+
+
+getHoverScrollState(): Promise<boolean>
+
+Obtains the status of the mouse hover scroll switch. This API uses a promise to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Return value**
+
+| Name | Description |
+| --------------------- | ------------------- |
+| Promise<boolean> | Promise used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.getHoverScrollState().then((state) => {
+ console.log(`Get the mouse hover scroll success, state: ${JSON.stringify(state)}`);
+ });
+} catch (error) {
+ console.log(`Get the mouse hover scroll failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.setMousePrimaryButton10+
+
+setMousePrimaryButton(primary: PrimaryButton, callback: AsyncCallback<void>): void
+
+Sets the primary button of the mouse. This API uses an asynchronous callback to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| -------- | ------------------------- | ---- | ------------------------------------- |
+| primary | [PrimaryButton](#primarybutton10) | Yes | ID of the primary mouse button. |
+| callback | AsyncCallback<void> | Yes | Callback used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.setMousePrimaryButton(pointer.PrimaryButton.RIGHT, (error) => {
+ if (error) {
+ console.log(`Set mouse primary button failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+ return;
+ }
+ console.log(`Set mouse primary button success`);
+ });
+} catch (error) {
+ console.log(`Set mouse primary button failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.setMousePrimaryButton10+
+
+setMousePrimaryButton(primary: PrimaryButton): Promise<void>
+
+Sets the primary button of the mouse. This API uses a promise to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| ----- | ------ | ---- | ----------------------------------- |
+| primary | [PrimaryButton](#primarybutton10) | Yes | ID of the primary mouse button.|
+
+**Return value**
+
+| Name | Description |
+| ------------------- | ---------------- |
+| Promise<void> | Promise used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.setMousePrimaryButton(pointer.PrimaryButton.RIGHT).then(() => {
+ console.log(`Set mouse primary button success`);
+ });
+} catch (error) {
+ console.log(`Set mouse primary button failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.getMousePrimaryButton10+
+
+getMousePrimaryButton(callback: AsyncCallback<PrimaryButton>): void
+
+Obtains the primary button of the mouse. This API uses an asynchronous callback to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| -------- | --------------------------- | ---- | -------------- |
+| callback | AsyncCallback<[PrimaryButton](#primarybutton10)> | Yes | Callback used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.getMousePrimaryButton((error, primary) => {
+ console.log(`Get mouse primary button success, primary: ${JSON.stringify(primary)}`);
+ });
+} catch (error) {
+ console.log(`Get mouse primary button failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.getMousePrimaryButton10+
+
+getMousePrimaryButton(): Promise<PrimaryButton>
+
+Obtains the primary button of the mouse. This API uses a promise to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Return value**
+
+| Name | Description |
+| --------------------- | ------------------- |
+| Promise<[PrimaryButton](#primarybutton10)> | Promise used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.getMousePrimaryButton().then((primary) => {
+ console.log(`Get mouse primary button success, primary: ${JSON.stringify(primary)}`);
+ });
+} catch (error) {
+ console.log(`Get mouse primary button failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## PrimaryButton10+
+
+Type of the primary mouse button.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+| Name | Value | Description |
+| -------------------------------- | ---- | ------ |
+| LEFT | 0 | Left mouse button. |
+| RIGHT | 1 | Right mouse button. |
+
+## pointer.setMouseScrollRows10+
+
+setMouseScrollRows(rows: number, callback: AsyncCallback<void>): void
+
+Sets the number of mouse scroll rows. This API uses an asynchronous callback to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| -------- | ------------------------- | ---- | ------------------------------------- |
+| rows | number | Yes | Number of mouse scroll rows. The value ranges from 1 to 100. The default value is **3**. |
+| callback | AsyncCallback<void> | Yes | Callback used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.setMouseScrollRows(1, (error) => {
+ if (error) {
+ console.log(`setMouseScrollRows failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+ return;
+ }
+ console.log(`setMouseScrollRows success`);
+ });
+} catch (error) {
+ console.log(`setMouseScrollRows failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.setMouseScrollRows10+
+
+setMouseScrollRows(rows: number): Promise<void>
+
+Sets the number of mouse scroll rows. This API uses a promise to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| ----- | ------ | ---- | ----------------------------------- |
+| rows | number | Yes | Number of mouse scroll rows. The value ranges from 1 to 100. The default value is **3**.|
+
+**Return value**
+
+| Name | Description |
+| ------------------- | ---------------- |
+| Promise<void> | Promise used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.setMouseScrollRows(20).then(() => {
+ console.log(`setMouseScrollRows success`);
+ });
+} catch (error) {
+ console.log(`setMouseScrollRows failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.getMouseScrollRows10+
+
+getMouseScrollRows(callback: AsyncCallback<number>): void
+
+Obtains the number of mouse scroll rows. This API uses an asynchronous callback to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Parameters**
+
+| Name | Type | Mandatory | Description |
+| -------- | --------------------------- | ---- | -------------- |
+| callback | AsyncCallback<number> | Yes | Callback used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.getMouseScrollRows((error, rows) => {
+ console.log(`getMouseScrollRows success, rows: ${JSON.stringify(rows)}`);
+ });
+} catch (error) {
+ console.log(`getMouseScrollRows failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
+## pointer.getMouseScrollRows10+
+
+getMouseScrollRows(): Promise<number>
+
+Obtains the mouse movement speed. This API uses a promise to return the result.
+
+**System capability**: SystemCapability.MultimodalInput.Input.Pointer
+
+**System API**: This is a system API.
+
+**Return value**
+
+| Name | Description |
+| --------------------- | ------------------- |
+| Promise<number> | Promise used to return the result.|
+
+**Example**
+
+```js
+try {
+ pointer.getMouseScrollRows().then((rows) => {
+ console.log(`getMouseScrollRows success, rows: ${JSON.stringify(rows)}`);
+ });
+} catch (error) {
+ console.log(`getMouseScrollRows failed, error: ${JSON.stringify(error, [`code`, `message`])}`);
+}
+```
+
## pointer.getPointerStyle9+
getPointerStyle(windowId: number, callback: AsyncCallback<PointerStyle>): void
diff --git a/en/device-dev/subsystems/Readme-EN.md b/en/device-dev/subsystems/Readme-EN.md
index 3ffc19418a1e83b0e87abc59cbfc460dfca1a392..d56854b895f3138843dba4ef56bd2858f82316d2 100644
--- a/en/device-dev/subsystems/Readme-EN.md
+++ b/en/device-dev/subsystems/Readme-EN.md
@@ -126,4 +126,6 @@
- [Thermal Policy Customization](subsys-thermal_policy.md)
- [Thermal Scene Customization](subsys-thermal_scene.md)
- Power Management
- - [Power Mode Customization](subsys-power-mode-customization.md)
\ No newline at end of file
+ - [Power Mode Customization](subsys-power-mode-customization.md)
+ - [Default Hibernation Behavior Customization](subsys-power-default-sleep-behavior-customization.md)
+ - [Wakeup Source Customization](subsys-power-wakeup-source-customization.md)
\ No newline at end of file
diff --git a/en/device-dev/subsystems/subsys-boot-init-sysparam.md b/en/device-dev/subsystems/subsys-boot-init-sysparam.md
index 1b5541a741273c7db7551bc6441bbfb44d1532a6..0dfc391b06ed14caf4bc5d0e17ce8a4654af723e 100644
--- a/en/device-dev/subsystems/subsys-boot-init-sysparam.md
+++ b/en/device-dev/subsystems/subsys-boot-init-sysparam.md
@@ -1,30 +1,39 @@
# Parameter Management
+
## Overview
+
### Function
-The parameter management module, namely, sysparam, provides an easy-to-use key-value pair access interface for system services to configure service functions based on their own system parameters.
+The parameter management subsystem, namely, sysparam, provides easy-to-use key-value pair access interfaces for system services to customize functions based on their own system parameters.
### Basic Concepts
-Figure 1 System parameter operation primitives
+#### Operation Primitives
+
+Figure 1 shows the primitives used to operate system parameters. For details about how they work, see Table 1.
+
+Figure 1 Overview of system parameter operation primitives

**Table 1** Description of system parameter operation primitives
-| Operation Primitive| Description|
+
+| Operation Primitive | Description |
| -------- | -------- |
| get | Obtains the value of a system parameter. |
| set | Sets the value of a system parameter. |
| wait | Waits for value change of a system parameter synchronously.|
| watch | Observes value change of a system parameter asynchronously.|
-#### System Parameter Definition
+#### Parameter Definition
- Naming format
- A system parameter name consists of multiple segments in dotted notation. Each segment can be a string that consists of letters, digits, and underscores (_). The total length cannot exceed 96 bytes. System parameter names are categorized into the following two types.
+ A system parameter name consists of multiple segments in dotted notation. Each segment can be a string that consists of letters, digits, and underscores (_). The total length cannot exceed 96 bytes.
+
+ Two naming formats are supported for system parameters, as described in Table 2.
- **Table 2** System parameter names
+ **Table 2** Description of system parameter naming formats
| Type | Example | Description |
| -------- | -------- | -------- |
@@ -33,31 +42,33 @@ Figure 1 System parameter operation primitives
- Type
- System parameters are categorized into three types.
+ System parameters are categorized into three types, as described in Table 3.
- **Table 3** System parameter types
+ **Table 3** Description of system parameter types
| Type| Prefix| Description|
| -------- | -------- | -------- |
- | Constant| const. | Constant parameter, which will not be changed once a value is assigned. The value can contain a maximum of 4,096 bytes (including the terminator).|
- | Writable| Others| Writable parameter, which will be lost after system restart. The value can contain a maximum of 96 bytes (including the terminator).|
- | Persistent| persist. | Writable and persistent parameter, which will not be lost after system restart. The value can contain a maximum of 96 bytes (including the terminator).|
+ | Constant| const. | Constant parameter, which will not change once a value is assigned. The value can contain a maximum of 4,096 bytes (including the end-of-text character).|
+ | Writable| Others| Writable parameter, which will be discarded after a system restart. The value can contain a maximum of 96 bytes (including the end-of-text character).|
+ | Persistent| persist. | Writable and persistent parameter, which will not be discarded after a system restart. The value can contain a maximum of 96 bytes (including the end-of-text character).|
- The general naming format is as follows:
+ Given below is the general naming format for system parameters:
```
[ const | persist ].$sub_system.$desc
```
- **$sub_system** is the name of the subsystem or module.
+ wherein,
+
+ - **$sub_system** is the subsystem or module name.
- **$desc** indicates the description of a system parameter. The description can contain multiple segments in dotted notation.
+ - **$desc** is the parameter description, which can contain multiple segments in dotted notation.
-#### Definition Rules
+#### Parameter Definition Rule
-Each subsystem defines the system parameters of its own modules, including the system parameter name, default value, and access permission information.
+System parameters are defined per module on each subsystem. The parameter definition includes the system parameter name, default value, and access permission information.
-- System parameter value definition file
+- Value definition file
- - The system parameter value definition file ends with the **.para** extension. An example of the file format is as follows:
+ - A value definition file of system parameters ends with the **.para** extension. The following is an example format of file content:
```shell
# This is comment
@@ -66,43 +77,49 @@ Each subsystem defines the system parameters of its own modules, including the s
const.telephony.enable=false|true
const.test.withblank=My Value
- const.test.withcomment=MyValue # This should be ommitted
+ const.test.withcomment=MyValue # This should be omitted
const.test.multiline="This is a multiline parameter.
Line2 value.
Last line."
```
- - You must use a complete system parameter command when assigning a value for a system parameter. The following table describes the value assignment modes.
+ - A complete system parameter command is required to assign a value for a system parameter. See Table 4 for the value assignment modes.
- **Table 4** Value assignment modes
+ **Table 4** Description of value assignment modes
| Type| Example| Description|
| -------- | -------- | -------- |
- | String | const.product.name=OHOS-PRODUCT | A multi-line string must be enclosed in double quotation marks ("").|
- | Number | const.os.version.api=26 | Numbers do not need to be enclosed in quotation marks.|
+ | String | const.product.name=OHOS-PRODUCT | A string that spans multiple lines must be enclosed in double quotation marks ("").|
+ | Number | const.os.version.api=26 | A number that spans multiple lines does not need to be enclosed in double quotation marks ("").|
| Boolean | const.telephony.enable=false | A Boolean value can be **0**, **1**, **false**, or **true**.|
- DAC definition file
- Currently, access permissions of system parameters are managed in Discretionary Access Control (DAC) mode. The access permission definition file ends with the **.para.dac** extension. The following is an example:
+ Access permissions of system parameters are managed in discretionary access control (DAC) mode. A DAC definition file ends with the **.para.dac** extension. The following is an example format of DAC information:
```java
const.product.="root:root:660"
```
- As shown above, we can use **parameter directory** to define the same access permission for system parameters with the same prefix. The DAC information is divided into three segments, user, group, and UGO rule, which are separated using a semicolon (:).
+ As shown in this example, a **parameter directory** can be used to define the same access permission for system parameters with the same prefix. A piece of DAC information is divided into three segments, user, group, and Ugo rule, which are separated using a semicolon (:).
+
+ > **NOTE**
+ >
+ > Ugo is the abbreviation for user access, group access, ad other system user's access, respectively. These permissions are set to allow or deny access to members of their own group, or any other groups.
+
+ Figure 2 shows the Ugo rule structure.
- The following figure shows the structure of the UGO rule.
+ **Figure 2** Overview of the Ugo rule structure
- **Figure 2** UGO rule structure
+ 
- 
+- SELinux policy
-- SELinux policy for system parameter configuration
+ An SELinux policy defines the access permissions for all users, programs, processes, and files.
- - Add SELinux tags.
+ - Adding an SELinux tag
- To add a SELinux tag to system parameters, you first need to define the tag in the **/base/security/selinux/sepolicy/base/public/parameter.te** file. For example:
+ To add an SELinux tag to system parameters, you first need to define the tag in the **/base/security/selinux/sepolicy/base/public/parameter.te** file. For example:
```java
type servicectrl_param, parameter_attr
@@ -114,62 +131,71 @@ Each subsystem defines the system parameters of its own modules, including the s
ohos.servicectrl. u:object_r:servicectrl_param:s0
```
- - Grant operation permissions. For example, to grant operation permissions such as map for the init process, add the following content to the **/base/security/selinux/sepolicy/ohos_policy/startup/init/public/init.te** file:
+ - Granting access permissions for a process
+
+ For example, to grant access permissions such as map for the init process, add the following code to the **/base/security/selinux/sepolicy/ohos_policy/startup/init/public/init.te** file:
```java
allow servicectrl_param tmpfs:filesystem associate;
allow init servicectrl_param:file { map open read relabelto relabelfrom };
```
- - Set the write permission. For example, grant the system parameter write permission for services such as **init**, **samgr**, and **hdf_devmgr**.
+ - Granting the write permission
+
+ For example, to grant the write permission for services such as **init**, **samgr**, and **hdf_devmgr**, use the following code:
```java
allow { init samgr hdf_devmgr } servicectrl_param:parameter_service { set };
```
- - Set the read permission. If you want to grant the permission only for certain services, replace **xxx** with the services in the following code:
+ - Granting the read permission
+
+ If you want to grant the read permission only for certain services, replace **xxx** with these services in the following code:
```java
allow { xxx } servicectrl_param:file { map open read };
```
- - If you want to grant the permission for all services, use the following code:
+ - Granting access permissions for all services
+
+ If you want to grant access permissions for all services, use the following code:
```java
allow { domain -limit_domain } servicectrl_param:file { map open read };
```
-- Suggestions
+- System parameter tag
- Keep only two system parameter tags for each subsystem:
+ You are advised to keep only two system parameter tags for each subsystem:
- A private tag to control system parameter settings.
- - A public tag to grant access from all services.
+ - A public tag to grant access permissions from all services.
- Loading sequence
- The following table provides the sequence of loading system parameters.
+ System parameters are loaded by priority in the specified sequence, as described in Table 5.
+
+ **Table 5** Description of the system parameter loading sequence
- **Table 5** System parameter loading sequence
| Type| Path| Description|
| -------- | -------- | -------- |
| Kernel parameters | /proc/cmdline | Convert some values of kernel parameters into system parameters. Specifically, convert all **ohospara.xxx=valXXX** parameters to **ohos.boot.xxx=valXXX** parameters.|
| OS system parameters| /system/etc/param/ohos_const/*.para | Load the definition file containing OS constants preferentially. |
| Vendor parameters| /vendor/etc/param/*.para | Load the system parameters defined by vendors with the secondary priority. |
- | System parameters| /system/etc/param/*.para | Load the parameters defined by each subsystem. If a system parameter already exists, ignore it.|
- | Persistent parameters| /data/parameters/ | If persistent parameters exist, load them at last. Persistent parameters will overwrite the default system parameters that have been loaded.|
+ | System parameters| /system/etc/param/*.para | Load the system parameters defined by each subsystem. A system parameter will be ignored if it already exists.|
+ | Persistent parameters| /data/parameters/ | Load persistent parameters, if any, at last. Persistent parameters will overwrite the default system parameters that have been loaded.|
-#### System Parameter Tag File Size
+#### Tag File Size
-If one tag corresponds to more than five system parameters, you need to set the size of the system parameter tag file in **/base/startup/init/services/etc/param/ohos.para.size**. The size value is **512** by default.
+If one tag is associated with more than five system parameters, you need to set the size of the system parameter tag file in **/base/startup/init/services/etc/param/ohos.para.size**. The default value is **512**.
-Configuring rule:
+The configuration rule is as follows:
System parameter tag = Size
-Example:
+For example:
```java
startup_init_param=40960
@@ -178,18 +204,21 @@ startup_init_param=40960
### Constraints
-The service management module is available only for the mini system and standard system.
+The parameter management subsystem is available only for the mini system and standard system.
## How to Develop
-### Use Cases
+### Application Scenario
+
You can set specific system parameters as needed to meet your service demand.
-### Available APIs
+### Implementation Method
- - Shell commands
+The parameter management subsystem allows you to manage system parameters by running shell commands or calling **syspara** APIs.
- You can operate system parameters directly by using shell commands. This operation mode is available only for the standard system. The following table lists the shell commands.
+ - Shell command mode
+
+ You can operate system parameters directly by running shell commands. This operation mode is available only for the standard system. Table 6 is a list of the shell commands.
**Table 6** Description of shell commands
@@ -200,51 +229,52 @@ You can set specific system parameters as needed to meet your service demand.
| param wait **key** **value** | Waits for the system parameter value of the specified key to match the specified value. Fuzzy match is supported. For example, * indicates any value, and val* indicates matching of only the first three val characters.|
| param watch | Observes value change of a system parameter asynchronously.|
- - syspara APIs
+ - syspara API mode
- The following table lists the APIs used to obtain system parameter values. The return result is a const string and the free operation is not supported.
+ Besides shell commands, you can use **syspara** APIs to manage system parameters. The return result is a constant string and the **free** operation is not supported. Table 7 is a list of the **syspara** APIs.
**Table 7** Description of syspara APIs
+
| API| Description|
| -------- | -------- |
| int GetParameter(const char\* key, const char\* def, char\* value, unsigned int len) | Obtains system parameters.|
| int SetParameter(const char\* key, const char\* value) | Sets or updates system parameters.|
| const char\* GetDeviceType(void) | Obtains the device type.|
- | const char\* GetManufacture(void) | Obtains the device manufacturer.|
- | const char\* GetBrand(void) | Obtains the device brand.|
- | const char\* GetMarketName(void) | Obtains the device marketing name.|
- | const char\* GetProductSeries(void) | Obtains the device series name.|
- | const char\* GetProductModel(void) | Obtains the device authentication model.|
- | const char\* GetSoftwareModel(void) | Obtains the device software model.|
- | const char\* GetHardwareModel(void) | Obtains the device hardware model.|
- | const char\* GetHardwareProfile(void) | Obtains the device hardware profile.|
- | const char\* GetSerial(void) | Obtains the device serial number (SN).|
- | const char\* GetOSFullName(void) | Obtains the operating system name.|
- | const char\* GetDisplayVersion(void) | Obtains the software version visible to users.|
- | const char\* GetBootloaderVersion(void) | Obtains the bootloader version of this device.|
- | const char\* GetSecurityPatchTag(void) | Obtains the security patch tag.|
- | const char\* GetAbiList(void) | Obtains the list of application binary interfaces (ABIs) supported on this device.|
- | int GetSdkApiVersion(void) | Obtains the SDK API level that matches the current system software.|
- | int GetFirstApiVersion(void) | Obtains the first SDK API level of the system software.|
- | const char\* GetIncrementalVersion(void) | Obtains the incremental version.|
+ | const char\* GetManufacture(void) | Obtains the device's manufacturer name.|
+ | const char\* GetBrand(void) | Obtains the device's brand name.|
+ | const char\* GetMarketName(void) | Obtains the device's marketing name.|
+ | const char\* GetProductSeries(void) | Obtains the device's product series name.|
+ | const char\* GetProductModel(void) | Obtains the device's authentication model.|
+ | const char\* GetSoftwareModel(void) | Obtains the device's software model.|
+ | const char\* GetHardwareModel(void) | Obtains the device's hardware model.|
+ | const char\* GetHardwareProfile(void) | Obtains the device's hardware profile.|
+ | const char\* GetSerial(void) | Obtains the device's serial number (SN).|
+ | const char\* GetOSFullName(void) | Obtains the device's OS name.|
+ | const char\* GetDisplayVersion(void) | Obtains the device's displayed software version.|
+ | const char\* GetBootloaderVersion(void) | Obtains the device's bootloader version.|
+ | const char\* GetSecurityPatchTag(void) | Obtains the device's security patch tag.|
+ | const char\* GetAbiList(void) | Obtains the list of supported application binary interfaces (ABIs).|
+ | int GetSdkApiVersion(void) | Obtains the SDK API version that matches the current system software.|
+ | int GetFirstApiVersion(void) | Obtains the first SDK API version of the system software.|
+ | const char\* GetIncrementalVersion(void) | Obtains the incremental version of the system software.|
| const char\* GetVersionId(void) | Obtains the version ID.|
| const char\* GetBuildType(void) | Obtains the build type.|
- | const char\* GetBuildUser(void) | Obtains the build account user name.|
- | const char\* GetBuildHost(void) | Obtains the build host name.|
+ | const char\* GetBuildUser(void) | Obtains the build user.|
+ | const char\* GetBuildHost(void) | Obtains the build host.|
| const char\* GetBuildTime(void) | Obtains the build time.|
- | const char\* GetBuildRootHash(void) | Obtains the buildroot hash value of this version.|
+ | const char\* GetBuildRootHash(void) | Obtains the buildroot hash value of the current version.|
| const char\* GetOsReleaseType(void) | Obtains the system release type.|
- | int GetDevUdid(char \*udid, int size) | Obtains the device identifier (UDID).|
- | const char *AclGetSerial(void); | Obtains the device SN (with ACL check).|
- | int AclGetDevUdid(char *udid, int size); | Obtains the UDID (with ACL check).|
+ | int GetDevUdid(char \*udid, int size) | Obtains the device's unique device ID (UDID).|
+ | const char *AclGetSerial(void); | Obtains the device's SN with ACL check.|
+ | int AclGetDevUdid(char *udid, int size); | Obtains the device's UDID with ACL check.|
-### How to Develop
+### Development Procedure
-1. System parameter definition
+#### Parameter Definition
- You can define default system parameters and implement permission control on them by configuring the subsystem or product .para and .para.dac files.
+You can define default system parameters and implement permission control on them by configuring the .para and .para.dac files of the respective subsystem or product.
- On a standard system, use the ohos_prebuilt_para template to install the configuration file to the /etc/param/ directory. The following is an example of the GN script:
+- On a standard system, use the ohos_prebuilt_para template to install the configuration file to the /etc/param/ directory. The following is an example of the GN script:
```go
import("//base/startup/init/services/etc/param/param_fixer.gni")
@@ -262,7 +292,7 @@ You can set specific system parameters as needed to meet your service demand.
}
```
- On a small system, run the copy command to copy the corresponding system parameter definition file to the system/etc/param directory.
+- On a small system, run the copy command to copy the corresponding system parameter definition file to the system/etc/param directory.
```go
copy("ohos.para") {
sources = [ "//base/startup/init/services/etc/param/ohos.para" ]
@@ -273,7 +303,7 @@ You can set specific system parameters as needed to meet your service demand.
outputs = [ "$root_out_dir/system/etc/param/ohos.para.dac" ]
}
```
- On a mini system, convert all defined default system parameters into header files through **action** and compile them into the system.
+- On a mini system, convert all defined default system parameters into header files through **action** and compile them into the system.
```go
action("lite_const_param_to") {
script = "//base/startup/init/scripts/param_cfg_to_code.py"
@@ -289,7 +319,7 @@ You can set specific system parameters as needed to meet your service demand.
outputs = [ "$target_gen_dir/${target_name}_param_cfg_to_code.log" ]
}
```
-2. Development example
+#### Development Example
```
// set && get
char key1[] = "rw.sys.version";
diff --git a/en/device-dev/subsystems/subsys-dfx-hisysevent-query.md b/en/device-dev/subsystems/subsys-dfx-hisysevent-query.md
index 2f5cd08ffab5ac1499f9e4a6e324caf1de64f106..76d048f3056769b13338e3a7629d6be00d2513ae 100644
--- a/en/device-dev/subsystems/subsys-dfx-hisysevent-query.md
+++ b/en/device-dev/subsystems/subsys-dfx-hisysevent-query.md
@@ -81,10 +81,6 @@ The **condition** parameter must be in the specified JSON string format. For exa
"and":[
{"param":"type_","op":">","value":0},
{"param":"uid_","op":"=","value":1201}
- ],
- "or":[
- {"param":"NAME","op":"=","value":"SysEventService"},
- {"param":"NAME","op":"=","value":"SysEventSource"}
]
}
}
@@ -93,7 +89,6 @@ The **condition** parameter must be in the specified JSON string format. For exa
- The **version** field is mandatory, indicating the supported version of the input condition. Currently, only **V1** is supported.
- The **condition** field is mandatory, indicating the input condition.
- The **and** field is optional, indicating the AND relationship between conditions.
- - The **or** field is optional, indicating the OR relationship between conditions.
- The **param** field is mandatory, indicating the parameter name for condition matching. The value must be a string.
- The **op** field is mandatory, indicating the parameter comparison operator for condition matching. The value must be a string. Supported comparison operators include the following: =, >, <, >=, and <=.
- The **value** field is mandatory, indicating the parameter value for condition matching. The value must be a string or an integer.
diff --git a/en/device-dev/subsystems/subsys-power-default-sleep-behavior-customization.md b/en/device-dev/subsystems/subsys-power-default-sleep-behavior-customization.md
new file mode 100644
index 0000000000000000000000000000000000000000..032395511926c8466dd714b79687d08bb3222085
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-power-default-sleep-behavior-customization.md
@@ -0,0 +1,161 @@
+# Default Hibernation Behavior Customization
+
+## Overview
+
+### Introduction
+
+By default, after a device screen is turned off, OpenHarmony starts the running lock loop detection thread and then enters the hibernation state. For different devices, the mode of turning off the screen is different, which can be closing the lid, setting a timeout, or pressing the power button. Besides, the default hibernation behavior is also different, which can be performing no action, powering off the screen, or entering the hibernation state. To address this issue, OpenHarmony provides the default hibernation behavior customization function, allowing you to customize the default hibernation behavior depending on your hardware specifications.
+
+### Constraints
+
+The configuration paths for battery level customization are subject to the configuration policy.
+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 default hibernation behavior customization.
+
+1. Create the `power_manager` 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 hibernation behavior configuration](https://gitee.com/openharmony/powermgr_power_manager/tree/master/services/native/profile), and install it in `/vendor/hihope/rk3568/power_manager`. The content is as follows:
+
+ ```text
+ profile
+ ├── BUILD.gn
+ ├── power_suspend.json
+ ```
+
+3. Write the custom `power_suspend.json` file that contains the custom default hibernation behavior. The following is an example of hibernation behavior configuration:
+
+ ```json
+ {
+ "powerkey": {
+ "action": 1,
+ "delayMs": 0
+ },
+ "timeout": {
+ "action": 1,
+ "delayMs": 0
+ },
+ "lid": {
+ "action": 1,
+ "delayMs": 0
+ },
+ "switch": {
+ "action": 1,
+ "delayMs": 0
+ }
+ }
+ ```
+
+ **Table 1** Description of hibernation sources
+
+ | Hibernation Source| Description|
+ | -------- | -------- |
+ | powerkey | Hibernation by power button|
+ | timeout | Hibernation by timeout|
+ | lid | Hibernation by lid|
+ | switch | Hibernation by switch|
+
+ **Table 2** Description of the hibernation source configuration
+
+ | Item| Description|
+ | -------- | -------- |
+ | action | Action to take after the screen is turned off. Set this parameter to an enumerated value. For details, see Table 3.|
+ | delayMs | Delay, in ms.|
+
+ **Table 3** Description of action
+
+ | action | Value| Description|
+ | -------- | -------- | -------- |
+ | ACTION_NONE | 0 | No action.|
+ | ACTION_AUTO_SUSPEND | 1 | Automatically entering the sleep mode.|
+ | ACTION_FORCE_SUSPEND | 2 | Forcibly entering the sleep mode.|
+ | ACTION_HIBERNATE | 3 | Entering the hibernation state.|
+ | ACTION_SHUTDOWN | 4 | Shutting down the system.|
+
+4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_power_manager/blob/master/services/native/profile/BUILD.gn) file in the default folder of hibernation behavior configuration to pack the `power_suspend.json` file to the `/vendor/etc/power_config` directory. The configuration is as follows:
+
+ ```shell
+ import("//build/ohos.gni") # Reference build/ohos.gni.
+
+ ohos_prebuilt_etc("suspend_config") {
+ source = "power_suspend.json"
+ relative_install_dir = "power_config"
+ 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/power_manager/profile:wakeup_config" // Add the configuration for building of suspend_config.
+ ]
+ }
+ },
+ "subsystem": "product_hihope"
+ }
+ ```
+ In the preceding code, `//vendor/hihope/rk3568/power_manager/` is the folder path, `profile` is the folder name, and `suspend_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. Customize hibernation sources in the `power_suspend.json` file.
+ ```json
+ {
+ "powerkey": {
+ "action": 4,
+ "delayMs": 0
+ },
+ "timeout": {
+ "action": 1,
+ "delayMs": 0
+ },
+ "lid": {
+ "action": 1,
+ "delayMs": 0
+ },
+ "switch": {
+ "action": 1,
+ "delayMs": 0
+ }
+ }
+ ```
+
+2. Power on the device, and then press the power button.
+
+ The device is powered off.
+
+3. Power on the device again, and then wait for a while.
+
+ The device screen is turned off.
diff --git a/en/device-dev/subsystems/subsys-power-stats-power-average-customization.md b/en/device-dev/subsystems/subsys-power-stats-power-average-customization.md
index d7867ed30ad70c2088416d5668441803a4d6ebfb..384b4350f417afc69717d0a4a98102f6ce66d4f5 100644
--- a/en/device-dev/subsystems/subsys-power-stats-power-average-customization.md
+++ b/en/device-dev/subsystems/subsys-power-stats-power-average-customization.md
@@ -4,7 +4,7 @@
### 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.
+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
diff --git a/en/device-dev/subsystems/subsys-power-wakeup-source-customization.md b/en/device-dev/subsystems/subsys-power-wakeup-source-customization.md
new file mode 100644
index 0000000000000000000000000000000000000000..a4d8f57c4792175adefa295470730f3fa19c2d46
--- /dev/null
+++ b/en/device-dev/subsystems/subsys-power-wakeup-source-customization.md
@@ -0,0 +1,178 @@
+# Wakeup Source Customization
+
+## Overview
+
+### Introduction
+
+OpenHarmony supports multiple wakeup sources, such as the power button, keyboard, and mouse, and provides custom modes for turning on and off these wakeup sources. After a device enters the sleep state, you can turn on the screen and wake up the device by pressing the power button, keyboard, or mouse. However, different products may support different peripherals, for example, stylus or folio keyboard. To address this issue, OpenHarmony provides the wakeup source customization function, allowing you to customize wakeup sources depending on your hardware specifications.
+
+### Constraints
+
+The configuration paths for battery level customization are subject to the configuration policy.
+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 wakeup source customization.
+
+1. Create the `power_manager` 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 wakeup source configuration](https://gitee.com/openharmony/powermgr_power_manager/tree/master/services/native/profile), and install it in `/vendor/hihope/rk3568/power_manager`. The content is as follows:
+
+ ```text
+ profile
+ ├── BUILD.gn
+ ├── power_wakeup.json
+ ```
+
+3. Write the custom `power_wakeup.json` file that contains the custom wakeup sources. The following is an example of wakeup source configuration:
+
+ ```json
+ {
+ "powerkey": {
+ "enable": true
+ },
+ "keyborad": {
+ "enable": true
+ },
+ "mouse": {
+ "enable": true
+ },
+ "touchscreen": {
+ "enable": true,
+ "click": 2
+ },
+ "touchpad": {
+ "enable": true
+ },
+ "pen": {
+ "enable": true
+ },
+ "lid": {
+ "enable": true
+ },
+ "switch": {
+ "enable": true
+ }
+ }
+ ```
+
+ **Table 1** Description of wakeup sources
+
+ | Wakeup Source| Description|
+ | -------- | -------- |
+ | powerkey | Wakeup by power button|
+ | keyborad | Wakeup by keyboard|
+ | mouse | Wakeup by mouse|
+ | touchscreen | Wakeup by touchscreen|
+ | touchpad | Wakeup by touchpad|
+ | pen | Wakeup by stylus|
+ | lid | Wakeup by lid|
+ | switch | Wakeup by switch|
+
+ **Table 2** Description of the wakeup source configuration
+
+ | Item| Type| Description|
+ | -------- | -------- | -------- |
+ | enable | bool | Whether to enable wakeup listening|
+ | click | int | Number of clicks|
+
+
+4. Write the `BUILD.gn` file by referring to the [BUILD.gn](https://gitee.com/openharmony/powermgr_power_manager/blob/master/services/native/profile/BUILD.gn) file in the default folder of wakeup source configuration to pack the `power_wakeup.json` file to the `/vendor/etc/power_config` directory. The configuration is as follows:
+
+ ```shell
+ import("//build/ohos.gni") # Reference build/ohos.gni.
+
+ ohos_prebuilt_etc("wakeup_config") {
+ source = "power_wakeup.json"
+ relative_install_dir = "power_config"
+ 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/power_manager/profile:wakeup_config" // Add the configuration for building of wakeup_config.
+ ]
+ }
+ },
+ "subsystem": "product_hihope"
+ }
+ ```
+ In the preceding code, `//vendor/hihope/rk3568/power_manager/` is the folder path, `profile` is the folder name, and `wakeup_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. Customize wakeup sources in the `power_wakeup.json` file.
+ ```json
+ {
+ "powerkey": {
+ "enable": true
+ },
+ "keyborad": {
+ "enable": true
+ },
+ "mouse": {
+ "enable": true
+ },
+ "touchscreen": {
+ "enable": false,
+ "click": 2
+ },
+ "touchpad": {
+ "enable": false
+ },
+ "pen": {
+ "enable": false
+ },
+ "lid": {
+ "enable": false
+ },
+ "switch": {
+ "enable": false
+ }
+ }
+ ```
+
+2. After the device is powered on, press the power button to switch the device to the sleep mode. Then, press the power button again.
+
+ The device screen is turned on and the device is woken up.
+
+3. Press the power button to switch the device to the sleep mode, and then press the keyboard.
+
+ The device screen is turned on and the device is woken up.
+
+4. Press the power button to switch the device to the sleep mode, and then move the mouse.
+
+ The device screen is turned on and the device is woken up.