diff --git a/en/application-dev/connectivity/net-sharing.md b/en/application-dev/connectivity/net-sharing.md
index 09356c3416609c84573a93b23451760eb11f391d..1fb8a1dc42a24702680e285ea221fabbca54be05 100644
--- a/en/application-dev/connectivity/net-sharing.md
+++ b/en/application-dev/connectivity/net-sharing.md
@@ -60,7 +60,7 @@ For the complete list of APIs and example code, see [Network Sharing](../referen
4. Return the callback for successfully starting network sharing.
```js
- // Import the sharing namespace from @ohos.net.sharing.
+// Import the sharing namespace from @ohos.net.sharing.
import sharing from '@ohos.net.sharing'
// Subscribe to network sharing state changes.
@@ -85,7 +85,7 @@ sharing.startSharing(sharing.SharingIfaceType.SHARING_WIFI, (error) => {
4. Return the callback for successfully stopping network sharing.
```js
- // Import the sharing namespace from @ohos.net.sharing.
+// Import the sharing namespace from @ohos.net.sharing.
import sharing from '@ohos.net.sharing'
// Subscribe to network sharing state changes.
@@ -110,7 +110,7 @@ sharing.stopSharing(sharing.SharingIfaceType.SHARING_WIFI, (error) => {
4. Call **stopSharing** to stop network sharing of the specified type and clear the data volume of network sharing.
```js
- // Import the sharing namespace from @ohos.net.sharing.
+// Import the sharing namespace from @ohos.net.sharing.
import sharing from '@ohos.net.sharing'
// Call startSharing to start network sharing of the specified type.
diff --git a/en/application-dev/connectivity/socket-connection.md b/en/application-dev/connectivity/socket-connection.md
index 5ef337f4d91cdc495a303a5fe4a2c40f614c94be..6f656ecccea384730223113ae87f5a1132355575 100644
--- a/en/application-dev/connectivity/socket-connection.md
+++ b/en/application-dev/connectivity/socket-connection.md
@@ -87,81 +87,81 @@ The implementation is similar for UDPSocket and TCPSocket connections. The follo
7. Enable the TCPSocket connection to be automatically closed after use.
- ```js
- import socket from '@ohos.net.socket'
-
- // Create a TCPSocket object.
- let tcp = socket.constructTCPSocketInstance();
-
- // Subscribe to TCPSocket connection events.
- tcp.on('message', value => {
- console.log("on message")
- let buffer = value.message
- let dataView = new DataView(buffer)
- let str = ""
- for (let i = 0;i < dataView.byteLength; ++i) {
- str += String.fromCharCode(dataView.getUint8(i))
- }
- console.log("on connect received:" + str)
- });
- tcp.on('connect', () => {
- console.log("on connect")
- });
- tcp.on('close', () => {
- console.log("on close")
- });
-
- // Bind the local IP address and port number.
- let bindAddress = {
- address: '192.168.xx.xx',
- port: 1234, // Bound port, for example, 1234.
- family: 1
- };
- tcp.bind(bindAddress, err => {
- if (err) {
- console.log('bind fail');
- return;
- }
- console.log('bind success');
-
- // Set up a connection to the specified IP address and port number.
- let connectAddress = {
- address: '192.168.xx.xx',
- port: 5678, // Connection port, for example, 5678.
- family: 1
- };
- tcp.connect({
- address: connectAddress, timeout: 6000
- }, err => {
- if (err) {
- console.log('connect fail');
- return;
- }
- console.log('connect success');
-
- // Send data.
- tcp.send({
- data: 'Hello, server!'
- }, err => {
- if (err) {
- console.log('send fail');
- return;
- }
- console.log('send success');
- })
- });
- });
-
- // Enable the TCPSocket connection to be automatically closed after use. Then, disable listening for TCPSocket connection events.
- setTimeout(() => {
- tcp.close((err) => {
- console.log('close socket.')
- });
- tcp.off('message');
- tcp.off('connect');
- tcp.off('close');
- }, 30 * 1000);
- ```
+```js
+import socket from '@ohos.net.socket'
+
+// Create a TCPSocket object.
+let tcp = socket.constructTCPSocketInstance();
+
+// Subscribe to TCPSocket connection events.
+tcp.on('message', value => {
+ console.log("on message")
+ let buffer = value.message
+ let dataView = new DataView(buffer)
+ let str = ""
+ for (let i = 0; i < dataView.byteLength; ++i) {
+ str += String.fromCharCode(dataView.getUint8(i))
+ }
+ console.log("on connect received:" + str)
+});
+tcp.on('connect', () => {
+ console.log("on connect")
+});
+tcp.on('close', () => {
+ console.log("on close")
+});
+
+// Bind the local IP address and port number.
+let bindAddress = {
+ address: '192.168.xx.xx',
+ port: 1234, // Bound port, for example, 1234.
+ family: 1
+};
+tcp.bind(bindAddress, err => {
+ if (err) {
+ console.log('bind fail');
+ return;
+ }
+ console.log('bind success');
+
+ // Set up a connection to the specified IP address and port number.
+ let connectAddress = {
+ address: '192.168.xx.xx',
+ port: 5678, // Connection port, for example, 5678.
+ family: 1
+ };
+ tcp.connect({
+ address: connectAddress, timeout: 6000
+ }, err => {
+ if (err) {
+ console.log('connect fail');
+ return;
+ }
+ console.log('connect success');
+
+ // Send data.
+ tcp.send({
+ data: 'Hello, server!'
+ }, err => {
+ if (err) {
+ console.log('send fail');
+ return;
+ }
+ console.log('send success');
+ })
+ });
+});
+
+// Enable the TCPSocket connection to be automatically closed after use. Then, disable listening for TCPSocket connection events.
+setTimeout(() => {
+ tcp.close((err) => {
+ console.log('close socket.')
+ });
+ tcp.off('message');
+ tcp.off('connect');
+ tcp.off('close');
+}, 30 * 1000);
+```
## Implementing encrypted data transmission over TLSSocket connections
@@ -184,6 +184,8 @@ TLSSocket connection process on the client:
7. Enable the TLSSocket connection to be automatically closed after use.
```js
+import socket from '@ohos.net.socket'
+
// Create a TLSSocket connection (for two-way authentication).
let tlsTwoWay = socket.constructTLSSocketInstance();
@@ -206,7 +208,7 @@ tlsTwoWay.on('close', () => {
});
// Bind the local IP address and port number.
-tlsTwoWay.bind({address: '192.168.xxx.xxx', port: xxxx, family: 1}, err => {
+tlsTwoWay.bind({ address: '192.168.xxx.xxx', port: xxxx, family: 1 }, err => {
if (err) {
console.log('bind fail');
return;
@@ -278,7 +280,7 @@ tlsTwoWay.on('close', () => {
});
// Bind the local IP address and port number.
-tlsOneWay.bind({address: '192.168.xxx.xxx', port: xxxx, family: 1}, err => {
+tlsOneWay.bind({ address: '192.168.xxx.xxx', port: xxxx, family: 1 }, err => {
if (err) {
console.log('bind fail');
return;
diff --git a/en/application-dev/dfx/Readme-EN.md b/en/application-dev/dfx/Readme-EN.md
index b8a4496e09420b3a7557e5c8b8996deaf14ce1c9..b5990650c61eae7ed57a0b1dbc35489947de8bc8 100644
--- a/en/application-dev/dfx/Readme-EN.md
+++ b/en/application-dev/dfx/Readme-EN.md
@@ -3,6 +3,10 @@
- [Development of Application Event Logging](hiappevent-guidelines.md)
- [Development of Performance Tracing](hitracemeter-guidelines.md)
- [Development of Distributed Call Chain Tracing](hitracechain-guidelines.md)
+- [HiLog Development (Native)](hilog-guidelines.md)
- Error Management
- [Development of Error Manager](errormanager-guidelines.md)
- [Development of Application Recovery](apprecovery-guidelines.md)
+- Log Management
+ - [Application Freeze (appfreeze) Log Analysis](appfreeze-guidelines.md)
+ - [Process Crash (cppcrash) Log Analysis](cppcrash-guidelines.md)
diff --git a/en/application-dev/dfx/appfreeze-guidelines.md b/en/application-dev/dfx/appfreeze-guidelines.md
new file mode 100644
index 0000000000000000000000000000000000000000..fb12c9384ed00af5bb99b870f2cbef280bf25290
--- /dev/null
+++ b/en/application-dev/dfx/appfreeze-guidelines.md
@@ -0,0 +1,200 @@
+# Application Freeze (appfreeze) Log Analysis
+
+## Introduction
+
+Application freeze (appfreeze) means that an application does not respond to user operations (for example, clicking) within a given period of time. OpenHarmony provides a mechanism for detecting appfreeze faults and generates appfreeze logs for fault analysis.
+
+> **NOTE**
+>
+> This guide applies only to applications in the stage model.
+> Before using this guide, you must have basic knowledge about the JS applications, C++ program stacks, and application-related subsystems.
+
+## How to Obtain
+
+appfreeze log is a type of fault logs managed together with the native process crash, JS application crash, and system process crash logs . You can obtain the log in any of the following ways.
+
+### Collecting Logs by Using Shell
+
+appfreeze logs start with **appfreeze-** in **/data/log/faultlog/faultlogger/**.
+
+The log files are named in the format of **appfreeze-application package name-application UID-time (seconds level)**.
+
+
+
+### Collecting Logs by Using DevEco Studio
+
+DevEco Studio collects device fault logs and saves them to FaultLog.
+
+The logs are displayed by the bundle name, fault, and time.
+
+
+
+
+### Collecting Logs by Using faultLogger APIs
+
+The FaultLogger module provides APIs to query various fault information. For details, see [@ohos.faultLogger](../reference/apis/js-apis-faultLogger.md).
+
+
+## appfreeze Detection
+
+Currently, appfreeze detection supports the fault types listed in the following table.
+
+| Fault Type| Description|
+| -------- | -------- |
+| THREAD_BLOCK_6S | The application main thread times out due to a suspension.|
+| APPLICATION_BLOCK_INPUT | The user input response times out.|
+| LIFECYCLE_TIMEOUT | Ability lifecycle switching times out.|
+| APP_LIFECYCLE_TIMEOUT | Application lifecycle switching times out.|
+
+### Application Main Thread Timeout
+
+If this fault occurs, the main thread of the current application is suspended or too many tasks are executed, affecting task execution smoothness and experience.
+
+Such a fault can be detected as follows: The watchdog thread of the application periodically inserts an activation detection subthread to the main thread and inserts a timeout reporting subthread to its own thread. If activation detection is not executed within 3 seconds, the THREAD_BLOCK_3S event is reported; if activation detection is not executed within 6 seconds, the THREAD_BLOCK_6S event is reported. The two events together form an appfreeze log. The following figure shows the working principle.
+
+
+
+### User Input Response Timeout
+
+This fault affects user experience. If this fault occurs, the system does not respond to a click event within 10 seconds.
+
+Such a fault can be detected as follows: When a user clicks a certain button of the application, the input system sends a click event to the application. If the input system does not receive a response from the application within 10 seconds, a fault event is reported. The following figure shows the working principle.
+
+
+
+### Lifecycle Switching Timeout
+
+This fault refers to an ability lifecycle switching timeout (LIFECYCLE\_TIMEOUT) or an application lifecycle switching timeout (APP\_LIFECYCLE\_TIMEOUT).
+
+The fault occurs during lifecycle switching and affects the switchover between abilities in the current application or the switchover between applications.
+
+Such a fault can be detected as follows: Upon the start of a lifecycle switchover process, the main thread inserts a timeout task to the watchdog thread, and then removes the timeout task when the lifecycle switchover is complete. If the timeout duration expires, a fault event is reported.
+
+
+
+The timeout duration varies according to the lifecycle.
+
+| Lifecycle| Timeout Duration|
+| -------- | -------- |
+| Load | 10s |
+| Terminate | 10s |
+| Connect | 3s |
+| Disconnect | 0.5s |
+| Foreground | 5s |
+| Background | 3s |
+
+## appfreeze Log Analysis
+
+To identify the cause of appfreeze, analyze the appfreeze logs together with HiLog logs.
+
+The following example uses main tread suspension as an example to illustrate how to conduct log analysis. You can treat other types of faults in a similar way.
+
+appfreeze logs are divided into several parts, including header information, and general and specific information in the body.
+
+### Log Header Information
+
+| Field| Description|
+| -------- | -------- |
+| Reason | Reason why the application does not respond. For details, see [appfreeze Detection](#appfreeze-detection).|
+| PID | PID of the failed process, which can be used to search for related process information in the log.|
+| PACKAGE_NAME | Application package name.|
+
+
+
+### General Information in the Log Body
+
+General information is present in all logs. It contains the fields listed in the following table. You can search for these fields to locate the related information in the log.
+
+| Field| Description|
+| -------- | -------- |
+| EVENTNAME | One or more fault events that constitute the cause of main thread suspension.|
+| TIMESTAMP | Time when the fault event reported. You can narrow down the time range for viewing HiLog logs based on the timeout duration described in [appfreeze Detection](#appfreeze-detection).|
+| PID | PID of the failed process, which can be used with the timestamp and timeout duration to search for related process information in the log.|
+| PACKAGE_NAME | Application package name.|
+| MSG | Dump information or description of the fault.|
+| OpenStacktraceCatcher | Stack trace information of the process.|
+| BinderCatcher | Information about IPC calls between a process and other system processes, such as the call waiting time.|
+| PeerBinder Stacktrace | Information about stack trace of the peer process.|
+| cpuusage | CPU usage of the device.|
+| memory | Memory usage of the process.|
+
+The following is an example process stack of OpenStacktraceCatcher.
+
+In this example, when the stack surface window sends events through IPC, the process is stuck in the IPC communication phase.
+
+
+
+Example BinderCatcher information:
+
+In the following example, process 1561 sends an IPC request to process 685 but does not receive any response within 10 seconds.
+
+
+
+Example PeerBinder Stacktrace information:
+
+The following example shows the stack information of process 685, which is suspended at the peer end.
+
+
+
+Example CPU usage information:
+
+The following example shows the CPU usage information of the device.
+
+
+
+Example memory usage information:
+
+The following example shows the memory usage information of the process.
+
+
+
+### Specific Information in the Log Body (Application Main Thread Timeout)
+
+According to [Application Main Thread Timeout] (#application-main-thread-timeout), the log in which **Reason** is **THREAD\_BLOCK\_6S** consists of two parts: THREAD\_BLOCK\_3S and THREAD\_BLOCK\_6S. By comparing the two parts, you can determine whether the appfreeze is due to a suspension or an excess number of tasks.
+
+THREAD\_BLOCK\_3S is followed by THREAD\_BLOCK\_6S in the log. You can use the **EVENTNAME** field to search for the locations of the two events in the log.
+
+Both events contain the **MSG** field, which stores information about the processing queue of the main thread when the suspension occurs. Hence, you can view the status of the event processing queue of the main thread at the two time points.
+
+The example log shows that the event carrying **05:06:18.145** in the low-priority queue is being processed, and it is present in both the THREAD_BLOCK_3S and THREAD_BLOCK_6S. This indicates that the main thread suspension is not caused by an excess number of tasks.
+
+Because THREAD_BLOCK_6S indicates a main thread suspension, you only need to analyze the stack information of the main thread (the ID of the main thread is the same as the process ID). In the example log, the main thread stack is run in the JS through ArkUI and therefore it can be concluded that the suspension occurs in the JS. Because stack is present in both THREAD_BLOCK_3S and THREAD_BLOCK_6S in the same position, the JS suspension is not caused by an excess number of tasks.
+THREAD_BLOCK_3S:
+
+
+
+THREAD_BLOCK_6S:
+
+
+
+Then, you can check for the code segment being executed on the application side based on the HiLog log.
+
+Generally, you can view the [general information in the log body](#general-information-in-the-log-body) to check for the cause of the suspension, for example, IPC suspension, high CPU usage, memory leakage, or high memory usage.
+
+### Specific Information in the Log Body (User Input Response Timeout)
+
+If **Reason** is **APPLICATION\_BLOCK\_INPUT**, no response is received within 10 seconds after a user click.
+
+You can find the event description in **MSG**.
+
+For details, see [General Information in the Log Body](#general-information-in-the-log-body). Note that there is a high probability that the main thread is suspended in the case of no response to the user input. You can compare the stack and BinderCatcher information in two log records for further analysis. If there is no log record indicating a main thread suspension, a large number of other events may exist before the input event. This may not cause a main thread suspension but can probably result in no response to user input.
+
+### Specific Information in the Log Body (Lifecycle Switching Timeout)
+
+For a lifecycle switching timeout, **Reason** can be **LIFECYCLE\_TIMEOUT** or **APP\_LIFECYCLE\_TIMEOUT**.
+
+**LIFECYCLE\_TIMEOUT** indicates a lifecycle switching timeout at the ability level, and **APP\_LIFECYCLE\_TIMEOUT** indicates a lifecycle switching timeout at the application level.
+
+MSG indicates the lifecycle that encounters a timeout.
+
+In this example, **LIFECYCLE\_TIMEOUT** indicates that the timeout occurs during switching of the ability to the background, and **APP\_LIFECYCLE\_TIMEOUT** indicates that the timeout occurs in the application termination phase. You can locate related HiLog logs according to the timeout duration described in [Lifecycle Switching Timeout] (#lifecycle-switching-timeout).
+
+LIFECYCLE_TIMEOUT:
+
+
+
+APP_LIFECYCLE_TIMEOUT:
+
+
+
+For details about other log information, see [General Information in the Log Body](#general-information-in-the-log-body). Note that there is a high probability that the main thread is suspended during lifecycle switching. You can compare the stack and BinderCatcher information in two log records for further analysis.
diff --git a/en/application-dev/dfx/apprecovery-guidelines.md b/en/application-dev/dfx/apprecovery-guidelines.md
index 3ccac845bf8916c2d65f714474882f1c95848695..284de5ca6d5f6027f2cce975a29b3259b2778021 100644
--- a/en/application-dev/dfx/apprecovery-guidelines.md
+++ b/en/application-dev/dfx/apprecovery-guidelines.md
@@ -40,7 +40,9 @@ Fault management is an important way for applications to deliver a better user e
- Fault query is the process of calling APIs of [faultLogger](../reference/apis/js-apis-faultLogger.md) to obtain the fault information.
The figure below does not illustrate the time when [faultLogger](../reference/apis/js-apis-faultLogger.md) is called. You can refer to the [LastExitReason](../reference/apis/js-apis-app-ability-abilityConstant.md#abilityconstantlastexitreason) passed during application initialization to determine whether to call [faultLogger](../reference/apis/js-apis-faultLogger.md) to query information about the previous fault.
+

+
It is recommended that you call [errorManager](../reference/apis/js-apis-app-ability-errorManager.md) to handle the exception. After the processing is complete, you can call the **saveAppState** API and restart the application.
If you do not register [ErrorObserver](../reference/apis/js-apis-inner-application-errorObserver.md) or enable application recovery, the application process will exit according to the default processing logic of the system. Users can restart the application from the home screen.
If you have enabled application recovery, the recovery framework first checks whether application state saving is supported and whether the application state saving is enabled. If so, the recovery framework invokes [onSaveState](../reference/apis/js-apis-app-ability-uiAbility.md#uiabilityonsavestate) of the [Ability](../reference/apis/js-apis-app-ability-uiAbility.md). Finally, the application is restarted.
diff --git a/en/application-dev/dfx/cppcrash-guidelines.md b/en/application-dev/dfx/cppcrash-guidelines.md
new file mode 100644
index 0000000000000000000000000000000000000000..4454422fe4f3aec6c781090a2e833ee103488dab
--- /dev/null
+++ b/en/application-dev/dfx/cppcrash-guidelines.md
@@ -0,0 +1,110 @@
+# cppcrash Log Analysis
+
+## Introduction
+
+A process crash refers to a C/C++ runtime crash. The FaultLogger module of OpenHarmony provides capabilities such as process crash detection, log collection, log storage, and log reporting, helping you to locate faults more effectively.
+
+In this document, you'll be guided through how to implement process crash detection, crash log collection, and crash log analysis. Before getting started, make sure you have basic knowledge about C/C++ program stacks.
+
+## Process Crash Detection
+
+Process crash detection is implemented based on the Linux signal mechanism. Currently, C/C++ crash exception signals listed in the following table are supported.
+
+| Signal Value| Signal| Description| Trigger Cause|
+| ------ | --------- | --------------- | ------------------------------------------- |
+| 4 | SIGILL | Invalid instruction | An invalid, incorrectly formatted, unknown, or privileged instruction is executed.|
+| 5 | SIGTRAP | Breakpoint or trap | An exception occurs or a trap instruction is executed.|
+| 6 | SIGABRT | Process abort | The process is aborted abnormally. Generally, this problem occurs if the process calls the `abort()` function of the standard function library.|
+| 7 | SIGBUS | Illegal memory access | The process accesses an aligned or nonexistent physical address.|
+| 8 | SIGFPE | Floating-point exception | The process performs an incorrect arithmetic operation, for example, a 0 divisor, floating point overflow, or integer overflow.|
+| 11 | SIGSEGV | Invalid memory access | The process accesses an invalid memory reference.|
+| 16 | SIGSTKFLT | Stack error | The processor performs an incorrect stack operation, such as a pop when the stack is empty or a push when the stack is full.|
+| 31 | SIGSYS | Incorrect system call | An incorrect or invalid parameter is used in a system call.|
+
+## Crash Log Collection
+
+Process crash log is the fault log managed together with the app freeze and JS application crash logs by the FaultLogger module. You can collect process crash logs in any of the following ways:
+
+### Collecting Logs by Using Shell
+
+- Fault logs in the `/data/log/faultlog/faultlogger/` directory of the device. The log files are named in the format of `cppcrash-process name-process UID-time (seconds level)`. They contain only information such as the device name, system version, and process crash call stack.
+
+ 
+
+- Fault logs in the `/data/log/faultlog/temp/` directory of the device. The log files are named in the format of `cppcrash-process name-process PID-system timestamp (seconds level)`. In addition to basic information, they also contain information such as the stack memory and process maps at the time of process crash.
+
+ 
+
+### Collecting Logs by Using DevEco Studio
+
+DevEco Studio collects process crash logs from `/data/log/faultlog/faultlogger/` to FaultLog, where logs are displayed by process name, fault, and time.
+
+
+
+### Collecting Logs by Using faultLogger APIs
+
+The FaultLogger module provides APIs to query various fault information. For details, see [@ohos.faultLogger](../reference/apis/js-apis-faultLogger.md).
+
+## Process Crash Log Analysis
+
+### Log Format
+
+The following is an example process crash log archived by DevEco Studio in FaultLog:
+
+```
+Generated by HiviewDFX@OpenHarmony
+==================================================================
+Device info:OpenHarmony 3.2 <- Device information
+Build info:OpenHarmony 4.0.5.5 <- Version information
+Module name:crasher_c <- Module name
+Pid:1205 <- Process ID
+Uid:0 <- User ID
+Reason:Signal:SIGSEGV(SEGV_ACCERR)@0x0042d33d <- Exception information
+Thread name:crasher <- Abnormal thread
+#00 pc 0000332c /data/crasher(TriggerSegmentFaultException+15)(8bc37ceb8d6169e919d178fdc7f5449e) <- Call stack
+#01 pc 000035c7 /data/crasher(ParseAndDoCrash+277)(8bc37ceb8d6169e919d178fdc7f5449e)
+#02 pc 00003689 /data/crasher(main+39)(8bc37ceb8d6169e919d178fdc7f5449e)
+#03 pc 000c3b08 /system/lib/ld-musl-arm.so.1(__libc_start_main+116)
+#04 pc 000032f8 /data/crasher(_start_c+112)(8bc37ceb8d6169e919d178fdc7f5449e)
+#05 pc 00003284 /data/crasher(_start+32)(8bc37ceb8d6169e919d178fdc7f5449e)
+...
+```
+
+### Locating Faults Through Logs
+
+1. Determine the faulty module and fault type based on fault logs.
+
+ Generally, you can identify the faulty module based on the crash process name and identify the crash cause based on the signal. Besides, you can restore the function call chain of the crash stack based on the method name in the stack.
+
+ In the example, **SIGSEGV** is thrown by the Linux kernel because of access to an invalid memory address. The problem occurs in the **TriggerSegmentFaultException** function.
+
+ In most scenarios, a crash is caused by the top layer of the crash stack, such as null pointer access and proactive program abort.
+
+ If the cause cannot be located through the call stack, you need to check for other faults, for example, memory corruption or stack overflow.
+
+2. Use the addr2line tool of Linux to parse the code line number to restore the call stack at the time of process crash.
+
+ When using the addr2line tool to parse the code line number of the crash stack, make sure that binary files with debugging information is used. Generally, such files are generated during version build or application build.
+
+ Application binary files are located in DevEco Studio's temporary directory for application build, for example, `build/default/intermediates/libs`.
+
+ System binary files are stored in the directories listed below. For versions that are directly obtained, the binary files are archived in the image package.
+ ```
+ \code root directory\out\product\lib.unstripped
+ \code root directory\out\product\exe.unstripped
+ ```
+
+ You can run `apt-get install addr2line` to install the addr2line tool on Linux.
+
+ On On DevEco Studio, you can also use the llvm-addr2line tool archived in the SDK to parse code line numbers. The usage method is the same.
+
+ The following example shows how to use the addr2line tool to parse the code line number based on the offset address:
+
+ ```
+ root:~/OpenHarmony/out/rk3568/exe.unstripped/hiviewdfx/faultloggerd$ addr2line -e crasher 0000332c
+ base/hiviewdfx/faultloggerd/tools/crasher/dfx_crasher.c:57
+ ```
+
+ In this example, the crash is caused by assignment of a value to an unwritable area. It is in code line 57 in the **dfx_crasher.c** file. You can modify it to avoid the crash.
+
+ If the obtained code line number is seemingly incorrect, you can fine-tune the address (for example, subtract the address by 1) or disable some compilation optimization items. It is known that the obtained code line number may be incorrect when Link Time Optimization (LTO) is enabled.
diff --git a/en/application-dev/dfx/figures/20230407111853.png b/en/application-dev/dfx/figures/20230407111853.png
new file mode 100644
index 0000000000000000000000000000000000000000..cedfb46aecd8a3a1a9482619e4b0ea5f18eccc4a
Binary files /dev/null and b/en/application-dev/dfx/figures/20230407111853.png differ
diff --git a/en/application-dev/dfx/figures/20230407112159.png b/en/application-dev/dfx/figures/20230407112159.png
new file mode 100644
index 0000000000000000000000000000000000000000..c2bce4198850fc25bdb2a4328c1b600d99d39e88
Binary files /dev/null and b/en/application-dev/dfx/figures/20230407112159.png differ
diff --git a/en/application-dev/dfx/figures/20230407112620.png b/en/application-dev/dfx/figures/20230407112620.png
new file mode 100644
index 0000000000000000000000000000000000000000..59a25256717ee791e0a3c40ec1d46c78d889a60f
Binary files /dev/null and b/en/application-dev/dfx/figures/20230407112620.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230308145160.png b/en/application-dev/dfx/figures/appfreeze_20230308145160.png
new file mode 100644
index 0000000000000000000000000000000000000000..2be8a97cf7b2518a0361cb0f8965642731282350
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230308145160.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230308145161.png b/en/application-dev/dfx/figures/appfreeze_20230308145161.png
new file mode 100644
index 0000000000000000000000000000000000000000..92c236037b7c75f6480b3781ee6b1aa15e44cc51
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230308145161.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230308145162.png b/en/application-dev/dfx/figures/appfreeze_20230308145162.png
new file mode 100644
index 0000000000000000000000000000000000000000..8cf8128baf5cf5bd91422dc0fda94a251287a71c
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230308145162.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230308145163.png b/en/application-dev/dfx/figures/appfreeze_20230308145163.png
new file mode 100644
index 0000000000000000000000000000000000000000..2a1ce3e36a87a79c725f15ea223258eae348dec1
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230308145163.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230308145164.png b/en/application-dev/dfx/figures/appfreeze_20230308145164.png
new file mode 100644
index 0000000000000000000000000000000000000000..be230c32e3e1c4da3a9a182c3d4825d60dca4808
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230308145164.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105865.png b/en/application-dev/dfx/figures/appfreeze_20230310105865.png
new file mode 100644
index 0000000000000000000000000000000000000000..0082b4a012d79e2a407934abc6b3e45e580e20dd
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105865.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105866.png b/en/application-dev/dfx/figures/appfreeze_20230310105866.png
new file mode 100644
index 0000000000000000000000000000000000000000..87e25e01d01d5e039c1089ee7604d2e14403efee
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105866.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105867.png b/en/application-dev/dfx/figures/appfreeze_20230310105867.png
new file mode 100644
index 0000000000000000000000000000000000000000..c77c4686a66c56dc051aaa3a1d7996a3cb93985b
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105867.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105868.png b/en/application-dev/dfx/figures/appfreeze_20230310105868.png
new file mode 100644
index 0000000000000000000000000000000000000000..7c1f36e709e4b07908567a7124df5e45fbd9bad1
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105868.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105869.png b/en/application-dev/dfx/figures/appfreeze_20230310105869.png
new file mode 100644
index 0000000000000000000000000000000000000000..a55b3373405f2f4db972507e2f35102021c7f92a
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105869.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105870.png b/en/application-dev/dfx/figures/appfreeze_20230310105870.png
new file mode 100644
index 0000000000000000000000000000000000000000..73c0549142e49e233b3ea38f8e1b6e44c642a30e
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105870.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105871.png b/en/application-dev/dfx/figures/appfreeze_20230310105871.png
new file mode 100644
index 0000000000000000000000000000000000000000..ea8fe6bb1156255571e45e4e22d69cea70ae474f
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105871.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105872.png b/en/application-dev/dfx/figures/appfreeze_20230310105872.png
new file mode 100644
index 0000000000000000000000000000000000000000..43406b804f9c981e636f4ad6099ce1abd69fb3d1
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105872.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105873.png b/en/application-dev/dfx/figures/appfreeze_20230310105873.png
new file mode 100644
index 0000000000000000000000000000000000000000..71457fa6a49bf657a3b4527c7a000818c824ba94
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105873.png differ
diff --git a/en/application-dev/dfx/figures/appfreeze_20230310105874.png b/en/application-dev/dfx/figures/appfreeze_20230310105874.png
new file mode 100644
index 0000000000000000000000000000000000000000..cb4fc75b47b439fe131121586f13bdbf41408082
Binary files /dev/null and b/en/application-dev/dfx/figures/appfreeze_20230310105874.png differ
diff --git a/en/application-dev/dfx/hilog-guidelines.md b/en/application-dev/dfx/hilog-guidelines.md
new file mode 100644
index 0000000000000000000000000000000000000000..a399a520ba96aa3a64eea8968ed359c05da5440b
--- /dev/null
+++ b/en/application-dev/dfx/hilog-guidelines.md
@@ -0,0 +1,70 @@
+# HiLog Development (Native)
+
+## Introduction
+
+HiLog is the log system of OpenHarmony that provides logging for the system framework, services, and applications to record information on user operations and system running status.
+
+> **NOTE**
+>
+> This development guide is applicable only when you use Native APIs for application development. For details about the APIs, see [HiLog Native API Reference](../reference/native-apis/_hi_log.md).
+
+## Available APIs
+
+| API/Macro| Description|
+| -------- | -------- |
+| int OH_LOG_Print(LogType type, LogLevel level, unsigned int domain, const char *tag, const char *fmt, ...) | Outputs logs based on the specified log type, log level, service domain, log tag, and variable parameters determined by the format specifier and privacy identifier in the printf format. Input arguments: See [Parameter Description](#parameter-description). Output arguments: None Return value: total number of bytes if log printing is successful; **-1** otherwise.|
+| #define OH_LOG_DEBUG(type, ...) ((void)OH_LOG_Print((type), LOG_DEBUG, LOG_DOMAIN, LOG_TAG, \_*VA*ARGS__))| Outputs DEBUG logs. This is a function-like macro.|
+| #define OH_LOG_INFO(type, ...) ((void)OH_LOG_Print((type), LOG_INFO, LOG_DOMAIN, LOG_TAG, \_*VA*ARGS__)) | Outputs INFO logs. This is a function-like macro.|
+| #define OH_LOG_WARN(type, ...) ((void)OH_LOG_Print((type), LOG_WARN, LOG_DOMAIN, LOG_TAG, \_*VA*ARGS__)) | Outputs WARN logs. This is a function-like macro.|
+| #define OH_LOG_ERROR(type, ...) ((void)OH_LOG_Print((type), LOG_ERROR, LOG_DOMAIN, LOG_TAG, \_*VA*ARGS__)) | Outputs ERROR logs. This is a function-like macro.|
+| #define OH_LOG_FATAL(type, ...) ((void)OH_LOG_Print((type), LOG_FATAL, LOG_DOMAIN, LOG_TAG, \_*VA*ARGS__)) | Outputs FATAL logs. This is a function-like macro.|
+| bool OH_LOG_IsLoggable(unsigned int domain, const char *tag, LogLevel level) | Checks whether logs of the specified service domain, tag, and level can be printed. Input arguments: See [Parameter Description](#parameter-description). Output arguments: none Return value: **true** if the specified logs can be printed; **false** otherwise.|
+
+## Parameter Description
+
+| Name| Type | Mandatory| Description |
+| ------ | ------ | ---- | ------------------------------------------------------------ |
+| type | enum | Yes | Log printing type. The default value is **LOG_APP** for application logs.|
+| level | enum | Yes | Log printing level. For details, see [Log Level](#loglevel).|
+| domain | number | Yes | Service domain of logs. The value ranges from **0x0** to **0xFFFF**. You can define the value as required. |
+| tag | string | Yes | Log tag in the string format. You are advised to use this parameter to identify a particular service behavior or the class holding the ongoing method.|
+| fmt | string | Yes | Format string used to output logs in a specified format. It can contain several parameters, where the parameter type and privacy identifier are mandatory. Parameters labeled **{public}** are public data and are displayed in plaintext; parameters labeled **{private}** (default value) are private data and are filtered by **\**.|
+| args | any[] | Yes | Variable-length parameter list corresponding to the format string. The number and type of parameters must map to the identifier in the format string.|
+
+## LogLevel
+
+Log level.
+
+| Name | Value | Description |
+| ----- | ------ | ------------------------------------------------------------ |
+| DEBUG | 3 | Log level used to record more detailed process information than INFO logs to help developers analyze service processes and locate faults.|
+| INFO | 4 | Log level used to record key service process nodes and exceptions that occur during service running, Log level used to record information about unexpected exceptions, such as network signal loss and login failure. These logs should be recorded by the dominant module in the service to avoid repeated logging conducted by multiple invoked modules or low-level functions.|
+| WARN | 5 | Log level used to record severe, unexpected faults that have little impact on users and can be rectified by the programs themselves or through simple operations.|
+| ERROR | 6 | Log level used to record program or functional errors that affect the normal running or use of the functionality and can be fixed at a high cost, for example, by resetting data.|
+| FATAL | 7 | Log level used to record program or functionality crashes that cannot be rectified.
+
+## Development Example
+
+1. Add the link of **libhilog_ndk.z.so** to **CMakeLists.txt**:
+```
+target_link_libraries(entry PUBLIC libhilog_ndk.z.so)
+```
+2. Include the **hilog** header file in the source file, and define the **domain** and **tag** macros.
+```c++
+#include "hilog/log.h"
+```
+
+```c++
+#undef LOG_DOMAIN
+#undef LOG_TAG
+#define LOG_DOMAIN 0x3200 // Global domain, which identifies the service domain.
+#define LOG_TAG "MY_TAG" // Global tag, which identifies the module log tag.
+```
+3. Print logs. For example, to print ERROR logs, use the following code:
+```c++
+OH_LOG_ERROR(LOG_APP, "Failed to visit %{private}s, reason:%{public}d.", url, errno);
+```
+4. View the output log information.
+```
+12-11 12:21:47.579 2695 2695 E A03200/MY_TAG: Failed to visit , reason:11.
+```
diff --git a/en/application-dev/reference/apis/Readme-EN.md b/en/application-dev/reference/apis/Readme-EN.md
index 00c14c10d78af872163b6c379315e5c11982b845..7dbd01e10fd51d7b908449efcf413db9f6c228cd 100644
--- a/en/application-dev/reference/apis/Readme-EN.md
+++ b/en/application-dev/reference/apis/Readme-EN.md
@@ -256,7 +256,6 @@
- [@ohos.net.connection (Network Connection Management)](js-apis-net-connection.md)
- [@ohos.net.ethernet (Ethernet Connection Management)](js-apis-net-ethernet.md)
- [@ohos.net.http (Data Request)](js-apis-http.md)
- - [@ohos.net.policy (Network Policy Management)](js-apis-net-policy.md)
- [@ohos.net.sharing (Network Sharing)](js-apis-net-sharing.md)
- [@ohos.net.socket (Socket Connection)](js-apis-socket.md)
- [@ohos.net.webSocket (WebSocket Connection)](js-apis-webSocket.md)
diff --git a/en/application-dev/reference/apis/js-apis-batteryStatistics.md b/en/application-dev/reference/apis/js-apis-batteryStatistics.md
index c2969b024889024afd1fc3178e5b61b77795d8f3..8314dd92cfc15cdbc9ad8e1e232b3fab2b00380b 100644
--- a/en/application-dev/reference/apis/js-apis-batteryStatistics.md
+++ b/en/application-dev/reference/apis/js-apis-batteryStatistics.md
@@ -18,7 +18,7 @@ import batteryStats from '@ohos.batteryStatistics';
getBatteryStats(): Promise
-Obtains the power consumption information list, using a promise to return the result.
+Obtains the power consumption information list. This API uses a promise to return the result.
**System API**: This is a system API.
@@ -34,9 +34,9 @@ Obtains the power consumption information list, using a promise to return the re
For details about the error codes, see [Thermal Manager Error Codes](../errorcodes/errorcode-batteryStatistics.md).
-| Code| Error Message |
-| -------- | -------------- |
-| 4600101 | Operation failed. Cannot connect to service.|
+| Code | Error Message |
+|---------|---------|
+| 4600101 | If connecting to the service failed. |
**Example**
@@ -64,15 +64,15 @@ Obtains the power consumption information list. This API uses an asynchronous ca
| Name | Type | Mandatory| Description |
| -------- | ----------------------------------------------------------- | ---- | ------------------------------------------------------------ |
-| callback | AsyncCallback> | Yes | Callback used to return the result. If the operation is successful, **err** is **undefined** and **data** is the array of power consumption information obtained. If the operation failed, **err** is an error object.|
+| callback | AsyncCallback> | Yes | Callback used to return the result. If the operation is successful, **err** is **undefined** and **data** is the array of power consumption information obtained (that is, **Array<[BatteryStatsInfo](#batterystatsinfo)>>**). If the operation failed, **err** is an error object.|
**Error codes**
For details about the error codes, see [Thermal Manager Error Codes](../errorcodes/errorcode-batteryStatistics.md).
-| Code| Error Message |
-| -------- | -------------- |
-| 4600101 | Operation failed. Cannot connect to service.|
+| Code | Error Message |
+|---------|---------|
+| 4600101 | If connecting to the service failed. |
**Example**
@@ -112,9 +112,9 @@ Obtains the power consumption of an application.
For details about the error codes, see [Thermal Manager Error Codes](../errorcodes/errorcode-batteryStatistics.md).
-| Code| Error Message |
-| -------- | -------------- |
-| 4600101 | Operation failed. Cannot connect to service.|
+| Code | Error Message |
+|---------|---------|
+| 4600101 | If connecting to the service failed. |
**Example**
@@ -153,9 +153,9 @@ Obtains the proportion of the power consumption of an application.
For details about the error codes, see [Thermal Manager Error Codes](../errorcodes/errorcode-batteryStatistics.md).
-| Code| Error Message |
-| -------- | -------------- |
-| 4600101 | Operation failed. Cannot connect to service.|
+| Code | Error Message |
+|---------|---------|
+| 4600101 | If connecting to the service failed. |
**Example**
@@ -194,15 +194,15 @@ Obtains the power consumption of a hardware unit according to the consumption ty
For details about the error codes, see [Thermal Manager Error Codes](../errorcodes/errorcode-batteryStatistics.md).
-| Code| Error Message |
-| -------- | -------------- |
-| 4600101 | Operation failed. Cannot connect to service.|
+| Code | Error Message |
+|---------|---------|
+| 4600101 | If connecting to the service failed. |
**Example**
```js
try {
- var value = batteryStats.getHardwareUnitPowerValue(ConsumptionType.CONSUMPTION_TYPE_SCREEN);
+ var value = batteryStats.getHardwareUnitPowerValue(batteryStats.ConsumptionType.CONSUMPTION_TYPE_SCREEN);
console.info('battery statistics value of hardware is: ' + value);
} catch(err) {
console.error('get battery statistics percent of hardware failed, err: ' + err);
@@ -235,15 +235,15 @@ Obtains the proportion of the power consumption of a hardware unit according to
For details about the error codes, see [Thermal Manager Error Codes](../errorcodes/errorcode-batteryStatistics.md).
-| Code| Error Message |
-| -------- | -------------- |
-| 4600101 | Operation failed. Cannot connect to service.|
+| Code | Error Message |
+|---------|---------|
+| 4600101 | If connecting to the service failed. |
**Example**
```js
try {
- var percent = batteryStats.getHardwareUnitPowerPercent(ConsumptionType.CONSUMPTION_TYPE_SCREEN);
+ var percent = batteryStats.getHardwareUnitPowerPercent(batteryStats.ConsumptionType.CONSUMPTION_TYPE_SCREEN);
console.info('battery statistics percent of hardware is: ' + percent);
} catch(err) {
console.error('get battery statistics percent of hardware failed, err: ' + err);
diff --git a/en/application-dev/reference/apis/js-apis-brightness.md b/en/application-dev/reference/apis/js-apis-brightness.md
index bd003733a485c1601ac251697461e78b863976a8..e6af63700029738f388f41edb5d980b51a9f9614 100644
--- a/en/application-dev/reference/apis/js-apis-brightness.md
+++ b/en/application-dev/reference/apis/js-apis-brightness.md
@@ -22,7 +22,7 @@ Sets the screen brightness.
**System API**: This is a system API.
-**System capability**: SystemCapability.PowerManager.DisplayPowerManager
+**System capability:** SystemCapability.PowerManager.DisplayPowerManager
**Parameters**
@@ -34,9 +34,9 @@ Sets the screen brightness.
For details about the error codes, see [Screen Brightness Error Codes](../errorcodes/errorcode-brightness.md).
-| Code | Error Message |
+| ID | Error Message |
|---------|---------|
-| 4700101 | Operation failed. Cannot connect to service.|
+| 4700101 | If connecting to the service failed. |
**Example**
diff --git a/en/application-dev/reference/apis/js-apis-bytrace.md b/en/application-dev/reference/apis/js-apis-bytrace.md
index 89e14f7ad3e4fb3f525ccd9d5aab83b56e8c6521..da3bb14c70e28a099ebd69235a7b460961387401 100644
--- a/en/application-dev/reference/apis/js-apis-bytrace.md
+++ b/en/application-dev/reference/apis/js-apis-bytrace.md
@@ -1,18 +1,17 @@
# @ohos.bytrace (Performance Tracing)
+The **bytrace** module implements performance tracing for processes.
+
> **NOTE**
-> - The APIs of this module are no longer maintained since API version 8. It is recommended that you use the APIs of [hiTraceMeter](js-apis-hitracemeter.md) instead.
+> - The APIs of this module are no longer maintained since API version 8. You are advised to use [`@ohos.hiTraceMeter`](js-apis-hitracemeter.md).
> - 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.
-
## Modules to Import
- ```js
+```js
import bytrace from '@ohos.bytrace';
```
-
-
## bytrace.startTrace
startTrace(name: string, taskId: number, expectedTime?: number): void
@@ -20,10 +19,9 @@ startTrace(name: string, taskId: number, expectedTime?: number): void
Marks the start of a timeslice trace task.
> **NOTE**
->
-> If multiple trace tasks with the same name need to be performed at the same time or a trace task needs to be performed multiple times concurrently, different task IDs must be specified in **startTrace**. If the trace tasks with the same name are not performed at the same time, the same taskId can be used. For details, see the bytrace.finishTrace example.
+> If multiple trace tasks with the same name need to be performed at the same time or a trace task needs to be performed multiple times concurrently, different task IDs must be specified in **startTrace**. If the trace tasks with the same name are not performed at the same time, the same task ID can be used. For details, see the bytrace.finishTrace example.
-**System capability**: SystemCapability.Developtools.Bytrace
+**System capability**: SystemCapability.HiviewDFX.HiTrace
**Parameters**
@@ -31,17 +29,16 @@ Marks the start of a timeslice trace task.
| -------- | -------- | -------- | -------- |
| name | string | Yes| Name of a timeslice trace task.|
| taskId | number | Yes| ID of a timeslice trace task.|
-| expectedTime | number | No| Expected duration of the trace, in ms.|
+| expectedTime | number | No| Expected duration of the trace, in ms. Optional. By default, this parameter is left blank.|
**Example**
- ```js
+```js
bytrace.startTrace("myTestFunc", 1);
bytrace.startTrace("myTestFunc", 1, 5); // The expected duration of the trace is 5 ms.
```
-
## bytrace.finishTrace
finishTrace(name: string, taskId: number): void
@@ -49,10 +46,9 @@ finishTrace(name: string, taskId: number): void
Marks the end of a timeslice trace task.
> **NOTE**
->
> To stop a trace task, the values of name and task ID in **finishTrace** must be the same as those in **startTrace**.
-**System capability**: SystemCapability.Developtools.Bytrace
+**System capability**: SystemCapability.HiviewDFX.HiTrace
**Parameters**
@@ -64,15 +60,15 @@ Marks the end of a timeslice trace task.
**Example**
- ```js
+```js
bytrace.finishTrace("myTestFunc", 1);
```
```
-// Start track tasks with the same name concurrently.
+// Start trace tasks with the same name concurrently.
bytrace.startTrace("myTestFunc", 1);
// Service flow
-bytrace.startTrace("myTestFunc", 2); // The second trace task starts while the first task is still running. The first and second tasks have the same name but different task IDs.
+bytrace.startTrace("myTestFunc", 2); // The second trace task starts while the first task is still running. The first and second tasks have the same name but different task IDs.
// Service flow
bytrace.finishTrace("myTestFunc", 1);
// Service flow
@@ -80,34 +76,33 @@ bytrace.finishTrace("myTestFunc", 2);
```
```
-// Start track tasks with the same name at different times.
+// Start trace tasks with the same name in serial mode.
bytrace.startTrace("myTestFunc", 1);
// Service flow
-bytrace.finishTrace("myTestFunc", 1); // The first trace task ends.
+bytrace.finishTrace("myTestFunc", 1); // The first trace task ends.
// Service flow
-bytrace.startTrace("myTestFunc", 1); // The second trace task starts after the first task ends. The two tasks have the same name and task ID.
+bytrace.startTrace("myTestFunc", 1); // The second trace task starts after the first task ends. The two tasks have the same name and task ID.
// Service flow
bytrace.finishTrace("myTestFunc", 1);
```
-
## bytrace.traceByValue
traceByValue(name: string, count: number): void
-Defines the variable that indicates the number of timeslice trace tasks.
+Defines a numeric variable that indicates the number of timeslice trace tasks.
**System capability**: SystemCapability.HiviewDFX.HiTrace
**Parameters**
| Name| Type| Mandatory| Description|
| -------- | -------- | -------- | -------- |
-| name | string | Yes| Name of the variable.|
-| count | number | Yes| Value of the variable.|
+| name | string | Yes| Name of the numeric variable.|
+| count | number | Yes| Value of the numeric variable.|
**Example**
- ```js
+```js
let traceCount = 3;
bytrace.traceByValue("myTestCount", traceCount);
traceCount = 4;
diff --git a/en/application-dev/reference/apis/js-apis-http.md b/en/application-dev/reference/apis/js-apis-http.md
index 47030e85deb6c615116c150e8c3a7c0525b772d7..8b6e6495c919bba52e0d3ce05c0e1675b493fa8f 100644
--- a/en/application-dev/reference/apis/js-apis-http.md
+++ b/en/application-dev/reference/apis/js-apis-http.md
@@ -64,6 +64,9 @@ httpRequest.request(
);
```
+> **NOTE**
+> If the data in **console.info()** contains a newline character, the data will be truncated.
+
## http.createHttp
createHttp(): HttpRequest
@@ -97,7 +100,7 @@ request(url: string, callback: AsyncCallback\):void
Initiates an HTTP request to a given URL. This API uses an asynchronous callback to return the result.
> **NOTE**
-> This API supports only transfer of data not greater than 5 MB.
+> This API supports only receiving of data not greater than 5 MB.
**Required permissions**: ohos.permission.INTERNET
@@ -148,7 +151,7 @@ request(url: string, options: HttpRequestOptions, callback: AsyncCallback\ **NOTE**
-> This API supports only transfer of data not greater than 5 MB.
+> This API supports only receiving of data not greater than 5 MB.
**Required permissions**: ohos.permission.INTERNET
@@ -234,7 +237,7 @@ request(url: string, options? : HttpRequestOptions): Promise\
Initiates an HTTP request containing specified options to a given URL. This API uses a promise to return the result.
> **NOTE**
-> This API supports only transfer of data not greater than 5 MB.
+> This API supports only receiving of data not greater than 5 MB.
**Required permissions**: ohos.permission.INTERNET
@@ -330,7 +333,7 @@ Destroys an HTTP request.
httpRequest.destroy();
```
-### on('headerReceive')
+### on('headerReceive')(deprecated)
on(type: 'headerReceive', callback: AsyncCallback\