1# Ability Framework 2 3## Overview 4 5The **ability framework** (also called the ability management framework) is used to centrally schedule and manage the running and lifecycle of abilities. An application process can support multiple abilities, and an ability can be called either within a process or across processes. The Ability Manager Service provided in the framework schedules and manages abilities in an application and manages the lifecycle changes of these abilities. 6 7 8 9**Architecture Description** 10 11- **Ability Kit** provides basic running environment for an ability to run. **Ability** is the minimum unit for the system to schedule an application. It is a component that can implement an independent functionality. An application can contain one or more **Ability** instances. There are two types of abilities: Feature Ability (FA) and Particle Ability (PA). FAs use the Page template, and PAs use the Service and Data templates. (The abilities implemented using the Page, Service, or Data template are referred to as the Page, Service, or Data abilities for short, respectively.) 12 13- **AbilityManagerService** is a system service used to coordinate the running relationships and lifecycle states of **Ability** instances. 14 - The AbilityStackManager sub-module maintains the presentation sequence of abilities in the stack. 15 - The AbilityConnectManager sub-module manages connections to Service abilities. 16 - The DataAbilityManager sub-module manages Data abilities. 17 - The AppScheduler sub-module schedules and manages the App Manager Service. 18 - The AbilityScheduler sub-module schedules and manages abilities. 19 - The LifecycleDeal sub-module schedules and manages ability lifecycle events. 20 21The **ability lifecycle** is a general term for all states of an ability (either a Page or a Service ability), such as **INACTIVE**, **ACTIVE**, and **BACKGROUND**. 22 23 - The following figure shows the transitions between different states in a Page ability's lifecycle. 24 25 26 27 28 29 - The following figure shows the transitions between different states in a Service ability's lifecycle. 30 31 32 33**Description of ability lifecycle states:** 34 35 - **UNINITIALIZED**: The ability is not initialized. This state is a temporary state. An ability changes directly to the **INITIAL** state upon its creation. 36 37 - **INITIAL**: This state refers to the initial or stopped state. The ability in this state is not running. The ability enters the **INACTIVE** state after it is started. 38 39 - **INACTIVE**: The ability is visible but does not gain focus. This state is the same as the **ACTIVE** state because the concept of window focus is not supported currently. 40 41 - **ACTIVE**: The ability is in the foreground and has focus. The ability changes from the **ACTIVE** state to the **INACTIVE** state before returning to the background. 42 43 - **BACKGROUND**: The ability returns to the background. After being re-activated, the ability enters the **ACTIVE** state. After being destroyed, the ability enters the **INITIAL** state. 44 45The following figure shows the callbacks to be invoked during the transitions between different lifecycle states of a Page ability. 46 47 48 49 50 51The following figure shows the callbacks to be invoked during the transitions between different lifecycle states of a Service ability. 52 53 54 55 56 57## Directory Structure 58 59``` 60foundation/ 61└──foundation/aafwk/standard 62 ├── frameworks 63 │ └── kits 64 │ └── ability # Core code for AbilityKit 65 ├── interfaces 66 │ └── innerkits 67 │ └── want # External APIs of the information carrier used for interaction between abilities 68 └── services 69 ├── abilitymgr # Framework code of the Ability Manager Service 70 ├── common # Log component 71 ├── test # Testing 72 └── tools # aa command code 73``` 74 75## Usage Guidelines 76 77The application framework does not have the permission management capability. 78 79In the current version, the JavaScript APIs of the following modules are provided only for the system applications Launcher, Settings, and SystemUI. Significant changes may be provided in later versions. 80 81- @ohos.feature_ability.d.ts 82 83- @ohos.napi_ability_manager.d.ts 84 85- abilityinfo.d.ts 86 87- abilitymissioninfo.d.ts 88 89- applicationinfo.d.ts 90 91- appprocessstate.ts 92 93- common.d.ts 94 95- elementname.d.ts 96 97- moduleinfo.d.ts 98 99- processinfo.d.ts 100 101- want.d.ts 102 103## **aa Commands** 104 105**aa help** 106 107| Command | Description | 108| ------- | ------------------ | 109| aa help | Displays the command help information.| 110 111**aa start** 112 113| Command | Description | 114| --------------------------------------------------------- | ------------------------ | 115| aa start [-d <device>] -a <ability-name> -b <bundle-name> | Starts an ability. The device ID can be empty.| 116 117Example: 118``` 119aa start -d 12345 -a com.ohos.app.MainAbility -b com.ohos.app 120``` 121 122**aa dump** 123 124| Command | Description | 125| ---------- | --------------------- | 126| aa dump -a | Displays the ability information in the stack.| 127 128## Repositories Involved 129Ability framework 130 131[ability_base](https://gitee.com/openharmony/ability_ability_base) 132 133[ability_runtime](https://gitee.com/openharmony/ability_ability_runtime) 134 135[form_fwk](https://gitee.com/openharmony/ability_form_fwk) 136
