diff --git a/README.md b/README.md index 6c9a52cea4cfa7aafa1d5bcdb6125c3a6201e2c5..7cc9907a35f131a5b7a37432316e894b8dae144c 100644 --- a/README.md +++ b/README.md @@ -31,3 +31,15 @@ This repository stores device and application development documents provided by OpenHarmony_v1.x_release: OpenHarmony v1.1.4 LTS. [Learn more](en/release-notes/OpenHarmony-v1-1-4-LTS.md) [More versions](en/release-notes/) + +## Third-Party Open-Source Software and License Notice + +Third-party license: [Third-Party Open-Source Software and License Notice](en/contribute/third-party-open-source-software-and-license-notice.md) + +## How to Contribute + +A great open-source project wouldn't be possible without the hard work of many contributors. We'd like to invite anyone from around the world to [participate](en/contribute/how-to-contribute.md) in this exciting journey, and we're grateful for your time, passion, and efforts! + +You can evaluate available documents, make simple modifications, provide feedback on document quality, and contribute your original content. For details, see [Documentation Contribution](en/contribute/documentation-contribution.md). + +Excellent contributors will be awarded and the contributions will be publicized in the developer community. \ No newline at end of file diff --git a/en/compatibility/readme.md b/en/compatibility/readme.md deleted file mode 100644 index 0db68d75ec7e941c5b6f0c7c8e3459c0b52a1749..0000000000000000000000000000000000000000 --- a/en/compatibility/readme.md +++ /dev/null @@ -1 +0,0 @@ -Todo diff --git a/en/contribute/Readme-EN.md b/en/contribute/Readme-EN.md index d4e6b9c01b01c1184bd496f04183b6e94245af9b..24fcbe6d10db5ead1172a88577af8523330e2f1e 100755 --- a/en/contribute/Readme-EN.md +++ b/en/contribute/Readme-EN.md @@ -4,7 +4,7 @@ - [Code of Conduct](code-of-conduct.md) - [Code Contribution](code-contribution.md) - [Contribution Process](contribution-process.md) -- [Auto-Test](../readme/test_subsystem.md) +- [Auto-Test](../readme/test.md) - [Documentation Contribution](documentation-contribution.md) - [Writing Instructions](writing-instructions.md) - [Communication in Community](communication-in-community.md) diff --git a/en/readme.md b/en/readme.md index acf52b9dab04b7dad49653def6426f48b085a071..e220bd152b32ff7cdf34c000d283acfab619fcba 100644 --- a/en/readme.md +++ b/en/readme.md @@ -1,83 +1,13 @@ -# Overview - -This project stores OpenHarmony documentation, including the quick start guide, development guides, and API reference. We appreciate your contribution to the OpenHarmony documentation. - -## Contents - -- [OpenHarmony Overview](OpenHarmony-Overview.md) -- Device development - - Mini and Small System Development Guidelines \(Reference Memory < 128 MB\) - - Device development - - **overview**: [Device Development Overview](device-dev/Readme-EN.md) - - **quick-start**: [Quick Start](device-dev/quick-start/Readme-EN.md) \(covering environment setup, source code acquisition, build, and burning\) - - Basic development capabilities - - **Kernel**: [Kernel for Mini Systems](device-dev/kernel/kernel-mini.md) - - **Kernel：**[Kernel for Small Systems](device-dev/kernel/kernel-small.md) - - **Drivers**: [drivers](device-dev/driver/Readme-EN.md) - - **Subsystems**: [subsystems](device-dev/subsystems/Readme-EN.md) \(such as compilation and building, graphics, DFX, and XTS\) - - **Security**: [privacy and security](device-dev/security/Readme-EN.md) - - **guide**: - - [WLAN-connected Products](device-dev/guide/device-wlan.md) \(LED peripheral control and third-party SDK integration\) - - [Screenless Cameras](device-dev/guide/device-iotcamera-control.md) \(camera control\) - - [Cameras with a Screen](device-dev/guide/device-camera.md) \(screen and camera control, visual application development\) - - **porting**: - - [Third-Party Library Porting Guide for Mini and Small Systems](device-dev/porting/porting-thirdparty.md) - - [Mini System SoC Porting Guide](device-dev/porting/porting-minichip.md) - - [Small System SoC Porting Guide](device-dev/porting/porting-smallchip.md) - - **bundles**: - - [HPM Bundle Development Specifications](device-dev/bundles/bundles-standard-rules.md) - - [HPM Bundle Development Guidelines](device-dev/bundles/bundles-guide.md) - - [HPM User Guide](device-dev/bundles/bundles-demo.md) - - Standard System Development Guidelines \(Reference Memory ≥ 128 MB\) - - Device development - - **overview**: [Device Development Overview](device-dev/Readme-EN.md) - - **quick-start**: [Quick Start](device-dev/quick-start/quickstart-standard.md) \(covering environment setup, source code acquisition, build, and burning\) - - Basic development capabilities - - **Kernel**: [Kernel for the Standard System](device-dev/kernel/kernel-standard.md) - - **Drivers**: [Drivers](device-dev/driver/Readme-EN.md) - - **Subsystems**: [Subsystems](device-dev/subsystems/Readme-EN.md) \(such as compilation and building, graphics, DFX, and XTS\) - - **Security**: [Privacy and Security](device-dev/security/Readme-EN.md) - - **guide**: - - [Development Guidelines on Clock Apps](device-dev/guide/device-clock-guide.md) - - [Development Example for Platform Drivers](device-dev/guide/device-driver-demo.md) - - [Development Example for Peripheral Drivers](device-dev/guide/device-outerdriver-demo.md) - - **porting**: - - [Standard System SoC Porting Guide](device-dev/porting/standard-system-porting-guide.md) - - [A Method for Rapidly Porting the OpenHarmony Linux Kernel ](device-dev/porting/porting-linux-kernel.md) - - **bundles**: - - [HPM Bundle Development Specifications](device-dev/bundles/bundles-standard-rules.md) - - [HPM Bundle Development Guidelines](device-dev/bundles/bundles-guide.md) - - [HPM User Guide](device-dev/bundles/bundles-demo.md) - - [FAQs](device-dev/faqs/Readme-EN.md) - - -- App development - - **Overview**: [Application Development Overview](application-dev/application-dev-guide.md) - - **quick-start**: [Quick Start](application-dev/quick-start/Readme-EN.md) - - **ui**: [UI](application-dev/ui/Readme-EN.md) - - **media**: [Media](application-dev/media/Readme-EN.md) - - **security**: [Security](application-dev/security/Readme-EN.md) - - **connectivity**: [Connectivity](application-dev/connectivity/Readme-EN.md) - - **Database**：[Data Management](application-dev/database/Readme-CN.md) - - **usb**: [USB Service](application-dev//usb/Readme-EN.md) - - **dfx**: [DFX](application-dev/dfx/Readme-EN.md) - - **reference**: [Development References](application-dev/reference/Readme-EN.md) -- **glossary**: [Glossary](glossary.md) - -## Version Change History - -For details, see [OpenHarmony Release Notes](release-notes/Readme.md). - -## Third-Party Open-Source Software and License Notice - -3rd-Party-License: [Third-Party Open-Source Software and License Notice](contribute/third-party-open-source-software-and-license-notice.md) - - -## How to Contribute - -A great open-source project wouldn't be possible without the hard work of many contributors. We'd like to invite anyone from around the world to [participate](en/contribute/how-to-contribute.md) in this exciting journey, and we're grateful for your time, passion, and efforts! - -You can evaluate available documents, make simple modifications, provide feedback on document quality, and contribute your original content. For details, see [Documentation Contribution](en/contribute/documentation-contribution.md). - -Excellent contributors will be awarded and the contributions will be publicized in the developer community. +# OpenHarmony Documentation + +This repository stores a complete range of OpenHarmony documentation. The content outline is as follows: + +- OpenHarmony Development + - [Device Development](device-dev/Readme-EN.md) + - [Application Development](application-dev/Readme-EN.md) + - [Release Notes](release-notes/Readme.md) + - [Subsystems](./readme) +- OpenHarmony Contribution + - [Contribution Guide](contribute/contribution-guide.md) + - [OpenHarmony Part and API Design Reference](./design) diff --git a/en/readme/compilation-and-building.md b/en/readme/compilation-and-building.md new file mode 100644 index 0000000000000000000000000000000000000000..e4493c817ba1fd1092cc21f8ac7f875d99379607 --- /dev/null +++ b/en/readme/compilation-and-building.md @@ -0,0 +1,57 @@ +# Compilation and Building + + +The compilation and building subsystem provides a framework based on Generate Ninja (GN) and Ninja. This subsystem allows you to: + +- Build products based on different chipset platforms, for example, Hi3516D V300. + +- Package capabilities required by a product by assembling modules based on the product configuration. + +## Basic Concepts + +It is considered best practice to learn the following basic concepts before you start building: + +- Platform + + A combination of development boards and kernels. Supported subsystems and components vary with the platform. + +- Subsystem + + OpenHarmony is designed with a layered architecture, which consists of the kernel layer, system service layer, framework layer, and application layer from the bottom up. System functions are developed by the level of system, subsystem, and component. In a multi-device deployment scenario, you can customize subsystems and components as required. A subsystem is a logical concept and is a flexible combination of components. + +- Component + + A component is a reusable software unit that contains source code, configuration files, resource files, and build scripts. A component can be built independently, integrated in binary mode, and then tested independently. + +- GN + + GN is a system used to generate build files for Ninja. + +- Ninja + + Ninja is a small high-speed build system. + + +## Working Principles + +The compilation and build process of OpenHarmony is as follows: + +- Parsing commands: Parse the name of the product to build and load related configurations. +- Running GN: Configure the toolchain and global options based on the parsed product name and compilation type. +- Running Ninja: Start building and generate a product distribution. + +## Building a Mini or Small System + +See [build\_lite](https://gitee.com/openharmony/build_lite/blob/master/README.md). + +## Building a Standard System + +See the readme of the **build** repository. + +## Repositories Involved + +**Compilation and building** + +[build\_lite](https://gitee.com/openharmony/build_lite) + +[build](https://gitee.com/openharmony/build) diff --git a/en/readme/customization.md b/en/readme/customization.md new file mode 100644 index 0000000000000000000000000000000000000000..4faad8762156022841a41318ab302bcddd4ae436 --- /dev/null +++ b/en/readme/customization.md @@ -0,0 +1,66 @@ +# Customization + +## Introduction + +When you develop OpenHarmony devices or applications for specific industries or regions, you may need to customize the system to meet the requirements of specific scenarios. This is where the customization subsystem comes into the picture. This subsystem provides enterprise device management and policy configuration. + +| Module Name | Description | +| :--------------: | ------------------------------------------------------------ | +| Config Policy Kit | Provides APIs for service modules to obtain the configuration directory or configuration file path at different configuration levels.| +| EnterpriseDeviceManagement Kit| Provides the management application development framework, management mode setting, and enterprise device management capabilities for developing Mobile Device Management (MDM) applications. You can leverage the system-level management APIs for your applications in the enterprise context.| + + + +## System Architecture + +**Figure 1** Customization subsystem + + +![](figures/customization-subsystem.png) + + +- Application layer + + System applications, extended applications, and third-party applications invoke interfaces at the interface layer to configure functions or obtain specific data. + +- Interface layer + + The EnterpriseDeviceManagement Kit provides system-level management APIs for applications in the enterprise context. The Config Policy Kit provides APIs for service modules to obtain the configuration directory or configuration file path at different configuration levels. + +- Service layer + + EnterpriseDeviceManagerService provides specific implementation capabilities for EnterpriseDeviceManagement Kit at the interface layer to help ensure normal service running. + +## Directory Structure + +The source code of the Customization subsystem is stored in **/base/customization**. The directory structure is as follows: + +``` +/base/customization/ +├── config_policy # Code repository of the Config Policy Kit +│ ├── frameworks # Core code of the Config Policy Kit +│ │ ├── config_policy # Module of the Config Policy Kit +│ │ │ └── src # Implementation code +│ ├── interfaces # Interfaces of the Config Policy Kit +│ │ ├── inner_api # Interfaces between Config Policy Kit subsystems +│ │ └── kits # JavaScript interfaces of the Config Policy Kit +│ └── test # Test code +├── enterprise_device_management # Code repository of the EnterpriseDeviceManagement Kit +│ ├── common # Common code +│ ├── etc # Configuration files of the processes contained in the EnterpriseDeviceManagement Kit +│ ├── interfaces # EdmKits code +│ │ └── inner_api # Subsystem interfaces +│ │ └── kits # Developer interfaces +│ ├── profile # Configuration files of the system services contained in the EnterpriseDeviceManagement Kit +│ └── services # Code for implementing the EnterpriseDeviceManagement Kit +``` + +## Repositories Involved + +**Customization** + +[customization_config_policy](https://gitee.com/openharmony/customization_config_policy) + +[customization_enterprise_device_management](https://gitee.com/openharmony/customization_enterprise_device_management) + +[applications_admin_provisioning](https://gitee.com/openharmony/applications_admin_provisioning) diff --git a/en/readme/development-toolchain.md b/en/readme/development-toolchain.md new file mode 100644 index 0000000000000000000000000000000000000000..ecff66ed87e2f4630342fc4ea8f9186b2025bed7 --- /dev/null +++ b/en/readme/development-toolchain.md @@ -0,0 +1,336 @@ +# Development Toolchain + + + +## Introduction + +The development toolchain subsystem provides debugging commands and tools for performance monitoring and tracing. + +This subsystem provides the following tools: + +- bytrace: a tool for you to trace processes and monitor performance. It encapsulates and extends the ftrace inside the kernel and supports tracing in the user space. +- hdc: a command line tool for debugging. With hdc, you can interact with real devices or simulators from Windows, Linux, or macOS. +- profiler: a performance profiling platform for you to analyze memory and performance issues. + +## Architecture + +The figure below shows the architecture of the development toolchain subsystem. + +**Figure 1** Architecture of the development toolchain subsystem + + +![](figures/development_toolchain_architecture.png) + +## Directory Structure + +``` +/developtools # Development toolchain subsystem +├── bytrace_standard # bytrace code +│ └── bin # bytrace function implementation +│ └── innerkits # Header files for internal subsystems +├── hdc_standard # hdc code +│ └── src # hdc function implementation +│ └── prebuilt # Prebuilt code +├── profiler # Profiler code +│ └── device # Device code +│ └── host # Host code +│ └── interfaces # APIs between modules and external APIs +│ └── trace_analyzer # bytrace analyzer code +│ └── protos # proto files +``` + +## Usage + +### bytrace + +The table below lists the commands supported by bytrace. + +**Table 1** Commands supported by bytrace + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Option

