@@ -148,19 +148,19 @@ The following example shows how to implement a distributed data object synchroni
8. Subscribe to the status (online/offline) changes of the distributed data object. A callback will be invoked to report the status change when the target distributed data object goes online or offline.
9. Unsubscribe from the status changes of the distributed data object. You can specify the callback to unsubscribe from. If you do not specify the callback, all status change callbacks will be unsubscribe from.
The sample code is as follows:
```js
// Unsubscribe from changeCallback.
local_object.off("status",changeCallback);
// unsubscribe from all status change callbacks.
The sample code is as follows:
```js
// Unsubscribe from statusCallback.
local_object.off("status",statusCallback);
// Unsubscribe from all status change callbacks.
local_object.off("status");
```
10. Remove a distributed data object from the synchronization network. After the distributed data object is removed from the network, the data changes on the local end will not be synchronized to the remote end.
@@ -253,7 +253,7 @@ The HDF-based driver development involves driver implementation and configuratio
>
> If **preload** is set to **1 (DEVICE_PRELOAD_ENABLE_STEP2)**, the driver is loaded after a quick start is complete. If the system does not support quick start, the value **1** has the same meaning as **DEVICE_PRELOAD_ENABLE**.
>
> If **preload** is set to **2 (DEVICE_PRELOAD_DISABLE)** , the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service, the HDF attempts to dynamically load the driver if the driver service does not exist. For more details, see [Driver Message Mechanism Management](driver-hdf-message-management.md).
> If **preload** is set to **2 (DEVICE_PRELOAD_DISABLE)** , the driver is dynamically loaded instead of being loaded during the system boot process. When a user-mode process requests the driver service, the HDF attempts to dynamically load the driver if the driver service does not exist. For more details, see [Driver Messaging Mechanism](driver-hdf-message-management.md).
>
> - Sequential loading (**preload** set to **0 (DEVICE_PRELOAD_ENABLE)**)<br/>
> In the configuration file, the **priority** fields (value range: 0 to 200) determines the loading sequence of a host and a driver. For drivers in different hosts, a smaller host priority value indicates a higher driver loading priority; for drivers in the same host, a smaller driver priority value indicates a higher driver loading priority.
The Hardware Driver Foundation \(HDF\) provides the following driver framework capabilities: driver loading, driver service management, and driver message mechanism. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you can perform one-time development and multi-system deployment.
The Hardware Driver Foundation (HDF) provides driver framework capabilities including driver loading, driver service management, and driver messaging mechanism. It strives to build a unified driver architecture platform to provide a more precise and efficient development environment, where you can perform one-time development for multi-device deployment.
Both on-demand loading and sequential loading are supported.
- On-demand loading
## Driver Loading
Drivers can be loaded by default during the operating system \(OS\) startup or be loaded dynamically after the OS startup.
The HDF supports the following loading modes:
- Sequential loading
- On-demand loading
The driver is loaded by default during the operating system (OS) boot process or dynamically loaded after OS is started.
Drivers can be loaded based on their priorities during the OS startup.
- Sequential loading
The driver is loaded based on its priority during the OS boot process.
## Driver Service Management<a name="section12453133414412"></a>
## Driver Service Management
The HDF centrally manages driver services. You can directly obtain a specified driver service by using the API provided by the HDF.
The HDF allows centralized management of driver services. You can obtain a driver service by using the API provided by the HDF.
# HDF Development Example<a name="EN-US_TOPIC_0000001052451677"></a>
# HDF Development Example
The following example shows how to add driver configuration, compile the driver code, and implement interaction between the user-state applications and the driver.
## Compiling the Code for Interaction<a name="section6205173816412"></a>
The following is the sample code compiled based on HDF for interaction between the driver and user-state applications. You can place the code in **drivers/adapter/uhdf** for compilation. For details about the **build.gn** file, see **drivers/framework/sample/platform/uart/dev/build.gn**.
## Implementing Interaction Between the Application and the Driver
Write the code for interaction between the user-mode application and the driver. Place the code in the **drivers/adapter/uhdf** directory for compilation. For details about **build.gn**, see **drivers/framework/sample/platform/uart/dev/build.gn**.
>The code compilation of user-state applications depends on the dynamic libraries **hdf\_core** and **osal** provided by HDF because user-state applications use the message sending interface of HDF. In the GN file, add the following dependencies:
> The user-mode application uses the message sending API of the HDF, and the compilation of the user-mode application depends on the dynamic libraries **hdf_core** and **osal** provided by the HDF. Therefore, you need to add the following dependencies to the .gn file:
The security subsystem provides system, data, and application security capabilities to protect system and user data of OpenHarmony.
Its functions include application integrity verification, application permission management, device authentication, OpenHarmony Universal KeyStore (HUKS) key management, and data transfer management.
It implemens application integrity verification, application permission management, device authentication, OpenHarmony Universal KeyStore (HUKS) key management, and data transfer management.
The security subsystem consists of the following functional modules:
...
...
@@ -45,7 +45,7 @@ The security subsystem consists of the following functional modules:
## Usage<a name="section2057642312536"></a>
**Application Permission Management**
#### Application Permission Management
In OpenHarmony, applications and system services run in independent sandboxes. Both processes and data are isolated from each other to protect the security of application data. However, services or applications running in the sandboxes provide some APIs to implement specific functionalities. To access these APIs across processes, applications in other sandboxes need the required permissions, which are granted and managed based on a permission management mechanism.
...
...
@@ -55,7 +55,7 @@ Application permission management also allows applications to request permission
In addition, application permission management allows users to view and manage the permission granting status.
**Application Integrity Verification**
#### Application Integrity Verification
OpenHarmony allows installation of applications. To ensure the integrity and trustworthiness of the applications to be installed in OpenHarmony, the applications must be signed and their signatures must be verified.
...
...
@@ -63,7 +63,7 @@ After developing an application and generating the installation package during t
In the application installation process, the OpenHarmony application framework subsystem installs applications. Upon receiving an application installation package, the application framework subsystem parses the signature of the installation package, and verifies the signature using the application integrity verification APIs. The application can be installed only after the verification is successful. During the verification, the application integrity verification module uses the preset public key certificate to verify the signature.
**Device Authentication and HUKS**
#### Device Authentication and HUKS
A unified device binding and authentication solution that covers 1+8+N devices is available. Generally, device authentication provides support for cross-device communication implemented by DSoftBus, rather than directly interacting with applications. Device authentication provides the following functionalities:
...
...
@@ -77,7 +77,7 @@ A unified device binding and authentication solution that covers 1+8+N devices i
HUKS provides credentials for device authentication and algorithms for key agreement protocols.
**Data Transfer Management**
#### Data Transfer Management
In OpenHarmony, the data transfer management module provides cross-device data transfer management and control policies for distributed services. The data transfer management module defines a sef of APIs to provide management and control policies for cross-device data transfer and obtain the highest risk level of data to be sent to the peer device.
