# 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**.
2. The data type declaration of the **@State**, **@Provide**, **@Link**, or **@Consume** decorated state variables can consist of only one of the primitive data types or reference data types.
The **Length**, **ResourceStr**, and **ResourceColor** types are combinations of primitive data types or reference data types. Therefore, they cannot be used by the aforementioned types of state variables.
For details about the definitions of **Length**, **ResourceStr**, and **ResourceColor**, see [Types](../../../application-dev/reference/arkui-ts/ts-types.md).
1. If the data type of a state variable decorated by a state decorator is declared as **any**, a build error will occur.
```ts
// ArkTS:ERROR Please define an explicit type, not any.
@StateisLunar:any=false
```
2. If the data type of a state variable decorated by a state decorator is declared as **Date**, a build error will occur.
```ts
// ArkTS:ERROR The @State property 'selectedDate' cannot be a 'Date' object.
@StateselectedDate:Date=newDate('2021-08-08')
```
3. If the data type of a **@State**, **@Provide**, **@Link**, and or **@Consume** decorated state variable is Length, **ResourceStr**, or **ResourceColor**, a build error will occur.
```ts
/* ArkTS:ERROR The state variable type here is 'ResourceStr', it contains both a simple type and an object type,
which are not allowed to be defined for state variable of a struct.*/
@Statemessage:ResourceStr=$r('app.string.hello')
```
**Key API/Component Changes**
N/A
**Adaptation Guide**
1. Explicitly declare the data type for state variables decorated by state decorators.
2. If a state variable decorated by a state decorator uses the **Date** object, change it to a regular variable – a variable not decorated by any decorator.
3. Adapt the **@State**, **@Provide**, **@Link**, and **@Consume** decorated variables based on the following code snippet so that they do not use the **Length(string|number|Resource)**, **ResourceStr(string|Resource)**, and **ResourceColor(string|number|Color|Resource)** types:
```ts
// Incorrect:
@Statemessage:ResourceStr=$r('app.string.hello')
// Corrected:
@StateresourceStr:Resource=$r('app.string.hello')
```
## cl.arkui.2 Initialization Rules and Restrictions of Custom Components' Member Variables
Comply with the following rules when using constructors to initialize member variables:
| **From the Variable in the Parent Component (Right) to the Variable in the Child Component (Below)**| **regular** | **@State** | **@Link** | **@Prop** | **@Provide** | **@Consume** | **@ObjectLink** |
| **@Consume** | Not supported | Not supported | Not supported | Not supported | Not supported | Not supported | Not supported |
| **@ObjectLink** | Not supported | Not supported | Not supported | Not supported | Not supported | Not supported | Not supported |
| **From the Variable in the Parent Component (Right) to the Variable in the Child Component (Below)**| **@StorageLink** | **@StorageProp** | **@LocalStorageLink** | **@LocalStorageProp** |
2. The **@ObjectLink** decorated variable cannot be directly initialized from a decorated variable in the parent component. The source of the parent component must be an array item or object attribute decorated by **@State**, **@Link**, **@Provide**, **@Consume**, or **@ObjectLink**.
```ts
letNextID:number=0;
@ObservedclassClassA{
publicid:number;
publicc:number;
constructor(c:number){
this.id=NextID++;
this.c=c;
}
}
@Component
structChild{
@ObjectLinkvarA:ClassA;
build(){
Row(){
Text('ViewA-'+this.varA.id)
}
}
}
@Component
structParent{
@LinklinkValue:ClassA
build(){
Column(){
/* ArkTS:ERROR The @Link property 'linkValue' cannot be assigned to
the @ObjectLink property 'varA'.*/
Child({varA:this.linkValue})
}
}
}
```
**Key API/Component Changes**
N/A
**Adaptation Guide**
1. When building a child component, do not perform the build on the variables decorated by **@LocalStorageLink** and **@LocalStorageProp** in the child component.
To change these variables from the parent component, use the API provided by the **LocalStorage** (such as the **set** API) to assign values to them.
2. For details about how to use **@ObjectLink**, see [@Observed and @ObjectLink](../../../application-dev/quick-start/arkts-state-mgmt-page-level.md).
## cl.bundlemanager.1 Field Change of the ApplicationInfo Struct in API Version 9
The **entryDir** field is deleted from the **ApplicationInfo** struct [[bundleManager/applicationInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/monthly_20221018/api/bundleManager/applicationInfo.d.ts)] in API version 9.
**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 must adapt to the new modules and APIs.
**Key API/Component Changes**
The following table describes the changed fields in the **ApplicationInfo** struct.
| Deleted Field| Added or Changed Field in API Version 9| Type|
| --- | --- | --- |
| entryDir | None | string |
**Adaptation Guide**
When importing the bundle management query module, delete the **entryDir** field from the **ApplicationInfo** struct of API version 9.
## cl.bundlemanager.2 Field Change of the HapModuleInfo Struct in API Version 9
The **moduleSourceDir** field is deleted from the **HapModuleInfo** struct [[bundleManager/hapModuleInfo.d.ts](https://gitee.com/openharmony/interface_sdk-js/blob/monthly_20221018/api/bundleManager/hapModuleInfo.d.ts)] in API version 9.
**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 must adapt to the new modules and APIs.
**Key API/Component Changes**
The following table describes the changed fields in the **HapModuleInfo** struct.
| Deleted Field| Added or Changed Field in API Version 9| Type|
| --- | --- | --- |
| moduleSourceDir | None | string |
**Adaptation Guide**
When importing the bundle manager query module, delete the **moduleSourceDir** field from the **HapModuleInfo** struct of API version 9.
## cl.window.1 Change of Window Stage Lifecycle Listener Types
Changed the enumerated listener types of the window stage lifecycle in version 3.2.10.5 and later.
**Change Impacts**
Application lifecycle listeners developed using **FOREGROUND** and **BACKGROUND** in versions earlier than 3.2.10.5 will be invalidated in version 3.2.10.5 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.
## 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.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).
# 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.
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.
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.
The definition of **Rect**, an enumeration type that indicates the component bound information, is changed since version 4.0.2.1.
## Change Impacts
This change affects the **Rect** API provided by **@ohos.uitest**. If you have used the **Rect** API of **@ohos.uitest-api9** during test case development, adaptation is required so that the compilation can be successful in the SDK environment of the new version.
## Key API/Component Changes
### Rect<sup>9+</sup>
Before change
| Name | Value | Description |
| ------- | ---- | ------------------------- |
| leftX | 1 | X-coordinate of the upper left corner of the component bounds.|
| topY | 2 | Y-coordinate of the upper left corner of the component bounds.|
| rightX | 3 | X-coordinate of the lower right corner of the component bounds.|
| bottomY | 4 | Y-coordinate of the lower right corner of the component bounds.|
After change
| Name | Value | Description |
| ------ | ---- | ------------------------- |
| left | 1 | X-coordinate of the upper left corner of the component bounds.|
| top | 2 | Y-coordinate of the upper left corner of the component bounds.|
| right | 3 | X-coordinate of the lower right corner of the component bounds.|
| bottom | 4 | Y-coordinate of the lower right corner of the component bounds.|
## Adaptation Guide
### Adaptation to the API Name Change
You can replace the class name according to the following rules:
