Update docs against 12374

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

en/application-dev/ability/Readme-EN.md → en/application-dev/ability-deprecated/Readme-EN.md

 # Ability Development
 
+> **NOTE**<br/>
+> This folder is deprecated. Read [Application Models](../application-models/Readme-EN.md) instead.
+
 - [Ability Framework Overview](ability-brief.md)
 - [Context Usage](context-userguide.md)
 - FA Model

en/application-dev/ability/ability-assistant-guidelines.md → en/application-dev/ability-deprecated/ability-assistant-guidelines.md

@@ -73,10 +73,10 @@ The ability assistant enables you to start applications, atomic services, and te
   | -a/--all          | -                    | Prints ability information in all missions.                                |
   | -l/--mission-list | type (All logs are printed if this parameter is left unspecified.)| Prints mission stack information.<br>The following values are available for **type**:<br>- NORMAL <br>- DEFAULT_STANDARD<br>- DEFAULT_SINGLE<br>- LAUNCHER |
   | -e/--extension    | elementName          | Prints extended component information.                                          |
-  | -u/--userId       | UserId               | Prints stack information of a specified user ID. This parameter must be used together with other parameters. <br/>Example commands: aa **dump -a -u 100** and **aa dump -d -u 100**. |
-  | -d/--data         | - | Prints Data ability information.                                          |
-  | -i/--ability      | AbilityRecord ID     | Prints detailed information about a specified ability.                                     |
-  | -c/--client       | - | Prints detailed ability information. This parameter must be used together with other parameters. <br/>Example commands: **aa dump -a -c** and **aa dump -i 21 -c**. |
+  | -u/--userId       | UserId               | Prints stack information of a specified user ID. This parameter must be used together with other parameters. <br/>Example commands: aa **dump -a -u 100** and **aa dump -d -u 100**.|
+  | -d/--data         | -                    | Prints Data ability information.                                          |
+  | -i/--ability      | AbilityRecord ID     | Prints detailed information about a specified ability.                                   |
+  | -c/--client       | -                    | Prints detailed ability information. This parameter must be used together with other parameters. <br/>Example commands: **aa dump -a -c** and **aa dump -i 21 -c**.|
   
   **Method**
   

en/application-dev/ability/ability-delegator.md → en/application-dev/ability-deprecated/ability-delegator.md

