diff --git a/en/contribute/template/figures/figure01.png b/en/contribute/template/figures/figure01.png new file mode 100644 index 0000000000000000000000000000000000000000..df3c115b78a0c8bb792c704735dd6e213a2d1e6c Binary files /dev/null and b/en/contribute/template/figures/figure01.png differ diff --git a/en/contribute/template/figures/figure02.png b/en/contribute/template/figures/figure02.png new file mode 100644 index 0000000000000000000000000000000000000000..159b193f425237a47ca351a8d093060a08f27d20 Binary files /dev/null and b/en/contribute/template/figures/figure02.png differ diff --git a/en/contribute/template/readme-template.md b/en/contribute/template/readme-template.md new file mode 100644 index 0000000000000000000000000000000000000000..127a3fc8b4483e13c80c0d6cdbf95e52a7e3e58b --- /dev/null +++ b/en/contribute/template/readme-template.md @@ -0,0 +1,155 @@ +# ***ExampleName*** Subsystem/Part + +- [Introduction](#Introduction) +- [Directory Structure](#Directory-Structure) +- [Constraints](#Constraints) +- [Compilation and Building](#Compilation-and-Building) +- [Usage](#Usage) + - [Available APIs](#Available-APIs) + - [How to Use](#How-to-Use) +- [Repositories Involved](#Repositories-Involved) + +[Title Description] Use **Subsystem** or **Part** based on the Readme file type. + + +![Subsystem-readme](figures/figure01.png) + + +## Introduction + + +[Writing Instructions] **Mandatory**. The following contents must be included: + +**Overall introduction.** Describe the subsystem from the following aspects: background (role in the entire OpenHarmony architecture), functions, use cases, and supported devices. + +**Architecture diagram.** Provide an architecture diagram and explain the main components in the architecture. + +**If this document is about a part, which is part of a subsystem, and related concepts of the subsystem can help understand the part, you are advised to include the following information:** + +**For more concepts related to the ***exampleName*** subsystem, see ***exampleName***. (Provide the link to the subsystem readme.)** + + +The precautions for writing are as follows: + + +| Item| Requirement| +| -------- | -------- | +| **A.1** | **Content**| +| A.1.1 | Style: Use formal language and avoid colloquial language.| +| A.1.2 | Compliance: Do not use terms that have compliance and legal risks, such as concepts specific to third-party intellectual property rights.| +| A.1.3 | Concise: Provide only necessary and minimum information to instruct developers to complete operations as soon as possible.| +| A.1.4 | Correct: The code and parameters in the Readme file must be consistent with the actual product information.| +| A.1.5 | Accurate: Use accurate rather than ambiguous description.| +| A.1.6 | Consistent: Words and concepts in the Readme file must be used consistently across the file and compliant with the glossary. The full name of an acronym or abbreviation must be provided when it appears for the first time in the file.| +| A.1.7 | Specific: Use specific words. For example, when indicating the quantity or degree, do not use "more" or "less". Use specific numbers instead.| +| **A.2** | **Format**| +| A.2.1 | Use punctuation correctly. End a sentence with punctuation.| +| A.2.2 | Present the content clearly, for example, by using bullets or categories. Do not include a single bullet or extra empty lines.| +| A.2.3 | Do not add a space between an English word and Chinese word.| +| A.2.4 | Use valid and specific links that provide direct redirection or download. It is recommended that relative links in Gitee instead of absolute links be used.| +| A.2.5 | For auxiliary description, use the "Note" format. For declaration in advance, use the "Notice" format.| +| **A.3** | **Tables**| +| A.3.1 | Include a caption for each table. Use nouns or noun phrases in the caption.| +| A.3.2 | Include a header for each table. Ensure that a table contains at least two rows and two columns.| +| A.3.3 | If there is no content in a table cell, use an underscore (_) in the cell, rather than leaving it blank.| +| **A.4** | **Figures**| +| A.4.1 | Do not include figures of religious beliefs.| +| A.4.2 | Include a caption for each figure. Use nouns or noun phrases in the caption.| +| A.4.3 | Figures must be clear, legible, complete, and easy to read. For example, a flowchart must contain "Start" and "End".| +| A.4.4 | Each figure must have clear logic and be provided with relevant text descriptions.| +| A.4.5 | It is recommended that each figure, in .png format, have the size less than or equal to 150 KB, the height about 640 px, and the width less than or equal to 820 px.| +| A.4.6 | Try not to include text in figures. If text is required, make sure the text language is consistent with your file's language.| + + +The following shows an architecture diagram. Pay attention to the **color and format requirements**. + +**Figure 1** Subsystem architecture +![Architecture](figures/figure02.png) + + + +## Directory Structure + +[Writing Instructions] **Mandatory**. Describe the code directory structure of the project repository and function description of the corresponding directory. + +```undefined +/foundation/ace +├── frameworks # Framework code +│ └── lite +│ ├── examples # Sample code +│ ├── include # Exposed header files +│ ├── packages # JS implementation +│ ├── src # Source code +│ ├── targets # Configuration file of each target device +│ └── tools # Tool code +├── interfaces # APIs exposed externally +│ └── innerkits # Header files for internal subsystems +│ └── builtin # Third-party module APIs provided by the JS application framework +``` + + + +## Constraints + +[Writing Instructions] **Optional**. Include the conditions for project running, for example, a specific programming language or a specific operating system with a given version. + +| Item| Requirement| +| -------- | -------- | +| D.1.1 | Clearly specify the function limitations or operation restrictions.| +| D.1.2 | Describe only constraints that affect task development or user experience.| +| D.1.3 | Describe operations that are prone to errors in the procedure, but not in this section.| + + +## Compilation and Building + +[Writing Instructions] **Optional**. This section is not required for a subsystem Readme file. Include this section in a part Readme file based on the actual conditions. + + +## Usage + + +### Available APIs + +[Writing Instructions] **Optional**. Describe the APIs related to the development guide so that developers can have a general understanding of the APIs before development. **This section is not required for a subsystem Readme file.** Determine whether this section is required for a part Readme file based on the actual conditions. If the corresponding API reference is available, you do not need to include this section. The precautions for writing are as follows: + +| Item| Requirement| +| -------- | -------- | +| J.1.1 | Include only APIs relevant to the development task.| +| J.1.2 | Provide only main APIs if there are too many APIs.| + + +### How to Use + +[Writing Instructions] **Optional**. Provide a concept introduction for a subsystem Readme file and function introduction for a part Readme file. If the corresponding development guide is available, you can provide a link, rather than details here. + +The table below describes the writing requirements. After finishing the writing, check your content against these requirements one by one. + +| Item| Requirement| +| -------- | -------- | +| **F.1** | **Writing a Development Procedure**| +| F.1.1 | Complete: Provide all mandatory steps.| +| F.1.2 | Clear: The logic of the writing must be clear and reasonable. The overview, preparations, and operations in the document must be described by following certain logic, and the chapters should not be broken or contradictory.| +| F.1.3 | Sentence pattern for tasks: Use verbs + nouns to describe actions in titles or sentences.| +| F.1.4 | Prevention in advance: If the operation involves restrictions, errors, or potential risks, describe them in advance.| +| F.1.5 | Clear steps-1: Describe the purpose of each step, no matter whether it is simple or not.| +| F.1.6 | Clear steps-2: Specify the environment, tools, operations, and how-to.| +| F.1.7 | If an operation is optional, specify the conditions in which the operation is required.| +| F.1.8 | After the development procedure is complete, specify the expected results.| +| **F.2** | **Writing a Code Segment**| +| F.2.1 | If a code segment involves commands to be copied by developers, display the commands in editable mode, instead of using screenshots. Use code snippets to wrap the commands.| +| F.2.2 | Provide comments for key sections and key steps in the code.| +| F.2.3 | The code display meets the code indentation requirements.| +| F.2.4 | If an API call is involved in a step, provide the API and its usage description or sample code. The code should come from specific instances.| + + +## Repositories Involved + +[Writing Instructions] **Mandatory**. List the links of all related repositories of the subsystem where the current repository is located and mark the current repository in bold. + +Example: + +[Kernel](https://gitee.com/openharmony/docs/blob/master/en/readme/kernel-subsystem.md) + +[drivers\_liteos](https://gitee.com/openharmony/drivers_liteos/blob/master/README.md) + +**kernel\_liteos\_a** \ No newline at end of file diff --git a/en/contribute/template/xxboard-template.md b/en/contribute/template/xxboard-template.md new file mode 100644 index 0000000000000000000000000000000000000000..1d2f96eee083e9f81f45cdbec5c302476af94727 --- /dev/null +++ b/en/contribute/template/xxboard-template.md @@ -0,0 +1,81 @@ +# ***ExampleName*** Development Board +*Template positioning: When a third-party development board is introduced to OpenHarmony, the board vendor needs to provide an introduction to the board for developers to quickly understand the board.* + +## Introduction + +*[Writing Instructions]* + +*Describe the functions, scenarios, and key features supported by the development board.* + +*Provide a picture to show the appearance of the development board.* + +*Provide a bottom board picture.* + +*Provide a functional block diagram and an introduction.* + +*Name the figures after the development board.* + +*Reference document: https://gitee.com/openharmony/docs/blob/master/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md* + +******** +## Development Board Specifications + +*[Writing Instructions] Provide the module and hardware specifications of the development board.* + +## (Optional) Constraints + +*[Writing Instructions] Describe the restrictions and suggestions on functions, features, and specifications of the development board, if any.* + +******** + + +## Key Features +*[Writing Instructions] List supported key features of OpenHarmony.* + +## Pin Definition +*[Writing Instruction] Describe the definitions of I/O pins, and how to configure pins and connect pins to external components.* + +## Setting Up the Development Environment + +### System Requirements + +*[Writing Instruction] Describe the dependency of the development board on the OpenHarmony system, software environment, and hardware environment.* + +### Required Tools + +*[Writing Instruction] Provide the paths for downloading the tools used to build and debug the development board.* + +### Setup Process + +*[Writing Instruction] Describe the procedure for setting up the environment step by step.* + +## Building and Debugging + +### Building + +*[Writing Instruction] Describe how to use OpenHarmony and update OpenHarmony binary files and devices on the development board.* + +### Burning + +*[Writing Instruction] Describe how to burn images step by step.* + +### Running + +*[Writing Instruction] Describe how to check whether the lighting, running, and output of the development board are proper.* + + +### Debugging + +*[Writing Instruction] Describe how to debug common errors on the development board.* + +## First Demo + +*[Writing Instruction] Provide a quick start example and running effect based on the development board, or provide the link of the demo source code.* + +## References + +*[Writing Instruction] Provide links to the reference documents, samples, and FAQs.* + +## (Optional) Acknowledgments + +*[Writing Instruction] Provide acknowledgements to third-party contributors.* diff --git a/en/device-dev/quick-start/oem_minitinier_des_3516.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md similarity index 100% rename from en/device-dev/quick-start/oem_minitinier_des_3516.md rename to en/device-dev/quick-start/quickstart-lite-introduction-hi3516.md diff --git a/en/device-dev/quick-start/oem_minitinier_des_3518.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3518.md similarity index 100% rename from en/device-dev/quick-start/oem_minitinier_des_3518.md rename to en/device-dev/quick-start/quickstart-lite-introduction-hi3518.md diff --git a/en/device-dev/quick-start/oem_minitinier_des_3861.md b/en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md similarity index 100% rename from en/device-dev/quick-start/oem_minitinier_des_3861.md rename to en/device-dev/quick-start/quickstart-lite-introduction-hi3861.md diff --git a/en/release-notes/OpenHarmony-v3.1-beta.md b/en/release-notes/OpenHarmony-v3.1-beta.md new file mode 100644 index 0000000000000000000000000000000000000000..aa1adb202f116eb73370e2f2970b0b00716c9d2d --- /dev/null +++ b/en/release-notes/OpenHarmony-v3.1-beta.md @@ -0,0 +1,215 @@ +# OpenHarmony 3.1 Beta + +- [Version Description](#Version-Description) +- [Version Mapping](#Version-Mapping) +- [Source Code Acquisition](#Source-Code-Acquisition) + - [Acquiring Source Code Using the repo Tool](#Acquiring-Source-Code-Using-the-repo-Tool) + - [Acquiring Source Code from a Mirror](#Acquiring-Source-Code-from-a-Mirror) +- [What's New](#What-Is-New) + - [Feature Updates](#Feature-Updates) + - [API Updates](#API-Updates) + - [Chip and Development Board Adaptation](#Chip-and-Development-Board-Adaptation) + - [Samples & Codelabs](#samples-amp-codelabs) + - [New Samples](#New-Samples) + - [New Codelabs](#New-Codelabs) +- [Resolved Issues](#Resolved-Issues) +- [Known Issues](#Known-Issues) + + +## Version Description + +OpenHarmony 3.1 Beta provides the following enhancements over OpenHarmony 3.0 LTS: + +- Enhanced basic capabilities for the standard system: The CMA usage is improved in the kernel. The background rendering module of RenderService is added to the Graphics subsystem. The STA and SoftAP features are provided for short-range communications. The geomagnetic field algorithm APIs are provided. The sensor driver model capability is enhanced. Application account query and subscription are supported. New globalization features are introduced. Unified build templates are provided for the Compilation and Building subsystem. Front-end compilation toolchains for Windows, macOS, and Linux are provided for the Multi-language Runtime subsystem. Previewer is supported for JS runtime. Six third-party JS libraries (JSON Processing, EventBus, VCard, Protobuf, RxJS, and libphonenumber) are supported. Time and time zone management is supported. The HiSysEvent module is added to DFX to provide query and subscription interfaces. + +- Enhanced distributed capabilities for the standard system: The distributed device profile is added. Distributed data management supports cross-device synchronization and subscription. DSoftBus supports network switchover. The distributed file system supports StatFS APIs. + +- Enhanced application framework capabilities for the standard system: The ArkUI-based custom drawing capability and Lottie animation capability are added. The implicit query and multi-HAP installation are added for the bundle management framework. Permission management, notification vibration setting, notification sound setting and query, do-not-disturb (DND) notification, and session notification are added for the Common Event and Notification subsystem. + +- Enhanced system application capabilities for the standard system: Text input and landscape-mode layout display for the input method application, SMS application information management, call log and dialer display in the contacts application, and more options in **Settings** are supported. + +- Enhanced capabilities for the mini system: The lightweight HiStreamer supports the customizable media pipeline framework. The Linux init process supports hot swap. The OS lightweight kernel and driver startup are optimized. The quick startup capability is supported. + + +## Version Mapping + +**Table 1** Version mapping of software and tools + +| Software/Tool| Version| Remarks| +| -------- | -------- | -------- | +| OpenHarmony | 3.1 Beta | NA | +| SDK | Ohos_sdk 3.1 Beta (API Version 8 Beta)| NA | +| (Optional) HUAWEI DevEco Studio| 3.0 Beta2 | Recommended for developing OpenHarmony applications| +| (Optional) HUAWEI DevEco Device Tool| 3.0 Beta2 | Recommended for developing OpenHarmony smart devices| + + +## Source Code Acquisition + + +### 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.1-Beta --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.1-Beta --no-repo-verify +repo sync -c +repo forall -c 'git lfs pull' +``` + +### Acquiring Source Code from a Mirror + +**Table 2** Mirrors for acquiring source code + +| Source Code| Version| Mirror| SHA-256 Checksum| +| -------------------------------- | ------------ | ------------ | ---------------- | +| Full code base (for mini, small, and standard systems)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/code-v3.1-Beta.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/code-v3.1-Beta.tar.gz.sha256)| +| Hi3516 standard system solution (binary)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/standard_hi3516.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/standard_hi3516.tar.gz.sha256)| +| RK3568 standard system solution (binary)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/standard_rk3568.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/standard_rk3568.tar.gz.sha256)| +| Hi3861 mini system solution (binary)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/hispark_pegasus.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/hispark_pegasus.tar.gz.sha256)| +| Hi3516 mini system solution - LiteOS (binary)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/hispark_taurus.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/hispark_taurus.tar.gz.sha256)| +| Hi3516 mini system solution - Linux (binary)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/hispark_taurus_linux.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/hispark_taurus_linux.tar.gz.sha256)| +| Standard system SDK package (macOS)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/ohos-sdk-mac.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/ohos-sdk-mac.tar.gz.sha256)| +| Standard system SDK package (Windows/Linux)| 3.1 Beta | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/ohos-sdk.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Beta/ohos-sdk.tar.gz.sha256)| +| Compiler toolchain| - | [Download](https://repo.huaweicloud.com/harmonyos/os/2.0/tool_chain/)| | + + +## What's New + +This version has the following updates to OpenHarmony 3.0 LTS. + + +### Feature Updates + +**Table 3** New and enhanced features + +| Subsystem| Standard System| Mini and Small Systems| +| -------- | -------- | -------- | +| Bundle management framework| - I4MBSE: Provides the home screen bundle management client.
- I4MBSF: Supports cache clearing.
- I4MBSG: Supports installation package information query.
- I4MBSD: Supports multi-HAP installation.
- I4MBSH: Supports signature verification during multi-HAP installation.
- I4MBSC: Supports the **srcPath** field for modules and abilities.| NA | +| Distributed Scheduler subsystem| -I4MBRW: Samgr supports intra-process system ability list control.
-I4MBRV: Samgr supports maintenance of the system service status list.
-I4MBRZ: Samgr supports initialization of the full service list.
-I4MBRY: Samgr supports maintenance of the system process status list.
-I4MBRX: Samgr supports loading a specific system service.| NA | +| DeviceProfile subsystem| -I4NY23: Insertion, deletion, and query of local device profiles.
-I4NY1X: Query of remote device profiles.
-I4NY1T: Subscription to remote profile changes.
-I4NY1W: Cross-device profile synchronization.| NA | +| Account subsystem| -I4MBQW: Application account addition and deletion.
-I4MBQV: Restrictions on the basic information about application accounts.
-I4MBQU: Application account subscription and unsubscription.
-I4MBQT: Application account function setting and content modification.
-I4MBQS: Application account information query.
-I4IT3U: Basic information management for application accounts.| NA | +| Pan-sensor subsystem| -I3NJ96: Acceleration sensor data reporting.
-I3NJ8H: Gyroscope sensor data reporting.
-I3NJ7J: Ambient light sensor data reporting.
-I3NJ76: Magnetic field sensor data reporting.
-I4MBRP: Magnetic declination and dip.
-I4MBRQ: Horizontal intensity and total intensity of the magnetic field.| NA | +| USB subsystem| I410OZ:
- Querying the list of connected USB devices.
- Obtaining the temporary permission to access USB devices.
- Setting USB device configurations and interfaces.
- Data transfer using USB devices.| NA | +| Multi-language Runtime subsystem| - I4MBUK: The default runtime of JS/TS is changed from quickjs to ARK.
- I4MBUJ: The memory reclaim capability of ARK runtime is enhanced. The concurrent marking and concurrent compression algorithms are supported. Some regions can be selected for compression GC, reducing the GC pause time by 30%.| NA | +| Globalization subsystem| - Added globalization features: singular and plural rules, string sorting, phone number processing, calendar and local calendar, weights and measures and formatting, locale representations and attributes, time segment formatting, alphabet retrieval, Unicode character attributes, wrapping and line feed.
- Supports system resources and rawfile resources.| NA | +| DSoftBus subsystem| -I4FZ29: DSoftBus provides the Ext API for transmission.
-I4FZ25: DSoftBus supports network switching.| -I4FZ29: DSoftBus provides the Ext API for transmission.
-I4FZ25: DSoftBus supports network switching.| +| Startup subsystem| NA | -I3XGJH: init basic environment building.
-I3XGKV: System parameter management.
-I3XGLN: init script management.
-I3XGMQ: Basic permission management.
-I3XGN8: Boot image building and loading.
-I3XGKV: uevent management.
-I3XGNM: Burning mode.| +| Media subsystem| NA | -I4BX5Z: HiStreamer supports audio playback and control.
-I4BX8A: HiStreamer supports playback of MP3 and WAV audio files.
-I4BX9E: HiStreamer playback engine framework requirements are met.
-I4DK89: HiStreamer plugin framework requirements are met.
-I4DK8D: HiStreamer performance and DFX requirements are met.| +| Graphics subsystem| New design of the OpenHarmony graphics stack:
Added the background rendering feature to the UI framework.
Supports the access to the background rendering module of RenderService from ArkUI components.| NA | +| Kernel subsystem| Kernel (Linux 5.10):
-I4LUG4: Supports Contiguous Memory Area (CMA) reuse. (Currently, only Hi3516D V300 is supported.)
-I4LX4G: Supports anonymous Virtual Memory Area (VMA) naming. (Currently, only Hi3516D V300 is supported.)| -I3ND6Y: Optimized OS kernel and driver startup performance.| +| Startup subsystem| NA | -I3NTCT: The Linux init process supports hot swap.| +| Distributed Data Management subsystem| NA | -I4H3JJ: Provides distributed objects for small-system devices.| +| Telephony subsystem| NA | -I4JQ2N: Provides HTTP JS APIs.
-I4JQ3G: Supports HTTP 2.0.| +| Misc Services subsystem| I4MBQE:
Enables applications to read the system time.
Enables applications to read the system time zone.
Provides time change notifications.
Provides time zone change notifications.
Provides minute change notifications.| NA | +| Compilation and Building subsystem| I4K7E3: Provides a unified compilation command as the compilation entry.
-I4KCNB: Supports the unified gn template.| -I4MBQN: Supports a unified compilation entry and uses **build.sh** to compile mini- and small-system devices.
-I4MBQP: Supports a unified compilation process.
-I4MBQR: Supports unified product configuration.| +| File Storage subsystem| -I4MBS2: Provides StatFS JS interfaces for obtaining the total space and free space of a device.| NA | +| Driver subsystem| -I4L3KK: The drive capability of sensor components is enhanced. The sensor sampling rate can be dynamically configured, the three-axis direction can be statically configured, and the ambient light gain can be adjusted.
-I4L3LF: The sensor driver model capability is enhanced to support cross-process service obtaining and invoking of sensor HDIs.
-I4MBTS: Provides more capabilities for HDF input devices and supports data reporting of joystick devices.
-I4MBTR: The default reference implementation of the Display HDI interface for the standard system is provided based on the DRM display architecture, which helps vendors to adapt the HDI.
-I4HPR7: Provides the hcs macro parsing mechanism. During compilation, the hc-gen tool is used to parse the driver parameters into parameters involved in the macro definition. The driver accesses these macro definition parameters through the hcs macro-format interface.
-I4KVJQ: Supports system-level sleep/wakeup of the Linux and LiteOS kernels.
-I4L3ZZF: Supports synchronous/asynchronous power management invoking and provides a synchronous/asynchronous mechanism for HDF device sleep/wakeup management.| -I4L3KK: The drive capability of sensor components is enhanced. The sensor sampling rate can be dynamically configured, the three-axis direction can be statically configured, and the ambient light gain can be adjusted.
Provides more capabilities for HDF input devices (running on Linux) and supports data reporting of joystick devices.
-I4HPR7: Provides the hcs macro parsing mechanism. During compilation, the hc-gen tool is used to parse the driver parameters into parameters involved in the macro definition. The driver accesses these macro definition parameters through the hcs macro-format interface.
-I4KVJQ: Supports system-level sleep/wakeup of the Linux and LiteOS kernels.
-I4L3ZZF: Supports synchronous/asynchronous power management invoking and provides a synchronous/asynchronous mechanism for HDF device sleep/wakeup management.| +| ArkUI| - I4MBUY: Added **target** to the event to obtain the size.
- I4MBUZ: The **\** component supports cache setting.
- I4MBV1: The **\** component supports synchronous and asynchronous rendering setting.
- I4MBV3: Added the component polymorphic style setting to the style setting feature.
- I4MBV5: Added the pop-up text for menu content extension to the **\** component.
- I4MBV6: Added the custom container components to the component customization feature.
- I4MBV7: Added scroll bar style customization.
- I4MBV8: Added switching forbidden for the **\** component.
- I4MBV9: Added tab bar content customization for the **\** component.
- I4MBVA: Added title bar setting for the **\** component.
- I4MBVB: Added toolbar display/hide control for the **\** component.
- I4MBVC: Added content customization for the **\** component.
- I4MBVD: Added the SysCap declaration compilation feature.
- I4MBVE: Added the JSSDK compilation feature.
- I4MBVF: Added the **Config.json** compilation feature.
- I4MBVG: Added the breakpoint debugging feature for single-instance debugging.
- I4MBVH: Added the attach debugging feature for single-instance debugging.
- I4MBVI: Added the declarative paradigm compilation feature to support compilation and verification.
- I4MBVJ: Added the JS module shared compilation feature.
- I4MBVK: Added the HAR reference and compilation feature.
- I4MBVL: Added the HPM reference and compilation feature.
- I4MBVN: Added the vertical display of the slider bar.
- I4MBVO: Added the content customization feature for the **\** component.
- I4MBVP: Added the drawing capability for the **\** component.
- I4MBVQ: Enhanced the capabilities of the **\** component.
- I4MBVR: Added the touch target setting.
- I4MBVS: Added the support for Lottie animation.
- I4MBVT: Added the feature for obtaining the component size.
- I4MBVU: Added content customization to the **\** component.
- I4MBVV: Added the support for the **\** gesture.
- I4MBVW: Added the inspector capability for UI preview.
- I4MBVX: Added the non-route file preview feature.
- I4MBVY: Added the NAPI preview feature.
- I4MBVZ: Added the declarative paradigm preview feature with the basic preview supported.
- I4MBW2: Added the declarative paradigm hot loading feature for modification to the existing nodes.
- I4MBW3: Added the declarative paradigm hot loading feature for node addition.
- I4MBW4: Added the declarative paradigm hot loading feature for node deletion.
- I4MBW5: Added the component preview feature and the page component preview.
Added the universal attribute **touchable** to specify whether a component is touchable.
Added the basic component **\**.
Added the basic component **\**.
Added the basic component **\