+

Description

+

-h, --help

+

Displays help information.

+

-b n, --buffer_size n

+

Sets n KB of memory for storing trace logs. The default value is 2 MB.

+

-t n, --time n

+

Sets the trace uptime, in seconds. The value varies depending on the time required for analysis.

+

--trace_clock clock

+

Sets the type of the clock for adding a timestamp to a trace. The value can be boot (default), global, mono, uptime, or perf.

+

--trace_begin

+

Starts trace.

+

--trace_dump

+

Dumps traced data to a specified position (console by default).

+

--trace_finish

+

Stops trace and outputs data to the specified position (console by default).

+

-l, --list_categories

+

Lists the bytrace categories supported by the device.

+

--overwrite

+

Overwrites the latest information when the buffer is full. By default, the earliest data is overwritten.

+

-o filename, --output filename

+

Outputs traced data to a specified file.

+

-z

+

Compresses the traced data.

+
+ +Examples: + +- Query supported labels. + + ``` + bytrace -l + Or + bytrace --list_categories + ``` + + +- Trace ability information for 10 seconds and store the traced data in a buffer of 4 MB. + + ``` + bytrace -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace + ``` + + +- Set the clock type for traces to mono. + + ``` + bytrace --trace_clock mono -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace + ``` + + +- Compress the traced data. + + ``` + bytrace -z -b 4096 -t 10 --overwrite ability > /data/mytrace.ftrace + ``` + +### hdc + +The table below lists the commands supported by hdc. + +**Table 2** Commands supported by hdc + + + + + + + + + + + + + +The + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Option

