# 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**.
Compared with OpenHarmony 3.2 Beta4, OpenHarmony3.2.10.3 has the following changes in APIs of the camera component in the multimedia subsystem.
## cl.subsystemname.1 Camera API Changed
1. All the APIs of the camera component are changed to system APIs in the API version 9.
2. Some functional APIs are added and some others are deprecated to:
- Improve the usability of camera APIs.
- Help you quickly understand camera APIs and use them for development.
- 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 features in the SDK environment of the new version.
**Key API/Component Changes**
| Module | Class | Method/Attribute/Enum/Constant | Is System API| Change Type|
In addition to the new APIs and deprecated APIs, you need to adapt your application to the changed APIs.
In Beta4 and later versions, the following APIs are changed.
**New APIs**
1.**CameraErrorCode** enums
Enum: INVALID_ARGUMENT; value: 7400101
Enum: OPERATION_NOT_ALLOWED; value: 7400102
Enum: SESSION_NOT_CONFIG; value: 7400103
Enum: SESSION_NOT_RUNNING; value: 7400104
Enum: SESSION_CONFIG_LOCKED; value: 7400105
Enum: DEVICE_SETTING_LOCKED; value: 7400106
Enum: CONFILICT_CAMERA; value: 7400107
Enum: DEVICE_DISABLED; value: 7400108
Enum: SERVICE_FATAL_ERROR; value: 7400201
2. Added **capture(): Promise<void>** to the **PhotoOutput** API.
3. Added the readonly type **MetadataObjectType** to the **MetadataObject** API.
4. Added **readonly timestamp: number** to the **MetadataObject** API.
5. Added **readonly boundingBox: Rect** to the **MetadataObject** API.
**Deprecated APIs**
1. Deprecated the **release(callback: AsyncCallback<void>): void** and **release(): Promise<void>** APIs in **CameraInput**.
2. Deprecated the **CameraInputErrorCode** enums and all their values: **ERROR_UNKNOWN** = **-1**, **ERROR_NO_PERMISSION** = **0**, **ERROR_DEVICE_PREEMPTED** = **1**, **ERROR_DEVICE_DISCONNECTED** = **2**, **ERROR_DEVICE_IN_USE** = **3**, **ERROR_DRIVER_ERROR** = **4**
3. Deprecated the **CameraInputError** API and its attribute **CameraInputErrorCode**.
4. Deprecated the **CaptureSessionErrorCode** enums and all their values: **ERROR_UNKNOWN** = **-1**, **ERROR_INSUFFICIENT_RESOURCES** = **0**, **ERROR_TIMEOUT** = **1**
5. Deprecated the **CaptureSessionError** API and its attribute **CaptureSessionErrorCode**.
6. Deprecated the **PreviewOutputErrorCode** enum and its value: **ERROR_UNKNOWN** = **-1**
7. Deprecated the **PreviewOutputError** API and its attribute **PreviewOutputErrorCode**.
8. Deprecated the **PhotoOutputErrorCode** enums and all their values: **ERROR_UNKNOWN** = **-1**, **ERROR_DRIVER_ERROR** = **0**, **ERROR_INSUFFICIENT_RESOURCES** = **1**, **ERROR_TIMEOUT** = **2**
9. Deprecated the **PhotoOutputError** API and its attribute **PhotoOutputErrorCode**.
10. Deprecated the **VideoOutputErrorCode** enums and all their values: **ERROR_UNKNOWN** = **-1**, **ERROR_DRIVER_ERROR** = **0**
11. Deprecated the **VideoOutputError** API and its attribute **VideoOutputErrorCode**.
12. Deprecated **getType(callback: AsyncCallback<MetadataObjectType>): void** in the **MetadataObject** API.
13. Deprecated **getType(): Promise<MetadataObjectType>** in the **MetadataObject** API.
14. Deprecated **getTimestamp(callback: AsyncCallback<number>): void** in the **MetadataObject** API.
15. Deprecated **getTimestamp(): Promise<number>** in the **MetadataObject** API.
16. Deprecated **getBoundingBox(callback: AsyncCallback<Rect>): void** in the **MetadataObject** API.
17. Deprecated **getBoundingBox(): Promise<Rect>** in the **MetadataObject** API.
18. Deprecated the **MetadataOutputErrorCode** enums and all their values: **ERROR_UNKNOWN** = **-1**, **ERROR_INSUFFICIENT_RESOURCES** = **0**
19. Deprecated the **MetadataOutputError** API and its attribute **MetadataOutputErrorCode**.
**Changed APIs**
1. Changed the return modes of the **getCameraManager** API in the camera module from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getCameraManager(context: Context, callback: AsyncCallback<CameraManager>): void** and **getCameraManager(context: Context): Promise<CameraManager>** are changed to **getCameraManager(context: Context): CameraManager**.
The sample code is as follows:
```
let cameraManager = camera.getCameraManager(context);
```
2. Changed the return modes of the **getSupportedCameras** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getSupportedCameras(callback: AsyncCallback<Array<CameraDevice>>): void** and **getSupportedCameras(): Promise<Array<CameraDevice>>** are changed to **getSupportedCameras(): Array<CameraDevice>**.
The sample code is as follows:
```
let cameras = cameraManager.getSupportedCameras();
```
3. Changed the return modes of the **getSupportedOutputCapability** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getSupportedOutputCapability(camera: CameraDevice, callback: AsyncCallback<CameraOutputCapability>): void** and **getSupportedOutputCapability(camera: CameraDevice): Promise<CameraOutputCapability>** are changed to **getSupportedOutputCapability(camera: CameraDevice): CameraOutputCapability**.
The sample code is as follows:
```
let cameraDevice = cameras[0];
let CameraOutputCapability = cameraManager.getSupportedOutputCapability(cameraDevice);
```
4. Changed the return modes of the **createCameraInput(camera: CameraDevice)** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **createCameraInput(camera: CameraDevice, callback: AsyncCallback<CameraInput>): void** and **createCameraInput(camera: CameraDevice): Promise<CameraInput>** are changed to **createCameraInput(camera: CameraDevice): CameraInput**.
The sample code is as follows:
```
let cameraDevice = cameras[0];
let cameraInput = cameraManager.createCameraInput(cameraDevice);
```
5. Changed the return modes of the **createCameraInput(position: CameraPosition, type: CameraType)** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **createCameraInput(position: CameraPosition, type: CameraType, callback: AsyncCallback<CameraInput>): void** and **createCameraInput(position: CameraPosition, type: CameraType): Promise<CameraInput>** are changed to **createCameraInput(position: CameraPosition, type: CameraType): CameraInput**.
The sample code is as follows:
```
let cameraDevice = cameras[0];
let position = cameraDevice.cameraPosition;
let type = cameraDevice.cameraType;
let cameraInput = cameraManager.createCameraInput(position, type);
```
6. Changed the return modes of the **createPreviewOutput** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **createPreviewOutput(profile: Profile, surfaceId: string, callback: AsyncCallback<PreviewOutput>): void** and **createPreviewOutput(profile: Profile, surfaceId: string): Promise<PreviewOutput>** are changed to **createPreviewOutput(profile: Profile, surfaceId: string): PreviewOutput**.
The sample code is as follows:
```
let profile = cameraoutputcapability.previewProfiles[0];
let previewOutput = cameraManager.createPreviewOutput(profile, surfaceId);
```
7. Changed the return modes of the **createPhotoOutput** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **createPhotoOutput(profile: Profile, surfaceId: string, callback: AsyncCallback<PhotoOutput>): void** and **createPhotoOutput(profile: Profile, surfaceId: string): Promise<PhotoOutput>** are changed to **createPhotoOutput(profile: Profile, surfaceId: string): PhotoOutput**.
The sample code is as follows:
```
let profile = cameraoutputcapability.photoProfiles[0];
let photoOutput = cameraManager.createPhotoOutput(profile, surfaceId);
```
8. Changed the return modes of the **createVideoOutput** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **createVideoOutput(profile: VideoProfile, surfaceId: string, callback: AsyncCallback<VideoOutput>): void** and **createVideoOutput(profile: VideoProfile, surfaceId: string): Promise<VideoOutput>** are changed to **createVideoOutput(profile: VideoProfile, surfaceId: string): VideoOutput**.
The sample code is as follows:
```
let profile = cameraoutputcapability.videoProfiles[0];
let videoOutput = cameraManager.createVideoOutput(profile, surfaceId);
```
9. Changed the return modes of the **createMetadataOutput** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **createMetadataOutput(metadataObjectTypes: Array<MetadataObjectType>, callback: AsyncCallback<MetadataOutput>): void** and **createMetadataOutput(metadataObjectTypes: Array<MetadataObjectType>): Promise<MetadataOutput>** are changed to **createMetadataOutput(metadataObjectTypes: Array<MetadataObjectType>): MetadataOutput**.
The sample code is as follows:
```
let metadataObjectTypes = cameraoutputcapability.supportedMetadataObjectTypes;
let metadataOutput = cameraManager.createMetadataOutput(metadataObjectTypes);
```
10. Changed the return modes of the **createCaptureSession** API in CameraManager from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **createCaptureSession(callback: AsyncCallback<CaptureSession>): void** and **createCaptureSession(): Promise<CaptureSession>** are changed to **createCaptureSession(): CaptureSession**.
The sample code is as follows:
```
let captureSession = cameraManager.createCaptureSession();
```
11. Changed the enum **CAMERA_TYPE_UNSPECIFIED** of **CameraType** to **CAMERA_TYPE_DEFAULT**.
12. Changed the return value type of the **on** API in CameraInput from **CameraInputError** to **BusinessError**. Therefore, the original API **on(type: 'error', camera: CameraDevice, callback: ErrorCallback<CameraInputError>): void** is changed to **on(type: 'error', camera: CameraDevice, callback: ErrorCallback<BusinessError>): void**.
13. Changed the return modes of the **beginConfig** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **beginConfig(callback: AsyncCallback<void>): void** and **beginConfig(): Promise<void>** are changed to **beginConfig(): void**.
The sample code is as follows:
```
captureSession.beginConfig();
```
14. Changed the return modes of the **addInput** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **addInput(cameraInput: CameraInput, callback: AsyncCallback<void>): void** and **addInput(cameraInput: CameraInput): Promise<void>** are changed to **addInput(cameraInput: CameraInput): void**.
The sample code is as follows:
```
captureSession.addInput(cameraInput);
```
15. Changed the return modes of the **removeInput** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **removeInput(cameraInput: CameraInput, callback: AsyncCallback<void>): void** and **removeInput(cameraInput: CameraInput): Promise<void>** are changed to **removeInput(cameraInput: CameraInput): void**.
The sample code is as follows:
```
captureSession.removeInput(cameraInput);
```
16. Changed the return modes of the **addOutput** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **addOutput(cameraOutput: CameraOutput, callback: AsyncCallback<void>): void** and **addOutput(cameraOutput: CameraOutput): Promise<void>** are changed to **addOutput(cameraOutput: CameraOutput): void**.
The sample code is as follows:
```
captureSession.addOutput(previewOutput);
```
17. Changed the return modes of the **removeOutput** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **removeOutput(cameraOutput: CameraOutput, callback: AsyncCallback<void>): void** and **removeOutput(cameraOutput: CameraOutput): Promise<void>** are changed to **removeOutput(cameraOutput: CameraOutput): void**.
The sample code is as follows:
```
captureSession.removeOutput(previewOutput);
```
18. Changed the return modes of the **hasFlash** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **hasFlash(callback: AsyncCallback<boolean>): void** and **hasFlash(): Promise<boolean>** are changed to **hasFlash(): boolean**.
The sample code is as follows:
```
let status = captureSession.hasFlash();
```
19. Changed the return modes of the **isFlashModeSupported** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **isFlashModeSupported(flashMode: FlashMode, callback: AsyncCallback<boolean>): void** and **isFlashModeSupported(flashMode: FlashMode): Promise<boolean>** are changed to **isFlashModeSupported(flashMode: FlashMode): boolean**.
The sample code is as follows:
```
let status = captureSession.isFlashModeSupported(camera.FlashMode.FLASH_MODE_AUTO);
```
20. Changed the return modes of the **getFlashMode** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getFlashMode(callback: AsyncCallback<FlashMode>): void** and **getFlashMode(): Promise<FlashMode>** are changed to **getFlashMode(): FlashMode**.
The sample code is as follows:
```
let flashMode = captureSession.getFlashMode();
```
21. Changed the return modes of the **isExposureModeSupported** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **isExposureModeSupported(aeMode: ExposureMode, callback: AsyncCallback<boolean>): void** and **isExposureModeSupported(aeMode: ExposureMode): Promise<boolean>** are changed to **isExposureModeSupported(aeMode: ExposureMode): boolean**.
The sample code is as follows:
```
let isSupported = captureSession.isExposureModeSupported(camera.ExposureMode.EXPOSURE_MODE_LOCKED);
```
22. Changed the return modes of the **getExposureMode** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getExposureMode(callback: AsyncCallback<ExposureMode>): void** and **getExposureMode(): Promise<ExposureMode>** are changed to **getExposureMode(): ExposureMode**.
The sample code is as follows:
```
let exposureMode = captureSession.getExposureMode();
```
23. Changed the return modes of the **setExposureMode** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **setExposureMode(aeMode: ExposureMode, callback: AsyncCallback<void>): void** and **setExposureMode(aeMode: ExposureMode): Promise<void>** are changed to **setExposureMode(aeMode: ExposureMode): void**.
24. Changed the return modes of the **getMeteringPoint** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getMeteringPoint(callback: AsyncCallback<Point>): void** and **getMeteringPoint(): Promise<Point>** are changed to **getMeteringPoint(): Point**.
The sample code is as follows:
```
let exposurePoint = captureSession.getMeteringPoint();
```
25. Changed the return modes of the **setMeteringPoint** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **setMeteringPoint(point: Point, callback: AsyncCallback<void>): void** and **setMeteringPoint(point: Point): Promise<void>** are changed to **setMeteringPoint(point: Point): void**.
The sample code is as follows:
```
let Point2 = {x: 2, y: 2};
captureSession.setMeteringPoint(Point2);
```
26. Changed the return modes of the **getExposureBiasRange** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getExposureBiasRange(callback: AsyncCallback<Array<number>>): void** and **getExposureBiasRange(): Promise<Array<number>>** are changed to **getExposureBiasRange(): Array<number>**.
The sample code is as follows:
```
let biasRangeArray = captureSession.getExposureBiasRange();
```
27. Changed the return modes of the **setExposureBias** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **setExposureBias(exposureBias: number, callback: AsyncCallback<void>): void** and **setExposureBias(exposureBias: number): Promise<void>** are changed to **setExposureBias(exposureBias: number): void**.
The sample code is as follows:
```
let exposureBias = biasRangeArray[0];
captureSession.setExposureBias(exposureBias);
```
28. Changed the return modes of the **getExposureValue** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getExposureValue(callback: AsyncCallback<number>): void** and **getExposureValue(): Promise<number>** are changed to **getExposureValue(): number**.
The sample code is as follows:
```
let exposureValue = captureSession.getExposureValue();
```
29. Changed the return modes of the **isFocusModeSupported** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **isFocusModeSupported(afMode: FocusMode, callback: AsyncCallback<boolean>): void** and **isFocusModeSupported(afMode: FocusMode): Promise<boolean>** are changed to **isFocusModeSupported(afMode: FocusMode): boolean**.
The sample code is as follows:
```
let status = captureSession.isFocusModeSupported(camera.FocusMode.FOCUS_MODE_AUTO);
```
30. Changed the return modes of the **getFocusMode** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getFocusMode(callback: AsyncCallback<FocusMode>): void** and **getFocusMode(): Promise<FocusMode>** are changed to **getFocusMode(): FocusMode**.
The sample code is as follows:
```
let afMode = captureSession.getFocusMode();
```
31. Changed the return modes of the **setFocusMode** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **setFocusMode(afMode: FocusMode, callback: AsyncCallback<void>): void** and **setFocusMode(afMode: FocusMode): Promise<void>** are changed to **setFocusMode(afMode: FocusMode): void**.
32. Changed the return modes of the **setFocusPoint** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **setFocusPoint(point: Point, callback: AsyncCallback<void>): void** and **setFocusPoint(point: Point): Promise<void>** are changed to **setFocusPoint(point: Point): void**.
The sample code is as follows:
```
let Point2 = {x: 2, y: 2};
captureSession.setFocusPoint(Point2);
```
33. Changed the return modes of the **getFocusPoint** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getFocusPoint(callback: AsyncCallback<Point>): void** and **getFocusPoint(): Promise<Point>** are changed to **getFocusPoint(): Point**.
The sample code is as follows:
```
let point = captureSession.getFocusPoint();
```
34. Changed the return modes of the **getFocalLength** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getFocalLength(callback: AsyncCallback<number>): void** and **getFocalLength(): Promise<number>** are changed to **getFocalLength(): number**.
The sample code is as follows:
```
let focalLength = captureSession.getFocalLength();
```
35. Changed the return modes of the **getZoomRatioRange** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getZoomRatioRange(callback: AsyncCallback<Array<number>>): void** and **getZoomRatioRange(): Promise<Array<number>>** are changed to **getZoomRatioRange(): Array<number>**.
The sample code is as follows:
```
let zoomRatioRange = captureSession.getZoomRatioRange();
```
36. Changed the return modes of the **getZoomRatio** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getZoomRatio(callback: AsyncCallback<number>): void** and **getZoomRatio(): Promise<number>** are changed to **getZoomRatio(): number**.
The sample code is as follows:
```
let zoomRatio = captureSession.getZoomRatio();
```
37. Changed the return modes of the **setZoomRatio** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **setZoomRatio(zoomRatio: number, callback: AsyncCallback<void>): void** and **setZoomRatio(zoomRatio: number): Promise<void>** are changed to **setZoomRatio(zoomRatio: number): void**.
The sample code is as follows:
```
let zoomRatio = zoomRatioRange[0];
captureSession.setZoomRatio(zoomRatio);
```
38. Changed the return modes of the **isVideoStabilizationModeSupported** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **isVideoStabilizationModeSupported(vsMode: VideoStabilizationMode, callback: AsyncCallback<boolean>): void** and **isVideoStabilizationModeSupported(vsMode: VideoStabilizationMode): Promise<boolean>** are changed to **isVideoStabilizationModeSupported(vsMode: VideoStabilizationMode): boolean**.
The sample code is as follows:
```
let isSupported = captureSession.isVideoStabilizationModeSupported(camera.VideoStabilizationMode.OFF);
```
39. Changed the return modes of the **getActiveVideoStabilizationMode** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **getActiveVideoStabilizationMode(callback: AsyncCallback<VideoStabilizationMode>): void** and **getActiveVideoStabilizationMode(): Promise<VideoStabilizationMode>** are changed to **getActiveVideoStabilizationMode(): VideoStabilizationMode**.
The sample code is as follows:
```
let vsMode = captureSession.getActiveVideoStabilizationMode();
```
40. Changed the return modes of the **setVideoStabilizationMode** API in CaptureSession from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **setVideoStabilizationMode(mode: VideoStabilizationMode, callback: AsyncCallback<void>): void** and **setVideoStabilizationMode(mode: VideoStabilizationMode): Promise<void>** are changed to **setVideoStabilizationMode(mode: VideoStabilizationMode): void**.
41. Changed the **on(type:'error') callback** type in CaptureSession from **ErrorCallback<CaptureSessionError>** to **ErrorCallback<BusinessError>**. Therefore, the original API **on(type: 'error', callback: ErrorCallback<CaptureSessionError>): void** is changed to **on(type: 'error', callback: ErrorCallback<BusinessError>): void**.
The sample code is as follows:
```
captureSession.on('error', (BusinessError) => {
})
```
42. Changed the **on(type:'error') callback** type in PreviewOutput, from **ErrorCallback<PreviewOutputError>** to **ErrorCallback<BusinessError>**. Therefore, the original API **on(type: 'error', callback: ErrorCallback<PreviewOutputError>): void** is changed to **on(type: 'error', callback: ErrorCallback<BusinessError>): void**.
The sample code is as follows:
```
previewOutput.on('error', (BusinessError) => {
})
```
43. Changed the return modes of the **isMirrorSupported** API in PhotoOutput from asynchronous callback and asynchronous promise to the synchronous mode. Therefore, the original APIs **isMirrorSupported(callback: AsyncCallback<boolean>): void** and **isMirrorSupported(): Promise<boolean>** are changed to **isMirrorSupported(): boolean**.
The sample code is as follows:
```
let isSupported = photoOutput.isMirrorSupported();
```
44. Changed the **on(type:'error') callback** type in PhotoOutput, from **ErrorCallback<PhotoOutputError>** to **ErrorCallback<BusinessError>**. Therefore, the original API **on(type: 'error', callback: ErrorCallback<PhotoOutputError>): void** is changed to **on(type: 'error', callback: ErrorCallback<BusinessError>): void**.
The sample code is as follows:
```
PhotoOutput.on('error', (BusinessError) => {
})
```
45. Changed the **on(type:'error') callback** type in VideoOutput, from **ErrorCallback<VideoOutputError>** to **ErrorCallback<BusinessError>**. Therefore, the original API **on(type: 'error', callback: ErrorCallback<VideoOutputError>): void** is changed to **on(type: 'error', callback: ErrorCallback<BusinessError>): void**.
The sample code is as follows:
```
VideoOutput.on('error', (BusinessError) => {
})
```
46. Changed the **on(type:'error') callback** type in MetadataOutput, from **ErrorCallback<MetadataOutputError>** to **ErrorCallback<BusinessError>**. Therefore, the original API **on(type: 'error', callback: ErrorCallback<MetadataOutputError>): void** is changed to **on(type: 'error', callback: ErrorCallback<BusinessError>): void**.
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.
Added the [AVPlayer](../../../application-dev/reference/apis/js-apis-media.md#avplayer9)<sup>9+</sup> API for audio and video playback, with the updated state machine and error codes, which is recommended. The following APIs for audio playback and video playback are no longer maintained: [AudioPlayer](../../../application-dev/reference/apis/js-apis-media.md#audioplayer)<sup>6+</sup> and [VideoPlayer](../../../application-dev/reference/apis/js-apis-media.md#videoplayer)<sup>8+</sup>.
**Change Impacts**
The original APIs can still be used but are no longer maintained. You are advised to use the new API instead.
For details, see the [reference](../../../application-dev/reference/apis/js-apis-media.md) for each API.
## cl.media.2 API Change of the Recording Function
Added the [AVRecorder](../../../application-dev/reference/apis/js-apis-media.md#avrecorder9)<sup>9+</sup> API for audio and video recording, with the updated state machine and error codes, which is recommended. The following APIs for audio recording and video recording are no longer maintained: [AudioRecorder](../../../application-dev/reference/apis/js-apis-media.md#audiorecorder)<sup>6+</sup> and [VideoRecorder](../../../application-dev/reference/apis/js-apis-media.md#videorecorder9)<sup>9+</sup>.
The [AudioSourceType](../../../application-dev/reference/apis/js-apis-media.md#audiosourcetype9) and [VideoSourceType](../../../application-dev/reference/apis/js-apis-media.md#videosourcetype9) APIs shared by the old and new recording APIs are changed to non-system APIs.
**Change Impacts**
The [AudioRecorder](../../../application-dev/reference/apis/js-apis-media.md#audiorecorder)<sup>6+</sup> and [VideoRecorder](../../../application-dev/reference/apis/js-apis-media.md#videorecorder9)<sup>9+</sup> APIs can still be used but are no longer maintained. You are advised to use the [AVRecorder](../../../application-dev/reference/apis/js-apis-media.md#avrecorder9)<sup>9+</sup> API instead.
For details, see the [reference](../../../application-dev/reference/apis/js-apis-media.md) for each API.
## cl.media.3 Error Code Change
Added the standard error code enumeration type [AVErrorCode9](../../../application-dev/reference/apis/js-apis-media.md#averrorcode)<sup>9+</sup> that replaces the original error code enumeration type [MediaErrorCode](../../../application-dev/reference/apis/js-apis-media.md#mediaerrorcode)<sup>8+</sup>.
**Change Impacts**
The error code enumeration type [MediaErrorCode](../../../application-dev/reference/apis/js-apis-media.md#mediaerrorcode)<sup>8+</sup> is still used for original APIs. [AVErrorCode9](../../../application-dev/reference/apis/js-apis-media.md#averrorcode)<sup>9+</sup> is used for newly added APIs.
## 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.
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).
# 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:
