OpenHarmony System Migration, Development, and Compatibility Testing: A Comprehensive Guide
In the era of rapid IoT and smart device development, OpenHarmony, as an opensource operating system, provides developers with rich resources and platforms. This article details the entire workflow—including system porting, development, adaptation, compatibility testing, and driver integration.
I. Project Background and Preparations
Before undertaking OpenHarmony system porting and development, it is essential to review devicespecific documentation such as system porting guides, application development manuals, and UX design specifications.
1. Environment Setup
Configure the appropriate toolchain and establish an OpenHarmonybased integrated development environment (IDE) based on project requirements.
2. Defining the Development Board and Product
In the OpenHarmony source repository, create a dedicated product directory for the target development board and define a `config.json` configuration file to specify product details (e.g., CPU type, OS version, vendor name).
Example: Assume MyProduct is a development board from P1Vendor using an SoC chip from SoCVendor.
Product Definition
Create a `config.json` file under `//vendor/P1Vendor/{product_name}`:
```json
//vendor/P1Vendor/P1/config.json
II. System Porting and Kernel Compilation
1. Porting Verification
Initiate product build validation using the command:
```bash
./build.sh productname MyProduct
```
After compilation, OpenHarmony image files are generated under `//out/{device_name}/packages/phone/images`.
2. Kernel Porting
To enable Linux kernel operation on the target chip:
Add kernel build subsystems for the chip.
Modify configuration files to integrate new subsystems.
Compile Linux 4.19 kernel to generate kernel and bootloader images.
Expected Build Output:
III. UserMode Bootstrapping and HDF Driver Porting
1. UserMode Bootstrapping
After kernel initialization, the usermode boot process involves:
Analyzing the `init` process flow (root filesystem mounting, ueventd activation for hotplug events).
Developing platformspecific initialization configurations for MyProduct to ensure hardware recognition.
UserMode Process Overview:
![Boot Process Diagram]
2. HDF Driver Porting
The Hardware Driver Foundation (HDF) framework supports hardware driver development. Key drivers ported for MyProduct include LCD, touchscreen, and WLAN.
LCD Driver:
Implement driver code, instantiate models, and register devices.
Update configuration files for LCD recognition.
Touchscreen Driver:
Develop touchscreen driver interfaces.
Configure driver parameters in system files.
WLAN Driver:
Code `ChipDriver` to interface with `HDF_WLAN_CORE` and `NetDevice`.
Define devicespecific configurations for WLAN support.
3. Troubleshooting: Boot Animation Freeze
Issue: System stalls at boot logo (OpenHarmony 4.0).
Root Cause: Lock screen service (`bootevent.lockscreen.ready`) remained active after lock screen app removal.
Solution:
Remove the lock screen service component from the subsystem configuration:
```json
{
"subsystem": "theme",
"components": [
{ "component": "wallpaper_mgr", "features": [] }
]
}
```
IV. OpenHarmony Application Development
1. Application Models
FA Model (deprecated): Supported since API 7.
Stage Model (recommended): Introduced in API 9, emphasizing longterm evolution with `AbilityStage` and `WindowStage` classes.
2. First Application with ArkUI
Step 1: Install DevEco Studio and create a "Stage Model" project (Compile SDK: 12).
Step 2: Explore the ArkTS project structure:
`entry`: Main module.
`src/main/ets`: Core logic.
`resources`: Assets and configurations.
V. Software Definition and Compatibility Testing
1. Version ID
A 10field identifier with specific meanings (e.g., platform type, OS version).
2. Version Hash
Enter "default" for compatibility testing.
VI. Authorization Verification Management
1. Soft Certificate Application
Follow the Soft Certificate Application Guide to generate and decrypt certificates using tools like `RsaDec.bat` and `RsaDec2.1.0.jar`.
2. Device Configuration
Modify system files to align with compatibility platform data:
Update `device_attest_oem_adapter.c` with `manu.key` and `ProdId` values.
Adjust OS and product info in `ohos.para`.
3. Build and Validation
Enable compilation in `devattestconfig.gni` (`enable_attest_test_sample = true`).
Generate `attesttestclient` via `./build.sh productname rk3568 ccache`.
Execute the binary to verify authorization.
VII. Conclusion
Postporting and driver integration, comprehensive compatibility testing ensures system stability, hardware recognition, and performance under diverse scenarios.
About Shenguang: Since 2022, we have assisted clients in OpenHarmony compatibility certification, including pretesting, kernel porting, driver adaptation, and failcase resolution. We offer dualsystem expertise (OpenHarmony for domestic markets, Android GMS for global markets) to streamline crossplatform certification.
Contact Us: For endtoend support in OpenHarmony and Android GMS certification, reach out to our team. One sample, two certifications—simplified.
+86-13266518903
