Update docs against 22245+22164+22211

Signed-off-by: wusongqing<wusongqing@huawei.com>

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)
-

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.');

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) => {

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.

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