1# Development of Application Recovery 2 3## Overview 4 5During application running, some unexpected behaviors are inevitable. For example, unprocessed exceptions and errors are thrown, and the call or running constraints of the recovery framework are violated. 6 7Process exit is treated as the default exception handling method. However, if user data is generated during application use, process exit may interrupt user operations and cause data loss. 8If the [application recovery](#available-apis) function is enabled in [AbilityStage](../reference/apis-ability-kit/js-apis-app-ability-abilityStage.md) and temporary data is saved, the previous application state and data will be restored upon next startup in the case of an abnormal exit, providing more consistent user experience. The application state includes two parts, namely, the page stack and the data saved in **onSaveState**. 9 10In API version 9, application recovery is supported only for a single ability of the application developed using the stage model. Application state saving and automatic restart are performed when a JsError occurs. 11 12In API version 10, application recovery is applicable to multiple abilities of an application developed using the stage model. Application state storage and restore are performed when an AppFreeze occurs. If an application is killed in control mode, the application state will be restored upon next startup. 13 14## Available APIs 15 16The application recovery APIs are provided by the **appRecovery** module, which can be imported via **import**. For details, see [Development Example](#development-example). 17 18### Available APIs 19 20| API | Description | 21| ------------------------------------------------------------ | ---------------------------------------------------- | 22| enableAppRecovery(restart?: RestartFlag, saveOccasion?: SaveOccasionFlag, saveMode?: SaveModeFlag) : void<sup>9+</sup> | Enables application recovery. After this API is called, the first ability that is displayed when the application is started from the initiator can be restored.| 23| saveAppState(): boolean<sup>9+</sup> | Saves the state of the ability that supports recovery in the current application.| 24| restartApp(): void<sup>9+</sup> | Restarts the current process and starts the ability specified by **setRestartWant**. If no ability is specified, a foreground ability that supports recovery is restarted.| 25| saveAppState(context?: UIAbilityContext): boolean<sup>10+</sup> | Saves the ability state specified by **Context**.| 26| setRestartWant(want: Want): void<sup>10+</sup> | Sets the abilities to restart when **restartApp** is actively called and **RestartFlag** is not **NO_RESTART**. The abilities must be under the same bundle name and must be a **UIAbility**.| 27 28No error will be thrown if the preceding APIs are used in the troubleshooting scenario. The following are some notes on API usage: 29 30**enableAppRecovery**: This API should be called during application initialization. For example, you can call this API in **onCreate** of **AbilityStage**. For details, see [Parameter Description](../reference/apis-ability-kit/js-apis-app-ability-appRecovery.md). 31 32**saveAppState**: After this API is called, the recovery framework invokes **onSaveState** for all abilities that support recovery in the current process. If you choose to save data in **onSaveState**, the related data and ability page stack are persistently stored in the local cache of the application. To save data of the specified ability, you need to specify the context corresponding to that ability. 33 34**setRestartWant**: This API specifies the ability to be restarted by **appRecovery**. 35 36**restartApp**: After this API is called, the recovery framework kills the current process and restarts the ability specified by **setRestartWant**, with **APP_RECOVERY** set as the startup cause. In API version 9 and scenarios where an ability is not specified by **setRestartWant**, the last foreground ability that supports recovery is started. If the no foreground ability supports recovery, the application crashes. If a saved state is available for the restarted ability, the saved state is passed as the **wantParam** attribute in the **want** parameter of the ability's **onCreate** callback. The interval between two restarts must be greater than 1 minute. If this API is called repeatedly within 1 minute, the application exits but does not restart. The behavior of automatic restart is the same as that of proactive restart. 37 38### Application State Management 39Since API version 10, application recovery is not limited to automatic restart in the case of an exception. Therefore, you need to understand when the application will load the saved state. 40If the last exit of an application is not initiated by a user and a saved state is available for recovery, the startup reason is set to **APP_RECOVERY** when the application is started by the user next time, and the recovery state of the application is cleared. 41The application recovery status flag is set when **saveAppState** is actively or passively called. The flag is cleared when the application exits normally or the saved state is consumed. (A normal exit is usually triggered by pressing the back key or clearing recent tasks.) 42 43 44 45### Application State Saving and Restore 46API version 10 or later supports saving of the application state when an application is suspended. If a JsError occurs, **onSaveState** is called in the main thread. If an AppFreeze occurs, however, the main thread may be suspended, and therefore **onSaveState** is called in a non-main thread. The following figure shows the main service flow. 47 48 49When the application is suspended, the callback is not executed in the JS thread. Therefore, you are advised not to use the imported dynamic Native library or access the **thread_local** object created by the main thread in the code of the **onSaveState** callback. 50 51### Framework Fault Management 52 53Fault management is an important way for applications to deliver a better user experience. The application framework offers three methods for application fault management: fault listening, fault rectification, and fault query. 54 55- Fault listening refers to the process of registering an [ErrorObserver](../reference/apis-ability-kit/js-apis-inner-application-errorObserver.md) via [errorManager](../reference/apis-ability-kit/js-apis-app-ability-errorManager.md), listening for faults, and notifying the listener of the faults. 56 57- Fault rectification refers to the process of restoring the application state and data through [appRecovery](../reference/apis-ability-kit/js-apis-app-ability-appRecovery.md). 58 59- Fault query is the process of calling APIs of [faultLogger](../reference/apis-performance-analysis-kit/js-apis-faultLogger.md) to obtain the fault information. 60 61The figure below does not illustrate the time when [faultLogger](../reference/apis-performance-analysis-kit/js-apis-faultLogger.md) is called. You can refer to the [LastExitReason](../reference/apis-ability-kit/js-apis-app-ability-abilityConstant.md#abilityconstantlastexitreason) passed during application initialization to determine whether to call [faultLogger](../reference/apis-performance-analysis-kit/js-apis-faultLogger.md) to query information about the previous fault. 62 63 64It is recommended that you call [errorManager](../reference/apis-ability-kit/js-apis-app-ability-errorManager.md) to handle the exception. After the processing is complete, you can call the **saveAppState** API and restart the application. 65If you do not register an [ErrorObserver](../reference/apis-ability-kit/js-apis-inner-application-errorObserver.md) instance or enable application recovery, the application process will exit according to the default processing logic of the system. Users can restart the application from the home screen. 66If you have enabled application recovery, the recovery framework first checks whether application state saving is supported and whether the application state saving is enabled. If so, the recovery framework invokes [onSaveState](../reference/apis-ability-kit/js-apis-app-ability-uiAbility.md#uiabilityonsavestate) of the [ability](../reference/apis-ability-kit/js-apis-app-ability-uiAbility.md). Finally, the application is restarted. 67 68### Supported Application Recovery Scenarios 69 70Common fault types include JavaScript application crash, application freezing, and C++ application crash. Generally, an application is closed when a crash occurs. Application freezing occurs when the application does not respond. The fault type can be ignored for the upper layer of an application. The recovery framework implements fault management in different scenarios based on the fault type. 71 72| Fault | Fault Listening | State Saving| Automatic Restart| Log Query| 73| ----------|--------- |--------- |--------- |--------- | 74| [JS_CRASH](../reference/apis-performance-analysis-kit/js-apis-faultLogger.md#faulttype) | Supported|Supported|Supported|Supported| 75| [APP_FREEZE](../reference/apis-performance-analysis-kit/js-apis-faultLogger.md#faulttype) | Not supported|Supported|Supported|Supported| 76| [CPP_CRASH](../reference/apis-performance-analysis-kit/js-apis-faultLogger.md#faulttype) | Not supported|Not supported|Not supported|Supported| 77 78**State Saving** in the table header means saving of the application state when a fault occurs. To protect user data as much as possible when an AppFreeze occurs, you can adopt either the periodic or automatic way, and the latter will save user data when an ability is switched to the background. 79 80 81 82## Development Example 83 84### Enabling Application Recovery 85 86 Enable **appRecovery** during application initialization. The following is an example of **AbilityStage**: 87 88```ts 89import { AbilityStage, appRecovery } from '@kit.AbilityKit'; 90 91export default class MyAbilityStage extends AbilityStage { 92 onCreate() { 93 console.info("[Demo] MyAbilityStage onCreate"); 94 appRecovery.enableAppRecovery(appRecovery.RestartFlag.ALWAYS_RESTART, 95 appRecovery.SaveOccasionFlag.SAVE_WHEN_ERROR | appRecovery.SaveOccasionFlag.SAVE_WHEN_BACKGROUND, 96 appRecovery.SaveModeFlag.SAVE_WITH_FILE); 97 } 98} 99``` 100### Enabling Application Recovery for the Specified Abilities 101Generally, the ability configuration list is named **module.json5**. 102```json 103{ 104 "abilities": [ 105 { 106 "name": "EntryAbility", 107 "recoverable": true, 108 }] 109} 110 111``` 112 113### Saving and Restoring Data 114 115After enabling **appRecovery**, you can use this function by either actively or passively saving the application state and restoring data in the ability. 116The following is an example of **EntryAbility**: 117 118#### Importing the Service Package 119 120```ts 121import { AbilityConstant, appRecovery, errorManager } from '@kit.AbilityKit'; 122``` 123 124#### Actively Saving the Application State and Restoring Data 125 126- Define and register the [ErrorObserver](../reference/apis-ability-kit/js-apis-inner-application-errorObserver.md) callback. For details about its usage, see [errorManager](../reference/apis-ability-kit/js-apis-app-ability-errorManager.md). 127 128```ts 129import { appRecovery, errorManager, UIAbility } from '@kit.AbilityKit'; 130import { window } from '@kit.ArkUI'; 131 132let registerId = -1; 133let callback: errorManager.ErrorObserver = { 134 onUnhandledException(errMsg) { 135 console.log(errMsg); 136 appRecovery.saveAppState(); 137 appRecovery.restartApp(); 138 } 139} 140 141export default class EntryAbility extends UIAbility { 142 onWindowStageCreate(windowStage: window.WindowStage) { 143 // Main window is created, set main page for this ability 144 console.log("[Demo] EntryAbility onWindowStageCreate"); 145 registerId = errorManager.on('error', callback); 146 147 windowStage.loadContent("pages/index", (err, data) => { 148 if (err.code) { 149 console.error('Failed to load the content. Cause:' + JSON.stringify(err)); 150 return; 151 } 152 console.info('Succeeded in loading the content. Data: ' + JSON.stringify(data)); 153 }) 154 } 155} 156``` 157 158- Save data. 159 160After the callback triggers **appRecovery.saveAppState()**, **onSaveState(state, wantParams)** of **EntryAbility** is triggered. 161 162```ts 163import { AbilityConstant, UIAbility } from '@kit.AbilityKit'; 164 165export default class EntryAbility extends UIAbility { 166 onSaveState(state:AbilityConstant.StateType, wantParams: Record<string, Object>) { 167 // Ability has called to save app data 168 console.log("[Demo] EntryAbility onSaveState"); 169 wantParams["myData"] = "my1234567"; 170 return AbilityConstant.OnSaveResult.ALL_AGREE; 171 } 172} 173``` 174 175- Restore data. 176 177After the callback triggers **appRecovery.restartApp()**, the application is restarted. After the restart, **onCreate(want, launchParam)** of **EntryAbility** is called, and the saved data is stored in **parameters** of **want**. 178 179```ts 180import { AbilityConstant, UIAbility, Want } from '@kit.AbilityKit'; 181 182let abilityWant: Want; 183 184export default class EntryAbility extends UIAbility { 185 storage: LocalStorage | undefined = undefined; 186 187 onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) { 188 console.log("[Demo] EntryAbility onCreate"); 189 abilityWant = want; 190 if (launchParam.launchReason == AbilityConstant.LaunchReason.APP_RECOVERY) { 191 this.storage = new LocalStorage(); 192 if (want.parameters) { 193 let recoveryData = want.parameters["myData"]; 194 this.storage.setOrCreate("myData", recoveryData); 195 this.context.restoreWindowStage(this.storage); 196 } 197 } 198 } 199} 200``` 201 202- Unregister the **ErrorObserver** callback. 203 204```ts 205import { errorManager, UIAbility } from '@kit.AbilityKit'; 206 207let registerId = -1; 208 209export default class EntryAbility extends UIAbility { 210 onWindowStageDestroy() { 211 // Main window is destroyed, release UI related resources 212 console.log("[Demo] EntryAbility onWindowStageDestroy"); 213 214 errorManager.off('error', registerId, (err) => { 215 console.error("[Demo] err:", err); 216 }); 217 } 218} 219``` 220 221#### Passively Saving the Application State and Restoring Data 222 223This is triggered by the recovery framework. You do not need to register an **ErrorObserver** callback. You only need to implement **onSaveState** for application state saving and **onCreate** for data restore. 224 225```ts 226import { AbilityConstant, UIAbility, Want } from '@kit.AbilityKit'; 227 228let abilityWant: Want; 229 230export default class EntryAbility extends UIAbility { 231 storage: LocalStorage | undefined = undefined 232 onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) { 233 console.log("[Demo] EntryAbility onCreate"); 234 abilityWant = want; 235 if (launchParam.launchReason == AbilityConstant.LaunchReason.APP_RECOVERY) { 236 this.storage = new LocalStorage(); 237 if (want.parameters) { 238 let recoveryData = want.parameters["myData"]; 239 this.storage.setOrCreate("myData", recoveryData); 240 this.context.restoreWindowStage(this.storage); 241 } 242 } 243 } 244 245 onSaveState(state:AbilityConstant.StateType, wantParams: Record<string, Object>) { 246 // Ability has called to save app data 247 console.log("[Demo] EntryAbility onSaveState"); 248 wantParams["myData"] = "my1234567"; 249 return AbilityConstant.OnSaveResult.ALL_AGREE; 250 } 251} 252``` 253 254#### Restart Flag for the Failed Ability 255 256If the failed ability is restarted again, the [ABILITY_RECOVERY_RESTART](../reference/apis-ability-kit/js-apis-app-ability-wantConstant.md#params) flag will be added as a **parameters** member for the **want** parameter in **onCreate** and its value is **true**. 257 258```ts 259import { AbilityConstant, UIAbility, Want, wantConstant } from '@kit.AbilityKit'; 260 261export default class EntryAbility extends UIAbility { 262 onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) { 263 if (want.parameters === undefined) { 264 return; 265 } 266 if (want.parameters[wantConstant.Params.ABILITY_RECOVERY_RESTART] != undefined && 267 want.parameters[wantConstant.Params.ABILITY_RECOVERY_RESTART] == true) { 268 console.log("This ability need to recovery"); 269 } 270 } 271} 272``` 273