@@ -46,19 +46,19 @@ For details about how to use DevEco Studio to start the test framework, see [Ope
 
 ## Introduction to TestRunner
 
-**TestRunner** is the entry class of the test framework test process. When the test process is started, the system calls related APIs in **TestRunner**. You need to inherit this class and override the **onPrepare** and **onRun** APIs. When creating an application template, DevEco Studio initializes the default **TestRunner** and starts the default **TestAbility** in the **onRun** API. You can modify the test code of **TestAbility** or override **onPrepare** and **onRun** in **TestRunner** to implement your own test code. For details, see [TestRunner](../reference/apis/js-apis-testRunner.md).
+**TestRunner** is the entry class of the test framework test process. When the test process is started, the system calls related APIs in **TestRunner**. You need to inherit this class and override the **onPrepare** and **onRun** APIs. When creating an application template, DevEco Studio initializes the default **TestRunner** and starts the default **TestAbility** in the **onRun** API. You can modify the test code of **TestAbility** or override **onPrepare** and **onRun** in **TestRunner** to implement your own test code. For details, see [TestRunner](../reference/apis/js-apis-application-testRunner.md).
 
 ## Introduction to AbilityDelegatorRegistry
 
-**AbilityDelegatorRegistry** is the **AbilityDelegator** repository class provided by the test framework. You can use **AbilityDelegatorRegistry** to obtain an **AbilityDelegator** instance and the input and generated parameters **AbilityDelegatorArgs** during the test. You can use **AbilityDelegator** to invoke the function set provided by the test framework for testing and verification. For details, see [AbilityDelegatorRegistry](../reference/apis/js-apis-abilityDelegatorRegistry.md).
+**AbilityDelegatorRegistry** is the **AbilityDelegator** repository class provided by the test framework. You can use **AbilityDelegatorRegistry** to obtain an **AbilityDelegator** instance and the input and generated parameters **AbilityDelegatorArgs** during the test. You can use **AbilityDelegator** to invoke the function set provided by the test framework for testing and verification. For details, see [AbilityDelegatorRegistry](../reference/apis/js-apis-application-abilityDelegatorRegistry.md).
 
 ## Introduction to AbilityDelegatorArgs
 
-**AbilityDelegatorArgs** is a test parameter class provided by the test framework. You can use **AbilityDelegatorArgs** to obtain the parameters passed and generated during the test. For details, see [AbilityDelegatorArgs](../reference/apis/js-apis-application-abilityDelegatorArgs.md).
+**AbilityDelegatorArgs** is a test parameter class provided by the test framework. You can use **AbilityDelegatorArgs** to obtain the parameters passed and generated during the test. For details, see [AbilityDelegatorArgs](../reference/apis/js-apis-inner-application-abilityDelegatorArgs.md).
 
 ## Introduction to AbilityMonitor
 
-**AbilityMonitor** is provided by the test framework for binding to and listening for abilities. You can use **AbilityMonitor** to bind to an **Ability** instance and add **AbilityMonitor** to the listening list. When **AbilityMonitor** is bound to an ability, the creation and lifecycle changes of the ability will trigger the related callback in **AbilityMonitor**. You can test and verify the ability in these callbacks. For details, see [AbilityMonitor](../reference/apis/js-apis-application-abilityMonitor.md).
+**AbilityMonitor** is provided by the test framework for binding to and listening for abilities. You can use **AbilityMonitor** to bind to an **Ability** instance and add **AbilityMonitor** to the listening list. When **AbilityMonitor** is bound to an ability, the creation and lifecycle changes of the ability will trigger the related callback in **AbilityMonitor**. You can test and verify the ability in these callbacks. For details, see [AbilityMonitor](../reference/apis/js-apis-inner-application-abilityMonitor.md).
 
 **Example**
 
@@ -131,7 +131,7 @@ abilityDelegator.startAbility(want, (err, data) => {
 
 ### Scheduling the Ability Lifecycle
 
-**AbilityDelegator** provides APIs to display and schedule the ability lifecycle and supports the foreground and background. It works with **AbilityMonitor** to listen for the ability lifecycle. For details, see [AbilityDelegator](../reference/apis/js-apis-application-abilityDelegator.md).
+**AbilityDelegator** provides APIs to display and schedule the ability lifecycle and supports the foreground and background. It works with **AbilityMonitor** to listen for the ability lifecycle. For details, see [AbilityDelegator](../reference/apis/js-apis-inner-application-abilityDelegator.md).
 
 ### Running a Shell Command
 

en/application-dev/ability/context-userguide.md → en/application-dev/ability-deprecated/context-userguide.md

@@ -4,12 +4,12 @@
 
 **Context** provides the capability of obtaining contextual information of an application.
 
-The OpenHarmony application framework has two models: Feature Ability (FA) model and stage model. Correspondingly, there are two sets of context mechanisms. **application/BaseContext** is a common context base class. It uses the **stageMode** attribute to specify whether the context is used for the stage model.
-
-- FA model 
-
-  Only the methods in **app/Context** can be used for the context in the FA model. Both the application-level context and ability-level context are instances of this type. If an ability-level method is invoked in the application-level context, an error occurs. Therefore, you must pay attention to the actual meaning of the **Context** instance.
+ The OpenHarmony application framework has two models: Feature Ability (FA) model and stage model. Correspondingly, there are two sets of context mechanisms. **application/BaseContext** is a common context base class. It uses the **stageMode** attribute to specify whether the context is used for the stage model.
 
+- FA model
+  
+Only the methods in **app/Context** can be used for the context in the FA model. Both the application-level context and ability-level context are instances of this type. If an ability-level method is invoked in the application-level context, an error occurs. Therefore, you must pay attention to the actual meaning of the **Context** instance.
+  
 - Stage model 
   
   The stage model has the following types of contexts: **application/Context**, **application/ApplicationContext**, **application/AbilityStageContext**, **application/ExtensionContext**, **application/AbilityContext**, and **application/FormExtensionContext**. For details about these contexts and how to use them, see [Context in the Stage Model](#context-in-the-stage-model).
@@ -239,7 +239,7 @@ export default class MainAbility extends Ability {
 
 ### application/FormExtensionContext
 
-For details, see [FormExtensionContext](../reference/apis/js-apis-formextensioncontext.md).
+For details, see [FormExtensionContext](../reference/apis/js-apis-inner-application-formExtensionContext.md).
 
 ### Obtaining the Context on an ArkTS Page
 

en/application-dev/ability/continuationmanager.md → en/application-dev/ability-deprecated/continuationmanager.md

@@ -188,7 +188,7 @@ As the entry of the ability continuation capability, **continuationManager** is
     }
     ```
 
-    The preceding multi-device collaboration operation is performed across devices in the stage model. For details about this operation in the FA model, see [Page Ability Development](https://gitee.com/openharmony/docs/blob/master/en/application-dev/ability/fa-pageability.md).
+    The preceding multi-device collaboration operation is performed across devices in the stage model. For details about this operation in the FA model, see [Page Ability Development](fa-pageability.md).
 
     You can also instruct the device selection module to update the device connection state. The sample code is as follows:
 

en/application-dev/ability/fa-brief.md → en/application-dev/ability-deprecated/fa-brief.md

@@ -38,4 +38,6 @@ When an ability is started, an application process as well as a thread for this
 
 For details about the project directory structure of the FA model, see [OpenHarmony Project Overview](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-project-overview-0000001218440650#section4154183910141).
 
-For details about how to configure the application package structure of the FA model, see [Application Package Structure Configuration File](../quick-start/package-structure.md).
+For details about how to configure the application package structure of the FA model, see [Application Package Structure Configuration File](../quick-start/application-configuration-file-overview-fa.md).
+
+ <!--no_check--> 
\ No newline at end of file

en/application-dev/ability/fa-dataability.md → en/application-dev/ability-deprecated/fa-dataability.md

@@ -148,7 +148,7 @@ The basic dependency packages include:
 
 1. Create a Data ability helper.
 
-   For details about the APIs provided by **DataAbilityHelper**, see [DataAbilityHelper Module](../reference/apis/js-apis-dataAbilityHelper.md).
+   For details about the APIs provided by **DataAbilityHelper**, see [DataAbilityHelper Module](../reference/apis/js-apis-inner-ability-dataAbilityHelper.md).
    ```js
    // Different from the URI defined in the config.json file, the URI passed in the parameter has an extra slash (/), because there is a DeviceID parameter between the second and the third slash (/).
    import featureAbility from '@ohos.ability.featureAbility'

en/application-dev/ability/fa-formability.md → en/application-dev/ability-deprecated/fa-formability.md

@@ -43,7 +43,7 @@ The table below describes the **LifecycleForm** APIs, which represent the lifecy
 | onDestroy(formId: string): void                              | Called to notify the widget provider that a widget has been destroyed.          |
 | onAcquireFormState?(want: Want): formInfo.FormState          | Called to instruct the widget provider to receive the status query result of a widget.      |
 
-The table below describes the **FormProvider** APIs. For details, see [FormProvider](../reference/apis/js-apis-formprovider.md).
+The table below describes the **FormProvider** APIs. For details, see [FormProvider](../reference/apis/js-apis-application-formProvider.md).
 
 **Table 2** FormProvider APIs
 

en/application-dev/ability/fa-pageability.md → en/application-dev/ability-deprecated/fa-pageability.md

@@ -61,7 +61,7 @@ By default, **singleton** is used.
 
 | API                                             | Description           |
 | --------------------------------------------------- | --------------- |
-| void startAbility(parameter: StartAbilityParameter) | Starts an ability.    |
+| void startAbility(parameter: StartAbilityParameter) | Starts an ability.   |
 | Context getContext():                               | Obtains the application context.|
 | void terminateSelf()                                | Terminates the ability.    |
 | bool hasWindowFocus()                               | Checks whether the ability has focus.   |

en/application-dev/ability/fa-serviceability.md → en/application-dev/ability-deprecated/fa-serviceability.md

@@ -22,7 +22,9 @@ The differences between **onCommand()** and **onConnect()** are as follows:
 
 ### Creating and Registering a Service Ability
 
-1. Override the Service ability-related lifecycle callbacks to implement your own logic for processing interaction requests. 
+1. Override the Service ability-related lifecycle callbacks to implement your own logic for processing interaction requests.
+   
+    
    
    ```ts
     export default {
@@ -45,7 +47,7 @@ The differences between **onCommand()** and **onConnect()** are as follows:
         }
     }
    ```
-   
+
 2. Register a Service ability.
 
    Declare the Service ability in the **config.json** file by setting its **type** attribute to **service**.

en/application-dev/ability/stage-ability-continuation.md → en/application-dev/ability-deprecated/stage-ability-continuation.md

@@ -301,11 +301,13 @@ In the ability continuation scenario, the distributed data object is used to syn
 
 ### Restrictions
 
-1.   The continuation must be performed between the same ability, which means the same bundle name, module name, and ability name. For details, see [Application Package Structure Configuration File](../quick-start/stage-structure.md).
+1.   The continuation must be performed between the same ability, which means the same bundle name, module name, and ability name. For details, see [Application Package Structure Configuration File](../quick-start/module-configuration-file.md).
 2.    Currently, the application can only implement the continuation capability. The continuation action must be initiated by the system.
 
 
 
 ### Best Practice
 
-   For better user experience, you are advised to use the **wantParam** parameter to transmit data smaller than 100 KB and use distributed objects to transmit data larger than 100 KB.
+For better user experience, you are advised to use the **wantParam** parameter to transmit data smaller than 100 KB and use distributed objects to transmit data larger than 100 KB.
+
+ <!--no_check--> 
\ No newline at end of file

en/application-dev/ability/stage-ability.md → en/application-dev/ability-deprecated/stage-ability.md

 # Ability Development
 ## When to Use
-Ability development in the [stage model](stage-brief.md) is significantly different from that in the FA model. The stage model requires you to declare the application package structure in the **module.json5** and **app.json5** files during application development. For details about the configuration file, see [Application Package Structure Configuration File](../quick-start/stage-structure.md). To develop an ability based on the stage model, implement the following logic:
+Ability development in the [stage model](stage-brief.md) is significantly different from that in the FA model. The stage model requires you to declare the application package structure in the **module.json5** and **app.json5** files during application development. For details about the configuration file, see [Application Package Structure Configuration File](../quick-start/application-package-structure-stage.md). To develop an ability based on the stage model, implement the following logic:
 - Create an ability that supports screen viewing and human-machine interaction. You must implement the following scenarios: ability lifecycle callbacks, obtaining ability configuration, requesting permissions, and notifying environment changes.
 - Start an ability. You need to implement ability startup on the same device, on a remote device, or with a specified UI page.
 - Call abilities. For details, see [Call Development](stage-call.md).
@@ -30,7 +30,7 @@ By default, the singleton mode is used. The following is an example of the **mod
 ```
 ## Creating an Ability
 ### Available APIs
-The table below describes the APIs provided by the **AbilityStage** class, which has the **context** attribute. For details about the APIs, see [AbilityStage](../reference/apis/js-apis-application-abilitystage.md).
+The table below describes the APIs provided by the **AbilityStage** class, which has the **context** attribute. For details about the APIs, see [AbilityStage](../reference/apis/js-apis-app-ability-abilityStage.md).
 
 **Table 1** AbilityStage APIs
 |API|Description|
@@ -321,3 +321,5 @@ struct Index {
   }
 }
 ```
+
+ <!--no_check--> 
\ No newline at end of file

en/application-dev/ability/stage-brief.md → en/application-dev/ability-deprecated/stage-brief.md

@@ -12,15 +12,15 @@ The stage model is designed based on the following considerations:
 
 - Efficient management of application processes
 
-   As the device memory becomes larger, the number of processes concurrently running in the system increases. If the number of concurrent processes reaches several hundreds, the overall power consumption and performance of the system will be adversely affected without effective management measures. To restrict the behavior of background processes, the stage model uses four measures: transient task, continuous task, agent task, and Work Scheduler task. With these measures, foreground processes will obtain guaranteed resources, thereby delivering a better user experience.
+As the device memory becomes larger, the number of processes concurrently running in the system increases. If the number of concurrent processes reaches several hundreds, the overall power consumption and performance of the system will be adversely affected without effective management measures. To restrict the behavior of background processes, the stage model uses four measures: transient task, continuous task, agent task, and Work Scheduler task. With these measures, foreground processes will obtain guaranteed resources, thereby delivering a better user experience.
 
 - Native support for cross-device migration and multi-device collaboration
 
-   OpenHarmony is a native distributed OS. Its application framework must be designed for easier component migration and collaboration across devices. The stage model achieves this design objective by providing features such as separation between ability and UI as well as integration of UI display and service capabilities.
+OpenHarmony is a native distributed OS. Its application framework must be designed for easier component migration and collaboration across devices. The stage model achieves this design objective by providing features such as separation between ability and UI as well as integration of UI display and service capabilities.
 
 - Different window forms for various device types
 
-   The stage model redefines the ability lifecycle. In terms of architecture, the component manager and window manager are decoupled. This facilitates adaptation between window forms and device types.
+The stage model redefines the ability lifecycle. In terms of architecture, the component manager and window manager are decoupled. This facilitates adaptation between window forms and device types.
 
 ## Basic Concepts
 
@@ -103,8 +103,12 @@ The processes of an application can be classified into three types:
 
   ![stageprocessmodel](figures/stageprocessmodel.png)
 
+
+
 ## Application Package Structure
 
 For details about the project directory structure of the stage model, see [OpenHarmony Project Overview](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-project-overview-0000001218440650#section56487581904).
 
-For details about how to configure the application package structure of the stage model, see [Application Package Structure Configuration File (Stage Model)](../quick-start/stage-structure.md).
+For details about how to configure the application package structure of the stage model, see [Application Package Structure Configuration File](../quick-start/application-configuration-file-overview-stage.md).
+
+ <!--no_check--> 
\ No newline at end of file

en/application-dev/ability/stage-call.md → en/application-dev/ability-deprecated/stage-call.md

@@ -34,7 +34,7 @@ The table below describes the ability call APIs. For details, see [Ability](../r
 **Table 2** Ability call APIs
 |API|Description|
 |:------|:------|
-|startAbilityByCall(want: Want): Promise\<Caller>|Starts an ability in the foreground (through the **want** configuration) or background (default) and obtains the **Caller** object for communication with the ability. For details, see [AbilityContext](../reference/apis/js-apis-ability-context.md#abilitycontextstartabilitybycall) or [ServiceExtensionContext](../reference/apis/js-apis-service-extension-context.md#serviceextensioncontextstartabilitybycall).|
+|startAbilityByCall(want: Want): Promise\<Caller>|Starts an ability in the foreground (through the **want** configuration) or background (default) and obtains the **Caller** object for communication with the ability. For details, see [AbilityContext](../reference/apis/js-apis-ability-context.md#abilitycontextstartabilitybycall) or [ServiceExtensionContext](../reference/apis/js-apis-inner-application-serviceExtensionContext.md#serviceextensioncontextstartabilitybycall).|
 |on(method: string, callback: CalleeCallBack): void|Callback invoked when the callee ability registers a method.|
 |off(method: string): void|Callback invoked when the callee ability deregisters a method.|
 |call(method: string, data: rpc.Sequenceable): Promise\<void>|Sends agreed sequenceable data to the callee ability.|

en/application-dev/ability/stage-formextension.md → en/application-dev/ability-deprecated/stage-formextension.md

@@ -31,7 +31,7 @@ Stage widget development refers to the development conducted by the widget provi
 
 ## Available APIs
 
-The **FormExtension** class has the following APIs. For details, see [FormExtension](../reference/apis/js-apis-formextension.md).
+The **FormExtension** class has the following APIs. For details, see [FormExtension](../reference/apis/js-apis-app-form-formExtensionAbility.md).
 
 **Table 1** FormExtension APIs
 
@@ -45,7 +45,7 @@ The **FormExtension** class has the following APIs. For details, see [FormExtens
 | onDestroy(formId: string): void                              | Called to notify the widget provider that a **Form** instance (widget) has been destroyed.          |
 | onConfigurationUpdated(config: Configuration): void;         | Called when the configuration of the environment where the widget is running is updated.                      |
 
-The **FormExtension** class also has a member context, that is, the **FormExtensionContext** class. For details, see [FormExtensionContext](../reference/apis/js-apis-formextensioncontext.md).
+The **FormExtension** class also has a member context, that is, the **FormExtensionContext** class. For details, see [FormExtensionContext](../reference/apis/js-apis-inner-application-formExtensionContext.md).
 
 **Table 2** FormExtensionContext APIs
 
@@ -54,7 +54,7 @@ The **FormExtension** class also has a member context, that is, the **FormExtens
 | startAbility(want: Want, callback: AsyncCallback<void>): void | Starts an ability. This API uses an asynchronous callback to return the result. (This is a system API and cannot be called by third-party applications.)|
 | startAbility(want: Want): Promise<void>                | Starts an ability. This API uses a promise to return the result. (This is a system API and cannot be called by third-party applications.)|
 
-For details about the **FormProvider** APIs, see [FormProvider](../reference/apis/js-apis-formprovider.md).
+For details, see [FormProvider](../reference/apis/js-apis-application-formProvider.md).
 
 **Table 3** FormProvider APIs
 
@@ -412,4 +412,4 @@ The following is an example:
        }
      }
    }
-   ```
\ No newline at end of file
+   ```

en/application-dev/ability/stage-serviceextension.md → en/application-dev/ability-deprecated/stage-serviceextension.md

@@ -71,4 +71,5 @@ OpenHarmony does not support creation of a Service Extension ability for third-p
             console.log('onDestroy');
         }
     }
-    ```
\ No newline at end of file
+    ```
+

en/application-dev/ability/wantagent.md → en/application-dev/ability-deprecated/wantagent.md

@@ -2,8 +2,6 @@
 ## When to Use
 The **WantAgent** class encapsulates want information that specifies a particular action, which can be starting an ability or publishing a common event. You can either call **wantAgent.trigger** to trigger a **WantAgent** directly or add a **WantAgent** to a notification so that it will be triggered when users tap the notification.
 
- 
-
 ## Available APIs
 | API                                                                                         | Description|
 | ---------------------------------------------------------------------------------------------- | ----------- |

en/application-dev/application-models/Readme-EN.md

+# Application Models
+