diff --git a/en/device-dev/device-dev-guide.md b/en/device-dev/device-dev-guide.md
index 65f1bdf8e5afcdaa4c8d092f68d87eb6ad406693..f0ececf4cb84370794b75de3a734e745664b7d48 100644
--- a/en/device-dev/device-dev-guide.md
+++ b/en/device-dev/device-dev-guide.md
@@ -34,7 +34,7 @@ In addition, OpenHarmony provides a wide array of system components that can be
| About OpenHarmony| Getting familiar with OpenHarmony | - [About OpenHarmony](https://gitee.com/openharmony)
- [Glossary](../glossary.md)|
| Development resources | Preparing for your development | - [Obtaining Source Code](get-code/sourcecode-acquire.md)
- [Obtaining Tools](get-code/gettools-acquire.md) |
| Getting started | Getting started with setup, build, burning, debugging, and running of OpenHarmony | - [Mini and Small System Overview](quick-start/quickstart-ide-lite-overview.md)|
-| Basic capabilities | Using basic capabilities of OpenHarmony | - [Kernel for Mini System](kernel/kernel-mini-overview.md)
- [Kernel for Small System](kernel/kernel-small-overview.md)
- [HDF](driver/driver-hdf-overview.md)
- [Subsystems](subsystems/subsys-build-mini-lite.md)
- [Security Guidelines](security/security-guidelines-overall.md)
- [Privacy Protection](security/security-privacy-protection.md)|
+| Basic capabilities | Using basic capabilities of OpenHarmony | - [Kernel for Mini System](kernel/kernel-mini-overview.md)
- [Kernel for Small System](kernel/kernel-small-overview.md)
- [HDF](driver/driver-hdf-overview.md)
- [Subsystems](subsystems/subsys-build-all.md)
- [Security Guidelines](security/security-guidelines-overall.md)
- [Privacy Protection](security/security-privacy-protection.md) |
| Advanced development | Developing smart devices based on system capabilities | - [WLAN-connected Products](guide/device-wlan-led-control.md)
- [Cameras Without a Screen](guide/device-iotcamera-control-overview.md)
- [Cameras with a Screen](guide/device-camera-control-overview.md) |
| Porting and adaptation | - Porting and adapting OpenHarmony to an SoC
- Porting and adapting OpenHarmony to a third-party library
- Third-party vendor porting cases
| - [Mini System SoC Porting Guide](porting/porting-minichip.md)
- [Small System SoC Porting Guide](porting/porting-smallchip-prepare-needs.md)
- [Third-Party Library Porting Guide for Mini and Small Systems](porting/porting-thirdparty-overview.md)
- [Mini-System Devices with Screens — Bestechnic SoC Porting Case](porting/porting-bes2600w-on-minisystem-display-demo.md)
- [Combo Solution – ASR Chip Porting Case](porting/porting-asr582x-combo-demo.md)
|
| Contributing components | Contributing components to OpenHarmony | - [HPM Part Overview](hpm-part/hpm-part-about.md)
- [HPM Part Development](hpm-part/hpm-part-development.md)
- [HPM Part Reference](hpm-part/hpm-part-reference.md) |
@@ -48,7 +48,7 @@ In addition, OpenHarmony provides a wide array of system components that can be
| About OpenHarmony| Getting familiar with OpenHarmony| - [About OpenHarmony](https://gitee.com/openharmony)
- [Glossary](../glossary.md)|
| Development resources| Preparing for your development| - [Obtaining Source Code](get-code/sourcecode-acquire.md)
- [Obtaining Tools](get-code/gettools-acquire.md)|
| Getting started| Getting started with setup, build, burning, debugging, and running of OpenHarmony| - [Standard System Overview](quick-start/quickstart-ide-standard-overview.md) |
-| Basic capabilities| Using basic capabilities of OpenHarmony| - [Kernel Development](kernel/kernel-standard.md)
- [HDF](driver/driver-hdf-overview.md)
- [Subsystems](subsystems/subsys-build-standard-large.md)
- [Security Guidelines](security/security-guidelines-overall.md)
- [Privacy Protection](security/security-privacy-protection.md)|
+| Basic capabilities| Using basic capabilities of OpenHarmony| - [Kernel Development](kernel/kernel-standard-overview.md)
- [HDF](driver/driver-hdf-overview.md)
- [Subsystems](subsystems/subsys-build-all.md)
- [Security Guidelines](security/security-guidelines-overall.md)
- [Privacy Protection](security/security-privacy-protection.md) |
| Advanced development| Developing smart devices based on system capabilities| - [Development Guidelines on Clock Apps](guide/device-clock-guide.md)
- [Development Example for Platform Drivers](guide/device-driver-demo.md)
- [Development Example for Peripheral Drivers](guide/device-outerdriver-demo.md) |
| Porting and adaptation| - Porting and adapting OpenHarmony to an SoC
- Rapidly porting the OpenHarmony Linux kernel| - [Standard System Porting Guide](porting/standard-system-porting-guide.md)
- [A Method for Rapidly Porting the OpenHarmony Linux Kernel](porting/porting-linux-kernel.md) |
| Contributing components| Contributing components to OpenHarmony| - [HPM Part Overview](hpm-part/hpm-part-about.md)
- [HPM Part Development](hpm-part/hpm-part-development.md)
- [HPM Part Reference](hpm-part/hpm-part-reference.md) |
diff --git a/en/device-dev/guide/device-driver-demo.md b/en/device-dev/guide/device-driver-demo.md
index ceed4c96f66bb1387814c350dd7e75873d58f61c..69d160ee94d4c8bb258ea12df6fd0262f95c0420 100644
--- a/en/device-dev/guide/device-driver-demo.md
+++ b/en/device-dev/guide/device-driver-demo.md
@@ -430,6 +430,8 @@ Initialize the controller hardware, call core-layer APIs to add or delete device
2. Build source code and burn images to the development board.
- For details, see the related sections in [Getting Started for Standard System](../quick-start/quickstart-standard.md).
+ - For details about the operations using the installation package, see [Building](../quick-start/quickstart-ide-standard-running-hi3516-build.md) and [Burning](../quick-start/quickstart-ide-standard-running-hi3516-burning.md).
+
+ - For details about the operations in IDE mode, see [Building](../quick-start/quickstart-standard-running-hi3516-build.md) and [Burning](../quick-start/quickstart-standard-running-hi3516-burning.md).
diff --git a/en/device-dev/guide/device-outerdriver-demo.md b/en/device-dev/guide/device-outerdriver-demo.md
index b2238b6af22a247927421bec914b118dcbfe18e9..fae7c72d1f7772dc911d59626df099ea4ea1fb22 100644
--- a/en/device-dev/guide/device-outerdriver-demo.md
+++ b/en/device-dev/guide/device-outerdriver-demo.md
@@ -315,7 +315,7 @@ The input driver model consists of three parts of drivers. To develop a brand-ne
**touch\_gt911.o** is the content added in this example.
-2. Build source code and burn images. For details, see the related sections in [Getting Started for Standard System](../quick-start/quickstart-standard.md).
+2. Build source code and burn images. For details, see the related sections in [Standard System Overview](../quick-start/quickstart-standard-overview.md).
## Debugging and Verification
diff --git a/en/device-dev/kernel/kernel-small-start-user.md b/en/device-dev/kernel/kernel-small-start-user.md
index fb34ba4194831b84c2683fd4ab11e2ee2cc2098c..64f0cf6dece3286be85e94b463c4b9549f534f94 100644
--- a/en/device-dev/kernel/kernel-small-start-user.md
+++ b/en/device-dev/kernel/kernel-small-start-user.md
@@ -32,8 +32,9 @@ During system startup, **OsUserInitProcess** is called to start the **init**
- Starts key system programs or services, such as shell.
- >![](../public_sys-resources/icon-note.gif) **NOTE:**
- >In OpenHarmony, the **init** process reads the **/etc/init.cfg** file and runs specified commands or starts specified processes based on configurations. For details, see [init Module](../subsystems/subsys-boot-init.md).
+ >![](../public_sys-resources/icon-note.gif) **NOTE**
+ >
+ >In OpenHarmony, the **init** process reads the **/etc/init.cfg** file and runs specified commands or starts specified processes based on configurations. For details, see [init Module](../subsystems/subsys-boot-init-cfg.md).
- Monitors the process for reclaiming the orphan process and clears the zombie processes in child processes.
diff --git a/en/device-dev/subsystems/subsys-boot-faqs.md b/en/device-dev/subsystems/subsys-boot-faqs.md
index e0b72945a026eaf5dd487f76351cbcec85b38b5e..f4e3eb59371a2cf083f9169c2ae42795eaa0f808 100644
--- a/en/device-dev/subsystems/subsys-boot-faqs.md
+++ b/en/device-dev/subsystems/subsys-boot-faqs.md
@@ -1,6 +1,6 @@
-# FAQs
+# FAQs
-## System startup interrupted due to "parse failed!" error
+## System startup interrupted due to "parse failed!" error
**Problem**
@@ -17,7 +17,7 @@ During the modification of the **init.cfg** file, required commas \(,\) or par
Check the **init.cfg** file and ensure that its format meets the JSON specifications.
-## System automatically restarted again and again
+## System automatically restarted again and again
**Problem**
@@ -25,7 +25,7 @@ After the image burning is complete, the system keeps restarting.
**Cause**
-Each service started by the init process has the **importance** attribute, as described in Table 3 in [init Module](subsys-boot-init.md).
+Each service started by the init process has the **importance** attribute, as described in Table 3 in [Job Management](../subsystems/subsys-boot-init-jobs.md).
- If the attribute value is **0**, the init process does not need to restart the development board when the current service process exits.
- If the attribute value is **1**, the init process needs to restart the development board when the current service process exits.
@@ -37,7 +37,7 @@ During the startup of a service whose **importance** is **1**, if the service
1. View logs to identify the service that encounters a process crash or exits due to an error, rectify the issue, and then burn the image again.
2. Alternatively, change the value of **importance** to **0** for the service that exits due to a process crash or an error, and then burn the image again. In this way, the development board will not be restarted even if the service exits.
-## Failed to call the **SetParameter** or **GetParameter** API with correct parameter values
+## Failed to call the **SetParameter** or **GetParameter** API with correct parameter values
**Problem**
diff --git a/en/device-dev/subsystems/subsys-boot-overview.md b/en/device-dev/subsystems/subsys-boot-overview.md
index c1adc013182349d0a93621bd84db02445cd5a40a..11cdf0f3a91eb965293dd8884a61dff2b9ec8d52 100644
--- a/en/device-dev/subsystems/subsys-boot-overview.md
+++ b/en/device-dev/subsystems/subsys-boot-overview.md
@@ -23,7 +23,7 @@ When the system is powered on, the kernel loads and starts services and applicat
The Startup subsystem consists of the following modules:
- init module
- This module corresponds to the init process, which is the first user-mode process started after the kernel is initialized. After the init process starts, it reads and parses the **init.cfg** file. Based on the parsing result, the init module executes the commands listed in [Table 2](../subsystems/subsys-boot-init.md) and starts the key system service processes in sequence with corresponding permissions granted.
+ This module corresponds to the init process, which is the first user-mode process started after the kernel is initialized. After the init process starts, it reads and parses the **init.cfg** file. Based on the parsing result, the init module executes the commands listed in Table 2 in [Job Management](../subsystems/subsys-boot-init-jobs.md) and starts the key system service processes in sequence with corresponding permissions granted.
- ueventd module
This module listens for **netlink** events about hot swap of kernel device drivers and dynamically manages the **dev** node of the corresponding device based on the event type.
diff --git a/en/device-dev/subsystems/subsys-testguide-test.md b/en/device-dev/subsystems/subsys-testguide-test.md
index bc145cf411b90da15ce9b9ac3f2f20a7ee9aad05..031361ae8970c62ef4e3063b8f605dff8dd4c2f0 100644
--- a/en/device-dev/subsystems/subsys-testguide-test.md
+++ b/en/device-dev/subsystems/subsys-testguide-test.md
@@ -4,7 +4,6 @@ OpenHarmony provides a comprehensive auto-test framework for designing test case
This document describes how to use the OpenHarmony test framework.
## Setting Up the Environment
The test framework depends on the Python running environment. Before using the test framework, set up the environment as follows:
- - [Setting Up the Environment](subsys-testguide-envbuild.md)
- [Obtaining Source Code](../get-code/sourcecode-acquire.md)
@@ -419,21 +418,22 @@ The following provides templates for different languages for your reference.
1. Add comment information for the file header.
- ```
+ ```
# Copyright (c) 2021 XXXX Device Co., Ltd.
```
2. Import the build template.
- ```
+ ```
import("//build/test.gni")
```
3. Specify the file output path.
-
- ```
+
+ ```
module_output_path = "subsystem_examples/calculator"
```
+
> **NOTE**
> The output path is ***Part name*/*Module name***.
@@ -470,15 +470,15 @@ The following provides templates for different languages for your reference.
}
```
- > **NOTE**
- > Set the test type based on actual requirements. The following test types are available:
- > - **ohos_unittest**: unit test
- > - **ohos_moduletest**: module test
- > - **ohos_systemtest**: system test
- > - **ohos_performancetest**: performance test
- > - **ohos_securitytest**: security test
- > - **ohos_reliabilitytest**: reliability test
- > - **ohos_distributedtest**: distributed test
+ > **NOTE**
+ > Set the test type based on actual requirements. The following test types are available:
+ > - **ohos_unittest**: unit test
+ > - **ohos_moduletest**: module test
+ > - **ohos_systemtest**: system test
+ > - **ohos_performancetest**: performance test
+ > - **ohos_securitytest**: security test
+ > - **ohos_reliabilitytest**: reliability test
+ > - **ohos_distributedtest**: distributed test
7. Group the test case files by test type.
@@ -490,7 +490,7 @@ The following provides templates for different languages for your reference.
```
> **NOTE**
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
-
+
- **Test case build file example (JavaScript)**
```
@@ -530,6 +530,7 @@ The following provides templates for different languages for your reference.
```
module_output_path = "subsystem_examples/app_info"
```
+
> **NOTE**
> The output path is ***Part name*/*Module name***.
@@ -539,9 +540,10 @@ The following provides templates for different languages for your reference.
ohos_js_unittest("GetAppInfoJsTest") {
}
```
- > **NOTE**
- >- Use the **ohos\_js\_unittest** template to define the JavaScript test suite. Pay attention to the difference between JavaScript and C++.
- >- The file generated for the JavaScript test suite must be in .hap format and named after the test suite name defined here. The test suite name must end with **JsTest**.
+
+ > **NOTE**
+ > - Use the **ohos\_js\_unittest** template to define the JavaScript test suite. Pay attention to the difference between JavaScript and C++.
+ > - The file generated for the JavaScript test suite must be in .hap format and named after the test suite name defined here. The test suite name must end with **JsTest**.
5. Configure the **config.json** file and signature file, which are mandatory.
@@ -623,6 +625,7 @@ The following provides templates for different languages for your reference.
deps = [ ":GetAppInfoJsTest" ]
}
```
+
> **NOTE**
> Grouping test cases by test type allows you to execute a specific type of test cases when required.
@@ -673,7 +676,7 @@ Perform the following steps:
resource_config_file = "//system/subsystem/partA/test/resource/calculator/ohos_test.xml"
}
```
- >**NOTE**
+ >**NOTE**
>- **target_name** indicates the test suite name defined in the **BUILD.gn** file in the **test** directory.**preparer** indicates the action to perform before the test suite is executed.
>- **src="res"** indicates that the test resources are in the **resource** directory under the **test** directory. **src="out"** indicates that the test resources are in the **out/release/$(*part*)** directory.
@@ -748,7 +751,7 @@ After the build is complete, the test cases are automatically saved in **out/his
2. Copy **developertest** and **xdevice** from the Linux environment to the **Test** directory on Windows, and copy the test cases to the **testcase** directory.
> **NOTE**
- > Port the test framework and test cases from the Linux environment to the Windows environment for subsequent execution.
+ > Port the test framework and test cases from the Linux environment to the Windows environment for subsequent execution.
3. Modify the **user_config.xml** file.
```
@@ -761,9 +764,10 @@ After the build is complete, the test cases are automatically saved in **out/his