See the API adaptation guide of **setSeed** in the API reference: [Crypto Framework - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cryptoFramework.md)
## cl.security.2 Migration of interface DataArray from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface DataArray** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.3 Migration of interface EncodingFormat from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface EncodingFormat** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.4 Migration of interface EncodingBlob from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface EncodingBlob** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.5 Migration of interface CertChainData from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface CertChainData** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.6 Migration of interface X509Cert from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface X509Cert** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.7 Migration of function createX509Cert from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **function createX509Cert** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.8 Migration of interface X509CrlEntry from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts.
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface X509CrlEntry** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.9 Migration of interface X509Crl from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface X509Crl** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.10 Migration of function createX509Crl from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **function createX509Crl** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.11 Migration of interface CertChainValidator from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **interface CertChainValidator** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.12 Migration of function createCertChainValidator from @ohos.security.cryptoFramework.d.ts to @ohos.security.cert.d.ts
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
Migrated **function createCertChainValidator** from **@ohos.security.cryptoFramework.d.ts** to **@ohos.security.cert.d.ts**.
**Adaptation Guide**
Import and use the new .d.ts file:
import cryptoCert from '@ohos.security.cert';
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.13 getPublicKey API Change of X509Cert from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.14 checkValidityWithDate API Change of X509Cert from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.15 getCertIssuer API Change of X509CrlEntry from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.16 getRevocationDate API Change of X509CrlEntry from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.17 isRevoked API Change of X509Crl from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.18 getRevokedCert API Change of X509Crl from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.19 getRevokedCertWithCert API Change of X509Crl from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
## cl.security.20 getTbsInfo API Change of X509Crl from Asynchronous to Synchronous
**Change Impacts**
Behavior of released JavaScript APIs will be changed.
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
See the corresponding API adaptation guide in the API reference: [Certificate - API Reference](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-cert.md)
# ChangeLog of JS API Changes of the Ability Subsystem
Compared with OpenHarmony 3.2 Beta4, OpenHarmony 3.2.10.1(Mr) has the following API changes in the ability subsystem:
## cl.ability.1 API Migration
The **requestPermissionsFromUser** API of **UIAbilityContext** is migrated from the ability subsystem to the security subsystem.
Previously, the permission popup was implemented based on **UIAbility**, which used the **startAbilityForResult** API of **UIAbilityContext** to return the permission authorization result to the caller. Therefore, **requestPermissionsFromUser** was temporarily placed in **UIAbilityContext**. The permission popup is now implemented based on **ServiceExtensionAbility**, which no longer requires **startAbilityForResult** of **UIAbilityContext**. Therefore, **requestPermissionsFromUser** is migrated to the security subsystem.
You need to adapt your applications based on the following information:
**Change Impacts**
JS APIs in API version 9 are affected. The application needs to adapt these APIs so that it can properly implement functions in the SDK environment of the new version.
**Key API/Component Changes**
| Module | Class | Method/Attribute/Enumeration/Constant | Change Type|
console.error('Failed to start ability',err.code);
})
}
```
## cl.ability.2 Deletion of Deprecated APIs in API Version 9
In the [Ability Exception Rectification](../OpenHarmony_3.2.8.3/changelogs-ability.md) document, some APIs in API version 9 have been marked as deprecated. According to API specifications of OpenHarmony, these APIs should be deleted.
**Change Impacts**
The application developed based on earlier versions needs to use new APIs to replace the deleted ones. Otherwise, the application compilation will be affected.
-**direction**, **screenDensity**, **displayId**, and **hasPointerDevice** of **Configuration** are deleted. Replace it with **Configuration** of **@ohos.app.ability.Configuration.d.ts**.
- @ohos.application.ConfigurationConstant.d.ts
-**Direction** and **ScreenDensity** are deleted. Replace them with **Direction** and **ScreenDensity** of **@ohos.app.ability.ConfigurationConstant.d.ts**.
- @ohos.application.abilityManager.d.ts
-**getExtensionRunningInfos** and **getTopAbility** are deleted. Replace them with synonymous methods of **@ohos.app.ability.abilityManager.d.ts**.
- @ohos.application.appManager.d.ts
-**ApplicationState** and **ProcessState** are deleted. Replace them with **ApplicationState** and **ProcessState** of **@ohos.app.ability.appManager.d.ts**.
-**registerApplicationStateObserver** and **getProcessRunningInformation** are deleted. Replace them with synonymous methods of **@ohos.app.ability.appManager.d.ts**.
- @ohos.application.formHost.d.ts
-**shareForm** and **notifyFormsPrivacyProtected** are deleted. Replace them with synonymous methods of **@ohos.app.form.formHost.d.ts**.
- @ohos.application.formInfo.d.ts
-**eTS** of **FormType** is deleted. Replace it with **eTS** of **FormType** in **@ohos.app.form.formInfo.d.ts**.
-**IDENTITY_KEY**, **BUNDLE_NAME_KEY**, **ABILITY_NAME_KEY**, and **DEVICE_ID_KEY** of **FormParam** are deleted. Replace them with synonymous enumerations of **@ohos.app.form.formInfo.d.ts**.
-**FormInfoFilter** is deleted. Replace it with **FormInfoFilter** of **@ohos.app.form.formInfo.d.ts**.
-**FormDimension** is deleted. Replace it with **FormDimension** of **@ohos.app.form.formInfo.d.ts**.
-**VisibilityType** is deleted. Replace it with **VisibilityType** of **@ohos.app.form.formInfo.d.ts**.
- @ohos.wantAgent.d.ts
-**trigger** and **getOperationType** are deleted. Replace them with synonymous methods of **@ohos.app.ability.wantAgent.d.ts**.
- application/ApplicationContext.d.ts
-**registerAbilityLifecycleCallback**, **unregisterAbilityLifecycleCallback**, **registerEnvironmentCallback**, and **unregisterEnvironmentCallback** are deleted. Replace them with **on** and **off**.
- application/ServiceExtensionContext.d.ts
-**connectAbility**, **connectAbilityWithAccount**, and **disconnectAbility** are deleted. Replace them with **connectServiceExtensionAbility**, **connectServiceExtensionAbilityWithAccount**, and **disconnectServiceExtensionAbility**.
- @ohos.application.ExtensionAbility.d.ts
-**onCreate**, **onCastToNormal**, **onUpdate**, **onVisibilityChange**, **onEvent**, **onDestroy**, **onAcquireFormState**, and **onShare** are deleted. Replace them with the following lifecycle methods of **@ohos.app.form.FormExtensionAbility.d.ts**: **onAddForm**, **onCastToNormalForm**, **onUpdateForm**, **onChangeFormVisibility**, **onFormEvent**, **onRemoveForm**, **onAcquireFormState**, and **onShareForm**.
- @ohos.application.abilityDelegatorRegistry.d.ts
-**AbilityDelegator**, **AbilityDelegatorArgs**, **AbilityMonitor**, and **ShellCmdResult** are deleted. Replace them with synonymous classes of **@ohos.app.ability.abilityDelegatorRegistry.d.ts**.
- @ohos.application.abilityManager.d.ts
-**AbilityRunningInfo** and **ExtensionRunningInfo** are deleted. Replace them with synonymous classes of **@ohos.app.ability.abilityManager.d.ts**.
- @ohos.application.appManager.d.ts
-**AbilityStateData**, **AppStateData**, **ApplicationStateObserver**, **ProcessRunningInfo**, and **ProcessRunningInformation** are deleted. Replace them with synonymous classes of **@ohos.app.ability.appManager.d.ts**.
- @ohos.application.missionManager.d.ts
-**MissionInfo**, **MissionListener**, and **MissionSnapshot** are deleted. Replace them with synonymous classes of **@ohos.app.ability.missionManager.d.ts**.
- @ohos.wantAgent.d.ts
-**TriggerInfo** and **WantAgentInfo** are deleted. Replace them with synonymous classes of **@ohos.app.ability.wantAgent.d.ts**.
**Adaptation Guide**
As mentioned above, only several APIs have their names changed in terms of, for example, the registration callbacks (**registerAbilityLifecycleCallback**, **unregisterAbilityLifecycleCallback**, **registerEnvironmentCallback**, and **unregisterEnvironmentCallback**) and connection and disconnection **ServiceExtensionAbility** (**connectAbility**, **connectAbilityWithAccount**, and **disconnectAbility**). For such APIs, replace their names with those of their corresponding new APIs in the lifecycle callbacks.
Most APIs are moved to the new namespace. Therefore, you can modify **import** for adaption.
For example, the original API uses **@ohos.application.Ability**:
```js
importAbilityfrom'@ohos.application.Ability';
```
You can directly modify **import** to switch to the new namespace:
```js
importAbilityfrom'@ohos.app.ability.UIAbility';
```
In addition, exception processing is needed. For details, see the API reference for the new APIs.
# ChangeLog of JS API Changes in the commonlibrary Subsystem
Compared with OpenHarmony 3.2 Beta4, OpenHarmony 3.2.10.1(Mr) has the following API changes in the commonlibrary subsystem.
## cl.commonlibrary.1 Error Code and Information Change
Changed error codes and information returned by APIs of the **ArrayList**, **List**, **LinkedList**, **Stack**, **Queue**, **Deque**, **PlainArray**, **LightWeightMap**, **LightWeightSet**, **HashMap**, **HashSet**, **TreeMap**, and **TreeSet** classes in the commonlibrary subsystem.
For details about the changed error codes, see [error codes of language basic class libraries](../../../application-dev/reference/errorcodes/errorcode-utils.md).
No adaptation is required for applications developed using these APIs.
**Key API/Component Changes**
Error code information is redefined for APIs in these classes and marked using **'@throws'** in the `*.d.ts` file of the corresponding module.
The sample code is as follows:
**ArrayList** class before the change:
constructor();
**ArrayList** class after the change:
@throws { BusinessError } 10200012 - The ArrayList's constructor cannot be directly invoked.
# ChangeLog of JS API Changes of the Distributed Data Management Subsystem
Compared with OpenHarmony 3.2 Beta4, OpenHarmony 3.2.10.1(Mr) has the following API changes in the distributed data management subsystem:
## cl.distributeddatamgr.1 API Change
APIs in the **kv_store** component of the distributed data management subsystem are changed:
**createKVManager** is changed from asynchronous to synchronous, because the execution duration is fixed and short and there is no need to asynchronously wait for the execution result. Therefore, the original APIs **function createKVManager(config: KVManagerConfig): Promise\<KVManager\>;** and **function createKVManager(config: KVManagerConfig, callback: AsyncCallback<KVManager>): void;** are changed to **function createKVManager(config: KVManagerConfig): KVManager;**.
You need to adapt your applications based on the following information:
**Change Impacts**
JS APIs in API version 9 are affected. The application needs to adapt these APIs so that it can properly implement functions in the SDK environment of the new version.
**Key API/Component Changes**
| Module | Class | Method/Attribute/Enumeration/Constant | Change Type|
The APIs are migrated from **@ohos.data.rdb.d.ts** to **@ohos.data.relationalStore.d.ts**.
```
function deleteRdbStoreV9(context: Context, name: string, callback: AsyncCallback<void>): void;
function deleteRdbStoreV9(context: Context, name: string): Promise<void>;
```
**Adaptation Guide**
*`import rdb from "@ohos.data.rdb"` is changed to `import rdb from "@ohos.data.relationalStore"`.
* The names of relevant methods should be changed according to the preceding changes.
## cl.distributeddatamgr.4 Migration of interface StoreConfigV9 from @ohos.data.rdb.d.ts to @ohos.data.relationalStore.d.ts
**Change Impacts**
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
**interface StoreConfigV9** is migrated from **@ohos.data.rdb.d.ts** to **@ohos.data.relationalStore.d.ts** and is renamed as **interface StoreConfig**.
**Adaptation Guide**
*`import rdb from "@ohos.data.rdb"` is changed to `import rdb from "@ohos.data.relationalStore"`.
* The names of relevant APIs should be changed according to the preceding changes.
## cl.distributeddatamgr.5 Migration of enum SecurityLevel from @ohos.data.rdb.d.ts to @ohos.data.relationalStore.d.ts
**Change Impacts**
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
**enum SecurityLevel** is migrated from **ohos.data.rdb.d.ts** to **@ohos.data.relationalStore.d.ts**.
**Adaptation Guide**
*`import rdb from "@ohos.data.rdb"` is changed to `import rdb from "@ohos.data.relationalStore"`.
* The names of relevant APIs should be changed according to the preceding changes.
## cl.distributeddatamgr.6 Migration of interface RdbStoreV9 from @ohos.data.rdb.d.ts to @ohos.data.relationalStore.d.ts
**Change Impacts**
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
**interface RdbStoreV9** is migrated from **@ohos.data.rdb.d.ts** to **@ohos.data.relationalStore.d.ts** and is renamed as **interface RdbStore**.
**Adaptation Guide**
*`import rdb from "@ohos.data.rdb"` is changed to `import rdb from "@ohos.data.relationalStore"`.
* The names of relevant APIs should be changed according to the preceding changes.
## cl.distributeddatamgr.7 Migration of class RdbPredicatesV9 from ohos.data.rdb.d.ts to @ohos.data.relationalStore.d.ts
**Change Impacts**
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
**class RdbPredicatesV9** is migrated from **ohos.data.rdb.d.ts** to **@ohos.data.relationalStore.d.ts** and is renamed as **interface RdbPredicates**.
**Adaptation Guide**
*`import rdb from "@ohos.data.rdb"` is changed to `import rdb from "@ohos.data.relationalStore"`.
* The names of relevant APIs should be changed according to the preceding changes.
## cl.distributeddatamgr.8 Migration of interface ResultSetV9 from api/@ohos.data.relationalStore.d.ts to @ohos.data.relationalStore.d.ts
**Change Impacts**
The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
**interface ResultSetV9** is migrated from **api/data/rdb/resultSet.d.ts** to **@ohos.data.relationalStore.d.ts** and is renamed as **interface ResultSet**.
**Adaptation Guide**
*`import rdb from "@ohos.data.rdb"` is changed to `import rdb from "@ohos.data.relationalStore"`.
* The **ResultSetV9** instance is obtained only via **getRdbStoreV9**. After modifications are made according to cl.distributeddatamgr.2, the code can automatically adapt to **ResultSet**.
In the [event notification exception handling rectification](../OpenHarmony_3.2.8.3/changelogs-notification.md), some APIs in API version 9 are marked as deprecated, and these APIs need to be deleted, according to OpenHarmony API specifications.
**Change Impacts**
The application developed based on earlier versions needs to use new APIs to replace the deleted ones. Otherwise, the application compilation will be affected.
**Key API/Component Changes**
Deprecated APIs in API version 9 will be deleted, and they will be replaced with new ones with same names.
- The **publishAsBundle**, **cancelAsBundle**, **isNotificationSlotEnabled**, **setSyncNotificationEnabledWithoutApp**, and **getSyncNotificationEnabledWithoutApp** APIs are deleted. Replace them with APIs with same names in **api/@ohos.notificationManager.d.ts**.
- The **enableNotificationSlot** API is deleted. Replace it with **setNotificationEnableSlot** in **api/@ohos.notificationManager.d.ts**.
- The export classes **NotificationActionButton**, **NotificationBasicContent**, **NotificationContent**, **NotificationLongTextContent**, **NotificationMultiLineContent**, **NotificationPictureContent**, **NotificationFlags**, **NotificationFlagStatus**, **NotificationRequest**, **DistributedOptions**, **NotificationSlot**, **NotificationSorting**, **NotificationTemplate**, and **NotificationUserInput** are deleted. Replace them with the export classes with the same names in **api/@ohos.notificationManager.d.ts**.
- The export classes **NotificationSubscribeInfo**, **NotificationSubscriber**, **SubscribeCallbackData**, and **EnabledNotificationCallbackData** are deleted. Replace them with the export classes with the same names in **api/@ohos.notificationSubscribe.d.ts**.
**Adaptation Guide**
The original APIs are only migrated to the new namespace. Therefore, you can modify **import** to solve the adaptation problem.
If the original API uses **@ohos.commonEvent**:
```js
importcommonEventfrom'@ohos.commonEvent';
```
You can directly modify **import** to switch to the new namespace:
```js
importcommonEventfrom'@ohos.commonEventManager';
```
**@ohos.notification** is split into two namespaces. You need to select a new namespace for adaptation.
In addition, exception handling is needed. For details, see the API reference for the new APIs.
Errors thrown by timer APIs of the time subsystem: **202** (non-system application) and **401** (invalid parameters).
**Change Impacts**
The API change is forward compatible. Applications developed based on earlier versions can still use the APIs, and corresponding error handling is added. The original functions are not affected.
**Key API/Component Changes**
Before change:
- The API throws an error message without an error code.
After change:
- The API throws an error message with an error code. Error code **202** indicates that the application is not a system application, and error code **401** indicates that the parameters are invalid.
| Module | Class | Method/Attribute/Enumeration/Constant | Change Type|
# ChangeLog of JS API Changes in the URL Subsystem
Compared with OpenHarmony 3.2 Beta4, OpenHarmony 3.2.10.1(Mr) has the following API changes in the URL subsystem:
## cl.url.1 URLParams Class API Changes
APIs in the **URLParams** class in the URL subsystem are changed:
**constructor(init?: string[][] | Record<string, string> | string | URLSearchParams)** is changed to **constructor(init?: string[][] | Record<string, string> | string | URLParams)**, and the parameter type is changed from URLSearchParams to URLParams.
You need to adapt your application based on the following information.
**Change Impacts**
JS APIs in API version 9 are affected. Your application needs to adapt these APIs so that it can properly implement functions in the SDK environment of the new version.
**Key API/Component Changes**
| Module | Class | Method/Attribute/Enumeration/Constant | Change Type|
console.error(`Fail to ceate URLParams.codeis${err.code},message is ${err.message}`);
}
```
## cl.url.2 URL Attribute Changes of URLParams Class APIs
URL attributes in the URL subsystem are changed:
The **searchParams: URLSearchParams** attribute is deprecated, and the **params: URLParams** attribute is added.
You need to adapt your application based on the following information.
**Change Impacts**
JS APIs in API version 9 are affected. Your application needs to adapt these APIs so that it can properly implement functions in the SDK environment of the new version.
**Key API/Component Changes**
| Module | Class| Method/Attribute/Enumeration/Constant | Change Type |
## cl.account_os_account.1 Change of Definition and Return Mode of Error Codes
To solve the issues that error code definitions of the account subsystem APIs were inconsistent and that the return mode of the error codes did not comply with relevant specifications of OpenHarmony, the following changes are made and take effect in API version 9 and later:
- Added the following unified error code definitions:
- Returned an error code in either of the following ways, according to the API type:
- Asynchronous API: An error message is returned via **AsyncCallback** or the **error** object of **Promise**. An error message related to the parameter type or quantity is returned via an exception.
- Synchronous API: An error message is returned via an exception.
**Change Impacts**
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
# ChangeLog of JS API Changes in the Multimedia Subsystem
Compared with OpenHarmony 3.2 Beta3, OpenHarmony 3.2 Beta4 has the following changes in APIs of the camera component in the multimedia subsystem.
## Camera API Changes
Some functional APIs are added and some others are deprecated to:
1. Improve the usability of camera APIs.
2. Help you quickly understand camera APIs and use them for development.
3. Facilitate expansion of framework functions in later versions, and reduce coupling between framework modules.
You need to refer to the following change description to adapt your application.
**Change Impacts**
JS APIs in API version 9 are affected. Your application needs to adapt these APIs so that it can properly implement functions in the SDK environment of the new version.
**Key API/Component Changes**
| Module | Class | Method/Attribute/Enumeration/Constant | Change Type|
console.log(`Promise returned with current exposure point : ${exposurePoint}`);
})
```
15. The **setMeteringPoint(point: Point, callback: AsyncCallback<void>): void;** and **setMeteringPoint(point: Point): Promise<void>;** APIs are added to **CaptureSession**.
The sample code is as follows:
```
const Point1 = {x: 1, y: 1};
captureSession.setMeteringPoint(Point1,(err) => {
if (err) {
console.log(`Failed to set the exposure point ${err.message}`);
return ;
}
console.log('Callback returned with the successful execution of setMeteringPoint');
5. The **release(callback: AsyncCallback<void>): void;** and **release(): Promise<void>;** APIs in **PreviewOutput** are deprecated.
6. The **release(callback: AsyncCallback<void>): void;** and **release(): Promise<void>;** APIs in **PhotoOutput** are deprecated.
7. The **release(callback: AsyncCallback<void>): void;** and **release(): Promise<void>;** APIs in **VideoOutput** are deprecated.
8. The **getCameraId(callback: AsyncCallback<string>): void;** and **getCameraId(): Promise<string>;** APIs in **CameraInput** are deprecated.
9. The **getExposurePoint(callback: AsyncCallback<Point>): void;** and **getExposurePoint(): Promise<Point>;** APIs in **CameraInput** are deprecated.
10. The **setExposurePoint(exposurePoint: Point, callback: AsyncCallback<void>): void;** and **setExposurePoint(exposurePoint: Point): Promise<void>;** APIs in **CameraInput** are deprecated.
**Changed APIs**
1. In **CameraManager**, the return value of **getCameras** is changed from **Array<Camera>** to **Array<CameraDevice>**, and the API name is changed from **getCameras** to **getSupportedCameras**. Therefore, the **getCameras(callback: AsyncCallback<Array<Camera>>): void;** and **getCameras(): Promise<Array<Camera>>;** APIs are changed to **getSupportedCameras(callback: AsyncCallback<Array<CameraDevice>>): void** and **getSupportedCameras(): Promise<Array<CameraDevice>>;**.
console.log(`Promise returned with an array of supported cameras: ${cameras.length}`);
})
```
2. In **CameraManager**, the input parameter of **createCameraInput** is changed from **cameraId: string** to **camera: CameraDevice**. Therefore, the **createCameraInput(cameraId: string, callback: AsyncCallback<CameraInput>): void;** and **createCameraInput(cameraId: string): Promise<CameraInput>;** APIs are changed to **createCameraInput(camera: CameraDevice, callback: AsyncCallback<CameraInput>): void;** and **createCameraInput(camera: CameraDevice): Promise<CameraInput>;**.
console.log('Promise returned with the CameraInput instance');
})
```
3. In **CameraManager**, the input parameter **profile: Profile** is added to **createPreviewOutput** and the **profile** parameter is obtained by the **getSupportedOutputCapability** API. Therefore, the **createPreviewOutput(surfaceId: string, callback: AsyncCallback<PreviewOutput>): void;** and **createPreviewOutput(surfaceId: string): Promise<PreviewOutput>;** APIs are changed to **createPreviewOutput(profile: Profile, surfaceId: string, callback: AsyncCallback<PreviewOutput>): void;** and **createPreviewOutput(profile: Profile, surfaceId: string): Promise<PreviewOutput>;**.
The sample code is as follows:
```
let profile = cameraoutputcapability.previewProfiles[0];
console.log('Promise returned with previewOutput created.');
})
```
4. In **CameraManager**, the input parameter **profile: Profile** is added to **createPhotoOutput** and the **profile** parameter is obtained by the **getSupportedOutputCapability** API. Therefore, the **CreatePhotoOutput(surfaceId: string, callback: AsyncCallback<PhotoOutput>): void;** and **CreatePhotoOutput(surfaceId: string): Promise<PhotoOutput>;** APIs are changed to **createPhotoOutput(profile: Profile, surfaceId: string, callback: AsyncCallback<PhotoOutput>): void;** and **createPhotoOutput(profile: Profile, surfaceId: string): Promise<PhotoOutput>;**.
The sample code is as follows:
```
let profile = cameraoutputcapability.photoProfiles[0];
console.log('Promise returned with photoOutput created.');
})
```
5. In **CameraManager**, the input parameter **profile: Profile** is added to **createVideoOutput** and the **profile** parameter is obtained by the **getSupportedOutputCapability** API. Therefore, the **createVideoOutput(surfaceId: string, callback: AsyncCallback<VideoOutput>): void;** and **createVideoOutput(surfaceId: string): Promise<VideoOutput>;** APIs are changed to **createVideoOutput(profile: VideoProfile, surfaceId: string, callback: AsyncCallback<VideoOutput>): void;** and **createVideoOutput(profile: VideoProfile, surfaceId: string): Promise<VideoOutput>;**.
The sample code is as follows:
```
let profile = cameraoutputcapability.videoProfiles[0];
console.log('Promise returned with videoOutput created.');
})
```
6. In **CameraManager**, the input parameter **metadataObjectTypes: Array<MetadataObjectType>** is added to **createMetadataOutput**, and the **metadataObjectTypes** parameter is obtained by the **getSupportedOutputCapability** API. Therefore, the **function createMetadataOutput(callback: AsyncCallback<MetadataOutput>): void;** and **function createMetadataOutput(): Promise<MetadataOutput>;** APIs are changed to **createMetadataOutput(metadataObjectTypes: Array<MetadataObjectType>, callback: AsyncCallback<MetadataOutput>): void;** and **createMetadataOutput(metadataObjectTypes: Array<MetadataObjectType>): Promise<MetadataOutput>;**.
The sample code is as follows:
```
let metadataObjectTypes = cameraoutputcapability.supportedMetadataObjectTypes;
console.log('Promise returned with metadataOutput created.');
})
```
7. In **CameraManager**, **createCaptureSession** does not need to consider the context attribute. Therefore, the **createCaptureSession(context: Context, callback: AsyncCallback<CaptureSession>): void;** and **createCaptureSession(context: Context): Promise<CaptureSession>;** APIs are changed to **createCaptureSession(callback: AsyncCallback<CaptureSession>): void;** and **createCaptureSession(): Promise<CaptureSession>;**.
console.log('Promise returned with captureSession created.');
})
```
8. The type of the **camera** attribute of the **CameraStatusInfo** API is changed from **Camera** to **CameraDevice**.
9. In **CameraInput**, the input parameter **camera: CameraDevice** is added to the **on(type: 'error')** API. Therefore, the **on(type: 'error', callback: ErrorCallback<CameraInputError>): void;** API is changed to **on(type: 'error', camera: CameraDevice, callback: ErrorCallback<CameraInputError>): void;**.
12. The following enumerations are added to **ExposureMode**:
Enumeration: EXPOSURE_MODE_AUTO; initial value: changed from the default value to **1**
Enumeration: EXPOSURE_MODE_CONTINUOUS_AUTO; initial value: changed from the default value to **2**
13. The following enumerations are added to **VideoStabilizationMode**:
Enumeration: LOW; initial value: changed from the default value to **1**
Enumeration: MIDDLE; initial value: changed from the default value to **2**
Enumeration: HIGH; initial value: changed from the default value to **3**
Enumeration: AUTO; initial value: changed from the default value to **4**
14. In **CaptureSession**, the parameter of the **addOutput** API is changed from the original subclass type (**PreviewOutput**, **PhotoOutput**, **VideoOutput**, and **MetadataOutput**) to the base class type (**CameraOutput**). After the change, the number of APIs is reduced from 8 to 2.
console.log('Promise returned with cameraOutput added.');
})
```
15. In **CaptureSession**, the parameter of the **removeOutput** API is changed from the original subclass type (**PreviewOutput**, **PhotoOutput**, **VideoOutput**, and **MetadataOutput**) to the base class type (**CameraOutput**). After the change, the number of APIs is reduced from 8 to 2.
## cl.device_manager.1 Error Information Return Method Change of APIs
The device manager API uses service logic return values to indicate the error information, which does not comply with the API error code specifications of OpenHarmony. The following changes are made in API version 9 and later:
Asynchronous API: An error message is returned via **AsyncCallback** or the **error** object of **Promise**.
Synchronous API: An error message is returned via an exception.
**Change Impacts**
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
Error code processing is added for the following APIs:
## cl.usb_manager.1 Error Information Return Method Change of APIs
The USB manager API uses service logic return values to indicate the error information, which does not comply with the API error code specifications of OpenHarmony. Beginning from API version 9, error information is returned by throwing exceptions.
**Change Impacts**
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
Changed the USB module name from **@ohos.usb.d.ts** to **@ohos.usbV9.d.ts**, and added error code processing for all APIs in the module.
**Adaptation Guide**
Take the **getDevices** API as an example. The sample code is as follows:
```ts
importusbV9from'@ohos.usbV9'
try{
usbV9.getDevices();// If an improper parameter is passed to this API, an exception will be thrown.
## IPC&RPC APIs support the exception handling mode and the selection of synchronous or asynchronous message sending by passing a Boolean value or a numeric value.
1. Some IPC&RPC APIs of DSoftBus use service logic return values to indicate the error information, which does not comply with the API error code specifications of OpenHarmony.
2. A Boolean value can be passed to specify the mode of sending information as asynchronous or synchronous.
#### Change Impacts
This version is compatible with earlier versions and no adaptation is required. Newly added APIs can be called to support the following changes:
1. Supports exception handling and return of error codes.
2. Supports selection of synchronous or asynchronous message sending by passing a Boolean value or by passing 0 or a non-0 number.
#### **Key API/Component Changes**
For adaptation to the unified API exception handling mode, related IPC&RPC APIs are deprecated, and corresponding new APIs and methods are added. The newly added APIs support unified error code handling specifications and function the same as the original APIs.
The newly added APIs return error codes and corresponding error information by throwing exceptions. Take the **create** API in **MessageParcel** as an example. The sample code is as follows:
The return value of file I/O APIs of **file_api** does not contain the error code. The original APIs are deprecated, and new APIs are added.
**Change Impacts**
For applications developed based on earlier versions, pay attention to the iterative update of discarded APIs. The specifications of the new APIs are slightly adjusted. Pay attention to the usage of the new APIs.
**Key API/Component Changes**
For the adaptation to the unified API exception handling mode, related file I/O APIs are deprecated, and corresponding new APIs are added. Original APIs are stored in **@ohos.fileio**, and the new ones are stored in **@ohos.file.fs**. The newly added APIs support unified error code handling specifications and function the same as the original APIs. The parameters are slightly adjusted.
## cl.global.1 Support of Error Codes for the Internalization Module
APIs provided by the internationalization component of the globalization subsystem are changed to support error codes in the following scenarios. The following changes are made in API version 9 and later:
- Obtaining the local expression of a country or language
- Obtaining the list of languages supported by the system and the list of areas supported by a language
- Checking whether a language matches an area
- Obtaining and setting the system language, country or region, and area
- Obtaining and setting the 24-hour format of the system
- Obtaining, adding, and removing the preferred language
- Obtaining and setting localized numbers
You need to adapt your applications based on the following information:
**Change Impacts**
The preceding APIs are changed to the static methods of the **System** class. When such an API is called, add the class name to the end of the module name.
The return value data type of the setting APIs (for example, **setSystemLanguage**) is changed from boolean to void.
When a call to an API fails, an error code is returned according to the failure cause. For example, when permissions are not correctly configured for an application, **201** is returned.
## cl.inputmethod_frameworks.1 API Error Information Return Method Change
The internal APIs of the following modules used service logic return values to indicate error information, which did not comply with the error code specifications of OpenHarmony. Therefore, they are modified in API version 9 and later.
- Input method framework module: system API, @ohos.inputmethod.d.ts
- Input method service module: system API, @ohos.inputmethodengine.d.ts
- Input method ExtentionAbility module: system API, @ohos.inputmethodextensionability.d.ts
- Input method ExtentionContext module: system API, @ohos.inputmethodextensioncontext.d.ts
- Input method subtype module: system API, @ohos.inputMethodSubtype.d.ts
Asynchronous API: An error message is returned via **AsyncCallback** or the **error** object of **Promise**.
Synchronous API: An error message is returned via an exception.
**Change Impacts**
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
Error code processing is added for the following APIs:
- Use the **getInputMethodAbility()** API to obtain an **InputMethodAbility** object, and do not use **getInputMethodEngine()** to obtain an **InputMethodEngine** object.
- Use methods in **InputMethodAbility**, and do not use methods in **InputMethodEngine**.
- Use the **on('inputStart')** method in **InputMethodAbility** to obtain a **KeyboardController** instance and an **InputClient** instance, and do not use the **on('inputStart')** method in **InputMethodEngine** to obtain a **TextInputClient** instance.
## cl.multimodalinput.1 Error Information Return Method Change of APIs
The internal APIs of the following modules used service logic return values to indicate error information, which did not comply with the error code specifications of OpenHarmony. Therefore, they are modified in API version 9 and later.
- Input consumer module (**@ohos.multimodalInput.inputConsumer.d.ts**): system APIs
- Screen hopping module (**@ohos.multimodalInput.inputDeviceCooperate.d.ts**): system APIs
- Key injection module (**@ohos.multimodalInput.inputEventClient.d.ts**): system APIs
- Input listening module (**@ohos.multimodalInput.inputMonitor.d.ts**): system APIs
- Mouse pointer module (**@ohos.multimodalInput.pointer.d.ts**): system APIs and third-party APIs
Asynchronous APIs in the preceding modules have the following changes: A parameter check error is returned synchronously; a service logic error is returned via **AsyncCallback** or the **error** object of **Promise**. No change is made to synchronous APIs.
**Change Impacts**
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
## cl.powermgr.1 Error Information Return Method Change of APIs
The following APIs used service logic return values to indicate error information, which did not comply with the error code specifications of OpenHarmony. Therefore, they are modified in API version 9 and later.
- Power consumption statistics: [@ohos.batteryStatistics](../../../application-dev/reference/apis/js-apis-batteryStatistics.md)
Asynchronous API: An error message is returned via **AsyncCallback** or the **error** object of **Promise**.
Synchronous API: An error message is returned via an exception.
#### Change Impacts
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
#### Key API/Component Changes
Error code processing is added for the following APIs:
For details, see the API reference document of each API.
## cl.powermgr.2 System API Change
#### Change Impacts
The application developed based on earlier versions needs to adapt to new API names and the new method for returning API error information. Otherwise, the original service logic will be affected.
Compared with OpenHarmony 3.2 Beta3, OpenHarmony 3.2.8.1 has the following changes in its upload and download subsystem:
## cl.request.1 Changes of Error Code Definitions and Some API Names
- The processing of the [upload and download error codes](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/errorcodes/errorcode-request.md) is added to the upload and download APIs.
- An error message is returned via **AsyncCallback** or the **error** object of **Promise**. An error message related to the parameter type or quantity is returned via an exception.
- Some APIs need to be replaced with new APIs, and the parameters remain unchanged.
**Change Impacts**
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
| Module | Class | Method/Attribute/Enumeration/Constant | Change Type|
## cl.resourceManager.1 Name Change of Some Multi-Project APIs in API Version 9 of Resource Manager
The resource manager can return error codes and error information for APIs in API version 9 and later. Some multi-project APIs in API version 9 need to be adapted. The following changes are made in API version 9 and later:
Some multi-project APIs of the resource manager need to be replaced with new APIs, and the parameters remain unchanged.
**Change Impacts**
For applications developed based on earlier versions, relevant JavaScript multi-project APIs need to be replaced with new APIs.
The following describes how to change **getMedia** to **getMediaContent** in callback mode. The promise mode is similar. You only need to change the function name, add the error code and error information, and keep other information unchanged. The sample code is as follows:
- Before the change: **getMedia(resource: Resource, callback: AsyncCallback<Uint8Array>): void;**
## cl.theme.1 Support of Exception Handling for APIs in API Version 9
The internal APIs of the following modules used service logic return values to indicate error information, which did not comply with the error code specifications of OpenHarmony. Therefore, they are modified in API version 9 and later.
APIs in the preceding modules are changed as follows:
Synchronous API: An error message is returned via an exception.
Asynchronous API: A parameter check error is returned synchronously. A service logic error is returned via **AsyncCallback** or the **error** object of **Promise**.
**Change Impacts**
The application developed based on earlier versions needs to adapt the method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
Deprecated APIs of the wallpaper management service:
The bundle manager APIs use service logic return values to indicate the error information, which does not comply with the API error code specifications of OpenHarmony. APIs in API version 8 and earlier are deprecated. Replace them with APIs in API version 9 instead.
**Change Impacts**
The application developed based on the SDK versions of OpenHarmony 3.2.8.2 and later needs to adapt the modules and APIs (version 9) and their method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
The new APIs are classified by module. The original **d.ts** file is divided into multiple ones. You can import the **d.ts** files as required. The newly added APIs support unified error code handling specifications and function the same as the original APIs. APIs whose functions are changed or added are listed separately.
For adaptation to the unified API exception handling mode, bundle manager APIs (version 8 and earlier) are deprecated (original APIs in the following table) and corresponding new APIs (version 9) in the following table are added.
2. Call the bundle manager installation and uninstallation API.
```
import installer form '@ohos.bundle.installer'
```
3. Call the bundle manager installation-free API.
```
import freeInstall form '@ohos.bundle.freeInstall'
```
4. Call the bundle manager launcher APIs.
```
import launcherBundleManager form '@ohos.bundle.launcherBundleManager'
import bundleMonitor form '@ohos.bundle.bundleMonitor'
```
6. Call the bundle manager API for the default application.
```
import defaultAppManager form '@ohos.bundle.defaultAppManager'
```
7. Call the distributed bundle manager API.
```
import distributedBundle form '@ohos.bundle.distributedBundle'
```
In addition, exception handling is needed. For details, see the API reference for the new APIs.
## cl.bundlemanager.1 Bundle Manager API Structure Changes
The bundle manager APIs use service logic return values to indicate the error information, which does not comply with the API error code specifications of OpenHarmony. The structures of APIs in API version 8 and earlier are deprecated. Use the structures of APIs in API version 9 instead.
**Change Impacts**
The application developed based on the SDK versions of OpenHarmony 3.2.8.2 and later needs to adapt new structures. Otherwise, the original service logic will be affected. The export function of original level-2 modules will also be deprecated. Instead, the level-2 modules' export function of new APIs will be used, and new level-1 d.ts modules are imported.
**Key API/Component Changes**
The structures of APIs in API version 8 and earlier are sorted out and deprecated, and those of new APIs in API version 9 are added. The following table lists the comparison before and after the change. Some structures are combined. For example, replace **moduleInfo.d.ts** with **hapModuleInfo.d.ts** and **customizeData.d.ts** with **metadata.d.ts**. The structures' functions are the same as those of the original ones. Structures whose attributes are changed or added are listed separately.
| Original Structure (Deprecated) | New Structure (Added) |
1. Replace the code of original structures with the code of new ones.
2. Deprecate the export function of original level-2 modules. Instead, use the level-2 modules' export function of new APIs, and import new level-1 d.ts modules.
## cl.bundlemanager.3 Bundle Manager Query API Changes
Bundle manager query APIs are changed as follows: APIs of version 8 and earlier in **@ohos.bundle** are deprecated, and APIs of version 9 in **@ohos.bundle** are changed to **@ohos.bundle.bundleManager**, **@ohos.bundle.freeInstall**, and **@ohos.bundle.installer**. Most deprecated APIs are added to **@ohos.bundle.bundleManager** and changed to system APIs, and the exception handling capability is added.
API call mode: APIs are now used by the **@ohos.bundle.bundleManager**, **@ohos.bundle.freeInstall**, and **@ohos.bundle.installer** modules, instead of the **@ohos.bundle** module.
The system capability of the **@ohos.bundle.bundleManager** and **@ohos.bundle.installer** modules is **SystemCapability.BundleManager.BundleFramework.Core**, and that of **@ohos.bundle.freeInstall** is **SystemCapability.BundleManager.BundleFramework.FreeInstall**.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. The applications that use the APIs of version 9 need to adapt new modules and APIs. APIs of version 9 in **@ohos.bundle** are moved to the new **@ohos.bundle.bundleManager.d.ts**, **@ohos.bundle.freeInstall**, and **@ohos.bundle.installer** files.
**Key API/Component Changes**
The following table lists the deprecated and changed APIs involved in **@ohos.bundle.d.ts**. The APIs not listed in the table have no change in API names and input parameters, and they have new exception handling and import modules. The APIs can be directly used after being imported to **@ohos.bundle.bundleManager.d.ts**, **@ohos.bundle.freeInstall**, and **@ohos.bundle.installer**. The APIs listed in the table are changed in API version 9, and those marked with "N/A" are deprecated in API version 9.
| Original API (Deprecated) | New API (Changed or Added) | System API| New File Name |
All **bundle/bundleInfo.d.ts** fields in the bundle manager are deprecated. [bundle/bundleInfo.d.ts]((https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundle/bundleInfo.d.ts)) is changed to [bundleManager/bundleInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/bundleInfo.d.ts), involving field type changes.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. The applications that use the APIs of version 9 need to adapt new modules and APIs. When a level-2 module is used to export **BundleInfo**, the **@ohos.bundle.bundleManager** module needs to be imported.
**Key API/Component Changes**
The following table describes the changed fields in the **BundleInfo** structure. After other fields are deprecated in **bundle/bundleInfo.d.ts**, they have corresponding values in the new **[bundleManager/bundleInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/bundleInfo.d.ts)**. If corresponding fields do not exist, the fields have been deprecated in API version 9.
| Deprecated | Added or Changed in API Version 9 | Type |
The **SignatureInfo** structure is added to API version 9 as follows.
| Field | Type |
| ----------- | ------ |
| appId | string |
| fingerprint | string |
**Adaptation Guide**
Use the **BundleInfo** structure of API version 9 for modules imported for bundle manager query. The following module needs to be imported when a level-2 module is used for export.
The **ApplicationInfo** structure is changed. The original **bundle/applicationInfo.d.ts** fields in the bundle manager are deprecated, and the file is changed from **bundle/applicationInfo.d.ts** to **bundleManager/applicationInfo.d.ts**, involving field type changes.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. The applications that use the APIs of version 9 need to adapt new modules and APIs. When a level-2 module is used to export **ApplicationInfo**, the **@ohos.bundle.bundleManager** module needs to be imported.
**Key API/Component Changes**
The following table describes the changed fields in the **ApplicationInfo** structure. After other fields are deprecated in **bundle/applicationInfo.d.ts**, they have corresponding values in the new [bundleManager/applicationInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/applicationInfo.d.ts). If corresponding fields do not exist, the fields have been deprecated in API version 9.
| Deprecated | Added or Changed in API Version 9| Type |
The **HapModuleInfo** structure is changed. The original **bundle/hapModuleInfo.d.ts** and **moduleInfo.d.ts** fields in the bundle manager are deprecated, and the files are changed to [bundleManager/hapModuleInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/hapModuleInfo.d.ts), involving field type changes.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. The applications that use the APIs of version 9 need to adapt new modules and APIs. When a level-2 module is used to export **HapModuleInfo**, the **@ohos.bundle.bundleManager** module needs to be imported.
**Key API/Component Changes**
The following table describes the changed fields in the **HapModuleInfo** structure. After other fields are deprecated in **bundle/hapModuleInfo.d.ts**, they have corresponding values in the new **bundleManager/hapModuleInfo.d.ts** file.
| Deprecated | Added or Changed in API Version 9 | Type |
The original **bundle/hapModuleInfo.d.ts** and **moduleInfo.d.ts** fields in the bundle manager are deprecated, and the files are changed to [bundleManager/hapModuleInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/hapModuleInfo.d.ts), involving field changes.
The **ModuleInfo** structure is deprecated and replaced by **HapModuleInfo** in [bundleManager/hapModuleInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/hapModuleInfo.d.ts).
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. The applications that use the APIs of version 9 need to adapt new modules and APIs. The **ModuleInfo** structure is deprecated and replaced by **HapModuleInfo**.
**Key API/Component Changes**
The **ModuleInfo** structure is deprecated and replaced by **HapModuleInfo**.
**Adaptation Guide**
Use the **HapModuleInfo** structure of API version 9.
The **AbilityInfo** structure is changed. The original **bundle/abilityInfo.d.ts** file is deprecated and changed to **bundleManager/abilityInfo.d.ts**, involving field type changes.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. The applications that use the APIs of version 9 need to adapt new modules and APIs.
**Key API/Component Changes**
The following table lists the field changes in the **AbilityInfo** structure for the bundle manager. Fields that are not listed in the table exist in the new **AbilityInfo** structure after being deprecated. Fields marked with "N/A" have been deprecated in API version 9 and do not exist in the new **AbilityInfo** structure.
| Deprecated | Added or Changed in API Version 9 | Type |
The fields of the new structure **WindowSize** of API version 9 are as follows.
| Field | Type |
| :-------------: | :----: |
| maxWindowRatio | number |
| minWindowRatio | number |
| maxWindowWidth | number |
| minWindowWidth | number |
| maxWindowHeight | number |
| minWindowHeight | number |
**Adaptation Guide**
Use the **AbilityInfo** structure of API version 9.
## cl.bundlemanager.9 BundleFlag Changes
**BundleFlag** is changed to **BundleFlag**, **ApplicationFlag**, and **AbilityFlag** in **@ohos.bundle.bundleManager**. Different types of flags are passed based on the input parameters of new APIs.
**Change Impacts**
**BundleFlag** is changed to **BundleFlag**, **ApplicationFlag**, and **AbilityFlag** in **@ohos.bundle.bundleManager**. Different types of flags are passed based on the input parameters of new APIs. If **BundleFlag** of a version earlier than API version 9 is directly used, the query may fail.
**Key API/Component Changes**
**BundleFlag** in the original **@ohos.bundle** is deprecated and replaced by **BundleFlag**, **ApplicationFlag**, and **AbilityFlag** in the new **@ohos.bundle.bundleManager**.
The following table describes **BundleFlag** of API version 9.
| GET_BUNDLE_INFO_DEFAULT | 0x00000000 | Obtains the default **BundleInfo**. The obtained **BundleInfo** does not contain **signatureInfo**, **hapModuleInfo**, **appInfo**, **reqPermissionDetails**, or **permissionGrantStates**.|
| GET_BUNDLE_INFO_WITH_APPLICATION | 0x00000001 | Obtains **appInfos** with the default **BundleInfo**. |
| GET_BUNDLE_INFO_WITH_HAP_MODULE | 0x00000002 | Obtains **hapModulesInfo** with the default **BundleInfo**. |
| GET_BUNDLE_INFO_WITH_ABILITY | 0x00000004 | Indicates whether **abilitiesInfo** is obtained with **hapModulesInfo**. This flag must be used together with **GET_BUNDLE_INFO_WITH_HAP_MODULE** and cannot be used independently.|
| GET_BUNDLE_INFO_WITH_EXTENSION_ABILITY | 0x00000008 | Indicates whether **extensionAbilitiesInfo** is obtained with **hapModulesInfo**. This flag must be used together with **GET_BUNDLE_INFO_WITH_HAP_MODULE** and cannot be used independently.|
| GET_BUNDLE_INFO_WITH_REQUESTED_PERMISSION | 0x00000010 | Obtains **reqPermissionDetails** and **permissionGrantStates** with the default **BundleInfo**. |
| GET_BUNDLE_INFO_WITH_METADATA | 0x00000020 | Indicates whether the returned **ApplicationInfo**, **AbilityInfo**, and **ExtensionAbilityInfo** contain metadata. This flag cannot be used independently.|
| GET_BUNDLE_INFO_WITH_DISABLE | 0x00000040 | Obtains **BundleInfo** of a disabled application and disabled ability information in **abilitiesInfo**.|
| GET_BUNDLE_INFO_WITH_SIGNATURE_INFO | 0x00000080 | Obtains **signatureInfo** with the default **BundleInfo**. |
The following table describes **ApplicationFlag** of API version 9.
| GET_APPLICATION_INFO_DEFAULT | 0x00000000 | Obtains the default **ApplicationInfo**. The obtained **ApplicationInfo** does not contain permission or metadata information.|
| GET_APPLICATION_INFO_WITH_PERMISSION | 0x00000001 | Obtains **permissions** with the default **ApplicationInfo**. |
| GET_APPLICATION_INFO_WITH_METADATA | 0x00000002 | Obtains **metadata** with the default **ApplicationInfo**. |
| GET_ABILITY_INFO_DEFAULT | 0x00000000 | Obtains the default **AbilityInfo**. The obtained **AbilityInfo** does not contain permission, metadata, or disabled ability information.|
| GET_ABILITY_INFO_WITH_DISABLE | 0x00000008 | Obtains all **AbilityInfo**, including disabled abilities. |
| GET_ABILITY_INFO_ONLY_SYSTEM_APP | 0x00000010 | Obtains **AbilityInfo** for system applications. |
**Adaptation Guide**
Use various flags according to the called API in **@ohos.bundle.bundleManager.d.ts**.
## cl.bundlemanager.10 ApplicationType Enumerated Value Changes in the Default Application Module
For the **@ohos.bundle.defaultApp** module, both API functions and usage remain unchanged, but only the enumerated values of **ApplicationType** are changed.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. The applications that use the APIs of version 9 need to adapt new enumerated values.
**Key API/Component Changes**
The enumerated values of **ApplicationType** are changed as follows.
| ApplicationType| Added or Changed in API Version 9 | API Version 8 and Earlier|
API exception handling is rectified. The distributed bundle manager module is changed. The original **@ohos.distributedBundle.d.ts** APIs are deprecated, and the **@ohos.distributedBundle.d.ts** file is changed to [@ohos.bundle.distributedBundle.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.bundle.distributedBundle.d.ts). The **getRemoteAbilityInfos** API is changed to **getRemoteAbilityInfo**. The export function of a level-2 module in the **RemoteAbilityInfo** structure can be used only after a new module is imported.
**Change Impacts**
Applications using APIs earlier than version 9 are not affected. The names of the distributed module and the **getRemoteAbilityInfos** API are changed. As a result, applications using APIs of version 9 may fail to be compiled using the new SDK.
**Key API/Component Changes**
All APIs in **@ohos.distributedBundle.d.ts** are deprecated. The **@ohos.bundle.distributedBundle.d.ts** file is added. The functions of some APIs are the same as those of the original ones. New APIs support exception handling. The API changes are as follows.
| Deprecated | Added or Changed in API Version 9 | System API|
import distributedBundle form '@ohos.bundle.distributedBundle'
```
## cl.bundlemanager.12 Installation-Free Module and API Changes
APIs support exception handling rectification. The installation-free module is moved from **@ohos.bundle.d.ts** to **@ohos.bundle.freeInstall.d.ts**, involving module and API changes. The system capability is **SystemCapability.BundleManager.BundleFramework.FreeInstall**.
1. The imported **@ohos.bundle** module needs to be changed to **@ohos.bundle.freeInstall**.
2. The **setModuleUpgradeFlag** API is changed to **setHapModuleUpgradeFlag**.
3. The **isModuleRemovable** API is changed to **isHapModuleRemovable**.
4. The **getDispatcher** API is changed to **getDispatchInfo**.
**Change Impacts**
Applications using APIs earlier than version 9 are not affected. Applications using APIs of version 9 will fail to be compiled.
**Key API/Component Changes**
The following table lists the installation-free API changes. For APIs not listed in the table, their names and usage are unchanged, but the module name is changed.
| Deprecated | Added or Changed in API Version 9 | System API|
To use installation-free APIs, import a new module and modify the APIs according to their mappings.
```
import freeInstall from '@ohos.bundle.freeInstall'
```
## cl.bundlemanager.13 Installation-Free Structure Field Changes
The fields of the **DisPatchInfo**, **AbilityFormInfo**, **ModuleDistroInfo**, and **ModuleConfigInfo** structures are changed as follows:
1. The name of the **dispatchAPI** field in **DispatchInfo** is changed to [dispatchAPIVersion](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/dispatchInfo.d.ts), and the type is string, which is unchanged. The field indicates the version of the installation-free API. The meaning remains unchanged.
2. The type of the **supportDimensions** field in the **AbilityFormInfo** structure is changed from **Array\<number>** to **Array\<string>**.
3. The type of the **defaultDimension** field in the **AbilityFormInfo** structure is changed from **number** to **string**.
4. The **mainAbility** field is deprecated in the **ModuleDistroInfo** structure and moved to the **ModuleConfigInfo** structure.
5. The **mainAbility** field is added to the **ModuleConfigInfo** structure.
**Change Impacts**
Applications using APIs earlier than version 9 are not affected. The value type of certain fields in the structures is changed. As a result, applications using APIs of version 9 may fail to be compiled using the new SDK.
**Key API/Component Changes**
1. DispatchInfo
| Deprecated | Added or Changed in API Version 9 | Type |
| Field | Added or Changed in API Version 9| Type |
| ----------- | -------------- | ------ |
| mainAbility | N/A | string |
4. MooduleConfigInfo
| Field| Added or Changed in API Version 9| Type |
| ---- | -------------- | ------ |
| N/A | mainAbility | string |
**Adaptation Guide**
To use installation-free APIs, import a new module and modify the structures according to their mappings.
```
import freeInstall from '@ohos.bundle.freeInstall'
```
## cl.bundlemanager.14 Structure Changes
The structure **GrantStatus** is changed to **PermissionGrantState**. The enumeration type and values remain unchanged.
**Change Impacts**
Applications using APIs earlier than version 9 are not affected. The structure name is changed. As a result, applications using APIs of version 9 may fail to be compiled using the new SDK.
**Key API/Component Changes**
The **GrantStatus** structure indicating the authorization status is changed to **PermissionGrantState** in **@ohos.bundle.bundleManager.d.ts**.
| Name | Value|
| ------------------ | ------ |
| PERMISSION_DENIED | -1 |
| PERMISSION_GRANTED | 0 |
**Adaptation Guide**
Import a new module and change the structure name to **PermissionGrantState**.
```
import bundle form '@ohos.bundle.bundleManager'
```
## cl.bundlemanager.15 Bundle Manager ShortcutInfo Structure Field Changes
Fields in the **ShortcutInfo** structure of the bundle manager are changed. The **bundle/shortcutInfo.d.ts** fields are deprecated, and the file is changed to [bundleManager/shortcutInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/bundleManager/shortcutInfo.d.ts). The **ShortcutInfo** and **ShortWant** structures are changed to system APIs.
**Change Impacts**
Applications using APIs earlier than version 9 are not affected. The value type of certain fields in the structures is changed. As a result, applications using APIs of version 9 may fail to be compiled using the new SDK.
**Key API/Component Changes**
The **ShortcutInfo** and **ShortcutWant** structures are involved. To use the level-2 module export function, import the new module **@ohos.bundle.launcherBundleManager**.
The following table lists the field changes of the **ShortcutInfo** structure. Fields that are not listed in the table still exist in API version 9.
| Deprecated | Added or Changed in API Version 9| Type |
| -------------- | -------------- | ------- |
| disableMessage | N/A | string |
| isStatic | N/A | boolean |
| isHomeShortcut | N/A | boolean |
| isEnabled | N/A | boolean |
| disableMessage | N/A | boolean |
The following table lists the field changes of the **ShortcutWant** structure. Fields that are not listed in the table still exist in API version 9.
| Deprecated | Added or Changed in API Version 9| Type |
| ----------- | -------------- | ------ |
| targetClass | targetAbility | string |
**Adaptation Guide**
To use installation-free APIs, import a new module and modify the structures according to their mappings.
```
import launcherBundleManager form '@ohos.bundle.launcherBundleManager'
```
## cl.bundlemanager.16 getBundleInstaller API Changes
The **getBundleInstaller** API of the bundle manager is moved from **@ohos.bundle.d.ts** to [@ohos.bundle.installer.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.bundle.installer.d.ts).
The system capability is **SystemCapability.BundleManager.BundleFramework.Core**.
**Change Impacts**
Applications using APIs earlier than version 9 are not affected. Applications that use APIs of version 9 need to adapt the new module and APIs.
**Key API/Component Changes**
1. For **getBundleInstaller**, the import module is changed from **@ohos.bundle** to **@ohos.bundle.installer**.
**Adaptation Guide**
Import the new bundle manager installation module and call **getBundleInstaller**.
```
import installer form '@ohos.bundle.installer'
```
## cl.bundlemanager.17 Bundle Manager Installation API Changes
The bundle manager installation API is moved from **bundle/bundleInstaller.d.ts** to [@ohos.bundle.installer.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.bundle.installer.d.ts). The system capability is **SystemCapability.BundleManager.BundleFramework.Core**.
**Change Impacts**
Applications using APIs earlier than version 9 are not affected. Applications that use APIs of version 9 need to adapt the new module and APIs.
**Key API/Component Changes**
1. The exception handling capability is added to the **install**, **uninstall**, and **recover** APIs. The API names and input parameters remain unchanged, and only the module name is changed.
2. Fields are added to the **HashParam** structure as follows.
| Added in API Version 9 | Type |
| ---------- | ------ |
| moduleName | string |
| hashValue | string |
3. Fields are added to the **InstallParam** structure as follows.
| Added in API Version 9 | Type |
| ----------------- | ----------------- |
| userId | number |
| installFlag | number |
| isKeepData | boolean |
| hashParams | Array\<HashParam> |
| crowdtestDeadline | number |
4. The **InstallStatus** structure is deprecated.
**Adaptation Guide**
Import the new bundle manager installation module and call **getBundleInstaller**.
```
import installer form '@ohos.bundle.installer'
```
## cl.bundlemanager.18 Bundle Manager Installation Function Changes
The installation specifications of the bundle manager module are changed, in which whether the application **deviceType** setting matches the device type is verified. If they do not match, the installation fails.
**Change Impacts**
Applications developed in earlier versions are affected. Applications can be successfully installed in the image of the new version only after adaptation.
**Key API/Component Changes**
N/A
**Adaptation Guide**
Configure device types in the application configuration file **config.json** or **module.json**.
```
{
"module": {
"name": "entry",
"type": "entry",
// ...
"deviceTypes":[
// In this example, default and tablet are configured. In this case, the application can be installed on default and tablet.
"default",
"tablet"
],
// ...
}
```
## cl.bundlemanager.19 innerBundleManger Module API Changes
**innerBundleManager** API functions are unchanged, but API usage is changed. The [@ohos.bundle.launcherBundleManager.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.bundle.launcherBundleManager.d.ts) module needs to be imported to use **innerBundleManager** APIs. The system capability is **SystemCapability.BundleManager.BundleFramework.Core**.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. Applications that use the **innerBundleManager** API capabilities need to adapt the new module and APIs.
**Key API/Component Changes**
The functions and input parameters of the following APIs remain unchanged, and API exception handling is added. When a level-2 module is used to export **ShortcutInfo** and **ShortcutWant**, the **@ohos.bundle.launcherBundleManager** module needs to be imported. The **on** and **off** APIs are deprecated from **@ohos.bundle.innerBundleManger.d.ts** and moved to **@ohos.bundle.bundleMonitor.d.ts**.
1. getLauncherAbilityInfos<br>
2. getAllLauncherAbilityInfos<br>
3. getShortcutInfos
**Adaptation Guide**
Import the new module **@ohos.bundle.launcherBundleManage**.
```
import launcherBundleManager form '@ohos.bundle.launcherBundleManage'
**innerBundleManager** API functions are unchanged, but API usage is changed. The [@ohos.bundle.bundleMonitor.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.bundle.bundleMonitor.d.ts) module needs to be imported to use **innerBundleManager** APIs, which are system APIs. The system capability is **SystemCapability.BundleManager.BundleFramework.Core**.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. Applications that use the **innerBundleManager** API capabilities need to adapt the new module and APIs.
**Key API/Component Changes**
The **on** and **off** APIs are changed to **@ohos.bundle.bundleMonitor.d.ts**. The input parameters are different from those of the original APIs. The function prototype of the APIs of version 9 is as follows:
```
function on(type: BundleChangedEvent, callback: Callback<BundleChangedInfo>): void;
function off(type: BundleChangedEvent, callback?: Callback<BundleChangedInfo>): void;
```
**BundleChangedEvent**:
```
type BundleChangedEvent = 'add' | 'update' | 'remove';
```
Callback function of **BundleChangedInfo**:
```
interface BundleChangedInfo {
readonly bundleName: string;
readonly userId: number;
}
```
After obtaining **BundleChangedInfo**, perform related operations (that is, the **add**, **update**, and **remove** functions in **BundleStatusCallback** of the original API).
**Adaptation Guide**
Import the **bundleMonitor** module and call related APIs.
```
import bundleMonitor form '@ohos.bundle.bundleMonitor'
```
## cl.bundlemanager.21 bundleStatusCallback.d.ts API Changes
The **bundleStatusCallback.d.ts** APIs of the bundle manager are deprecated and moved to [@ohos.bundle.bundleMonitor.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.bundle.bundleMonitor.d.ts). The **add**, **update**, and **remove** functions in **BundleStatusCallback** are deprecated and changed to **BundleChangedEvent**, which is a system API. The system capability is **SystemCapability.BundleManager.BundleFramework.Core**.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. Applications that use the **BundleStatusCallback** API capabilities need to adapt the new module and APIs.
**Key API/Component Changes**
All the following functions are deprecated. The **BundleChangedEvent** API is added to **@ohos.bundle.bundleMonitor.d.ts**.
1. add
2. update
3. remove
**Adaptation Guide**
Import the **bundleMonitor** module and call related APIs. Different from the previous **BundleStatusCallback**, **BundleStatusCallback** passes the **add**, **update**, and **remove** functions to the **on** and **off** APIs. The **BundleMonitor** uses the **on** or **off** API of version 9 to return **BundleChangedInfo** to the caller through the callback.
```
import bundleMonitor form '@ohos.bundle.bundleMonitor'
```
## cl.bundlemanager.22 Zlib Module API Changes
The **Zlib** module APIs of the bundle manager are changed. Certain APIs in [@ohos.zlib.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/master/api/@ohos.zlib.d.ts) are deprecated and changed. The system capability is **SystemCapability.BundleManager.Zlib**.
**Change Impacts**
There is no impact on applications that use the APIs of versions earlier than 9. Applications that use APIs of version 9 need to adapt the new module and APIs.
**Key API/Component Changes**
The following table lists the changed APIs in **@ohos.zlib.d.ts**. The usage of the new APIs of version 9 is the same, and API exception handling is supported.
| Deprecated | Added or Changed in API Version 9| System API|
| --------- | -------------- | --------- |
| zipFile | compressFile | Yes |
| unzipFile | decompressFile | Yes |
| ErrorCode | N/A | Yes |
**Adaptation Guide**
The import module does not change. The new API is directly used to adapt exception handling.
## cl.DistributedManagerService.1 continuationManager API Changes
- Event names passed to the **continuationManager** API do not comply with the OpenHarmony API specifications.
- The **continuationManager.on** API does not have a unified return value for various events, which does not comply with the OpenHarmony API specifications.
The following changes have been made:
- The device selection event name of **continuationManager.on** and **continuationManager.off** is changed from **deviceConnect** to **deviceSelected**, and the device deselection event name is changed from **deviceDisconnect** to **deviceUnselected**.
- The **continuationManager.on** API returns **Callback<Array<ContinuationResult>>** for all events.
**Change Impacts**
The application developed based on earlier versions needs to adapt the new APIs. Otherwise, the original service logic will be affected.
## cl.wifi.1 Migration of System APIs and APIs in API Version 9 to the New @ohos.wifiManager.d.ts
**@ohos.wifi.d.ts** does not allow for throwing error codes, which is required by API version 9 and the system APIs. Therefore, all system APIs and APIs in API version 9 of **@ohos.wifi.d.ts** are migrated to the newly added **@ohos.wifiManager.d.ts**, and error code description is also added.
Import **@ohos.wifiManager.d.ts**, so that system APIs and APIs in API version 9 of the Wi-Fi subsystem can be used.
import wifiManager from '@ohos.wifiManager';
**Change Impacts**
System APIs and APIs in API version 9 are affected. Import **@ohos.wifiManager** to make sure that system APIs and APIs in API version 9 of the Wi-Fi subsystem can be used.
| wifi | namespace | declare namespace wifi | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function enableWifi(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value type to void. |
| wifi | method | function disableWifi(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value type to void. |
| wifi | method | function scan(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value type to void. |
| wifi | method | function getScanResults(): Promise<Array<WifiScanInfo>> | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed **getScanInfos** to **getScanResults**.|
| wifi | method | function getScanResults(callback: AsyncCallback<Array<WifiScanInfo>>): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed **getScanInfos** to **getScanResults**.|
| wifi | method | function getScanResultsSync(): Array<[WifiScanInfo]> | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function addCandidateConfig(config: WifiDeviceConfig): Promise<number> | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function addCandidateConfig(config: WifiDeviceConfig, callback: AsyncCallback<number>): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function removeCandidateConfig(networkId: number): Promise<void> | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function removeCandidateConfig(networkId: number, callback: AsyncCallback<void>): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function addUntrustedConfig(config: WifiDeviceConfig): Promise<boolean> | Deleted this API in API version 9. |
| wifi | method | function addUntrustedConfig(config: WifiDeviceConfig, callback: AsyncCallback<boolean>): void | Deleted this API in API version 9. |
| wifi | method | function removeUntrustedConfig(config: WifiDeviceConfig): Promise<boolean> | Deleted this API in API version 9. |
| wifi | method | function removeUntrustedConfig(config: WifiDeviceConfig, callback: AsyncCallback<boolean>): void | Deleted this API in API version 9. |
| wifi | method | function getCandidateConfigs(): Array<[WifiDeviceConfig]> | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function connectToCandidateConfig(networkId: number): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function connectToNetwork(networkId: number): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function connectToDevice(config: WifiDeviceConfig): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function disconnect(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function reassociate(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function reconnect(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function disableNetwork(netId: number): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function removeAllNetwork(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function removeDevice(id: number): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function enableHotspot(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function disableHotspot(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function setHotspotConfig(config: HotspotConfig): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function getP2pLocalDevice(): Promise<WifiP2pDevice> | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function getP2pLocalDevice(callback: AsyncCallback<WifiP2pDevice>): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function getP2pGroups(): Promise<Array<WifiP2pGroupInfo>> | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function getP2pGroups(callback: AsyncCallback<Array<WifiP2pGroupInfo>>): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | method | function createGroup(config: WifiP2PConfig): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function removeGroup(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function p2pConnect(config: WifiP2PConfig): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function p2pCancelConnect(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function startDiscoverDevices(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function stopDiscoverDevices(): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function deletePersistentGroup(netId: number): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | method | function setDeviceName(devName: string): void | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and changed the return value to **void**.|
| wifi | interface | export interface WifiEapConfig | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | enum | export enum EapMethod | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | enum | export enum Phase2Method | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | interface | export interface WifiDeviceConfig | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and added the **eapConfig** parameter.|
| wifi | interface | export interface IpConfig | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and added the **prefixLength** parameter.|
| wifi | interface | export interface WifiInfoElem | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | enum | export enum WifiChannelWidth | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**. |
| wifi | interface | export interface WifiScanInfo | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and added the following three parameters: **centerFrequency0**, **centerFrequency1**, and **infoElems**.|
| wifi | enum | export enum WifiSecurityType | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and added four encryption types. |
| wifi | interface | export interface WifiLinkedInfo | Migrated this API in API version 9 to **@ohos.wifiManager.d.ts**, and added the **MacType** parameter. |
**(Optional) Adaptation Guide**
The following uses **getLinkedInfo** as an example to show how it is called in the new version:
## cl.wifiext.1 Migration of System APIs and APIs in API Version 9 to the New @ohos.wifiManagerExt.d.ts
**@ohos.wifiext.d.ts** does not allow for throwing error codes, which is required by API version 9 and the system API. Therefore, all system APIs and APIs in API version 9 of **@ohos.wifiext.d.ts** are migrated to the newly added **@ohos.wifiManagerExt.d.ts**, and error code description is also added.
Import **@ohos.wifiManagerExt.d.ts**, so that system APIs and APIs in API version 9 of the Wi-Fi subsystem can be used.
import wifiManagerExt from '@ohos.wifiManagerExt';
**Change Impacts**
System APIs and APIs in API version 9 are affected. Import **@ohos.wifiManagerExt**, so that system APIs and APIs in API version 9 of the Wi-Fi subsystem can be used together with the Wi-Fi manager.
import wifiManagerExt from '@ohos.wifiManagerExt';
The rules for starting application components of the ability subsystem are changed in the following scenarios:
- Start application components when the application is in the background.
- Start invisible application components across applications.
- Start **serviceAbility** and **dataAbility** of the FA model across applications.
- Use the **startAbilityByCall** API.
You need to adapt your application based on the following information.
**Change Impacts**
If new rules are not adapted, application components cannot be started in the previous scenarios.
> **NOTE**
>
> Starting application components refers to any behavior starting or connecting to an ability.
>
> 1. Start an ability using APIs such as **startAbility**, **startServiceExtensionAbility**, and **startAbilityByCall**.
> 2. Connect to an ability using APIs such as **connectAbility**, **connectServiceExtensionAbility**, **acquireDataAbilityHelper**, and **createDataShareHelper**.
Startup rules for different scenarios are as follows:
-**Start application components when the application is in the background.**
- OpenHarmony 3.2 Beta3 rules:
- Starting application components when the application is in the background is not restricted.
- OpenHarmony 3.2 Beta4 rules:
- When the application is in the background, starting application components requires authentication. The following permission needs to be applied for:
> 1. Starting components of the same application is also restricted by this rule.
> 2. For SDKs of API version 8 or earlier, starting **serviceAbility** and **dataAbility** is not restricted by this rule.
-**Start invisible application components across applications.**
- OpenHarmony 3.2 Beta3 rules:
- For applications whose APL is normal, invisible application components cannot be started across applications.
- OpenHarmony 3.2 Beta4 rules:
- For all applications, starting invisible application components across applications requires authentication. The following permission needs to be applied for:
```json
{
"name":"ohos.permission.START_INVISIBLE_ABILITY",
"grantMode":"system_grant",
"availableLevel":"system_core",
"provisionEnable":true,
"distributedSceneEnable":false
}
```
-**Start serviceAbility and dataAbility of the FA model across applications.**
- OpenHarmony 3.2 Beta3 rules:
- Starting **serviceAbility** and **dataAbility** across applications is not restricted.
- OpenHarmony 3.2 Beta4 rules:
- Associated startup needs to be configured for the provider of **serviceAbility** and **dataAbility**. Otherwise, **serviceAbility** and **dataAbility** cannot be started across applications. (Associated startup cannot be configured for common applications.)
-**Use the startAbilityByCall API.**
- OpenHarmony 3.2 Beta3 rules:
- The API call is not restricted.
- OpenHarmony 3.2 Beta4 rules:
- The **startAbilityByCall** API cannot be called by the same application.
- Calling the **startAbilityByCall** API across applications requires authentication. The following permission needs to be applied for:
Startup rules for different scenarios are as follows:
-**Start application components when the application is in the background.**
- OpenHarmony 3.2 Beta3 rules:
- Starting application components when the application is in the background is not restricted.
- OpenHarmony 3.2 Beta4 rules:
- When the application is in the background, starting application components requires authentication. The following permission needs to be applied for:
> 1. Starting components of the same application is also restricted by this rule.
> 2. For SDKs of API version 8 or earlier, starting **serviceAbility** is not restricted by this rule.
-**Start invisible application components across applications.**
- OpenHarmony 3.2 Beta3 rules:
- Invisible application components cannot be started across applications.
- OpenHarmony 3.2 Beta4 rules:
- Starting invisible application components across applications requires authentication. The following permission needs to be applied for:
```json
{
"name":"ohos.permission.START_INVISIBLE_ABILITY",
"grantMode":"system_grant",
"availableLevel":"system_core",
"provisionEnable":true,
"distributedSceneEnable":false
}
```
-**Start serviceAbility of the FA model across applications.**
- OpenHarmony 3.2 Beta3 rules:
- Starting **serviceAbility** across applications is not restricted.
- OpenHarmony 3.2 Beta4 rules:
- Associated startup needs to be configured for the **serviceAbility** provider application. Otherwise, **serviceAbility** cannot be started across applications. (Associated startup cannot be configured for common applications.)
- Configure associated startup as follows:
```json
{
"bundleName":"",
"app_signature":["xxxxxxxxxxxxxxxxxxx"],
"associatedWakeUp":true
}
```
## cl.ability.3 API Exception Handling Method Change
Certain APIs of the ability subsystem use service logic return values to indicate error information, which does not comply with the API error code specifications of OpenHarmony.
**Change Impacts**
The application developed based on earlier versions needs to adapt the new APIs and their method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
For adaptation to the unified API exception handling mode, certain ability subsystem APIs are deprecated (original APIs in the following table) and corresponding new APIs in the following table are added. (In the following table, original APIs in API version 9 will be deleted, and APIs in API version 8 and earlier will be deprecated.) The newly added APIs support unified error code handling specifications and function the same as the original APIs.
## cl.account_os_account.1 Change in Error Information Return Method of Account System APIs
Certain system APIs of the account subsystem use service logic return values to indicate error information, which does not comply with the API error code specifications of OpenHarmony. The following changes are made in API version 9 and later:
Asynchronous API: An error message is returned via **AsyncCallback** or the **error** object of **Promise**.
Synchronous API: An error message is returned via an exception.
**Change Impacts**
The application developed based on earlier versions needs to adapt the new APIs and their method for returning API error information. Otherwise, the original service logic will be affected.
## cl.account_os_account.2 ACTION Definition Change for the Application Account Authentication Service
**Change Impacts**
For the application developed based on an earlier version, you need to modify **ACTION** in the application configuration file (**config.json** for the FA model and **module.json5** for the Stage model) to normally provide the application authentication service.
For a third-party application providing the account authentication service, adapt the changed application account authentication **ACTION** in the **ServiceAbility** configuration file (**config.json** for the FA module or **module.json5** for the Stage module).
Compared with OpenHarmony 3.2.8.1, OpenHarmony 3.2.8.3 has the following API changes in the customization subsystem:
## cl.Customization.1 Change of the Enterprise Device Management Module Name
Beginning from OpenHarmony 3.2.8.3, **@ohos.enterpriseDeviceManager.d.ts** is changed to **@ohos.enterprise.adminManager.d.ts**. You need to adapt your applications according to the following information.
**Change Impacts**
The application developed based on OpenHarmony earlier than 3.2.8.3 must be adapted so that it can be properly compiled in the SDK environment of the new version.
Beginning from OpenHarmony 3.2.8.3, **enterpriseDeviceManager/DeviceSettingsManager.d.ts** is changed to **ohos.enterprise.dateTimeManager.d.ts**.
**Change Impacts**
The application developed based on OpenHarmony earlier than 3.2.8.3 must be adapted so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
| Original API | Original API Type | New API | New API Type |
| @ohos.enterprise.adminManager | adminManager | **function** enableAdmin(admin: Want, enterpriseInfo: EnterpriseInfo, type: AdminType, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** enableAdmin(admin: Want, enterpriseInfo: EnterpriseInfo, type: AdminType, userId: number, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** enableAdmin(admin: Want, enterpriseInfo: EnterpriseInfo, type: AdminType, userId?: number): Promise<**void**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** disableAdmin(admin: Want, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** disableAdmin(admin: Want, userId: number, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** disableAdmin(admin: Want, userId?: number): Promise<**void**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** disableSuperAdmin(bundleName: String, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** disableSuperAdmin(bundleName: String): Promise<**void**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** isAdminEnabled(admin: Want, callback: AsyncCallback<**boolean**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** isAdminEnabled(admin: Want, userId: number, callback: AsyncCallback<**boolean**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** isAdminEnabled(admin: Want, userId?: number): Promise<**boolean**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** getEnterpriseInfo(admin: Want, callback: AsyncCallback<**EnterpriseInfo**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** getEnterpriseInfo(admin: Want): Promise<**EnterpriseInfo**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** setEnterpriseInfo(admin: Want, enterpriseInfo: EnterpriseInfo, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** setEnterpriseInfo(admin: Want, enterpriseInfo: EnterpriseInfo): Promise<**void**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** isSuperAdmin(bundleName: String, callback: AsyncCallback<**boolean**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** isSuperAdmin(bundleName: String): Promise<**boolean**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** subscribeManagedEvent(admin: Want, managedEvents: Array<**ManagedEvent**>, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** subscribeManagedEvent(admin: Want, managedEvents: Array<**ManagedEvent**>): Promise<**void**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** unsubscribeManagedEvent(admin: Want, managedEvents: Array<**ManagedEvent**>, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **function** unsubscribeManagedEvent(admin: Want, managedEvents: Array<**ManagedEvent**>): Promise<**void**>; | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **interface** EnterpriseInfo | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **enum** AdminType | Changed to a system API |
| @ohos.enterprise.adminManager | adminManager | **enum** ManagedEvent | Changed to a system API |
| @ohos.enterprise.dataTimeManager | dateTimeManager | **function** setDateTime(admin: Want, time: number, callback: AsyncCallback<**void**>): void; | Changed to a system API |
| @ohos.enterprise.dataTimeManager | dateTimeManager | **function** setDateTime(admin: Want, time: number): Promise<**void**>; | Changed to a system API |
## cl.Customization.4 API Permission Change
Beginning from OpenHarmony 3.2.8.3, permission verification is required for some APIs.
**Change Impacts**
The application developed based on OpenHarmony earlier than 3.2.8.3 must have the corresponding permission so that it can properly call these APIs.
**Key API/Component Changes**
| Module | Class | Method/Attribute/Enumeration/Constant | New Permission|
## cl.location.1 Migration of System APIs and APIs in API Version 9 to the New @ohos.geoLocationManager.d.ts
APIs in **@ohos.geolocation.d.ts** do not support throwing error codes. However, APIs in API version 9 and system APIs all need to support throwing error codes. To support this function, all system APIs and APIs in API version 9 in **@ohos.geolocation.d.ts** are migrated to the newly added **@ohos.geoLocationManager.d.ts** file, and corresponding error code description is added.
To use system APIs and APIs in API version 9 of the location subsystem, you need to import **@ohos.geoLocationManager**.
import geoLocationManager from '@ohos.geoLocationManager';
**Change Impacts**
System APIs and APIs in API version 9 are affected. To ensure normal use of these APIs, you need to import **@ohos.geoLocationManager**.
import geoLocationManager from '@ohos.geoLocationManager';
Other APIs are not affected.
**Key API/Component Changes**
| Class| API Type| API Declaration| Change Type|
| -- | -- | -- | -- |
|geolocation| namespace | declare namespacegeolocation| Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation | interface | export interface ReverseGeocodingMockInfo | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation | interface | export interface LocationMockConfig | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation | interface | export interface CountryCode | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation | enum | export enum CountryCodeType | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation.GeoAddress | field | isFromMock?: Boolean; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation.Location | field | isFromMock?: Boolean; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation.GeoLocationErrorCode | field | NOT_SUPPORTED = 100 | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation.GeoLocationErrorCode | field | QUERY_COUNTRY_CODE_ERROR | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation| method | function on(type: 'countryCodeChange', callback: Callback<CountryCode>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation| method | function off(type: 'countryCodeChange', callback?: Callback<CountryCode>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation| method | function getCountryCode(callback: AsyncCallback<CountryCode>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation| method | function getCountryCode(): Promise<CountryCode>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation| method | function enableLocationMock(scenario: LocationRequestScenario, callback: AsyncCallback<void>): void; | Deleted this API in API version 9.|
|geolocation| method | function enableLocationMock(callback: AsyncCallback<void>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation| method | function enableLocationMock(scenario: LocationRequestScenario): Promise<void>; | Deleted this API in API version 9.|
|geolocation| method | function enableLocationMock(): Promise<void>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**.|
|geolocation| method | function disableLocationMock(scenario: LocationRequestScenario, callback: AsyncCallback<void>): void; | Deleted this API in API version 9.|
|geolocation| method | function disableLocationMock(callback: AsyncCallback<void>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function disableLocationMock(scenario: LocationRequestScenario): Promise<void>; | Deleted this API in API version 9.|
|geolocation| method | function disableLocationMock(): Promise<void>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function setMockedLocations(config: LocationMockConfig, callback: AsyncCallback<void>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function setMockedLocations(config: LocationMockConfig): Promise<void>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function enableReverseGeocodingMock(callback: AsyncCallback<void>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function enableReverseGeocodingMock(): Promise<void>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function disableReverseGeocodingMock(callback: AsyncCallback<void>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function disableReverseGeocodingMock(): Promise<void>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function setReverseGeocodingMockInfo(mockInfos: Array<ReverseGeocodingMockInfo>, callback: AsyncCallback<void>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function setReverseGeocodingMockInfo(mockInfos: Array<ReverseGeocodingMockInfo>): Promise<void>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function isLocationPrivacyConfirmed(type: LocationPrivacyType, callback: AsyncCallback<boolean>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function isLocationPrivacyConfirmed(type: LocationPrivacyType): Promise<boolean>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts**. |
|geolocation| method | function setLocationPrivacyConfirmStatus(type: LocationPrivacyType, isConfirmed: boolean, callback: AsyncCallback<boolean>): void; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts** and changed the callback return value to **void**. |
|geolocation| method | function setLocationPrivacyConfirmStatus(type: LocationPrivacyType, isConfirmed: boolean): Promise<boolean>; | Migrated this API in API version 9 to **@ohos.geoLocationManager.d.ts** and changed the promise return value to **void**. |
**(Optional) Adaptation Guide**
The following uses **enableLocation** as an example to show how it is called in the new version:
## cl.location.2 Location Service Permission Change
From API version 9, the **ohos.permission.APPROXIMATELY_LOCATION** permission is added for obtaining the approximate location.
If you use API version 9 or later, you need to apply for both the **ohos.permission.LOCATION** and **ohos.permission.APPROXIMATELY_LOCATION** permissions. Applying for only the **ohos.permission.LOCATION** permission will fail.
**Change Impacts**
Applications using API versions earlier than 9 are not affected. For an application using API version 9 or later, the method for applying for the location permission is changed. The details are as follows:
Before using basic location capabilities, check whether your application has been granted the permission to access the device location information. If not, your application needs to obtain the permission from the user as described below.
The system provides the following location permissions:
- ohos.permission.LOCATION
- ohos.permission.APPROXIMATELY_LOCATION
- ohos.permission.LOCATION_IN_BACKGROUND
If your application needs to access the device location information, it must first apply for required permissions. Specifically speaking:
API versions earlier than 9: Apply for **ohos.permission.LOCATION**.
API version 9 and later: Apply for **ohos.permission.APPROXIMATELY_LOCATION**, or apply for **ohos.permission.APPROXIMATELY_LOCATION** and **ohos.permission.LOCATION**. Note that **ohos.permission.LOCATION** cannot be applied for separately.
| API Version| Location Permission| Permission Application Result| Location Accuracy|
| -------- | -------- | -------- | -------- |
| Earlier than 9| ohos.permission.LOCATION | Success| Location accurate to meters|
| 9 and later| ohos.permission.LOCATION | Failure| No location obtained|
| 9 and later| ohos.permission.APPROXIMATELY_LOCATION | Success| Location accurate to 5 kilometers|
| 9 and later| ohos.permission.APPROXIMATELY_LOCATION and ohos.permission.LOCATION| Success| Location accurate to meters|
If your application needs to access the device location information when running in the background, it must be configured to be able to run in the background and be granted the **ohos.permission.LOCATION_IN_BACKGROUND** permission. In this way, the system continues to report device location information after your application moves to the background.
You can declare the required permission in your application's configuration file. For details, see the [permission application guide](../../../application-dev/security/accesstoken-guidelines.md).
**Key API/Component Changes**
Applications using API versions earlier than 9 are not affected.
If your application uses API version 9 or later and needs to call APIs requiring the **ohos.permission.LOCATION** permission in **@ohos.geolocation** and **@ohos.geoLocationManager**, you need to apply for the corresponding permission as described previously.
## cl.multimedia.media.001 Change of VideoRecorder APIs to System APIs
In the MR version, the formal **AVRecorder** APIs (integrating audio and video) will be provided for external use.
**VideoRecorder** APIs in API version 9 are changed to system APIs, which are available only to system users. In the future, **VideoRecorder** APIs will be deprecated after system users switch to **AVRecorder**.
**Change Impacts**
If the **VideoRecorder** caller is not a system user, the call will fail.
Involved APIs and enumerations:
function createVideoRecorder(callback: AsyncCallback<VideoRecorder>): void;
function createVideoRecorder(): Promise<VideoRecorder>;
## cl.multimedia.media.002 No Externally Provided Bit Rate Selection API in VideoPlayer
In API version 9, **VideoPlayer** does not externally provide the bit rate selection API. Such an API will be provided by **AVPlayer** in the MR version.
**Change Impacts**
Bit rate selection cannot be performed in the multi-bit rate scenario of **VideoPlayer**. Relevant functions will be provided by **AVPlayer**.
# Common Event and Notification Subsystem ChangeLog
## cl.notification.1 API Exception Handling Method Changes
Certain event notification APIs use service logic return values to indicate error information, which does not comply with the API error code specifications of OpenHarmony.
**Change Impacts**
The application developed based on earlier versions needs to adapt the new APIs and their method for returning API error information. Otherwise, the original service logic will be affected.
**Key API/Component Changes**
For adaptation to the unified API exception handling mode, certain event notification APIs are deprecated (original APIs in the following table) and corresponding new APIs in the following table are added. The newly added APIs support unified error code handling specifications and function the same as the original APIs.
## cl.useriam.1 API Exception Handling Method Change
Certain APIs of user IAM use service logic return values to indicate error information, which does not comply with the API error code specifications of OpenHarmony. The following changes are made in API version 9 and later:
An error message is returned via an exception.
**Change Impacts**
Applications developed based on earlier versions are not affected. If your application uses API version 9 or later, you need to adapt the change in the way for APIs to return the error information. Otherwise, service logic will be affected.
**Key API/Component Changes**
For adaptation to the unified API exception handling mode, certain APIs of user IAM are deprecated (original APIs in the following table) and corresponding new APIs in the following table are added. The newly added APIs support unified error code handling specifications and function the same as the original APIs.
| Module | Class | Method/Attribute/Enumeration/Constant | Change Type |
console.info("get version failed, error = "+error);
}
```
For sample code of more APIs, see the [user authentication API reference](../../../application-dev/reference/apis/js-apis-useriam-userauth.md) and [face authentication API reference](../../../application-dev/reference/apis/js-apis-useriam-faceauth.md).
## cl.useriam.2 API Call Permission Change
Some APIs of user IAM can only be called by system applications, and system application runtime authentication is required. The following changes are made in API version 9 and later:
The service logic for checking whether an application is a system application is added for the **setSurfaceId** API of the face authentication module. Non-system applications cannot call this API.
**Change Impacts**
Applications developed based on earlier versions are not affected. If your application uses API version 9 or later and wants to call this API, your application must be a system application.
**Key API/Component Changes**
The service logic for checking whether an application is a system application is added for the **setSurfaceId** API. Error code **202** will be returned if the API is called by a non-system application.
**Adaptation Guide**
Modify the **UnsgnedReleasedProfileTemplate.json** file related to [app signing](https://gitee.com/openharmony/developtools_hapsigner/tree/master/dist) to change the **app-feature** field to **hos_system_app**, so that the signed application is a system application.
## cl.DistributedManagerService.1 Adding DATASYNC Permission Verification on the continuationManager API
In earlier versions, the **continuationManager** API does not verify the caller, which does not comply with the OpenHarmony API specifications.
Now, before using **continuationManager**, the caller must apply for the **ohos.permission.DISTRIBUTED_DATASYNC** permission.
**Change Impacts**
The application developed based on earlier versions needs to apply for the **ohos.permission.DISTRIBUTED_DATASYNC** permission in advance. Otherwise, the original service logic will be affected.
Some released web controllers are migrated to the webviewController, and the original webController is deprecated. The following changes are made in API version 9 and later:
The input parameter of **setWebController** is replaced by the new **webviewController**.
**Change Impacts**
Input parameters of JS APIs need to be adapted for applications developed based on earlier versions. Otherwise, relevant functions will be affected.
The **getUnfilterendLinkUrl** API is misspelled and should be changed to **getUnfilteredLinkUrl**.
**Change Impacts**
The JS API name needs to be adapted for applications developed based on earlier versions. Otherwise, relevant functions will be affected.
**Key API/Component Changes**
- Involved API:
getUnfilteredLinkUrl(): string;
- Before change:
```js
getUnfilterendLinkUrl():string;
```
- After change:
```js
getUnfilteredLinkUrl():string;
```
**Adaptation Guide**
The JS API name needs to be adapted for applications developed based on earlier versions. The new API name is used to replace the original one. Otherwise, relevant functions will be affected.
Changes that affect contract compatibility of the last version should be described in the ChangeLog. The changes include but are not limited to those related to API names, parameters, return values, required permissions, call sequence, enumerated values, configuration parameters, and paths. The last version can be an LTS, release, beta, or monthly version, or the like. Contract compatibility, also called semantic compatibility, means that the original program behavior should remain consistent over versions.
## cl.subsystemname.x xxx Function Change (Example: DeviceType Attribute Change or Camera Permission Change. Use a short description.)
Add the number **cl.*subsystemname*.*x*** before each change title, where **cl** is the abbreviation of ChangeLog, *subsystemname* is the standard English name of the subsystem, and *x* indicates the change sequence number (starting from 1 in ascending order).
Describe the changes in terms of functions. Example: *n* and *m* of the *a* function are changed. Developers need to adapt their applications based on the change description.
If there is a requirement or design document corresponding to the change, attach the requirement number or design document number in the description.
**Change Impacts**
Describe whether released APIs (JS or native APIs) are affected or API behavior is changed.
Describe whether available applications are affected, that is, whether an adaptation is required for building the application code in the SDK environment of the new version.
**Key API/Component Changes**
List the API/component changes involved in the function change.
**Adaptation Guide (Optional)**
Provide guidance for developers on how to adapt their application to the changes to be compatible with the new version.
The following APIs of the **xcomponent** component of the ArkUI subsystem are changed:
-**getXComponentSurfaceId** and **setXComponentSurfaceSize**: The **@systemapi** tag is removed.
-**getXComponentSurfaceId**, **getXComponentContext**, and **setXComponentSurfaceSize**: The return value types are specified.
You need to adapt your applications based on the following information.
**Change Impacts**
Released JS APIs are affected. The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
-**getXComponentSurfaceId**: is changed to a public API, with its return value type specified as string.
-**setXComponentSurfaceSize**: is changed to a public API, with its return value type specified as void.
-**getXComponentContext**: has its return value type specified as object.
**Adaptation Guide**
Startup rules for different scenarios are as follows:
Adaptions to be made:
-**getXComponentSurfaceId**
- OpenHarmony 3.2 Beta3 rules:
- System API
- No specified return value
- OpenHarmony 3.2 Beta4 rules:
- Public API
- Return value type specified as string
- You need to process the return value as a string.
-**setXComponentSurfaceSize**
- OpenHarmony 3.2 Beta3 rules:
- System API
- No specified return value
- OpenHarmony 3.2 Beta4 rules:
- Public API
- Return value type specified as void
- You need to process the return value as a void.
-**getXComponentContext**
- OpenHarmony 3.2 Beta3 rules:
- No specified return value
- OpenHarmony 3.2 Beta4 rules:
- Return value type specified as object
- You need to process the return value as an object.
## cl.arkui.2 Change of Styles of Popup Component and APIs
The styles of the **alertDialog**, **actionSheet**, and **customDialog** components, as well as the **prompt** and **promptAction** APIs were changed. Specifically speaking:
The popup background blurring effect is added to **promptAction.showDialog**, **promptAction.showActionMenu**, **alertDialog**, **actionSheet**, and **customDialog**.
**Change Impacts**
The popup background blurring effect is set by default.
**Key API/Component Changes**
APIs: **promptAction.showDialog** and **promptAction.showActionMenu;**
Components: **alertDialog**, **actionSheet**, and **customDialog**
**Adaptation Guide**
No adaptation is required.
## cl.arkui.3 Supplementation of the Initialization Mode and Restriction Verification Scenarios of Custom Components' Member Variables
For details, see [Restrictions and Extensions](../../../application-dev/quick-start/arkts-restrictions-and-extensions.md).
**Change Impacts**
If custom components' member variables are initialized or assigned with values not according to the document specifications, an error will be reported during compilation.
**Key API/Component Changes**
N/A
**Adaptation Guide**
Make modification according to specifications in the above document.
## cl.arkui.4 Supplementation of Verification Scenarios of Value Assignment Restrictions on Member Variables of Custom Parent Components and Child Components
For details, see [Restrictions and Extensions](../../../application-dev/quick-start/arkts-restrictions-and-extensions.md).
**Change Impacts**
If member variables of the parent component or child component are initialized not according to the document specifications, an error will be reported during compilation.
**Key API/Component Changes**
N/A
**Adaptation Guide**
Make modification according to specifications in the above document, using other decorators or normal member variables for value assignment.
## cl.arkui.5 Supplementation of Verification for a Single Subcomponent
Verification for a single subcomponent is enabled for the following components: **Button**, **FlowItem**, **GridItem**, **GridCol**, **ListItem**, **Navigator**, **Refresh**, **RichText**, **ScrollBar**, **StepperItem**, and **TabContent**.
**Change Impacts**
If one of the preceding components contains more than one subcomponent, an error will be reported during compilation.
## cl.telephony.1 Input Parameter Change of System APIs of the SMS Module
Input parameters are changed for some released system APIs of the SMS module of the telephony subsystem, which do not comply with the API specifications of OpenHarmony. The following changes are made in API version 9 and later:
The **slotId** parameter is added to the **isImsSmsSupported** API, indicating the slot ID.
**Change Impacts**
Input parameters of JavaScript APIs need to be adapted for applications developed based on earlier versions. Otherwise, relevant functions will be affected.
Released JS APIs are affected. The application needs to adapt these APIs so that it can be properly compiled in the SDK environment of the new version.
**Key API/Component Changes**
| OpenHarmony 3.2.8.1 API | OpenHarmony 3.2.9.1 SP8 API |
Changes that affect contract compatibility of the last version should be described in the ChangeLog. The changes include but are not limited to those related to API names, parameters, return values, required permissions, call sequence, enumerated values, configuration parameters, and paths. The last version can be an LTS, release, beta, or monthly version, or the like. Contract compatibility, also called semantic compatibility, means that the original program behavior should remain consistent over versions.
## cl.subsystemname.x xxx Function Change (Example: DeviceType Attribute Change or Camera Permission Change. Use a short description.)
Add the number **cl.*subsystemname*.*x*** before each change title, where **cl** is the abbreviation of ChangeLog, *subsystemname* is the standard English name of the subsystem, and *x* indicates the change sequence number (starting from 1 in ascending order).
Describe the changes in terms of functions. Example: *n* and *m* of the *a* function are changed. Developers need to adapt their applications based on the change description.
If there is a requirement or design document corresponding to the change, attach the requirement number or design document number in the description.
**Change Impacts**
Describe whether released APIs (JS or native APIs) are affected or API behavior is changed.
Describe whether available applications are affected, that is, whether an adaptation is required for building the application code in the SDK environment of the new version.
**Key API/Component Changes**
List the API/component changes involved in the function change.
**Adaptation Guide (Optional)**
Provide guidance for developers on how to adapt their application to the changes to be compatible with the new version.
Changes that affect contract compatibility of the last version should be described in the ChangeLog. The changes include but are not limited to those related to API names, parameters, return values, required permissions, call sequence, enumerated values, configuration parameters, and paths. The last version can be an LTS, release, beta, or monthly version, or the like. Contract compatibility, also called semantic compatibility, means that the original program behavior should remain consistent over versions.
## cl.subsystemname.x xxx Function Change (Example: DeviceType Attribute Change or Camera Permission Change. Use a short description.)
Add the number **cl.*subsystemname*.*x*** before each change title, where **cl** is the abbreviation of ChangeLog, *subsystemname* is the standard English name of the subsystem, and *x* indicates the change sequence number (starting from 1 in ascending order).
Describe the changes in terms of functions. Example: *n* and *m* of the *a* function are changed. Developers need to adapt their applications based on the change description.
If there is a requirement or design document corresponding to the change, attach the requirement number or design document number in the description.
**Change Impacts**
Describe whether released APIs (JS or native APIs) are affected or API behavior is changed.
Describe whether available applications are affected, that is, whether an adaptation is required for building the application code in the SDK environment of the new version.
**Key API/Component Changes**
List the API/component changes involved in the function change.
**Adaptation Guide (Optional)**
Provide guidance for developers on how to adapt their application to the changes to be compatible with the new version.
## cl.account_os_account.1 Expansion of Distributed Account Nickname and Profile Picture Specifications
The existing distributed account nickname and profile picture specifications cannot meet requirements in scenarios where the nickname is long and profile picture is large.
Therefore, the distributed account nickname and profile picture specifications are expanded.
**Change Impacts**
The API change is forward compatible. Applications developed based on earlier versions can use the APIs in accordance with the new specifications, without affecting the original logic.
**Key API/Component Changes**
Before change:
- The nickname cannot exceed 20 characters, and the profile picture size cannot exceed 3 MB.
After change:
- The nickname cannot exceed 1024 characters, and the profile picture size cannot exceed 10 MB.
## cl.window.1 Change of Window Stage Lifecycle Listener Types
Changed the enumerated listener types of the window stage lifecycle in version 4.0.1.1 and later.
**Change Impacts**
Application lifecycle listeners developed using **FOREGROUND** and **BACKGROUND** in versions earlier than 4.0.1.1 will be invalidated in version 4.0.1.1 and later.
**Key API/Component Changes**
## WindowStageEventType<sup>9+</sup>
Before change:
| Name | Value | Description |
| ---------- | ---- | ---------- |
| FOREGROUND | 1 | The window stage is running in the foreground.|
| BACKGROUND | 4 | The window stage is running in the background.|
After change:
| Name | Value | Description |
| ------ | ---- | ---------- |
| SHOWN | 1 | The window stage is running in the foreground.|
| HIDDEN | 4 | The window stage is running in the background.|
**Adaptation Guide**
When registering lifecycle listeners, change the foreground and background event types to **SHOWN** and **HIDDEN**, respectively.