Skip to content

D
Docs

OpenHarmony / Docs
1 年多 前同步成功

通知 159
Star 292
Fork 28
D
Docs
未验证 提交 a571f02a 编写于 作者: O openharmony_ci 提交者： Gitee
浏览文件
操作

!1344 1084 Done! 3.1 Beta Release Notes 

Merge pull request !1344 from wusongqing/master
上级 cce33c52 cbdf0fab
展开全部 隐藏空白更改
内联 并排
Showing with 966 addition and 30 deletion
en/contribute/template/readme-template.md 0 → 100644
浏览文件 @ a571f02a
# ***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
en/contribute/template/xxboard-template.md 0 → 100644
浏览文件 @ a571f02a
# ***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.*
en/release-notes/OpenHarmony-v3.1-beta.md 0 → 100644
浏览文件 @ a571f02a
此差异已折叠。
en/release-notes/Readme.md
浏览文件 @ a571f02a
# OpenHarmony Release Notes
## OpenHarmony 3.x Releases
[OpenHarmony v3.0 LTS (2021-09-30)](OpenHarmony-v3.0-LTS.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 2.x Releases
- [OpenHarmony v2.2 beta2 (2021-08-04)](OpenHarmony-v2.2-beta2.md)
- [OpenHarmony 2.0 Canary (2021-06-02)](openharmony-2-0-canary.md)
- [OpenHarmony 2.0 Canary (2021-06-02)](OpenHarmony-2-0-canary.md)
## OpenHarmony 1.x Releases
- [OpenHarmony v1.1.3 LTS (2021-09-30)](OpenHarmony-v1-1-3-LTS.md)
- [OpenHarmony v1.1.2 LTS (2021-08-04)](OpenHarmony-v1.1.2-LTS.md)
- [OpenHarmony 1.1.1 LTS (2021-06-22)](OpenHarmony-1-1-1-LTS.md)
- [OpenHarmony 1.1.0 LTS (2021-04-01)](openharmony-1-1-0-lts.md)
- [OpenHarmony 1.1.0 LTS (2021-04-01)](OpenHarmony-1-1-0-LTS.md)
- [OpenHarmony 1.0 (2020-09-10)](OpenHarmony-1-0.md)
en/release-notes/api-change/v3.1-beta/changelog-v3.1-beta.md 0 → 100644
浏览文件 @ a571f02a
# Changelog
##### Key API/Component Changes
## IPC Subsystem
#### cl.rpc.1 sendRequest Return Value Type Change
##### Change Impact
The **sendRequest** method in the JS modules **RemoteProxy** and **RemoteObject** is changed to an asynchronous interface. The new version uses a **Promise** object to return a **SendRequestResult** instance. Existing applications need to be adapted.
##### Key API/Component Changes
```
Module: ohos.rpc.IRemoteObject, ohos.rpc.RemoteProxy and ohos.rpc.RemoteObject
Old method: sendRequest(code: number, data: MessageParcel, reply: MessageParcel, options: MessageOption): boolean
New method:
sendRequest(code: number, data: MessageParcel, reply: MessageParcel, options: MessageOption): Promise<SendRequestResult>
```
**Adaptation Guidelines**
```
import rpc from "@ohos.rpc"
let option = new rpc.MessageOption()
let data = rpc.MessageParcel.create()
let reply = rpc.MessageParcel.create()
proxy.sendRequest(1, data, reply, option)
.then(function(result) {
console.info("send request done")
if (result.errCode === 0) {
// read result from result.reply
}
})
.catch(function(e) {
console.error("send request failed: " + e)
})
.finally(() => {
data.reclaim()
reply.reclaim()
})
```
en/release-notes/api-change/v3.1-beta/native-apidiff-v3.1-beta.md 0 → 100644
浏览文件 @ a571f02a
# Native API Differences
This document describes the changes of APIs in OpenHarmony 3.1 Beta when compared with OpenHarmony 3.0 LTS.
## Standard System API Changes
| Module| API| Change Type| Change Description|
| ------------------ | ------------------------------------------------------------ | -------- | ------------------------------------------------- |
| bundle | napi_value ClearBundleCache(napi_env env, napi_callback_info info) | Added| Added the API for clearing the cache of an application.|
| bundle | napi_value SetApplicationEnabled(napi_env env, napi_callback_info info) | Added| Added the API for setting whether to enable an application.|
| bundle | napi_value SetAbilityEnabled(napi_env env, napi_callback_info info) | Added| Added the API for setting whether to enable an ability.|
| innerbundlemanager | napi_value JSGetLauncherAbilityInfos(napi_env env, napi_callback_info info) | Added| Added the API for obtaining the launcher ability information by **bundleName**.|
| innerbundlemanager | napi_value JSLauncherServiceOn(napi_env env, napi_callback_info info) | Added| Added the API for subscribing to bundle status changes.|
| innerbundlemanager | napi_value JSLauncherServiceOff(napi_env env, napi_callback_info info) | Added| Added the API for unsubscribing from bundle status changes.|
| innerbundlemanager | napi_value JSGetAllLauncherAbilityInfos(napi_env env, napi_callback_info info) | Added| Added the API for obtaining the application abilities on all launchers by **userId**.|
| innerbundlemanager | napi_value JSGetShortcutInfos(napi_env env, napi_callback_info info) | Added| Added the API for obtaining the application shortcut information by **bundleName**.|
zh-cn/contribute/template/README-template.md
浏览文件 @ a571f02a
# xxx子系统/组件
# xxx子系统/部件
- [简介](#简介)
- [目录](#目录)
......@@ -10,7 +10,7 @@
- [Changelog](#changelog)
- [相关仓](#相关仓)
【标题说明】根据当前Readme的类型，使用 **子系统**或者 **组件**。
【标题说明】根据当前Readme的类型，使用 **子系统**或者 **部件**。
![子系统readme](figures/figure01.png)
......@@ -23,9 +23,9 @@
**内容介绍：**从以下几个方面介绍该子系统：出现背景（在整个OpenHarmony架构中的作用）、实现的功能、使用场景、支持的设备等。
**架构图：**使用架构图说明该子系统【组件】架构，对架构中的主要组成部分进行必要的解释说明
**架构图：**使用架构图说明该子系统【部件】架构，对架构中的主要组成部分进行必要的解释说明
**如果本组件仓库只是子系统一部分，需要理解子系统相关概念，建议给出：**
**如果本部件仓库只是子系统一部分，需要理解子系统相关概念，建议给出：**
**更多XXX子系统相关概念，请参考：xxx。(给出到子系统readme的链接)**
......@@ -54,13 +54,12 @@
| A.3.2 | 表格有表头，至少为2行2列，避免出现单行或单列表。 |
| A.3.3 | 表格无内容用“_”，不出现空白的单元格。 |
| **A.4** | **图形** |
| A.4.2 | 避免涉及宗教信仰类截图。 |
| A.4.3 | 图文并茂，行文应力求简明，如有可能，配以适当的图，表。 |
| A.4.4 | 图形有图注（不可直接粘贴图形），图注风格一致，采用名词或名词词组形式。 |
| A.4.5 | 图形应清晰可辩识，信息表达完整，易于阅读。如流程图不可缺少“开始”和“结束”。 |
| A.4.6 | 图形逻辑清晰，图文配合使用，切忌图文分离。 |
| A.4.7 | 图片的高度建议在640px左右，宽度不超过820px，一般为.png格式，图片的大小建议不超过150k。 |
| A.4.8 | 图形建议尽量不要用文字，中文图用中文，英文图用英文。 |
| A.4.1 | 避免涉及宗教信仰类截图。 |
| A.4.2 | 图形有图注（不可直接粘贴图形），图注风格一致，采用名词或名词词组形式。 |
| A.4.3 | 图形应清晰可辩识，信息表达完整，易于阅读。如流程图不可缺少“开始”和“结束”。 |
| A.4.4 | 图形逻辑清晰，图文配合使用，切忌图文分离。 |
| A.4.5 | 图片的高度建议在640px左右，宽度不超过820px，一般为.png格式，图片的大小建议不超过150k。 |
| A.4.6 | 图形建议尽量不要用文字，中文图用中文，英文图用英文。 |
架构图参考如下，注意需要绘图的 **颜色，格式有规范要求**，请参照：
......@@ -104,7 +103,7 @@
## 编译构建/使用方法
【写作要求】 可选，子系统Readme不需要提供，对于组件仓的Readme，根据实际情况，提供编译构建的说明。
【写作要求】 可选，子系统Readme不需要提供，对于部件仓的Readme，根据实际情况，提供编译构建的说明。
## 说明
......@@ -153,10 +152,10 @@
【写作要求】 **必选**。列出当前仓所在子系统的所有相关仓的链接，并加粗标识当前的仓
[xxx子系统](https://gitee.com/openharmony)
示例：
[组件1](https://gitee.com/openharmony)
[内核子系统](https://gitee.com/openharmony/docs/blob/master/zh-cn/readme/%E5%86%85%E6%A0%B8%E5%AD%90%E7%B3%BB%E7%BB%9F.md)
**[组件2](https://gitee.com/openharmony)**
[drivers\_liteos](https://gitee.com/openharmony/drivers_liteos/blob/master/README_zh.md)
[组件3](https://gitee.com/openharmony)
\ No newline at end of file
**kernel\_liteos\_a**
\ No newline at end of file
zh-cn/contribute/template/xxboard-template.md
浏览文件 @ a571f02a
......@@ -15,7 +15,7 @@
**图片名称以开发板名称命名。*
*参考文档：https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/quick-start/oem_minitinier_des_3861.md*
*参考文档：https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/quick-start/quickstart-lite-introduction-hi3861.md*
********
## 开发板规格
......@@ -33,7 +33,7 @@
*【写作说明】支持的OpenHarmony关键特性列表。*
## 引脚定义
*【写作说明】介绍单板的管脚定义等，描述单板I/O引脚，PIN，以及如何配置PIN、如何使用PIN连接外部组件。*
*【写作说明】介绍单板的管脚定义等，描述单板I/O引脚，以及如何配置PIN、如何使用PIN连接外部组件。*
## 搭建开发环境
......
zh-cn/release-notes/OpenHarmony-v3.1-beta.md
浏览文件 @ a571f02a
......@@ -105,7 +105,7 @@ repo forall -c 'git lfs pull'
| 语言编译器运行时子系统 | -&nbsp;I4MBUK：JavaScript/TypeScript默认运行时从quickjs替换为方舟运行时。<br/>-&nbsp;I4MBUJ：方舟运行时内存回收功能增强，支持并发标记算法以及并发压缩算法，支持选择部分region进行压缩GC（Partial&nbsp;CompressionGC），优化GC&nbsp;pause&nbsp;time减少30%。 | NA |
| 全球化子系统 | -&nbsp;支持国际化特性：单复数规则、字符串排序、电话号码处理、日历&amp;本地历法、度量衡体系和格式化、区域表示和属性、时间段格式化、字母表检索、unicode字符属性、断词换行<br/>-&nbsp;支持系统资源、rawfile资源 | NA |
| 分布式软总线子系统 | -I4FZ29：软总线提供传输ExtAPI接口<br/>-I4FZ25：软总线支持网络切换组网 | -I4FZ29：软总线提供传输ExtAPI接口<br/>-I4FZ25：软总线支持网络切换组网 |
| 启动子系统 | NA | -I3XGJH：init基础环境构建<br/>-I3XGKV：sytemparameter管理<br/>-I3XGLN：init&nbsp;脚本管理<br/>-I3XGMQ：基础权限管理<br/>-I3XGN8：bootimage构建和加载<br/>-I3XGKV：uevent&nbsp;管理<br/>-I3XGKV：sytemparameter管理<br/>-I3XGNM：烧写模式支持 |
| 启动子系统 | NA | -I3XGJH：init基础环境构建<br/>-I3XGKV：system parameter管理<br/>-I3XGLN：init&nbsp;脚本管理<br/>-I3XGMQ：基础权限管理<br/>-I3XGN8：bootimage构建和加载<br/>-I3XGKV：uevent&nbsp;管理<br/>-I3XGNM：烧写模式支持 |
| 媒体子系统 | NA | -I4BX5Z：HiStreamer支持音频播放和控制<br/>-I4BX8A：HiStreamer支持常见音频格式mp3/wav的播放<br/>-I4BX9E：HiStreamer播放引擎框架需求<br/>-I4DK89：HiStreamer插件框架需求<br/>-I4DK8D：HiStreamer性能和DFX需求 |
| 图形子系统 | 全新设计OpenHarmony&nbsp;图形栈：<br/>新增UI框架渲染后端特性支持<br/>新增ArkUI控件接入RenderService渲染后端 | NA |
| 内核子系统 | 内核（Linux&nbsp;5.10）<br/>-I4LUG4&nbsp;CMA内存区域复用（目前仅支持Hi3516DV300，暂不支持RK平台）<br/>-I4LX4G&nbsp;支持anonymous&nbsp;vma命名（目前仅支持Hi3516DV300，暂不支持RK平台） | -I3ND6Y：【性能】OS内核&amp;驱动启动优化 |
......@@ -142,7 +142,7 @@ _[Changelog](api-change/v3.1-beta/changelog-v3.1-beta.md)_
#### 新增Samples
**表1** Samples列表
**表4** Samples列表
| 名称 | 简介 | 开发语言 |
| -------- | -------- | -------- |
......@@ -165,13 +165,13 @@ _[Changelog](api-change/v3.1-beta/changelog-v3.1-beta.md)_
| [JS页面弹窗](https://gitee.com/openharmony/app_samples/tree/master/UI/JsDialog) | JS中支持用户自定义弹窗，&lt;dialog/&gt;组件作为容器组件，用户可以自定义弹窗的样式和布局。本示例完成了添加和删除联系人功能，在添加和删除时使用自定义弹窗来实现。 | JS |
| [JSList商品列表](https://gitee.com/openharmony/app_samples/tree/master/UI/JsList) | 本示例展示了list控件在商品分类列表中的应用，在listGroup里采用两个list-item分别展示了Group收缩和Group展开的两种列表形态，点击后会弹出相应的list列表。 | JS |
| [JSPanel](https://gitee.com/openharmony/app_samples/tree/master/UI/JsPanel) | JS提供一种轻量级的内容展示面板，此面板可滑动，可自定义触发方式、弹出高度等属性。本示例通过可滑动面板展示了商品详细信息与平台保障。 | JS |
| [JsSvg](https://gitee.com/openharmony/app_samples/tree/master/UI/JsSvg) | 本示例展示了JS中&lt;svg/>组件及其子组件的使用，包括<svg\>、<rect\>、<circle\>、<ellipse\>、<path\>、<line\>、<polygon\>、<polyline\>、<text\>、<animate\>、<animateTransform\> 。 | JS |
| [JsSvg](https://gitee.com/openharmony/app_samples/tree/master/UI/JsSvg) | 本示例展示了JS中<svg/>组件及其子组件的使用，包括<svg\>、<rect\>、<circle\>、<ellipse\>、<path\>、<line\>、<polygon\>、<polyline\>、<text\>、<animate\>、<animateTransform\> 。 | JS |
| [JS自定义组件](https://gitee.com/openharmony/app_samples/tree/master/UI/JSUICustomComponent) | 自定义组件是用户根据业务需求，将已有的组件组合，封装成的新组件，可以在工程中多次调用，提高代码的可读性。本示例展示了JS中自定义组件的使用，包括基本用法、自定义事件、Props和事件参数。 | JS |
#### 新增Codelabs
**表2** Codelabs列表
**表5** Codelabs列表
| 名称 | 简介 | 开发语言 |
| -------- | -------- | -------- |
......@@ -190,7 +190,7 @@ _[Changelog](api-change/v3.1-beta/changelog-v3.1-beta.md)_
## 修复缺陷列表
**表4** 修复缺陷ISSUE列表
**表6** 修复缺陷ISSUE列表
| ISSUE单号 | 问题描述 |
| -------- | -------- |
......@@ -203,7 +203,7 @@ _[Changelog](api-change/v3.1-beta/changelog-v3.1-beta.md)_
## 遗留缺陷列表
**表6** 遗留缺陷列表
**表7** 遗留缺陷列表
| ISSUE | 问题描述 | 影响 | 计划解决日期 |
| -------- | -------- | -------- | -------- |
......
zh-cn/release-notes/api-change/v3.1-beta/js-apidiff-v3.1-beta.md
浏览文件 @ a571f02a
# JS API 差异报告
OpenHarmony 3.1 Beta1相较于OpenHarmony 3.0 LTS版本的API变更如下:
OpenHarmony 3.1 Beta相较于OpenHarmony 3.0 LTS版本的API变更如下:
## 标准系统接口变更
......@@ -43,7 +43,7 @@ OpenHarmony 3.1 Beta1相较于OpenHarmony 3.0 LTS版本的API变更如下:
| Ark UI框架-画布组件 | Lottie | 新增 | 新增Lottie库的支持。 |
| Ark UI框架-全局UI方法 | ActionSheet | 新增 | 新增列表选择弹窗。 |
| USB服务-usb | getDevices(): Array<Readonly<USBDevice>> | 新增 | 新增获取USB设备列表的接口 |
| USB服务-usb | connectDevice(device: USBDevice): Readonly<USBDevicePipe> | 新增 | 新增根据{@link getDevices()}返回的设备信息打开USB设备的接口 |
| USB服务-usb | connectDevice(device: USBDevice): Readonly<USBDevicePipe> | 新增 | 新增根据**getDevices()**返回的设备信息打开USB设备的接口 |
| USB服务-usb | hasRight(deviceName: string): boolean | 新增 | 新增判断是否有权访问设备的接口 |
| USB服务-usb | requestRight(deviceName: string): Promise<boolean> | 新增 | 新增请求给定软件包的临时权限以访问设备的接口 |
| USB服务-usb | claimInterface(pipe: USBDevicePipe, iface: USBInterface, force?: boolean): number | 新增 | 新增获取接口的接口 |
......
zh-cn/release-notes/api-change/v3.1-beta/native-apidiff-v3.1-beta.md
浏览文件 @ a571f02a
......@@ -4,7 +4,7 @@ OpenHarmony 3.1 Beta相较于OpenHarmony 3.0 LTS版本的API变更如下:
## 标准系统接口变更
| 模块名称 | 接口名称 | 变更类型 | 变更类型 |
| 模块名称 | 接口名称 | 变更类型 | 变更说明 |
| ------------------ | ------------------------------------------------------------ | -------- | ------------------------------------------------- |
| bundle | napi_value ClearBundleCache(napi_env env, napi_callback_info info) | 新增 | 新增清理应用缓存接口 |
| bundle | napi_value SetApplicationEnabled(napi_env env, napi_callback_info info) | 新增 | 新增设置应用使能接口 |
......
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或