+

Description

+

-t key

+

Specifies the identifier of the device to connect.

+

-s socket

+

Specifies the listening socket.

+

-h/help -v/version

+

Displays the hdc help and version information.

+

list targets[-v]

+

Displays all connected devices.

+

target mount

+

Mounts the system partition in read/write mode.

+

target boot [bootloader|recovery]

+

Restarts a target device. The system is started by default. The bootloader and recover modes are supported.

+

smode [off]

+

Grants the root permission to the background hdc service. You can use the off option to revoke the granted permissions.

+

kill

+

Terminates the hdc service.

+

tconn host[:port][-remove]

+

Connects to the device with the specified IP address and port number.

+

tmode usb

+

Restarts the daemon process of the device and connects to the device through USB preferentially.

+

tmode port port-number

+

Restarts the daemon process of the device and connects to the device over TCP preferentially. If the TCP connection fails, try a USB connection.

+

fport local remote -b

+

Adds a port relay connection.

+

fport list

+

Lists all relay connections.

+

fport rm local

+

Deletes the relayed local connection. If no parameter is specified, all connections will be deleted.

+

file send local remote

+

Sends a file to a remote device.

+

file recv [-a] remote local

+

Sends a file from a remote device to the local device.

+

app install [-r/-d/-g] package

+

