Skip to content

D
Docs

OpenHarmony / Docs
接近 2 年 前同步成功

通知 159
Star 292
Fork 28
D
Docs
提交 1042f045 编写于 作者: G Gloria
浏览文件
操作

replaced folders (excluding application-dev and device-dev) (en) with those in master 

Signed-off-by: wusongqing<wusongqing@huawei.com>
上级 abac74be
展开全部 隐藏空白更改
内联 并排
Showing with 10383 addition and 424 deletion
en/OpenHarmony-Overview.md
浏览文件 @ 1042f045
......@@ -146,7 +146,7 @@ The following table describes the subsystems of OpenHarmony. For details about t
## Supported Development Boards
Currently, the OpenHarmony community supports 17 types of development boards, which are listed in [Development Boards Supported](device-dev/dev-board-on-the-master.md). The following table describes three of them, which are the first three integrated into the OpenHarmony master. You can visit http://ci.openharmony.cn/dailys/dailybuilds to obtain daily builds.
Currently, the OpenHarmony community supports 22 types of development boards, which are listed in [Development Boards Supported](device-dev/dev-board-on-the-master.md). The following table describes three of them, which are the first three integrated into the OpenHarmony master. You can visit http://ci.openharmony.cn/dailys/dailybuilds to obtain daily builds.
| System Type| Board Model| Chip Model| <div style="width:200pt">Function Description and Use Case</div> | Application Scenario| Code Repository |
| -------- | -------- | -------- | -------- | -------- | -------- |
......@@ -156,11 +156,9 @@ Currently, the OpenHarmony community supports 17 types of development boards, wh
## Getting Started
- [Getting Started for Device Development](device-dev/quick-start/quickstart-ide-lite-overview.md)
- [Getting Started for Device Development](device-dev/quick-start/quickstart-overview.md)
- [Getting Started for Application Development](application-dev/quick-start/start-overview.md)
## Code Repository Addresses
OpenHarmony project: [https://gitee.com/openharmony](https://gitee.com/openharmony)
......@@ -173,6 +171,8 @@ OpenHarmony archived projects: [https://gitee.com/openharmony-retired](https://g
## OpenHarmony Documentation
[Official website](https://www.openharmony.cn/)
[Chinese version](https://gitee.com/openharmony/docs/tree/master/zh-cn)
[English version](https://gitee.com/openharmony/docs/tree/master/en)
......@@ -197,7 +197,7 @@ For details about how to contribute, see [How to contribute](contribute/how-to-c
OpenHarmony complies with Apache License Version 2.0. For details, see the LICENSE in each repository.
OpenHarmony uses third-party open-source software and licenses. For details, see [Third-Party Open-Source Software](https://gitee.com/openharmony/docs/blob/master/en/contribute/third-party-open-source-software-and-license-notice.md).
OpenHarmony uses third-party open-source software and licenses. For details, see [Open Source Software and License Notice](https://gitee.com/openharmony/docs/blob/master/en/contribute/open-source-software-and-license-notice.md).
## Contact Info
......
en/contribute/OpenHarmony-JavaScript-coding-style-guide.md
浏览文件 @ 1042f045
......@@ -170,9 +170,9 @@ function render(container, dataSource) {
#### Rule 2.3 The use of braces must comply with the following conventions:
1. If the value in the braces is empty, the value can be abbreviated as `{}` without a newline.
2. The left braces do not contain a line feed, and the left braces are followed by a line feed.
3. Line feeds before the right brace. If there is `else` or `catch` after the brace, line feeds are not required. In other cases, line feeds are required.
1. If the value in the braces is empty, the value can be abbreviated as `{}` without a line feed.
2. Do not use a line feed before the left brace, and use one after it.
3. Use a line feed before the right brace, and use one after it as long as it is not followed by `else` or `catch`.
#### Rule 2.4 Implementations of conditional and loop statements must be enclosed in braces, even if there is only one statement.
......
en/contribute/OpenHarmony-security-test-guide.md 0 → 100644
浏览文件 @ 1042f045
# OpenHarmony Security Test Guide
With reference to industry standards and best practices, this document provides specifications for security tests of the OpenHarmony project.
## Security Test Content
- Review the code of each module according to [OpenHarmony C&C++ Secure Coding Guide](OpenHarmony-c-cpp-secure-coding-guide.md) and fix all issues found in the review.
- Use the OpenHarmony gated check-in to scan your code and clear all alarms.
- Use the compilation option scanning tool to scan your binary file and ensure that the settings of all the compilation options comply with the [OpenHarmony Compilation Specifications].
- For the module that receives and processes user-mode parameters, develop gray-box and white-box fuzz testing suites according to the [Fuzz Testing Guide](https://gitee.com/openharmony/test_developertest/tree/master/libs/fuzzlib) and complete the tests.
- Use mainstream vulnerability scanning tools to scan open-source components. Ensure that all the detected vulnerabilities have been fixed according to the vulnerability management process of the community.
- Perform consistency check of the released versions, and check that the [released version images](../release-notes/Readme.md) provide the SAH-256 checksum.
- Complete the security design self-check for each module according to [OpenHarmony Security Design Specifications](OpenHarmony-security-design-guide.md). Ensure that all design issues found in the self-check have been fixed.
- Use mainstream viruses scanning software to scan software packages. Ensure that all virus detected have been removed or confirmed as false alarms.
- Search for ".cer" and ".pem" or keyword such as "PRIVATE KEY" to find the certificate key, and check that the certificate key is within the validity period and the encryption algorithm meets [encryption algorithm requirements](OpenHarmony-security-design-guide.md#3-encryption). Ensure that all certificate key issues have been resolved.
- Perform black-box fuzz testing on exposed user-mode APIs, including system service APIs, kernel driver APIs, socket APIs, and more.
>**NOTE**
>
>The preceding requirements apply to all new and inherited features.
## Security Test Completion Requirements
The mandatory security test performed before version release is complete only when:
- All the security tests mentioned in [Security Test Content](#security-test-content) are complete.
- All security issues have been closed.
## Security Test Report Template
- The security test report must contain the security test results in [Security Test Content](#security-test-content) and pending security issues.
- The version security test report is released with the entire test report of the version, instead of being released and archived separately.
en/contribute/code-contribution.md
浏览文件 @ 1042f045
......@@ -25,6 +25,9 @@ Develop, review, and test code following the OpenHarmony coding standards. Make
### Introducing Open-source Software
For details, see [Introducing Open-Source Software](introducing-open-source-software.md).
### Test Guide
[OpenHarmony Secure Test Guide](OpenHarmony-security-test-guide.md)
## Contribution Workflow
......@@ -32,7 +35,10 @@ For details, see [Contribution Process](contribution-process.md).
## Security Issue Disclosure
- [OpenHarmony Security Vulnerability Governance](https://gitee.com/openharmony/security/blob/master/en/security-process/README.md)
- [OpenHarmony Security and Disclosure Statement](https://gitee.com/openharmony/security/blob/master/en/security-process/security-disclosure.md)
- [OpenHarmony Security Vulnerability Governance](https://gitee.com/openharmony/security/blob/master/en/security-process/README.md)
- [OpenHarmony Security and Disclosure Statement](https://gitee.com/openharmony/security/blob/master/en/security-process/security-disclosure.md)
<!--no_check-->
en/contribute/license-and-copyright-specifications.md
浏览文件 @ 1042f045
......@@ -7,7 +7,7 @@ This document describes how code contributors, committers, and PMC members in th
3. Copyright and license header
## Scope
This document applies only to the OpenHarmony community. It is not applicable to the scenario where the OpenHarmony project is used by individuals or enterprises to develop their products or the scenario where third-party open-source software is introduced. For details, see [Introducing Third-Party Open-Source Software](introducing-third-party-open-source-software.md).
This document applies only to the OpenHarmony community. It is not applicable to the scenario where the OpenHarmony project is used by individuals or enterprises to develop their products or the scenario where third-party open-source software is introduced.
## Improvements and Revisions
1. This document is drafted and maintained by the OpenHarmony PMC. What you are reading now is the latest version of this document.
......
en/contribute/open-source-software-and-license-notice.md
浏览文件 @ 1042f045
# Third-Party Open-Source Software and License Notice
# Open Source Software and License Notice
The following table lists the licenses of the third-party open source software used by OpenHarmony.
......
en/design/API-Review-Template.md
浏览文件 @ 1042f045
......@@ -2,7 +2,7 @@
## Background
* API type: [Public API | Test API | HDI]
* API type: [Public API | System API | Test API | HDI]
* API requirement source:
* API usage scenario:
* Belonging subsystem:
......
en/design/OpenHarmony-API-governance.md
浏览文件 @ 1042f045
......@@ -2,9 +2,9 @@
## Introduction
To help the OpenHarmony ecosystem develop and evolve in a healthy and orderly way, this Charter defines the governance process and lifecycle (creation, change, deprecation, and deletion) of OpenHarmony APIs. It also specifies basic design requirements of OpenHarmony APIs.
To help the OpenHarmony ecosystem develop and evolve in a healthy and orderly way, this Charter defines the governance process and lifecycle (create, change, deprecate, and delete) of OpenHarmony APIs. It also specifies basic design requirements of OpenHarmony APIs.
This Charter is formulated by the API SIG and approved by the PMC for release. Any revision to this Charter will be released only after being reviewed by the API SIG and approved by the PMC.
This Charter is formulated by the [API SIG](https://www.openharmony.cn/SIG/api/) and approved by the [PMC](https://www.openharmony.cn/community/pmc/) for release. Any revision to this Charter will be released only after being reviewed by the API SIG and approved by the PMC.
## Overview
......@@ -12,23 +12,23 @@ This Charter is formulated by the API SIG and approved by the PMC for release. A
The OpenHarmony software stack contains multiple roles. Naturally, OpenHarmony APIs have multiple types.
<img src="figures/API-Category.png" width="800" />
![](figures/API-Category.png)
Different types of APIs have different compatibility requirements, as described in the table below.
| Type | Prepared By | Used By | Compatibility Requirement | Guarding Method |
|--- |--- |--- |--- |--- |
| Public API | System and framework | All application developers | Five API versions | X test suite (XTS) |
| Test API | Test framework | All application developers | Three API versions | To be built |
| System API | System and framework |System application developers |Not guaranteed | To be built |
| HDI | HDF | System services | Four API versions | XTS |
| Driver API | HDF | Driver developers | Not guaranteed | None |
| Inner API | System parts | System parts | Not guaranteed | None |
| Type| Prepared By| Used By| Compatibility Requirement| Guarding Method|
|---|---|---|---|---|
| Public API | System and framework| All application developers| 5 API versions| X test suite (XTS)|
| Test API | Test framework | All application developers| 3 API versions| To be built|
| System API | System and framework|System application developers|Not guaranteed| To be built|
| HDI | HDF| System services| 4 API versions| X test suite (XTS)|
| Driver API | HDF | Driver developers| Not guaranteed| None|
| Inner API | System parts| System parts| Not guaranteed| None|
The APIs are described as follows:
* Public API: APIs provided for all application developers.
* Test API: APIs provided for developers to test their applications.
* Test API: APIs used for testing. They can be used only in the test phase.
* System API: APIs provided for privileged system applications. Common applications cannot use these APIs.
* HDI: APIs that describe hardware capabilities.
* Driver API: APIs provided for driver developers.
......@@ -41,6 +41,7 @@ OpenHarmony aims to build a next-generation Operating System (OS) for the Intern
* C/C++
* JavaScript
* TypeScript
* ArkTS
The content described in this Charter is irrelevant to the programming language in use. Regardless of the programming language, APIs must comply with this Charter while meeting the programming language requirements.
......@@ -48,25 +49,25 @@ The content described in this Charter is irrelevant to the programming language
### Roles and Responsibilities
| Role | Responsibilities in API Governance |
| --- | --- |
| Contributor | Commit API code and design documents. |
| Committer | Review the code and submit a pre-review comment on an API commit. |
| Domain SIG | Comment on the commits of new API code, so the passed commits can be merged. <br/>Submit a pre-review comment on updated API code. |
| API SIG | Comment on updated API code. |
| PMC | Release API version plans. Review amendments of this Charter, revise the terms, and publish this Charter. |
|**Role**|**Responsibilities in API Governance**|
| - | - |
|Contributor|Commit API code and design documents.|
|Committer|Review the code and submit a pre-review comment on an API commit.|
|Domain SIG| Comment on the commits of new API code, so the passed commits can be merged.<br>Provide pre-review comments on updated API code.|
|API SIG|Comment on updated API code.|
|PMC|Release API version plans. Review amendments of this Charter, revise the terms, and publish this Charter.|
### API Review Process
The API review process is as follows:
<img src="figures/API-Workflow.png" width="800" />
![](figures/API-Workflow.png)
The main process is as follows:
1. Initiate API review and commit code (contributor). If any APIs are added or modified, the contributor must additionally submit an API review application to specify the API requirement source, usage scenario, permission design, and privacy protection design. For details, see "API Review Application Composites" below. To avoid rework, the contributor can send an email to submit the API design document to the committer, domain SIG, and API SIG for pre-review before the formal API review application and code commit.
1. Review code (committer). After the code review is approved, the committer should submit the APIs to the domain SIG. If the API code involves multiple domains, they should be submitted to the committers of the corresponding domains. The next review step can be performed only after all committers review and approve the code.
1. Review APIs (domain SIG). The code of new APIs can be merged only after being reviewed and approved by the domain SIG. If there are changes to existing APIs, the domain SIG should submit them to the API SIG. If the new APIs involve multiple domains, they should be submitted to the SIGs of the corresponding domains. The code can be merged after being reviewed and approved by one of the domain SIGs. If the changed APIs involve multiple domains, they should be submitted to the SIGs of the corresponding domains. The next review step can be performed only after all domain SIGs approve the APIs.
1. Review API changes (API SIG). The code of changed APIs can be merged only after being reviewed and approved by the API SIG.
1. Review API changes (owner: API SIG): The code of changed APIs can be merged only after being reviewed and approved by the API SIG.
1. The review is complete.
### API Review Application Composites
......@@ -87,75 +88,11 @@ For changed APIs, except the preceding operations, you must:
2. (Mandatory) Describe the change impact, substitute APIs, and corresponding application adaptation solution.
3. (Mandatory) Update the ChangeLog file. Update the API-diff file (Mandatory if JS or native API changes are involved.)
## API Design Requirements
### Consistency
1. Concept: Scenario-based service models must be abstracted to form coherent, consistent, and self-consistent OpenHarmony user program models and service concepts.
1. Term: Service terms must be nouns. Multiple nouns with similar semantic meanings are not allowed to represent the same service object. Similarly, to avoid confusion, it is not allowed to use the same noun or linguistically close nouns for different service objects.
1. Operation: Every operation action must be expressed using a unique verb.
1. Parameter sequence: The location and sequence of the same parameter or parameter sequence in multiple APIs must be the same.
1. Mechanism and algorithm: The communication mechanism, calling mode, authentication mechanism, and encryption algorithm must be consistent.
1. API reference, demo, and template style: The layout and usage must be consistent.
### Ease to Use
Design APIs from the perspective of their users rather than providers.
1. Readability: API naming and features must be easy to understand.
1. Ease of use: Provide easy-to-use APIs by reducing unnecessary coupling between APIs, avoiding dependencies on the calling sequence of multiple unrelated APIs, and avoiding calling multiple methods from different packages, modules, or classes at the same time when using a single feature.
1. Avoiding misleading: Provide capabilities complying with user expectations to avoid misuse.
1. Provide required API reference documents.
### Naming
1. Be able to express the capabilities clearly. Use full descriptive words.
1. Avoid misleading. Misleading names are more harmful than ill-stated ones.
1. Use words with clear meaning. Do not use words with common meanings, such as info, data, and object.
1. The larger the scope is, the more precise the naming should be.
1. Eliminate or minimize the use of abbreviations. Common terms in the industry must comply with industry conventions and can be abbreviated.
1. Bundle name/Module name/Namespace prefix convention:
1. JS API module name: @ohos.\*.
2. Native API namespace: namespace OHOS.\*.
3. If external open-source code is referenced, retain the original bundle name, module name, or namespace, or replace the bundle name according to the preceding rules.
1. The bundle name, module name, and namespace must contain 2 to 4 segments. One word is recommended for each segment, and a maximum of two words are allowed.
1. The class name, method name, function name, member variable, and variable name cannot exceed four words.
### Permission Control
1. Completeness: All behaviors across application sandboxes must be limited by permission control.
1. Optimal granularity: One permission protects only one type of object. Developers only need to apply for one permission to access an interface.
1. Clearness: The protected object, permission scope, and sensitivity level must be clearly specified in the permission definition.
1. Minimum scope: A permission is assigned only to applications that have service requirements to minimize permission scope.
### Privacy Protection
1. The response returned from API calling should contain only necessary information.
1. Mobile phone users' personal data cannot be obtained through API calling unless required permissions are assigned by users.
1. In case that an API is called by multiple applications, if personal data needs to be disclosed to the API to be called, the caller must specify the disclosed data type, data receiver, and data use purpose in the privacy statement.
1. When an API needs to access sensitive user data (such as phone calls, contacts, and media content), the system picker mechanism must be used to prevent the API from accessing the data through sensitive permission application.
1. API openness does not allow unrelated features.
### Documentation
1. The API reference document must be written in English.
1. The API reference document must include the brief and detailed descriptions of modules and packages.
1. The API reference document must include brief descriptions of classes, methods, interfaces, enumerations, and member variables.
1. The API reference document can optionally include detailed descriptions of classes, methods, interfaces, enumerations, and member variables.
1. The API reference document must contain descriptions of all input parameters of every method or interface.
1. If a method or interface has a return value, the API reference document must contain a return value description.
1. If an exception may be thrown during the execution, the API reference document must contain the exception description.
1. The starting version of the API (annotated with @since) must be included.
1. The version of a module or class (annotated with @version) is optionally included.
1. If incompatible API changes are involved, both API-Diff and ChangeLog files must be delivered.
### Compatibility
1. The API compatibility requirements in descending order are as follows: contract compatibility > binary-code compatibility > source-code compatibility.
1. Source-code compatibility: After version evolution, the existing source code can be compiled properly.
1. Binary-code compatibility: After version evolution, the existing programs can be linked to and run properly without recompilation.
1. Contract compatibility: also called semantic compatibility. After version evolution, the original program behaviors remain unchanged.
1. API backward compatibility must meet binary-code compatibility requirements. Exceptions must be reviewed by the API SIG and approved by the PMC. Common API changes that break binary-code compatibility include:
1. Delete any API elements.
1. Reduce the visibility of a method. For example, change from protected to private or from public to protected.
1. Change the class type. For example, change from an abstract class to a non-abstract class, or from an interface class to a non-interface class.
1. Change the method prototype. For example, change the return value type, input parameter sequence, or input parameter type.
1. Change the member attributes. For example, change the member attribute from non-final to final or from non-static to static.
1. Do not modify APIs with the same prototype but incompatible features. You can modify APIs by deprecating old APIs and adding new ones with restrictions.
1. Depending on the release type, the API lifecycle and compatibility requirements are as follows:
## API Lifecycle and Compatibility Requirements
OpenHarmony APIs will evolve in the form of API versions. Each version goes through the release period shown in the following figure,
which also demonstrates the compatibility requirements for the APIs in different periods.
![](figures/API-Lifecycle.png)
......@@ -163,7 +100,7 @@ Design APIs from the perspective of their users rather than providers.
1. Canary versions are compatible with the previous Release version.
1. Different Canary versions of the same API version are not required to keep compatible.
1. Beta version: publicly released beta version, which cannot ensure API stability.
1. Beta versions are compatible with the previous Release version.
1. Canary versions are compatible with the previous Release version.
1. Beta versions are not compatible with the early Canary versions of the same API version.
1. Different Beta versions of the same API version are not required to keep compatible.
1. The APIs are frozen after the API Stable version is released. API additions or changes are not allowed for later Beta versions.
......@@ -173,33 +110,6 @@ Design APIs from the perspective of their users rather than providers.
1. Provide substitute APIs.
1. Retain the deprecated APIs in at least five API versions released since the deprecation.
### Performance
1. Respond in a timely manner to avoid callers waiting. If an API call takes a long time, use an asynchronous API.
2. Make sure that the impact of API call timing and frequency on the RAM usage is under control.
3. Make sure that the impact of API call timing and frequency on the power consumption is under control.
4. Resources must be released in a timely manner when APIs that use resources are called. A fault tolerance mechanism must be provided for abnormal scenarios to ensure timely resource release.
### Power Consumption
1. Evaluate the impact of the API call timing and frequency on power consumption, and optimize the design if there is any impact.
2. Make sure that the power consumption does not deteriorate during version evolution.
### Reliability
1. APIs shall not crash due to external input (such as input parameters, system status, and external data), internal status, or data exceptions. It must return a specific error code or throw a predefined exception.
2. It must be specified whether an API is called synchronously or asynchronously. If an API is called synchronously, specify the timeout duration or allow the caller to set the timeout duration to prevent service response failure caused by call suspension.
3. APIs must support multi-thread reentrant.
4. APIs must meet the idempotence requirement, which means that the same effect should be obtained for one or multiple API call requests with the same service meaning (except that API call depends on external resource changes). For reentrant API call, avoid introducing time-varying factors, such as system ticks, static variables, and global variables without mutual exclusion protection. For repeated call of the same client, **contextID**, **clientToken**, and **sequenceNo** can be used as input parameters.
5. The lifecycle of objects created in APIs must have an end to prevent object resource leakage.
6. The APIs must specify the maximum number of retries allowed after a call failure.
### Testing
1. Automatic API test cases must be delivered for all new APIs.
2. Use a test case for each single scenario. One test case covers a single function of an API, simplifying the code logic of each single test case.
3. The test case execution must be efficient. The execution time of each test case must be limited to milliseconds.
4. Automatic API test cases must be available for all APIs.
5. Assertions with functional logic are required in addition to the capability of throwing exceptions.
### Programming Languages
### API Design Specifications
Regardless of the programming language in use, APIs must comply with the OpenHarmony programming language specifications.
For details, see [OpenHarmony API Design Specifications](OpenHarmony-API-quality.md).
en/design/OpenHarmony-API-quality.md 0 → 100644
浏览文件 @ 1042f045
此差异已折叠。
en/glossary.md
浏览文件 @ 1042f045
......@@ -4,20 +4,35 @@
- ### Ability
An abstraction of a functionality that an application can provide. An ability is the minimum unit for the system to schedule applications. An application can contain one or more **Ability** instances.
The abstraction of a functionality provided by an application. **Ability** is the minimum unit for the system to schedule an application. It is a component that can implement an independent functionality. An application can contain one or more **Ability** instances. Different types of abilities are defined in the Feature Ability (FA) model and stage model.
- ### AMS
Ability Manager Service, a service that manages abilities.
- ### App pack
An application package released to the application market. The package contains one or more HAP files with the file name extension .app.
- ### App component
Same as ability. Each ability is an app component.
- ### ArkCompiler
A component-based and configurable multi-language compilation and running platform built in OpenHarmony. Bolstered by key components such as the compiler, toolchain, and runtime, ArkCompiler is able to compile and run code written in various advanced programming languages on multiple chip platforms. It also enables the OpenHarmony standard system and its applications and services to run on a variety of device types, from phones and PCs, tablets, TVs, automobiles, to smart wearables.
A component-based, configurable multi-language compilation and running platform built in OpenHarmony. Bolstered by key components such as the compiler, toolchain, and runtime, ArkCompiler is able to compile and run code written in various advanced programming languages on multiple chip platforms. It also enables the OpenHarmony standard system and its applications and services to run on a variety of device types, from phones and PCs, tablets, TVs, automobiles, to smart wearables.
- ### ArkTS
Application development language used in OpenHarmony. Based on TypeScript, ArkTS extends capabilities such as declarative UI and status management, helping you develop applications in a simpler and more natural way.
- ### ArkUI
A simplified and high-performance UI development framework for cross-device application design and development, increasing your productivity when creating application UIs for use across devices. For details, see [ArkUI Overview](application-dev/ui/arkui-overview.md).
Native UI framework of OpenHarmony. ArkUI is a simplified, high-performance UI development framework for cross-device application design and development, increasing your productivity when creating application UIs for use across devices. For details, see [ArkUI Overview](application-dev/ui/arkui-overview.md).
- ### Atomic service
A brand-new application form provided by OpenHarmony. Each atomic service has an independent entry for users to easily access, such as by tapping it, using OneHop, or scanning a particular QR code. They support silent installation (installed automatically by the system in the background).
## B
......@@ -26,17 +41,29 @@
Bundle Manager Service, a service that manages application bundles.
## C
- ### C API
Native development interface provided by the OpenHarmony SDK.
- ### Continuation
Distributed operations provided by OpenHarmony, including cross-device migration and multi-device collaboration.
## D
- ### Derivative framework
A third-party framework bridged to the native framework.
- ### DevEco Device Tool
A one-stop development environment and all-in-one resource platform for smart device developers. It provides comprehensive capabilities spanning the entire process of device development, from chip template project creation and custom development resource selection to code writing, build, debugging, and burning.
- ### DMS
Distributed Management Service, a service used for distributed data management.
Distributed Management Service, a service used for distributed management.
## F
......@@ -46,8 +73,7 @@
- ### FA model
Feature Ability model, one of the development models supported by the ability development framework. It is the only application development model supported by API version 8 and earlier. The FA model provides [FAs](#fa) and [Particle abilities (PAs)](#pa). The FA supports the Page ability template, and the PA supports the Service, Data, and Form ability templates. For details, see [FA Model Overview](application-dev/ability/fa-brief.md).
A development model provided by the ability framework. It is the only application development model supported by API version 8 and earlier. The FA model provides [FAs](#fa) and [Particle abilities (PAs)](#pa). The FA supports the Page ability template, and the PA supports the Service, Data, and Form ability templates. For details, see [FA Model Overview](application-dev/ability/fa-brief.md).
## H
......@@ -55,9 +81,13 @@
OpenHarmony Ability Package, released with the file name extension .hap. One HAP provides all content of an application, including code, resources, third-party libraries, and an application configuration file.
- ### HAR
OpenHarmony Archive file, which contains the middle format of code, resources, and configuration files.
- ### HCS
HDF Configuration Source (HCS), providing the [Hardware Driver Foundation (HDF)](#hdf) configuration in key-value pairs. HCS removes the dependency between configuration code and driver code, simplifies configuration management.
HDF Configuration Source, providing the Hardware Driver Foundation (HDF) configuration in key-value pairs. HCS removes the dependency between configuration code and driver code, simplifying configuration management.
- ### HC-GEN
......@@ -67,7 +97,7 @@
- ### HDF
Hardware Driver Foundation that provides a unified access interface for peripherals and the framework for driver development and management in OpenHarmony.
Hardware Driver Foundation, which provides a unified access interface for peripherals and the framework for driver development and management in OpenHarmony.
- ### Hypium
......@@ -80,6 +110,12 @@
Intelligent Distributed Networking, a distributed networking unit of OpenHarmony. You can use IDN to obtain the device list and device states and subscribe to the connection state changes of devices on a distributed network.
## N
- ### Native framework
A development framework provided by the system. A non-native framework is a third-party framework.
## P
......@@ -87,18 +123,41 @@
Particle Ability, an ability that does not have a UI in the ability framework of the FA model. It provides services and support for FAs. For example, a PA can function as a background service to provide computing power or as a data store to provide data access capabilities. The PA supports Service, Data, and Form ability templates.
## S
- ### SA
System Ability, which is a system-level component written by system developers.
- ### Secondary framework
A third-party framework that does not depend on the native framework.
- ### Stage model
A development model provided by the ability framework since API version 9. The stage model provides **UIAbility** and **ExtensionAbility** classes. The **ExtensionAbility** classes include **ServiceExtensionAbility**, **FormExtensionAbility**, **DataShareExtensionAbility**, and more.
- ### Super Virtual Device
Also called Super Device. It integrates the capabilities of multiple devices through the distributed technology into a virtual hardware resource pool and then centrally manages and schedules these capabilities based on application requirements.
- ### Stage model
- ### SysCap
A development model supported by the Ability development framework since API version 9. The stage model provides **Ability** and **ExtensionAbility** classes. The **ExtensionAbility** classes include **ServiceExtensionAbility**, **FormExtensionAbility**, **DataShareExtensionAbility**, and more.
System Capability, each relatively independent feature in OpenHarmony, such as Bluetooth, Wi-Fi, NFC, and camera. Each system capability corresponds to multiple APIs, and each API definition contains the corresponding SysCap tag.
- ### System type
- Mini system: an operating system for the devices that come with MCU processors, such as Arm Cortex-M and 32-bit RISC-V, and memory greater than or equal to 128 KiB. This system provides rich short-distance connection capabilities and peripheral access bus. The mini system applies to smart home products such as LinkIoT module devices and sensors.
- Small system: an operating system for the devices that come with application processors, such as Arm Cortex-A, and memory greater than or equal to 1 MiB. This system provides higher security capabilities, a standard graphics framework, and video encoding and decoding capabilities. The small system applies to smart home products such as IP cameras, peephole cameras, and routers as well as smart travel products such as event data recorders (EDRs).
- Standard system: an operating system for the devices that come with application processors, such as Arm Cortex-A, and memory greater than or equal to 128 MiB. This system provides a complete application framework supporting enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. The standard system applies to high-end refrigerator displays.
- Mini system: an operating system for the devices that come with MCU processors, such as Arm Cortex-M and 32-bit RISC-V, and memory greater than or equal to 128 KiB. This system provides rich short-range connection capabilities and peripheral access bus. The mini system applies to smart home products such as LinkIoT module devices and sensors.
- Small system: an operating system for the devices that come with application processors such as Arm Cortex-A and memory greater than or equal to 1 MiB. This system provides higher security capabilities, a standard graphics framework, and video encoding and decoding capabilities. The small system applies to smart home products such as IP cameras, peephole cameras, and routers as well as easy travel products such as event data recorders (EDRs).
- Standard system: an operating system for the devices that come with application processors such as Arm Cortex-A and memory greater than or equal to 128 MiB. This system provides a complete application framework supporting enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. The standard system applies to high-end refrigerator displays.
## U
- ### UI component
Part of the UI that supports user interaction.
## X
- ### XComponent
Component interfaces provided by ArkUI to meet self-rendering requirements of developers.
en/readme/ARK-Runtime-Subsystem.md
浏览文件 @ 1042f045
# ArkCompiler JS Runtime
# ArkCompiler Runtime
## Introduction
ArkCompiler is a built-in componentized and configurable multi-language compilation and runtime platform of OpenHarmony. It contains core components such as the compiler, toolchain, and runtime. It supports compilation and running of high-level programming languages on the multi-chip platform. It accelerates the running of the OpenHarmony standard operating system and its applications and services on mobile phones, PCs, tablets, TVs, automobiles, and smart wearables. ArkCompiler JS Runtime provides the capability of compiling and running the JavaScript (JS) language on the OpenHarmony operating system.
ArkCompiler is a unified compilation and runtime platform that supports joint compilation and running across programming languages and chip platforms. It supports a variety of dynamic and static programming languages such as JS, TS, and ArkTS. It is the compilation and runtime base that enables OpenHarmony to run on multiple device forms such as mobile phones, PCs, tablets, TVs, automobiles, and wearables.
ArkCompiler JS Runtime consists of two parts: JS compiler toolchain and JS runtime. The JS compiler toolchain compiles JS source code into ArkCompiler bytecodes. The JS runtime executes the generated ArkCompiler bytecodes. Unless otherwise specified, bytecodes refer to ArkCompiler bytecodes in this document.
**Figure 1** Architecture of the JS compiler toolchain
ArkCompiler consists of two parts: compiler toolchain and runtime.
**Figure 1** Architecture of the compiler toolchain
![](figures/en-us_image_ark_frontend.png)
The source code compiler of ArkCompiler JS Runtime receives JS source code, based on which ts2abc generates an abc file.
The compiler toolchain compiles ArkTS, TS, and JS source code into abc files, that is, ArkCompiler bytecode.
**Figure 2** Architecture of ArkCompiler JS Runtime
**Figure 2** Runtime architecture
![](figures/en-us_image_ark-js-arch.png)
![](figures/en-us_image_ark-ts-arch.png)
ArkCompiler JS Runtime runs ArkCompiler bytecode files to implement JS semantic logic.
The runtime runs the abc files to implement the corresponding semantic logic.
ArkCompiler JS Runtime consists of four subsystems:
The ArkCompiler runtime consists of four subsystems:
- Core subsystem
The core subsystem consists of basic language-irrelevant runtime libraries, including ArkCompiler File, Tooling, and ArkCompiler Base. ArkCompiler File provides bytecodes. Tooling supports Debugger. ArkCompiler Base is responsible for implementing system calls.
The core subsystem consists of basic language-irrelevant runtime libraries, including File, Tooling, and Base. File provides bytecode. Tooling supports Debugger. Base implements system calls.
- JS execution subsystem
- Execution subsystem
The JS execution subsystem consists of an interpreter that executes bytecodes, inline caching that stores hidden classes, and Profiler that analyzes and records runtime types.
The execution subsystem consists of the interpreter for executing bytecode, the inline caching, and the profiler for capturing runtime information.
- JS compiler subsystem
- Compiler subsystem
The JS compiler subsystem consists of the Stub compiler, optimized compilation framework based on the Circuit IR, and code generator.
The compiler subsystem consists of the stub compiler, circuit framework, and Ahead-of-Time (AOT) compiler.
- JS runtime subsystem
- Runtime subsystem
The JS runtime subsystem contains various modules related to JS runtime:
The runtime subsystem contains modules related to the running of ArkTS, TS, and JS code.
- Memory management: object allocator and garbage collector (CMS-GC and Partial-Compressing-GC for concurrent marking and partial memory compression)
- Analysis tools: DFX tool and CPU and heap profiling tool
- Concurrency management: abc file manager in the actor concurrency model
- Standard library: standard library defined by ECMAScript, efficient container library, and object model
- Others: asynchronous work queues, TypeScript (TS) type loading, and JS native APIs (JSNAPIs) for interacting with C++ interfaces
**Design features of ArkCompiler JS Runtime:**
- ArkCompiler JS Runtime is designed to provide a JS/TS application execution engine for OpenHarmony rather than a JS execution engine for the browser.
**Design features of ArkCompiler eTS Runtime**
- To improve the application execution performance and security, ArkCompiler JS Runtime statically pre-compiles JS/TS programs into ArkCompiler bytecode (with static type information) to reduce the overhead caused by compilation and type information collection during runtime. To ensure security and performance, ArkCompiler JS Runtime selects the code that supports strict but not eval.
- Native support for type information
- Native support for TS
Currently, mainstream engines in the industry convert TS source code into JS source code and then run the JS source code to complete semantic logic. However, the ArkCompiler compiler toolchain analyzes and deduces the TS type information when compiling the TS source code and transfers the information to the runtime. The runtime uses the TS type information to pre-generate an inline cache before running, speeding up bytecode execution. The TS AOT compiler directly compiles and generates machine code based on the TS type information in the abc file, so that an application can directly run the optimized machine code, thereby greatly improving the running performance.
The common way to process TS in the industry is to convert TS into JS and execute JS code with JS runtime. ts2abc is planned to analyze and obtain the TS type information when compiling the TS source code and send the information to ArkCompiler JS Runtime. ArkCompiler JS Runtime directly uses the type information to statically generate inline caching to accelerate bytecode execution. The TS Ahead of Time (AOT) compiler directly converts the source code into high-quality machine code based on the TS type information sent from ts2abc, which greatly improves the running performance.
- Optimized concurrency model and concurrency APIs
- Lightweight Actor concurrency model
The ArkCompiler eTS runtime statically pre-compiles ArkTS programs into ArkCompiler bytecode (with static type information) to reduce the overhead caused by compilation and type information collection during runtime. To ensure security and performance, the ArkCompiler eTS runtime selects the code that supports strict but not eval.
ECMAScript does not provide concurrency specifications. The Actor concurrency model is used in the JS engines in the industry to implement concurrent processing. In this model, executors do not share data and communicate with each other using the messaging mechanism. The JS Actor model (web-worker) in the industry has defects such as slow startup and high memory usage. ArkCompiler JS Runtime is required to provide the Actor implementation that features fast startup and low memory usage to better leverage the device's multi-core feature to improve performance. Now ArkCompiler JS Runtime is able to share immutable objects, methods, and bytecodes (built-in code blocks and constant strings in the future) in Actor instances based on the Actor memory isolation model to accelerate the startup of JS Actor, reduce memory overhead, and implement the lightweight Actor concurrency model.
- Native support for TS
The ECMAScript specification does not include concurrency semantic representation. Engines in the industry, such as browser or Node.js, usually provide the Worker APIs for multi-thread development based on the Actor concurrency model. In this model, executors do not share data objects or communicate with each other using the messaging mechanism. The worker thread of the web engine or Node.js engine has defects such as slow startup and high memory usage. To address these defects, the ArkCompiler runtime supports sharing of immutable objects (methods and bytecode) in Actor instances, greatly optimizing Actor startup performance and startup memory.
In addition to the Worker APIs, the ArkCompiler runtime provides TaskPool, a task pool function library that supports priority-based scheduling and automatic scaling of worker threads. With TaskPool, you do not need to care about the lifecycle of concurrent instances or create or destroy concurrent instances upon task load changes. This greatly simplifies the development of high-performance multithreaded OpenHarmony applications.
- Cross-language interaction of TS and C++
In the API implementation, it is common for C/C++ code to access and operate TS objects in OpenHarmony. ArkCompiler JS Runtime is planned to statically generate a C/C++ header file that contains the TS object layout description and the C/C++ implementation library for operating the TS object based on the class declaration and runtime conventions in the TS program. The C/C++ code usually includes the TS object layout description header file and the corresponding implementation library to implement the direct operation on the TS object. The TS type or its internal layout is not always fixed. Therefore, in the code implementation for TS object operations, type check is used. If the object type or layout changes during runtime, the common slow path is rolled back.
- Security
The ArkCompiler compiler toolchain statically precompiles ArkTS, TS, and JS code into ArkCompiler bytecode and enhances the multi-obfuscation capability, effectively improving the security of your code assets. For security purposes, ArkCompiler does not support JS code in sloppy mode or functions such as eval for running dynamic strings.
## Directory Structure
```
/ark
├── ets_runtime # JS runtime module
/arkcompiler
├── ets_runtime # ArkTS runtime module
├── runtime_core # Runtime core subsystem
└── ets_frontend # JS frontend tool
├── ets_frontend # ArkTS frontend tool
└── toolchain # ArkTS toolchain
```
## Usage
[Ark Runtime User Guide](https://gitee.com/openharmony/ark_js_runtime/blob/master/docs/ARK-Runtime-Usage-Guide.md)
[Ark Runtime User Guide](https://gitee.com/openharmony/arkcompiler_ets_runtime/blob/master/docs/ARK-Runtime-Usage-Guide.md)
## Repositories Involved
......@@ -79,3 +81,5 @@ ArkCompiler JS Runtime consists of four subsystems:
[arkcompiler\_ets\_runtime](https://gitee.com/openharmony/arkcompiler_ets_runtime)
[arkcompiler\_ets\_frontend](https://gitee.com/openharmony/arkcompiler_ets_frontend)
[arkcompiler\_toolchain](https://gitee.com/openharmony/arkcompiler_toolchain)
en/readme/DeviceProfile.md
浏览文件 @ 1042f045
......@@ -2,7 +2,9 @@
## Introduction<a name="section11660541593"></a>
DeviceProfile is used to manage device hardware capabilities and system software features. A typical device profile includes the device type, device name, OS type, and OS version. By allowing quick access to local and remote device profiles, DeviceProfile lays the foundation for initiating distributed services. It provides the following features:
DeviceProfile is used to manage device hardware capabilities and system software features. A typical device profile includes the device type, device name, OS type, and OS version.
By allowing quick access to local and remote device profiles, DeviceProfile lays the foundation for initiating distributed services. It provides the following features:
- Querying, inserting, and deleting local device profile information
- Querying remote device profile information
......@@ -23,28 +25,28 @@ The main code directory structure of DeviceProfile is as follows:
```
├── interfaces
│   └── innerkits
│ └── distributeddeviceprofile // Internal APIs
│ └── innerkits
│ └── distributeddeviceprofile // innerkits APIs
├── ohos.build
├── sa_profile // SAID profile
│   ├── 6001.xml
│   └── BUILD.gn
├── services
│   └── distributeddeviceprofile
│   ├── BUILD.gn
│   ├── include
│ │ ├── contentsensor // Header file for content sensor data collection
│ │ ├── dbstorage // Header file for database operations
│ │ ├── devicemanager // Header file for device management
│ │ └── subscribemanager // Header file for subscription management
│   ├── src
│ │ ├── contentsensor // Implementation of content sensor data collection
│ │ ├── dbstorage // Implementation of database operations
│ │ ├── devicemanager // Implementation of device management
│ │ ├── subscribemanager // Implementation of subscription management
│ └── test // Test cases
└── tools
└── dp // Auxiliary test tool
│ ├── 6001.xml
│ └── BUILD.gn
└── services
└── distributeddeviceprofile
├── BUILD.gn
├── include
│ ├── authority // Permission verification
│ ├── contentsensor // Header file for content sensor data collection
│ ├── dbstorage // Header file for database operations
│ ├── devicemanager // Header file for device management
│ └── subscribemanager // Header file for subscription management
├── src
│ ├── authority // Permission verification
│ ├── contentsensor // Implementation of content sensor data collection
│ ├── dbstorage // Implementation of database operations
│ ├── devicemanager // Implementation of device management
│ └── subscribemanager // Implementation of subscription management
└── test // Test cases
```
## Constraints<a name="section1718733212019"></a>
......@@ -58,11 +60,11 @@ The main code directory structure of DeviceProfile is as follows:
* Parameters of GetDeviceProfile
| Name| Type| Mandatory| Description|
| Name | Type | Mandatory| Description |
| --------- | ---------------------------- | ---- | ----------------------------------- |
| deviceId | std::string | Yes| ID of the device whose profile is to be queried. A null value indicates the local device.|
| serviceId | std::string | Yes| Service ID (ID of the service data record).|
| profile | ServiceCharacteristicProfile | Yes| Return value.|
| deviceId | std::string | Yes | ID of the device whose profile is to be queried. A null value indicates the local device.|
| serviceId | std::string | Yes | Service ID (ID of the service data record). |
| profile | ServiceCharacteristicProfile | Yes | Return value. |
* Example
......@@ -79,9 +81,9 @@ result.append("jsonData:" + jsonData + "\n");
* Parameters of PutDeviceProfile
| Name| Type| Mandatory| Description|
| Name | Type | Mandatory| Description |
| --------- | ---------------------------- | ---- | ----------------------------------- |
| profile | ServiceCharacteristicProfile | Yes| Profile information to insert.|
| profile | ServiceCharacteristicProfile | Yes | Profile information to insert. |
* Example
......@@ -102,9 +104,9 @@ DistributedDeviceProfileClient::GetInstance().PutDeviceProfile(profile);
* Parameters of DeleteDeviceProfile
| Name| Type| Mandatory| Description|
| Name | Type | Mandatory| Description |
| --------- | ---------------------------- | ---- | ----------------------------------- |
| serviceId | std::string | Yes| ID of the service record to delete.|
| serviceId | std::string | Yes | ID of the service record to delete. |
* Example
......@@ -119,10 +121,10 @@ DistributedDeviceProfileClient::GetInstance().DeleteDeviceProfile(serviceId);
* Parameters of SyncDeviceProfile
| Name| Type| Mandatory| Description|
| Name | Type | Mandatory| Description |
| --------- | ---------------------------- | ---- | ----------------------------------- |
| syncOption| SyncOption | Yes| Synchronization mode and range.|
| syncCb | IProfileEventCallback | Yes| Callback used to return the synchronization result.|
| syncOption| SyncOption | Yes | Synchronization mode and range. |
| syncCb | IProfileEventCallback | Yes | Callback used to return the synchronization result. |
* Example
......@@ -142,11 +144,11 @@ DistributedDeviceProfileClient::GetInstance().SyncDeviceProfile(syncOption,
* Parameters of SubscribeProfileEvents
| Name| Type| Mandatory| Description|
| Name | Type | Mandatory| Description |
| -------------- | ---------------------------- | ---- | ----------------------------------- |
| subscribeInfos | SubscribeInfo | Yes| Type of the event to subscribe to.|
| eventCb | IProfileEventCallback | Yes| Callback for the subscribed event.|
| failedEvents | ProfileEvent | Yes| Failure event.|
| subscribeInfos | SubscribeInfo | Yes | Type of the event to subscribe to. |
| eventCb | IProfileEventCallback | Yes | Callback for the subscribed event. |
| failedEvents | ProfileEvent | Yes | Failure event. |
* Example
......@@ -178,7 +180,6 @@ profileEvents.emplace_back(ProfileEvent::EVENT_PROFILE_CHANGED);
failedEvents.clear();
// Cancel the subscription.
DistributedDeviceProfileClient::GetInstance().UnsubscribeProfileEvents(profileEvents, callback, failedEvents);
callback, failedEvents);
```
## Repositories Involved<a name="section176111311166"></a>
......
en/readme/distributed-data-management.md
浏览文件 @ 1042f045
......@@ -5,7 +5,7 @@
**Distributed Data Management Subsystem**
The Distributed Data Management subsystem can persistently store various structured data of a single device and also supports data synchronization and sharing across devices. With the Distributed Data Management subsystem, application data can be seamlessly processed across different devices, ensuring consistent user experience for the same application across devices.
The Distributed Data Management subsystem can persistently store various structured data of a single device. It also supports data synchronization and sharing across devices. With the Distributed Data Management subsystem, application data can be seamlessly processed across devices, ensuring consistent user experience for the same application across devices.
**Subsystem Architecture**
......@@ -47,15 +47,15 @@ The **DataShare** module allows an application to manage its own data and share
### DDS
The Distributed Data Service (DDS) implements distributed database collaboration across devices for applications. The DDS isolates data based on a triplet of the account, application, and database. The DDS synchronizes data between trusted devices to provide users with consistent data access experience on different devices.
The Distributed Data Service (DDS) implements database collaboration across devices for applications. The DDS isolates data based on a triplet of the account, application, and database. The DDS synchronizes data between trusted devices, delivering a consistent data access experience on different devices.
### Preferences
The **Preferences** module allows quick access to data in KV pairs and storage of a small amount of data for local applications. The data is stored in local files and loaded in memory, which allows faster access and higher processing efficiency. Preferences provide non-relational data storage and are not suitable for storing a large amount of data.
The **Preferences** module allows quick access to data in KV pairs and storage of a small amount of data for local applications. The data is stored in local files in KV pairs and loaded in memory, which allows for faster access and higher processing efficiency. Preferences provide non-relational data storage and are not suitable for storing a large amount of data.
1. The **Preferences** module provides APIs for **preferences** operations.
2. You can use **getPreferences()** to load the content of a specified file to a **Preferences** instance. Each file has only one **Preferences** instance. The system stores the instance data in memory through a static container until the app removes the instance from the memory or deletes the file.
3. After obtaining a **Preferences** instance, the app can call the APIs in **Preferences** to read data from or write data to the **Preferences** instance, and call **flush()** to save the instance data to a file.
2. You can use **getPreferences()** to load the content of a specified file to a **Preferences** instance. Each file has only one **Preferences** instance. The system stores the instance data in memory through a static container until the application removes the instance from the memory or deletes the file.
3. After obtaining a **Preferences** instance, the application can call the APIs of **Preferences** to read data from or write data to the **Preferences** instance, and call **flush()** to save the instance data to a file.
### RDB Store
......
en/release-notes/OpenHarmony-v2.2-beta2.md
浏览文件 @ 1042f045
......@@ -99,9 +99,9 @@ This release provides the following new and enhanced features based on OpenHarmo
For details, see:
- [JS API Differences](api-change/v2.2-beta2/js-apidiff-v2.2-beta2.md)
- [JS API Differences](api-diff/v2.2-beta2/js-apidiff-v2.2-beta2.md)
- [Native API Differences](api-change/v2.2-beta2/native-apidiff-v2.2-beta2.md)
- [Native API Differences](api-diff/v2.2-beta2/native-apidiff-v2.2-beta2.md)
## Resolved Issues
......
en/release-notes/OpenHarmony-v3.0-LTS.md
浏览文件 @ 1042f045
......@@ -127,7 +127,7 @@ This version has the following updates to OpenHarmony 2.2 Beta2.
### API Updates
For details, see [JS API Differences](api-change/v3.0-LTS/js-apidiff-v3.0-lts.md).
For details, see [JS API Differences](api-diff/v3.0-LTS/js-apidiff-v3.0-lts.md).
### Chip and Development Board Adaptation
......
en/release-notes/OpenHarmony-v3.0.7-LTS.md 0 → 100644
浏览文件 @ 1042f045
# OpenHarmony 3.0.7 LTS
## Version Description
OpenHarmony 3.0.7 LTS is a maintenance version of OpenHarmony 3.0 LTS. It has rectified certain issues detected in OpenHarmony 3.0.6 LTS.
## Version mapping
**Table 1** Version mapping of software and tools
| Software/Tool| Version| Remarks|
| -------- | -------- | -------- |
| OpenHarmony | 3.0.7 LTS| NA |
| (Optional) HUAWEI DevEco Studio| 3.0 Beta3 for OpenHarmony | Recommended for developing OpenHarmony applications|
| (Optional) HUAWEI DevEco Device Tool| 3.0 Release | Recommended for developing OpenHarmony smart devices|
## Source Code Acquisition
### Prerequisites
1. Register your account with Gitee.
2. Register an SSH public key for access to Gitee.
3. Install the [git client](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) and [git-lfs](https://gitee.com/vcs-all-in-one/git-lfs?_from=gitee_search#downloading), and configure user information.
```
git config --global user.name "yourname"
git config --global user.email "your-email-address"
git config --global credential.helper store
```
4. Run the following commands to install the **repo** tool:
```
curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 > /usr/local/bin/repo # If you do not have the permission, download the tool to another directory and configure it as an environment variable by running the chmod a+x /usr/local/bin/repo command.
pip3 install -i https://repo.huaweicloud.com/repository/pypi/simple requests
```
### Acquiring Source Code Using the repo Tool
**Method 1 (recommended)**: Use the **repo** tool to download the source code over SSH. (You must have an SSH public key for access to Gitee.)
```
repo init -u git@gitee.com:openharmony/manifest.git -b refs/tags/OpenHarmony-v3.0.7-LTS --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'
```
**Method 2**: Use the **repo** tool to download the source code over HTTPS.
```
repo init -u https://gitee.com/openharmony/manifest.git -b refs/tags/OpenHarmony-v3.0.7-LTS --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'
```
### Acquiring Source Code from Mirrors
**Table 2** Mirrors for acquiring source code
| LTS Code| Version| Mirror| SHA-256 Checksum|
| -------- | -------- | -------- | -------- |
| Full code base (for mini, small, and standard systems)| 3.0.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/code-v3.0.7-LTS.tar.gz)| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/code-v3.0.7-LTS.tar.gz.sha256)|
| Standard system Hi3516 solution (binary)| 3.0.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/standard.tar.gz)| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/standard.tar.gz.sha256)|
| Mini system Hi3861 solution (binary)| 3.0.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/hispark_pegasus.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/hispark_pegasus.tar.gz.sha256) |
| Small system Hi3516 solution - LiteOS (binary)| 3.0.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/hispark_taurus.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/hispark_taurus.tar.gz.sha256) |
| Small system Hi3516 solution - Linux (binary)| 3.0.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/hispark_taurus_linux.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.0.7/hispark_taurus_linux.tar.gz.sha256) |
## What's New
### Feature Updates
This version does not involve feature updates.
### API Updates
This version does not involve API updates.
### Chip and Development Board Adaptation
For details about the adaptation status, see [SIG-Devboard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard.md).
## Fixed Security Vulnerabilities
**Table 3** Fixed security vulnerabilities
| Issue No.| Description| PR Link|
| -------- | -------- | -------- |
| I5VFI7 | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-3303, CVE-2022-42703, CVE-2022-20422, CVE-2022-41222, CVE-2022-3239, CVE-2022-20423 and CVE-2022-41850 | [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/508) |
| I5UHPU | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-40768, CVE-2022-3577, CVE-2022-20409, CVE-2022-3566, CVE-2022-3606, CVE-2022-3564 and CVE-2022-3649| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/506) |
| I5QBIA | Security vulnerability of the Kernel_linux_5.10 component: CVE-2022-1184 | [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/475) |
| I5VFK1 | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-20421, CVE-2022-42719, CVE-2022-42720, CVE-2022-42721, CVE-2022-42722, CVE-2022-41674, CVE-2022-3535, CVE-2022-3521, CVE-2022-3565, CVE-2022-3594, CVE-2022-3435, CVE-2022-41849, CVE-2022-3524, CVE-2022-3542, and CVE-2022-3534| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/503) |
| I5OJL9 | Security vulnerability of the Kernel_linux_5.10 component: CVE-2022-26373 | [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/495) |
| I5WC2X | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-23816, CVE-2022-29901, and CVE-2022-29900| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/494) |
| I5VQVK | Security vulnerability of the Kernel_linux_5.10 component: CVE-2022-1462 | [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/490) |
| I5VP0D | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-39189, CVE-2022-39190, and CVE-2022-2663| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/489) |
| I5QBPW | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-39188, CVE-2022-3078, CVE-2022-2905, and CVE-2022-39842| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/481) |
| I5SCE3 | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-3202 and CVE-2022-40307| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/464) |
| I5QBK8 | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-3028, CVE-2022-2977, and CVE-2022-2964| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/442) |
| I5RQTK | Security vulnerability of the Kernel_linux_5.10 component: CVE-2022-3061 | [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/444) |
| I5R8CM | Security vulnerabilities of the Kernel_linux_5.10 component: CVE-2022-2959 and CVE-2022-2991| [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/436) |
| I5R8BB | Security vulnerability of the Kernel_linux_5.10 component: CVE-2022-2503 | [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/435) |
| I5R6VI | Security vulnerability of the Kernel_linux_5.10 component: CVE-2022-2938 | [PR](https://gitee.com/openharmony/kernel_linux_5.10/pulls/434) |
| I5ZA11 | Security vulnerabilities of the curl component: CVE-2022-32221, CVE-2022-42915, and CVE-2022-42916| [PR](https://gitee.com/openharmony/third_party_curl/pulls/90) |
| I5QBFJ | Security vulnerability of the curl component: CVE-2022-35252 | [PR](https://gitee.com/openharmony/third_party_curl/pulls/85) |
| I5UHWM | Security vulnerability of the wayland component: CVE-2021-3782 | [PR](https://gitee.com/openharmony/third_party_wayland_standard/pulls/22) |
| I5MVPK | Security vulnerability on the css-what component: CVE-2021-33587 | [PR](https://gitee.com/openharmony/third_party_css-what/pulls/9) |
| I5YR0H | Security vulnerability of the gstreamer component: CVE-2021-3185 | [PR](https://gitee.com/openharmony/third_party_gstreamer/pulls/207) |
| I5XT87 | Security vulnerability of the expat component: CVE-2022-43680 | [PR](https://gitee.com/openharmony/third_party_expat/pulls/22) |
| I5SD4W | Security vulnerability of the expat component: CVE-2022-40674 | [PR](https://gitee.com/openharmony/third_party_expat/pulls/19) |
en/release-notes/OpenHarmony-v3.1-beta.md
浏览文件 @ 1042f045
......@@ -128,11 +128,11 @@ This version has the following updates to OpenHarmony 3.0 LTS.
For details, see the following:
_[JS API Differences](api-change/v3.1-beta/js-apidiff-v3.1-beta.md)_
_[JS API Differences](api-diff/v3.1-beta/js-apidiff-v3.1-beta.md)_
_[Native API Differences](api-change/v3.1-beta/native-apidiff-v3.1-beta.md)_
_[Native API Differences](api-diff/v3.1-beta/native-apidiff-v3.1-beta.md)_
_[Changelog](api-change/v3.1-beta/changelog-v3.1-beta.md)_
_[Changelog](api-diff/v3.1-beta/changelog-v3.1-beta.md)_
### Chip and Development Board Adaptation
......
en/release-notes/OpenHarmony-v3.1-release.md
浏览文件 @ 1042f045
......@@ -189,7 +189,7 @@ This version has the following updates to OpenHarmony 3.1 Beta.
For details, see the following:
*[API Differences](api-change/v3.1-Release/Readme-EN.md)*
*[API Differences](api-diff/v3.1-Release/Readme-EN.md)*
### Chip and Development Board Adaptation
......
en/release-notes/OpenHarmony-v3.1.4-release.md
浏览文件 @ 1042f045
......@@ -13,7 +13,7 @@ OpenHarmony 3.1.4 Release provides enhanced system security over OpenHarmony 3.1
| Software/Tool| Version| Remarks|
| -------- | -------- | -------- |
| OpenHarmony | 3.1.4 Release| NA |
| Full SDK | Ohos_sdk_full 3.1.9.7 (API Version 8 Release)| This toolkit is intended for original equipment manufacturers (OEMs) and contains system APIs that require system permissions.<br>To use the Full SDK, you must manually obtain it from the mirror and switch to it in DevEco Studio. For details, see [Guide to Switching to Full SDK](../application-dev/quick-start/full-sdk-switch-guide.md).|
| Full SDK | Ohos_sdk_full&nbsp;3.1.9.7&nbsp;(API&nbsp;Version&nbsp;8&nbsp;Relese) | This toolkit is intended for original equipment manufacturers (OEMs) and contains system APIs that require system permissions.<br>To use the Full SDK, you must manually obtain it from the mirror and switch to it in DevEco Studio. For details, see [Guide to Switching to Full SDK](../application-dev/quick-start/full-sdk-switch-guide.md).|
| Public SDK | Ohos_sdk_public 3.1.9.7 (API Version 8 Release)| This toolkit is intended for application developers and does not contain system APIs that require system permissions.<br>It is provided as standard in DevEco Studio 3.0 Beta4 or later.|
| (Optional) HUAWEI DevEco Studio| 3.1 Preview for OpenHarmony| Recommended for developing OpenHarmony applications|
| (Optional) HUAWEI DevEco Device Tool| 3.0 Release| Recommended for developing OpenHarmony smart devices|
......@@ -75,12 +75,12 @@ repo forall -c 'git lfs pull'
| Source Code| Version| Mirror| SHA-256 Checksum|
| -------- | -------- | -------- | -------- |
| Full code base (for mini, small, and standard systems)| 3.1.4&nbsp;Release | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/code-v3.1.4-Release.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/code-v3.1.4-Release.tar.gz.sha256) |
| Hi3516 standard system solution (binary)| 3.1.4&nbsp;Release | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_hi3516.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_hi3516.tar.gz.sha256) |
| RK3568 standard system solution (binary)| 3.1.4&nbsp;Release | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_rk3568.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_rk3568.tar.gz.sha256) |
| Hi3861 mini system solution (binary)| 3.1.4&nbsp;Release | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_pegasus.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_pegasus.tar.gz.sha256) |
| Hi3516 small system solution - LiteOS (binary)| 3.1.4&nbsp;Release | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus.tar.gz.sha256) |
| Hi3516 small system solution - Linux (binary)| 3.1.4&nbsp;Release | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus_linux.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus_linux.tar.gz.sha256) |
| Full code base (for mini, small, and standard systems)| 3.1.4 Release| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/code-v3.1.4-Release-2022-12-12.tar.gz)| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/code-v3.1.4-Release-2022-12-12.tar.gz.sha256)|
| Hi3516 standard system solution (binary)| 3.1.4 Release| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_hi3516.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_hi3516.tar.gz.sha256) |
| RK3568 standard system solution (binary)| 3.1.4 Release| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_rk3568.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/standard_rk3568.tar.gz.sha256) |
| Hi3861 mini system solution (binary)| 3.1.4 Release| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_pegasus.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_pegasus.tar.gz.sha256) |
| Hi3516 small system solution - LiteOS (binary)| 3.1.4 Release| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus.tar.gz.sha256) |
| Hi3516 small system solution - Linux (binary)| 3.1.4 Release| [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus_linux.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/hispark_taurus_linux.tar.gz.sha256) |
| Full SDK package for the standard system (macOS)| 3.1.9.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/ohos-sdk-mac-full.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/ohos-sdk-mac-full.tar.gz.sha256) |
| Full SDK package for the standard system (Windows/Linux)| 3.1.9.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/ohos-sdk-full.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/ohos-sdk-full.tar.gz.sha256) |
| Public SDK package for the standard system (macOS)| 3.1.9.7 | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/ohos-sdk-mac-public.tar.gz) | [Download](https://mirrors.huaweicloud.com/openharmony/os/3.1.4/ohos-sdk-mac-public.tar.gz.sha256) |
......
en/release-notes/OpenHarmony-v3.2-beta1.md
浏览文件 @ 1042f045
......@@ -172,7 +172,7 @@ This version has the following updates to OpenHarmony 3.1 Release.
### API Updates
*[API Differences](api-change/v3.2-beta1/Readme-EN.md)*
*[API Differences](api-diff/v3.2-beta1/Readme-EN.md)*
### Chip and Development Board Adaptation
......@@ -204,7 +204,7 @@ For details about the adaptation status, see [SIG-Devboard](https://gitee.com/op
| ArkUI | [Game2048](https://gitee.com/openharmony/applications_app_samples/tree/master/ETSUI/Game2048) | This sample shows how to develop a 2048 game using the **\<Grid>** component.| eTS |
| Window Manager| [Window](https://gitee.com/openharmony/applications_app_samples/tree/master/Graphics/Window) | This sample shows how to create a window, display an application over another application in the form of a floating window, and display an application on split screens.| eTS |
| Distributed data management| [Preference](https://gitee.com/openharmony/applications_app_samples/tree/master/data/Preferences) | This sample shows the theme switching function of preferences.| eTS |
| ArkUI | [NativeAPI](https://gitee.com/openharmony/applications_app_samples/tree/master/Native/NativeAPI) | This sample shows how to call C++ APIs in eTS and how C++ APIs call back JS APIs to play the Gomoku game. The native APIs implement the calculation logic, and eTS implements UI rendering and re-rendering.| eTS/C++ |
| ArkUI | [NativeAPI](https://gitee.com/openharmony/app_samples/tree/master/Native/NativeAPI) | This sample shows how to call C++ APIs in eTS and how C++ APIs call back JS APIs to play the Gomoku game. The native APIs implement the calculation logic, and eTS implements UI rendering and re-rendering.| eTS/C++ |
| Globalization| [International](https://gitee.com/openharmony/applications_app_samples/tree/master/common/International) | This sample shows how to use APIs related to i18n, intl, and resourceManager in eTS to set the system language, region, time, and time zone. It also provides locale setting examples.| eTS |
For more information, visit [Samples](https://gitee.com/openharmony/applications_app_samples).
......
en/release-notes/OpenHarmony-v3.2-beta3.md
浏览文件 @ 1042f045
......@@ -176,7 +176,7 @@ This version has the following updates to OpenHarmony 3.2 Beta2.
For details about the API changes, see the following:
[API Differences](api-change/v3.2-beta3/Readme-EN.md)
[API Differences](api-diff/v3.2-beta3/js-apidiff-ability.md)
### Chip and Development Board Adaptation
......
en/release-notes/OpenHarmony-v3.2-beta4.md 0 → 100644
浏览文件 @ 1042f045
此差异已折叠。
en/release-notes/Readme.md
浏览文件 @ 1042f045
# OpenHarmony Release Notes
## OpenHarmony 3.x Releases
- [OpenHarmony v3.2 Beta4 (2022-11-30)](OpenHarmony-v3.2-beta4.md)
- [OpenHarmony v3.2 Beta3 (2022-09-30)](OpenHarmony-v3.2-beta3.md)
- [OpenHarmony v3.2 Beta2 (2022-07-30)](OpenHarmony-v3.2-beta2.md)
- [OpenHarmony v3.2 Beta1 (2022-05-31)](OpenHarmony-v3.2-beta1.md)
......@@ -11,6 +12,7 @@
- [OpenHarmony v3.1.1 Release (2022-05-31)](OpenHarmony-v3.1.1-release.md)
- [OpenHarmony v3.1 Beta (2021-12-31)](OpenHarmony-v3.1-beta.md)
- [OpenHarmony v3.0 LTS (2021-09-30)](OpenHarmony-v3.0-LTS.md)
- [OpenHarmony v3.0.7 LTS (2022-12-05)](OpenHarmony-v3.0.7-LTS.md)
- [OpenHarmony v3.0.6 LTS (2022-09-15)](OpenHarmony-v3.0.6-LTS.md)
- [OpenHarmony v3.0.5 LTS (2022-07-01)](OpenHarmony-v3.0.5-LTS.md)
- [OpenHarmony v3.0.3 LTS (2022-04-08)](OpenHarmony-v3.0.3-LTS.md)
......
en/release-notes/api-change/v3.2-beta2/Readme-EN.md 已删除 100644 → 0
浏览文件 @ abac74be
# Readme
This directory records the API changes in OpenHarmony 3.2 Beta2 over OpenHarmony 3.2 Beta1, including new, updated, deprecated, and deleted APIs.
- JS API Differences
- [Ability framework](js-apidiff-ability.md)
- [Accessibility subsystem](js-apidiff-accessibility.md)
- [Account subsystem](js-apidiff-account.md)
- [ArkUI development framework](js-apidiff-arkui.md)
- [Bundle management framework](js-apidiff-bundle.md)
- [Communication subsystem](js-apidiff-communicate.md)
- [Utils subsystem](js-apidiff-compiler-and-runtime.md)
- [DFX subsystem](js-apidiff-dfx.md)
- [Distributed data management subsystem](js-apidiff-distributed-data.md)
- [Common event and notification subsystem](js-apidiff-event-and-notification.md)
- [File management subsystem](js-apidiff-file-management.md)
- [Location subsystem](js-apidiff-geolocation.md)
- [Globalization subsystem](js-apidiff-global.md)
- [Graphics subsystem](js-apidiff-graphic.md)
- [Misc services subsystem](js-apidiff-misc.md)
- [Multimodal input subsystem](js-apidiff-multi-modal-input.md)
- [Multimedia subsystem](js-apidiff-multimedia.md)
- [Resource scheduler subsystem](js-apidiff-resource-scheduler.md)
- [Security subsystem](js-apidiff-security.md)
- [Pan-sensor subsystem](js-apidiff-sensor.md)
- [DSoftBus subsystem](js-apidiff-soft-bus.md)
- [Test subsystem](js-apidiff-unitest.md)
- [Update subsystem](js-apidiff-update.md)
- [USB subsystem](js-apidiff-usb.md)
- [User IAM subsystem](js-apidiff-user-authentication.md)
- [Web subsystem](js-apidiff-web.md)
- [Window manager subsystem](js-apidiff-window.md)
- ChangeLog
- [Updates (OpenHarmony 3.2 Beta1 -> OpenHarmony 3.2 Beta2)](changelog-v3.2-beta2.md)
- [Adaptation Guide for the Application Sandbox](application-sandbox-adaptation-guide.md)
en/release-notes/api-diff/v3.2-beta4/js-apidiff-dfx.md 0 → 100644
浏览文件 @ 1042f045
此差异已折叠。
en/release-notes/api-diff/v3.2-beta4/js-apidiff-misc.md 0 → 100644
浏览文件 @ 1042f045
此差异已折叠。
en/release-notes/api-diff/v3.2-beta4/js-apidiff-msdp.md 0 → 100644
浏览文件 @ 1042f045
此差异已折叠。
en/release-notes/api-diff/v3.2-beta4/js-apidiff-usb.md 0 → 100644
浏览文件 @ 1042f045
此差异已折叠。
en/release-notes/api-diff/v3.2-beta4/js-apidiff-web.md 0 → 100644
浏览文件 @ 1042f045
此差异已折叠。
en/website.md
浏览文件 @ 1042f045
此差异已折叠。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或