1 -> Integration Project Migration
Starting from the NEXT Developer Beta 1 version, DevEco Studio provides an out-of-the-box development experience, integrating SDKs, Node.js, Hvigor, OHPM and other tool chains to simplify the installation and configuration process of DevEco Studio. It also provides integrated historical project migration capabilities to help developers quickly complete project conversion.
note
To avoid data loss, back up the project before migration.
The integration changes are as follows:
1.1 -> Automatic migration
- Open the history project, and the Notifications notification bar will show "Sync failed." If the synchronization fails, click Migrate Assistant to go to the Migration Assistant page.
illustrate
You can go to the Tools > Migrate Assistant page in the menu bar.
- Select Migrate to 5.0.0/5.0.1/5.0.2 in the Migrate Assistant tab at the bottom of the page, and click the Migrate button. If you confirm that the backup has been completed, click Migrate in the pop-up window to start the migration task.
- When the project completes the synchronization again and there is no other error message, the migration is successful.
illustrate
If the project is an API 8/9 project managed by NPM, first complete the upgrade according to the OHPM package management, and then go to the Tools > Migrate Assistant page in the menu bar to complete the automatic migration of the integrated project.
1.2 -> Manual migration
1.2.1 -> Migration of historical projects with API 10 and above
If the automated migration is unsuccessful or you want to perform a manual migration, you also need to back up the project before migration. The manual migration process is as follows:
- Go to the project-level build-profile.json5 file and delete the compileSdkVersion configuration. If the project is an Openharmony project, you do not need to delete the compileSdkVersion field.
- Delete and modify Hvigor related files:
Delete the hvigorw and hvigorw.bat files in the project directory on the left, and delete the hvigor-wrapper.js files in the hvigor directory.
Go to the hvigor > hvigor-config.json5 file and add the modelVersion field, which is 5.0.0 for API 12. And remove the hvigorVersion field, the @ohos/hvigor-ohos-plugin and rollup fields in dependencies.
- You also need to add the modelVersion field in the project-level oh-package.json5 file, taking API 12 as an example, its value is "5.0.0".
- In the local.properties file, delete the HarmonyOS SDK configuration. If the project is an Openharmony project, you do not need to perform this step.
- Click Sync now at the top of the editing screen or click File > Sync and Refresh Project in the menu bar to resynchronize the project. If no other errors are reported, the manual migration of the historical project is completed.
1.2.2 -> API 9 Historical Project Migration
- Delete the compileSdkVersion field from the project-level build-profile.json5 file, and migrate the compatibleSdkVersion field from the app field to the currently selected product. You can click on the current effective product in the upper right corner of the edit area
- Change compatibleSdkVersion and targetSdkVersion (if configured) from 9 to 4.0.0(10) and configure runtimeOS. The version number must meet the string type of the M.S.F(X) rule, and use English. and ().
"app": {
"signingConfigs": [],
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "4.0.0(10)", //指定HarmonyOS应用/元服务兼容的最低版本。
"targetSdkVersion": "4.0.0(10)", //指定HarmonyOS应用/元服务目标版本。若没有设置,默认为compatibleSdkVersion
"runtimeOS": "HarmonyOS", //指定为HarmonyOS
}
],
...
}
- Delete the runtimeOS configured in the target field in the build-profile.json5 file at each module level.
- The remaining steps are the same as those in API 10 and above, refer to Step 2 of 1.2.1 to complete the remaining manual migration steps.
illustrate
The one-click upgrade takes effect only for the currently selected product.
If there are multiple products, you need to switch between different products and upgrade the project according to the manual upgrade method. For each product, you need to configure the corresponding compatibleSdkVersion and runtimeOS.
For API 8/9 NPM projects, you must first complete the upgrade according to the management of the adaptive OHPM package, and then complete the manual migration configuration according to the API 9 historical project migration.
Starting from DevEco Studio 4.0 Release, the code editor and the compilation and build process have enhanced the check of the ArkTS syntax specification.
If a historical project contains low-code APIs, you need to convert the low-code APIs to ArkTS code and correct the errors before they can be compiled properly. The transcoding operation deletes the visual file and its parent directory, and is an irreversible process, and the visual file cannot be reversely generated from the ETS file after the transcoding operation.
Top comments (0)