Installs an OpenHarmony app.

+

app install-multiple [-rdg] --hap path

+

Installs all OpenHarmony apps in the specified directory.

+

app uninstall [-k] package

+

Uninstalls the specified OpenHarmony app.

+

hilog

+

Obtains log information.

+

bugreport [PATH]

+

Captures bug report information.

+

shell [command]

+

Runs a command remotely or enters the interactive command environment.

+
+ +Examples: + +- Send a file to a remote device. + + ``` + hdc file send E:\c.txt /sdcard + ``` + +- Restart a device. + + ``` + hdc target boot + ``` + + +- Obtain log information. + + ``` + hdc hilog + ``` + +- Enter the interactive command mode: + + ``` + hdc shell + ``` + +- Set the listening socket. + + ``` + hdc -s 192.168.1.100:1234 + ``` + + +- Restart the device in bootloader mode. + + ``` + hdc target boot bootloader + ``` + +- Connect to the device with a specified IP address and port number. + + ``` + hdc tconn 192.168.0.100:8710 + ``` + + +### profiler + +The profiler module consists of the system and application profiler frameworks. It provides a performance profiler platform for you to analyze system issues related to the memory and performance. + +The profiler module provides the following capabilities: + +- Capabilities for the PC: The capabilities are released as a DevEco Studio plug-in, which contains UI drawing, device management, process management, plug-in management, data import, data storage, data analysis, session management, and configuration management. +- Capabilities for the device: The capabilities include the command line tool, service processes, plug-ins, and application components. The device-side profiler provides APIs for extending plug-ins. With these APIs, you can define capabilities and integrate them into the framework. Currently, the real-time memory analysis and trace plug-ins are available. For details, see the profiler readme. + +## Repositories Involved + +**Development Toolchain Subsystem** + +[developtools\_hdc\_standard](https://gitee.com/openharmony/developtools_hdc_standard) + +[developtools\_bytrace\_standard](https://gitee.com/openharmony/developtools_bytrace_standard) + +[developtools\_profiler](https://gitee.com/openharmony/developtools_profiler) diff --git a/en/readme/driver-subsystem.md b/en/readme/driver.md similarity index 100% rename from en/readme/driver-subsystem.md rename to en/readme/driver.md diff --git a/en/readme/figures/customization-subsystem.png b/en/readme/figures/customization-subsystem.png new file mode 100644 index 0000000000000000000000000000000000000000..0e6cbf453628d48ae18423af0a9489f46f96d370 Binary files /dev/null and b/en/readme/figures/customization-subsystem.png differ diff --git a/en/readme/figures/development_toolchain_architecture.png b/en/readme/figures/development_toolchain_architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..bd816833f678acb416958c45ff43c66c69e66c9f Binary files /dev/null and b/en/readme/figures/development_toolchain_architecture.png differ diff --git a/en/readme/figures/en_architecture-of-netmanager-subsystem.png b/en/readme/figures/en_architecture-of-netmanager-subsystem.png new file mode 100644 index 0000000000000000000000000000000000000000..426e1360e245a115219fe6666c67fc0b26fed0c1 Binary files /dev/null and b/en/readme/figures/en_architecture-of-netmanager-subsystem.png differ diff --git a/en/readme/figures/security_subsustem_architecture.png b/en/readme/figures/security_subsustem_architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..2e2b7e577f4f3ab9729a7cfc37b440acd964579d Binary files /dev/null and b/en/readme/figures/security_subsustem_architecture.png differ diff --git a/en/readme/netwowk-management.md b/en/readme/netwowk-management.md new file mode 100644 index 0000000000000000000000000000000000000000..13dc0951936c47a6fd440f46b06536c0e996f5f7 --- /dev/null +++ b/en/readme/netwowk-management.md @@ -0,0 +1,127 @@ +# Network Management + + +## Introduction + +As a mandatory component for device networking, the network management subsystem manages different types of network connections in a unified manner and provides network protocol stack capabilities. An application can call APIs to obtain connection information of a data network, query and subscribe to connection status, and transfer data by using the network protocol stack. + +The network management subsystem consists of the following components: + +- Basic network connection management component: provides basic network connection management and corresponding JavaScript and native APIs to implement functions, such as managing network connection priorities, querying network connection information, observing network connection status changes, performing DNS resolution, and managing physical networks. +- Network protocol stack component: provides basic network protocol stacks including HTTP, HTTPS, TCP, and UDP stacks, and corresponding JavaScript APIs. + +**Figure 1** System architecture + +![](figures/en_architecture-of-netmanager-subsystem.png) + +## Directory Structure + +``` +foundation/communication/ +├── netmanager_base # Basic network connection management +└── netstack # Network protocol stacks +``` + +## Usage + +### Receiving Network Status Change Notifications + +1. Import the **connection** namespace from **@ohos.net.connection.d.ts**. + +2. Call **createNetConnection()** to create a **NetConnection object**. You can specify the network capability, network type, and timeout interval (optional). + +3. Call the **on()** method of the object to subscribe to concerned events by specifying **type** and **callback**. + +4. Call the **register()** method of the object to subscribe to status change notifications of the specified network. + +5. When the network is available, the callback will be invoked to return the **netAvailable** event. + +6. Call the **unregister()** method of the object to unsubscribe from the notifications if required. + + ``` + // Import the package name. + import connection from '@ohos.net.connection' + + let netCap = { + // Set the network type to cellular network. + bearerTypes: [connection.NetBearType.BEARER_CELLULAR], + // Set the network capability to Internet. + networkCap: [connection.NetCap.NET_CAPABILITY_INTERNET], + }; + let netSpec = { + netCapabilities: netCap, + }; + // Set the timeout interval to 10s. + let timeout = 10 * 1000; + // Create a NetConnection object. + let conn = connection.createNetConnection(netSpec, timeout); + // Subscribe to on_netAvailable events. + conn.on('netAvailable', (data=> { + console.log("net is available, netId is " + data.netId); + })); + // Register a listener for network status changes. + conn.register((err, data) => {}); + // When the network is not used, call the unregister method to cancel the subscription. + conn.unregister((err, data) => {}); + ``` + + +### Sending a Network Request + +1. Import the **http** namespace from **@ohos.net.http.d.ts**. +2. Call the **createHttp** method to create an **HttpRequest** object. +3. Call the **on()** method of the object to subscribe to the HTTP response header. This method returns a response earlier than the request. You can subscribe to HTTP Response Header events based on service requirements. +4. Call the **request()** method of the object with the URL and optional parameters of the HTTP request to initiate a network request. +5. Parse the returned result based on service requirements. +6. Call the **destroy()** method to destroy the request. + +``` +// Import the package name. +import http from '@ohos.net.http'; + +// Each httpRequest corresponds to an HttpRequestTask object and cannot be reused. +let httpRequest = http.createHttp(); +// Subscribe to the HTTP response header, which is returned earlier than httpRequest. You can subscribe to HTTP Response Header events based on service requirements. +httpRequest.on('headersReceive', (data) => { + console.info('header: ' + data.header); +}); +httpRequest.request( + // Set the URL of the HTTP request. You need to define the URL. Set the parameters of the GET request in extraData. + "EXAMPLE_URL", + { + method: 'POST', // Optional. The default value is GET. + // You can add the header field based on service requirements. + header: { + 'Content-Type': 'application/json' + }, + // This field is used to transfer data when the POST request is used. + extraData: { + "data": "data to send", + }, + connectTimeout: 60000, // Optional. The default value is 60 seconds. + readTimeout: 60000, // Optional. The default value is 60 seconds. + },(err, data) => { + if (!err) { + // data.result contains the HTTP response. Parse the response based on service requirements. + console.info('Result:' + data.result); + console.info('code:' + data.responseCode); + // data.header contains the HTTP response header. Parse the content based on service requirements. + console.info('header:' + data.header); + console.info('header:' + data.cookies); + } else { + console.info('error:' + err); + } + // Call the destroy() method to release resources after the call is complete. + httpRequest.destroy(); + } +); +``` + + +## Repositories Involved + +**Network Management Subsystem** + +[communication_netmanager_base](https://gitee.com/openharmony/communication_netmanager_base/blob/master/README_zh.md) + +[communication_netstack](https://gitee.com/openharmony/communication_netstack/blob/master/README_zh.md) diff --git a/en/readme/security.md b/en/readme/security.md new file mode 100644 index 0000000000000000000000000000000000000000..ad2f1c556a4c9f99324124c17b4c9f0c92d965a2 --- /dev/null +++ b/en/readme/security.md @@ -0,0 +1,88 @@ +# Security + + +## Introduction + +The security subsystem provides system, data, and application security capabilities to protect system and user data of OpenHarmony. + +It implemens application integrity verification, application permission management, device authentication, OpenHarmony Universal KeyStore (HUKS) key management, and data transfer management. + +## Architecture + +**Figure 1** Security subsystem architecture + +![](figures/security_subsustem_architecture.png) + +The security subsystem consists of the following functional modules: + +- Interface layer: provides APIs to developers, some of which are only available for system applications + +- Application permission management: implements permission management for the application framework subsystem and provides APIs for applications to request permissions and query the permission granting status. + +- Application integrity verification: verifies application integrity during application signing and installation. +- Device authentication: provides key agreement and trusted device management capabilities for interconnections between devices in a distributed network. + +- HUKS key management: provides the key management service for basic device authentication. + +- Data transfer management: provides API definitions related to data transfer management and control. + +## Directory Structure + +``` +/base/security +├── appverify # Application integrity verification +├── dataclassification # Data transfer management +├── device_auth # Device authentication +├── huks # HUKS key management +└── permission # Permission management +``` + +## Constraints + +- In the current version, application permission management is available only for local applications. (The stub mode is used for joint commissioning of upper-layer distributed services.) +- Device authentication includes authentication for devices with the same account and peer-to-peer device authentication. Currently, only the latter is available. (The stub mode is used for joint commissioning of upper-layer distributed services.) +- OpenHarmony-specific certificates are used for application integrity verification. The corresponding public key certificates and private keys are preset in the open-source code repositories of OpenHarmony to provide offline signing and verification capabilities for the open-source community. The public key certificates and the corresponding private keys need to be replaced in commercial versions that are based on OpenHarmony. + +## Usage + +#### 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. + +Application permission management provides a mechanism for defining permissions, allowing system services and applications to define new permissions for their sensitive APIs. To access these APIs, other applications need the required permissions. + +Application permission management also allows applications to request permissions that are defined by the system or other applications. Upon obtaining the permissions, applications can access the sensitive APIs provided by the system or other applications. + +In addition, application permission management allows users to view and manage the permission granting status. + +#### 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. + +After developing an application and generating the installation package during the application development process, you must sign the installation package to prevent it from being tampered with when released on devices. The OpenHarmony application integrity verification module provides the signing tool, specifications for generating the signing certificate, and required public key certificate for you to sign the application packages. A public key certificate and a corresponding private key are preset in OpenHarmony to ease your operation. You need to replace the public key certificate and private key in your commercial version of OpenHarmony. + +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 + +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: + +- Building and maintaining unified trust relationship for a group of devices using different accounts + + Devices with different accounts can set up a local trust group after a trust relationship is built by certain means such as scanning a QR code. Services can call APIs to query the group information. + +- Implementing unified device authentication + + A unified authentication solution is provided to discover devices and perform connection authentication and key agreement for encrypted, end-to-end sessions through DSoftBus for the devices in a trust group. + +HUKS provides credentials for device authentication and algorithms for key agreement protocols. + +#### 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. + +## Repositories Involved + +Security subsystem + +base/security diff --git a/en/release-notes/Readme.md b/en/release-notes/Readme.md index bbb73e4020aaeab4a89b496c9838e6a9771ba2bd..6108fb738d624a487f3eb716283d46948eae5130 100644 --- a/en/release-notes/Readme.md +++ b/en/release-notes/Readme.md @@ -2,7 +2,7 @@ ## OpenHarmony 3.x Releases - [OpenHarmony v3.1 Release (2022-03-30)](OpenHarmony-v3.1-release.md) - [OpenHarmony 3.1 Beta (2021-12-31)](OpenHarmony-v3.1-beta.md) -- [OpenHarmony 3.0.2 LTS (2022-01-12)](OpenHarmony-v3.0.2-LTS.md) +- [OpenHarmony 3.0.2 LTS (2022-03-18)](OpenHarmony-v3.0.2-LTS.md) - [OpenHarmony 3.0.1 LTS (2022-01-12)](OpenHarmony-v3.0.1-LTS.md) - [OpenHarmony 3.0 LTS (2021-09-30)](OpenHarmony-v3.0-LTS.md)