diff --git a/en/application-dev/application-models/component-startup-rules.md b/en/application-dev/application-models/component-startup-rules.md index bddf63dbc69ea243733e6f60f67f92a854833bf7..2db47d35f24df7d3eb155bb4ab2540f4a1af7ce0 100644 --- a/en/application-dev/application-models/component-startup-rules.md +++ b/en/application-dev/application-models/component-startup-rules.md @@ -26,7 +26,7 @@ In view of this, OpenHarmony formulates a set of component startup rules, as fol - If the **exported** field of the target component is **false**, verify the **ohos.permission.START_INVISIBLE_ABILITY** permission. - For details, see [Component exported Configuration](../quick-start/module-configuration-file.md#abilities). -- **Before starting a component of a background application, verify the BACKGROUND permission.** +- **Before starting a UIAbility component of a background application, verify the BACKGROUND permission.** - An application is considered as a foreground application only when the application process gains focus or its UIAbility component is running in the foreground. - Verify the **ohos.permission.START_ABILITIES_FROM_BACKGROUND** permission. @@ -45,7 +45,9 @@ In view of this, OpenHarmony formulates a set of component startup rules, as fol The rules for starting components on the same device vary in the following scenarios: -- Starting or connecting to the UIAbility, ServiceExtensionAbility, and DataShareExtensionAbility components +- Starting the UIAbility component + +- Starting the ServiceExtensionAbility and DataShareExtensionAbility components - Using **startAbilityByCall()** to start the UIAbility component @@ -56,9 +58,10 @@ In view of this, OpenHarmony formulates a set of component startup rules, as fol The rules for starting components on a different device vary in the following scenarios: -- Starting or connecting to the UIAbility, ServiceExtensionAbility, and DataShareExtensionAbility components +- Starting the UIAbility component + +- Starting the ServiceExtensionAbility and DataShareExtensionAbility components - Using **startAbilityByCall()** to start the UIAbility component ![component-startup-rules](figures/component-startup-inter-stage.png) - diff --git a/en/application-dev/application-models/figures/component-startup-inner-stage.png b/en/application-dev/application-models/figures/component-startup-inner-stage.png index 00514276f4ac3eb8ead650e5858cebb0a344d2c6..9761b9879e513f0e1ad942b5fe18997f1331c9e5 100644 Binary files a/en/application-dev/application-models/figures/component-startup-inner-stage.png and b/en/application-dev/application-models/figures/component-startup-inner-stage.png differ diff --git a/en/application-dev/application-models/figures/component-startup-inter-stage.png b/en/application-dev/application-models/figures/component-startup-inter-stage.png index a6f79e6803edc160e5570729456569f46cc80967..517407f6b557648db78a0de89431d8b18f8e2b59 100644 Binary files a/en/application-dev/application-models/figures/component-startup-inter-stage.png and b/en/application-dev/application-models/figures/component-startup-inter-stage.png differ diff --git a/en/application-dev/application-models/start-pageability-from-stage.md b/en/application-dev/application-models/start-pageability-from-stage.md index bd6a11187fdfbc81c63bcc6601f8a8e82b0dbe4c..123e15c45614f83ece1c11db87827535b2ac4937 100644 --- a/en/application-dev/application-models/start-pageability-from-stage.md +++ b/en/application-dev/application-models/start-pageability-from-stage.md @@ -8,6 +8,10 @@ This topic describes how the two application components of the stage model start A UIAbility starts a PageAbility in the same way as it starts another UIAbility. +> **NOTE** +> +> In the FA model, **abilityName** consists of **bundleName** and **AbilityName**. For details, see the code snippet below. + ```ts import UIAbility from '@ohos.app.ability.UIAbility'; @@ -25,7 +29,7 @@ export default class EntryAbility extends UIAbility { }); let want = { bundleName: "com.ohos.fa", - abilityName: "EntryAbility", + abilityName: "com.ohos.fa.EntryAbility", }; this.context.startAbility(want).then(() => { console.info('Start Ability successfully.'); diff --git a/en/application-dev/application-models/start-uiability-from-fa.md b/en/application-dev/application-models/start-uiability-from-fa.md index 42d8e034cd6519643423bb289217d1aa140a18d4..8520cf94be0d0d21999af3175848a37edac85c52 100644 --- a/en/application-dev/application-models/start-uiability-from-fa.md +++ b/en/application-dev/application-models/start-uiability-from-fa.md @@ -14,7 +14,7 @@ import featureAbility from '@ohos.ability.featureAbility'; let parameter = { "want": { bundleName: "com.ohos.stage", - abilityName: "com.ohos.stage.EntryAbility" + abilityName: "EntryAbility" } }; featureAbility.startAbility(parameter).then((code) => { diff --git a/en/application-dev/application-models/want-overview.md b/en/application-dev/application-models/want-overview.md index cf5cac43999a5efbe59659252b6b3db325cacd8a..9260c71666f3c47181756ba205c265391d989b05 100644 --- a/en/application-dev/application-models/want-overview.md +++ b/en/application-dev/application-models/want-overview.md @@ -12,7 +12,7 @@ ## Types of Want -- **Explicit Want**: If **abilityName** and **bundleName** are specified in the **want** parameter when starting an an application component, explicit Want is used. +- **Explicit Want**: If **abilityName** and **bundleName** are specified in the **want** parameter when starting an application component, explicit Want is used. Explicit Want is usually used to start a known target application component in the same application. The target application component is started by specifying **bundleName** of the application where the target application component is located and **abilityName** in the **Want** object. When there is an explicit object to process the request, explicit Want is a simple and effective way to start the target application component. @@ -24,7 +24,7 @@ } ``` -- **Implicit Want**: If **abilityName** is not specified in the **want** parameter when starting the an application component, implicit Want is used. +- **Implicit Want**: If **abilityName** is not specified in the **want** parameter when starting an application component, implicit Want is used. Implicit Want can be used when the object used to process the request is unclear and the current application wants to use a capability (defined by the [skills tag](../quick-start/module-configuration-file.md#skills)) provided by another application. The system matches all applications that declare to support the capability. For example, for a link open request, the system matches all applications that support the request and provides the available ones for users to select. @@ -47,6 +47,7 @@ > - An application component that meets the conditions is matched. That application component is started. > - Multiple application components that meet the conditions are matched. A dialog box is displayed for users to select one of them. > - > - If the **want** parameter passed does not contain **abilityName** or **bundleName**, the ServiceExtensionAbility components of all applications cannot be started through implicit Want. + > - In the scenario for starting the ServiceExtensionAbility component: + > - If the **want** parameter passed in contains **abilityName**, the ServiceExtensionAbility component cannot be started through implicit Want. > - > - If the **want** parameter passed contains **bundleName**, the **startServiceExtensionAbility()** method can be used to implicitly start ServiceExtensionAbility. By default, ServiceExtensionAbility with the highest priority is returned. If all the matching ServiceExtensionAbility components have the same priority, the first ServiceExtensionAbility is returned. + > - If the **want** parameter passed in contains **bundleName**, the **startServiceExtensionAbility()** method can be used to implicitly start the ServiceExtensionAbility component. By default, the ServiceExtensionAbility component with the highest priority is returned. If all the matching ServiceExtensionAbility components have the same priority, the first ServiceExtensionAbility component is returned. diff --git a/en/release-notes/OpenHarmony-v4.0-beta2.md b/en/release-notes/OpenHarmony-v4.0-beta2.md index 892d95e83883ddd30781465bd87481d9897f8bbc..56acfca9e0916441a7ca86aee7adcb19da88747c 100644 --- a/en/release-notes/OpenHarmony-v4.0-beta2.md +++ b/en/release-notes/OpenHarmony-v4.0-beta2.md @@ -40,7 +40,7 @@ The standard system capabilities of OpenHarmony 4.0 are continuously improved. A - RDB store NDK interfaces are provided. These interfaces are used for transaction addition, deletion, modification, and query, data encryption, hierarchical data protection, and backup and restore. -- The system can automatically selects a Bluetooth or Wi-Fi P2P channel for synchronization of key-value and distributed data objects based on the data volume. +- The system can automatically select a Bluetooth or Wi-Fi P2P channel for synchronization of key-value and distributed data objects based on the data volume. ### DSoftBus @@ -391,7 +391,7 @@ This version has the following updates to OpenHarmony 4.0 Beta1. ### API -For details about the API changes over OpenHarmony 4.0 Beta1, see [API Differences](/api-diff/v4.0-beta2/Readme-EN.md). A few API changes may affect applications developed using API version 9 or earlier. For details about the change impact and adaptation guide, see [Changelogs](changelogs/v4.0-beta2/Readme-EN.md). +For details about the API changes over OpenHarmony 4.0 Beta1, see [API Differences](https://gitee.com/openharmony/docs/blob/OpenHarmony-4.0-Beta2/en/release-notes/api-diff/v4.0-beta2/Readme-EN.md). A few API changes may affect applications developed using API version 9 or earlier. For details about the change impact and adaptation guide, see [Changelogs](https://gitee.com/openharmony/docs/blob/OpenHarmony-4.0-Beta2/en/release-notes/changelogs/v4.0-beta2/Readme-EN.md). ### Feature Updates