title=”HarmonyOS PC openEuler is commonly used to develop software” frameborder=”0” allow=”accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share” referrerpolicy=”strict-origin-when-cross-origin” allowfullscreen></iframe>

Background of the problem

glibc version conflict

In the openEuler container of the HarmonyOS PC Convergence Development Engine, an error is encountered when trying to install the nvim-treesitter plugin:

[nvim-treesitter/install/c] error: Error during “tree-sitter build”: 
tree-sitter: /usr/lib64/libc.so.6: version `GLIBC_2.39’ not found (required by tree-sitter)

Version check

ldd --version
# 输出：ldd (GNU libc) 2.38

cat /etc/os-release
# NAME=”openEuler”
# VERSION=”24.03 (LTS-SP1)”

glibc for openEuler 24.03 SP1 is 2.38, while the precompiled tree-sitter CLI downloaded by nvim-treesitter requires glibc 2.39.

Root causes

Container environments share virtual machine kernels and cannot be upgraded to glibc. The solution is to compile all components from source, using the glibc version of the current system.

Solution overview

1. 安装编译依赖
2. 安装Rust工具链（编译tree-sitter CLI需要）
3. 从源码编译tree-sitter CLI
4. 从源码编译Neovim
5. 配置AstroNvim

1. Install compilation dependencies

Basic tools

# 安装cmake和ninja
sudo dnf install -y cmake ninja-build

# 验证安装
cmake --version
ninja --version

Other dependencies

# gcc、make等已预装
gcc --version
make --version

2. Install the Rust toolchain

The tree-sitter CLI is written in Rust and needs to be installed first:

# 设置代理（可选）
export https_proxy=http://192.168.3.6:1080

# 安装Rust
curl --proto ‘=https’ -sSf https://sh.rustup.rs | sh -s -- -y

# 加载环境
source ~/.cargo/env

# 验证
cargo --version
rustc --version

3. Compile the tree-sitter CLI

Get the source code

export https_proxy=http://192.168.3.6:1080

# 克隆tree-sitter CLI（使用稳定版本v0.24.1）
git clone --depth 1 --branch v0.24.1 \
    https://github.com/tree-sitter/tree-sitter.git \
    ~/tree-sitter-cli

Compilation

cd ~/tree-sitter-cli
cargo build --release

The compilation process takes about 1-2 minutes.

Installation

# 系统安装
sudo cp ~/tree-sitter-cli/target/release/tree-sitter /usr/local/bin/

# 或替换mason的预编译版本
cp ~/tree-sitter-cli/target/release/tree-sitter \
    ~/.local/share/nvim/mason/packages/tree-sitter-cli/tree-sitter-linux-arm64

# 验证
tree-sitter --version
# 输出：tree-sitter 0.24.1

4. Compiling Neovim

Get the source code

export https_proxy=http://192.168.3.6:1080

# 查看最新版本
git ls-remote --tags https://github.com/neovim/neovim.git | \
    grep -v ‘\^{}’ | grep ‘v0\.1[0-2]’ | tail -5

# 克隆最新稳定版v0.12.0
git clone --depth 1 --branch v0.12.0 \
    https://github.com/neovim/neovim.git \
    ~/neovim

Compilation

cd ~/neovim
make CMAKE_BUILD_TYPE=Release

The compilation process takes about 3-5 minutes and automatically downloads and compiles all dependencies.

Installation

sudo make install

# 验证
nvim --version
# 输出：
# NVIM v0.12.0
# Build type: Release
# LuaJIT 2.1.1774638290

Compile output location

ls ~/neovim/build/bin/nvim
# -rwxr-xr-x 1 user user 10346568 ... nvim

5. Configure AstroNvim

AstroNvim is a pre-configured Neovim distribution that provides a complete IDE experience.

Back up existing configurations

# 备份旧配置
mv ~/.config/nvim ~/.config/nvim.bak
mv ~/.local/share/nvim ~/.local/share/nvim.bak
mv ~/.local/state/nvim ~/.local/state/nvim.bak

Install AstroNvim

# 克隆AstroNvim配置
git clone --depth 1 https://github.com/AstroNvim/AstroNvim \
    ~/.config/nvim

# 复制默认用户配置模板
cp ~/.config/nvim/lua/user_template.lua ~/.config/nvim/lua/user.lua

First launch

nvim

The first launch automatically installs all plugins and the tree-sitter parser. Since we have compiled the tree-sitter CLI, the treesitter installation does not give glibc errors.

Custom configuration

Edit :~/.config/nvim/lua/user.lua

return {
  -- 自定义颜色方案
  colorscheme = “catppuccin-mocha”,
  
  -- 自定义选项
  options = {
    opt = {
      relativenumber = true, -- 相对行号
    },
  },
  
  -- 自定义插件
  plugins = {
    “rebelot/kanagawa.nvim”,
    -- 添加更多插件...
  },
  
  -- LSP配置
  lsp = {
    formatting = {
      format_on_save = true,
    },
    servers = {
      -- 添加LSP服务器...
    },
  },
}

Install LSPs and tools

Running in Neovim:

:LspInstall python
:LspInstall lua_ls
:TSInstall python
:TSInstall lua
:MasonInstall prettier

6. Verify the tree-sitter work

Install the parser

:TSInstallInfo

Review the available parsers and select the desired installation:

:TSInstall vimdoc
:TSInstall lua
:TSInstall python
:TSInstall javascript
:TSInstall html
:TSInstall css
:TSInstall json
:TSInstall markdown

Check the status

:TSInstallInfo

All parsers should appear as .✓ installed

7. Summary

Compiled checklist

Components version state cmake 3.27.9

✓ Installedninja1.11.1

✓ InstalledRust1.94.1

✓ Installedtree-sitter CLI0.24.1

✓ Compiled Neovim0.12.0

✓ Compiled Astro Nvim latest

✓ Configured

Key points

1. glibc compatible: Compiling from source ensures that the current glibc is used

2. Rust dependencies: tree-sitter CLI requires Rust compilation

3. Full flow: Rely on → Rust → tree-sitter → Neovim → AstroNvim

Performance

The compiled Neovim runs smoothly in the openEuler container:

• Startup speed: < 100ms

• LSP Response: Fast

• Treesitter Highlight: Normal

• Plugin ecosystem: Full support

Guide to avoiding pits

1. Don’t use precompiled tree-sitter: mason downloaded precompiled versions of glibc are not compatible

2. Remember to replace Mason’s tree-sitter: otherwise nvim-treesitter will still use the precompiled version

3. Use stable version: avoid instability in the main branch

8. Clean up the construction files

After the compilation is complete, you can clean up the source code:

# 可选：保留源码用于后续升级
# 或删除以节省空间
rm -rf ~/tree-sitter-cli
rm -rf ~/neovim

It is recommended to keep the source code directory for future version upgrades.

9. Follow-up upgrades

Upgrading Neovim:

cd ~/neovim
git fetch --tags
git checkout v0.13.0  # 假设新版本
make CMAKE_BUILD_TYPE=Release
sudo make install

Upgrade tree-sitter:

cd ~/tree-sitter-cli
git fetch --tags
git checkout v0.25.0  # 假设新版本
cargo build --release
sudo cp target/release/tree-sitter /usr/local/bin/

References:

• Neovim official website:

https://neovim.io

• tree-sitter project:

https://tree-sitter.github.io

• AstroNvim documentation:

https://astronvim.com

• AstroNvim repository: https://github.com/AstroNvim/AstroNvim

Source: 欢迎回来╮(╯▽╰)╭

This document describes how to configure the Neovim (AstroNvim) development environment on the openEuler (aarch64) system for Cangjie language development.

Table of contents

• System requirements:

• Install the Cangjie SDK

• 安装 Cangjie STDX

• Environment variable configuration

• Neovim Configuration

• FAQs

System requirements:

• 操作系统：openEuler 2403 SP1 (aarch64)

• GCC version: 12.3.1 or higher

• Neovim version: 0.9.0 or higher

Install the Cangjie SDK

1. Download Cangjie SDK (aarch64 version) from official channels

2. Extract to the directory~/.config/cjvs/store/

Example of a directory structure:

~/.config/cjvs/
└── store/
    └── 1.1.0-beta.25/
        ├── envsetup.sh
        ├── lib/
        ├── runtime/
        └── ...

安装 Cangjie STDX

STDX is Cangjie’s standard extension library and needs to be installed separately:

1. 从发布页面下载：https://gitcode.com/Cangjie/cangjie_stdx/releases/v1.1.0-beta.24.1

2. Select Versionlinux_aarch64_cjnative

3. Extract to the directory~/.config/cjvs/stdx/

Example of a directory structure:

~/.config/cjvs/
└── stdx/
    └── 1.1.0-beta.24/
        └── linux_aarch64_cjnative/
            └── static/
                └── stdx/
                    ├── stdx.cjo
                    └── ...

Environment variable configuration

Edit to add the following configuration:~/.zshrc

# 仓颉 SDK 环境配置
source $HOME/.config/cjvs/store/1.1.0-beta.25/envsetup.sh

# STDX 路径配置
export CANGJIE_STDX_PATH=”$HOME/.config/cjvs/stdx/1.1.0-beta.24/linux_aarch64_cjnative/static/stdx”

After configuration, execute:

source ~/.zshrc

Note:

• envsetup.sh: Sets the environment variables required by the Cangjie compiler

• CANGJIE_STDX_PATH: Specifies the path to the STDX library

Create a gmotic link to the GCC runtime library

Since the Cangjie linker script searches the directory by default, you need to create a symlink:/lib64

sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtbeginS.o /lib64/crtbeginS.o
sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtendS.o /lib64/crtendS.o
sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtbegin.o /lib64/crtbegin.o
sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtend.o /lib64/crtend.o

Note: Addresses an issue where runtime libraries such as cannot be found when linkingcrtbeginS.o

Neovim Configuration

1. Install AstroNvim

git clone --depth 1 https://github.com/AstroNvim/AstroNvim ~/.config/nvim

2. Configure the Cangjie LSP plug-in

Create File :~/.config/nvim/lua/plugins/cangjie-lsp.lua

return {
  “https://gitcode.com/ystyle/cangjie-nvim”,
  dependencies = { “neovim/nvim-lspconfig” },
  opts = { auto_install = true },
  config = function(plugin)
    require(”cangjie-nvim”).setup(plugin.opts)

    vim.api.nvim_create_autocmd(”LspAttach”, {
      callback = function(args)
        if vim.bo[args.buf].filetype ~= “Cangjie” then return end
        
        local function map(mode, lhs, rhs, desc)
          vim.keymap.set(mode, lhs, rhs, { buffer = args.buf, desc = desc })
        end

        map(”n”, “<leader>li”, “<cmd>LspInfo<cr>”, “LSP Info”)
        map(”n”, “K”, vim.lsp.buf.hover, “Hover Document”)
        map(”n”, “<leader>lf”, function() vim.lsp.buf.format { async = true } end, “Format Document”)
        map(”n”, “gl”, vim.diagnostic.open_float, “Line Diagnostics”)
        map(”n”, “<leader>ld”, vim.diagnostic.open_float, “Line Diagnostics”)
        map(”n”, “<leader>lD”, vim.diagnostic.setqflist, “All Diagnostics”)
        map(”n”, “gra”, vim.lsp.buf.code_action, “Code Actions”)
        map(”n”, “<leader>la”, vim.lsp.buf.code_action, “Code Actions”)
        map(”n”, “<leader>lh”, vim.lsp.buf.signature_help, “Signature Help”)
        map(”n”, “grn”, vim.lsp.buf.rename, “Rename”)
        map(”n”, “<leader>lr”, vim.lsp.buf.rename, “Rename”)
        map(”n”, “<leader>ls”, vim.lsp.buf.document_symbol, “Document Symbols”)
        map(”n”, “<leader>lG”, vim.lsp.buf.workspace_symbol, “Workspace Symbols”)
        map(”n”, “]d”, vim.diagnostic.goto_next, “Diagnostic Next”)
        map(”n”, “[d”, vim.diagnostic.goto_prev, “Diagnostics Previous”)
        map(”n”, “]e”, function() vim.diagnostic.goto_next { severity = vim.diagnostic.severity.ERROR } end, “Error Next”)
        map(”n”, “[e”, function() vim.diagnostic.goto_prev { severity = vim.diagnostic.severity.ERROR } end, “Error Previous”)
        map(”n”, “]w”, function() vim.diagnostic.goto_next { severity = vim.diagnostic.severity.WARN } end, “Warning Next”)
        map(”n”, “[w”, function() vim.diagnostic.goto_prev { severity = vim.diagnostic.severity.WARN } end, “Warning Previous”)
        map(”n”, “gD”, vim.lsp.buf.declaration, “Declaration”)
        map(”n”, “gy”, vim.lsp.buf.type_definition, “Type Definition”)
        map(”n”, “gd”, vim.lsp.buf.definition, “Definition”)
        map(”n”, “gri”, vim.lsp.buf.implementation, “Implementation”)
        map(”n”, “grr”, vim.lsp.buf.references, “References”)
      end,
    })
  end,
}

3. Launch Neovim and install the plugin

nvim

AstroNvim automatically detects and installs plugins. When you first open the file, the plugin automatically downloads the LSP wrapper binary.cangjie-nvim.cj

LSP Wrapper Address:

• 项目地址：https://gitcode.com/ystyle/cangjie-lsp-wrapper

• Automatic download location:~/.local/share/nvim/data/cangjie-nvim/bin/

FAQs

1. 链接错误：cannot find crtbeginS.o

Error message:

/usr/bin/ld: cannot find crtbeginS.o: No such file or directory

Solution:
Create a symbolic link to the GCC runtime library:

sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtbeginS.o /lib64/crtbeginS.o
sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtendS.o /lib64/crtendS.o
sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtbegin.o /lib64/crtbegin.o
sudo ln -sf /usr/lib/gcc/aarch64-openEuler-linux/12/crtend.o /lib64/crtend.o

2. LSP does not work

Check Steps:

1. Verify that the Cangjie SDK environment variables are loaded:echo $CANGJIE_HOME

2. Confirm that the LSP wrapper is downloaded:ls ~/.local/share/nvim/data/cangjie-nvim/bin/

3. To install the LSP wrapper manually:

:lua require(”cangjie-nvim”).install()

3. STDX not found

Error message:

error: cannot find stdx module

Solution:
Confirm that the environment variable points to the correct directory:CANGJIE_STDX_PATH

ls $CANGJIE_STDX_PATH
# 应该能看到 stdx.cjo 文件

4. Quick event context error

Error message:

E5560: nvim_create_namespace must not be called in a fast event context

Solution:
This issue has been fixed in the plugin, make sure you are using the latest version.cangjie-nvim

Keybit mapping

Source: 欢迎回来╮(╯▽╰)╭

I. Basic Environment Setup

1. nodejs

Note: Some versions of the latest Node.js may have issues; we recommend using version 20, which is included in the repository, when running Node-RED.

sudo dnf update -y
sudo dnf install nodejs -y
node -v

2. Development Tools

sudo dnf groupinstall "Development Tools" -y
sudo dnf install cmake -y

2. Installing Node-RED

1. Installation

sudo npm install -g --unsafe-perm node-red --registry=https://registry.npmmirror.com

Once the installation is complete, type `node-red` to start it.

Then open http://172.16.100.2:1880 in your browser. A pop-up window will appear by default to notify you of updates; choose whether to enable notifications based on your preferences.

1. Node.js

Note: Some versions of the latest Node.js may have issues; we recommend using version 20, which is included in the repository, when running Node-RED.

sudo dnf update -y
sudo dnf install nodejs -y
node -v

2. Development Tools

sudo dnf groupinstall "Development Tools" -y
sudo dnf install cmake -y

2. Installing Node-RED

1. Installation

sudo npm install -g --unsafe-perm node-red --registry=https://registry.npmmirror.com

Once the installation is complete, type `node-red` to start it.

Then open http://172.16.100.2:1880 in your browser. A pop-up window will appear by default to notify you of updates; choose whether to enable notifications based on your preferences.

2. Enable HTTPS

Enable HTTPS so that certain components, such as those related to the microphone and camera, can function properly.

cd /home/user/.node-red
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out certificate.crt

Fill in the country, province, city, and company according to your actual information, or you can just enter any values.

vi /home/user/.node-red/settings.js

Comment out or delete the following content, then modify the paths for the key and certificate.

key：/home/user/.node-red/private.key

cert：/home/user/.node-red/certificate.crt

接着执行vi ~/.bashrc打开bashrc，在最后一行添加如下内容，忽略证书警告。最后执行source ~/.bashrc

export NODE_TLS_REJECT_UNAUTHORIZED=0

Restart Node-RED, then visit https://172.16.100.2:1880/. If you see a warning about an insecure certificate, just ignore it.

III. Installation Nodes

1. Installation Instructions

Here, I’ll use the base64 module as an example for the installation

2. Common Nodes

node-red-dashboard

Dashboard UI Collection

You can install both the old and new versions. The one marked as “deprecated” is the old version.

node-red-node-serialport

Serial port node (USB mapping has not yet been implemented in the virtual machine, so it cannot be used at this time)

node-red-node-ui-table

Table node

node-red-node-base64

Encoding and decoding data in Base64 format

node-red-node-random

Generate random numbers within a specified range

node-red-node-ui-webcam

Access the camera and capture an image from the dashboard

node-red-node-ui-lineargauge

Create a linear gauge to visualize a range of values

node-red-contrib-ui-led

Display LED status indicators on the dashboard

node-red-node-ui-list

Display simple list data on the dashboard

node-red-contrib-ip

Output IP address

node-red-node-ui-microphone

Microphone node

node-red-node-ui-webcam

Webpage access to the camera

node-red-contrib-modbus

Modbus industrial communication protocol

node-red-node-mysql

MySQL database client

node-red-contrib-tfjs-coco-ssd

TensorFlow image recognition node

node-red-contrib-ui-svg

Display SVG image nodes

node-red-contrib-ui-contextmenu

Dropdown menu node

node-red-contrib-ui-artless-gauge

A minimalist dashboard UI component for displaying values

node-red-contrib-image-output

Preview images in the programming interface

Other nodes I’ve used before but don’t use very often:

node-red-contrib-ui-countdown-timer-switch、node-red-contrib-ui-actions、node-red-node-ui-vega、node-red-contrib-ui-etable、node-red-contrib-ui-simple-level、node-red-contrib-ui-statechart、node-red-contrib-ui-digital-clock、node-red-contrib-ui-clock、node-red-contrib-readdir、node-red-contrib-ui-joystick

Source: 鸿蒙PC openEuler安装node-red - Feishu Docs

Setting Up the Flutter Toolchain on HarmonyOS Using HiSH

This guide provides a complete, step-by-step walkthrough for setting up a native Flutter development environment for OpenHarmony on a HarmonyOS PC, tablet, or even a phone. By following these instructions, you will be able to build and run Flutter applications directly on your HarmonyOS device without needing a separate macOS, Windows, or Linux machine. The key enabler is HiSH, a Linux emulator and shell tool specifically designed for HarmonyOS that allows you to run a complete Linux environment, transforming your device into a portable Linux development terminal.

The Unix-like Philosophy on HarmonyOS with HiSH

The approach described here adheres to the classic “Unix-ish principles” you referenced, similar to how toolchains operate on macOS and Linux. HiSH provides a full arm64 Linux kernel and a choice of userland environments (Alpine Linux, Ubuntu 24.04, or Debian 12) on top of HarmonyOS. This creates a stable, Linux-based command-line interface where you can execute standard tools like git, bash, curl, and most importantly, the Flutter SDK. While HarmonyOS has its own native terminal (HiShell), it lacks the complete Linux userspace required by the Flutter toolchain. HiSH fills this gap entirely, making your HarmonyOS device a first-class development host.

Step-by-Step Guide to Setting Up the Flutter Toolchain on HarmonyOS

This process breaks down into four logical phases: installing HiSH and the necessary IDEs, configuring the Linux environment inside HiSH, creating or migrating your Flutter project, and finally signing and deploying your app.

Phase 1: Environment Preparation (The Foundation)

Before any code is written, you must install the three core components that form the foundation of your development environment.

Step 1.1: Install HiSH (The Linux Environment)
HiSH is the non-negotiable core of this setup. It is a Linux emulator and shell tool specifically designed for HarmonyOS. Based on qemu-ohos, it supports both 2-in-1 PCs, tablets, and phones.

• Action: You have three options to obtain HiSH:

  1. Easiest: Install it directly from the AppGallery (note that this version does not support JIT, so it runs slower).

  2. Recommended for Developers: Download the HAP file from the HiSH Releases page, sign it yourself (using DevEco Studio’s signing tool), and then install it with hap_installer or deployment through DevEco Studio IDE itself. This version supports JIT and runs much faster.

  3. From Source: Clone the HiSH repository and build it in DevEco Studio for the maximum level of customization.

• Why HiSH: The OpenHarmony-SIG Flutter SDK relies on a toolchain designed for Unix-like systems. HiSH fulfills this dependency by providing a complete, virtualized Linux kernel and root filesystem with networking, port forwarding, and a shared folder for easy file exchange between HarmonyOS and the Linux environment.

Step 1.2: Install DevEco Studio (The Native IDE & SDK Manager)

DevEco Studio is the Rust-based, native IDE for HarmonyOS. It is not a JetBrains product but a custom, high-performance environment written in Rust and using Huawei’s in-house Bifeng framework.

• Action: Download and install DevEco Studio from the official Huawei developer website.

• Why: DevEco Studio serves two critical functions in this workflow:

  1. It manages the OpenHarmony/HarmonyOS SDK, which contains the native tools (hdc, ohpm, hvigor) needed to build and deploy apps.

  2. It handles the final signing and deployment of the .hap (HarmonyOS Ability Package) file to your device. It also provides the “Auto-Signing” feature to generate security certificates.

Step 1.3: Install BiSheng JDK 17 (The Missing Link)
Flutter’s internal tools require a Java runtime to function. On HarmonyOS, this is provided by the BiSheng JDK.

• Action: Install BiSheng JDK 17-OH from the AppGallery. This process will automatically register the Java environment with the system’s toolchain configurations, linking it to both CodeArts IDE and DevEco Studio.

• Critical Note: Without this specific JDK, the flutter command will fail inside HiSH because it cannot find a valid Java runtime.

Phase 2: SDK and Environment Configuration (Inside HiSH)

With the core apps installed, you now launch HiSH and configure the Linux environment to recognize the Flutter SDK and the BiSheng JDK.

Step 2.1: Launch HiSH and Set Up the Shared Folder
Open the HiSH app on your HarmonyOS device. Once the Linux kernel boots and you are presented with a shell prompt (likely from the included Alpine Linux rootfs), you need to identify the shared folder. This folder is a bidirectional bridge: files placed here are visible both in HarmonyOS and inside the HiSH Linux environment.

• Action: HiSH typically creates a shared directory. You can find its location by looking for a mounted directory (often /mnt/shared or similar) or by checking the HiSH documentation. Place all your development projects in this shared folder so you can access them from both HiSH (for command-line builds) and DevEco Studio (for signing and deployment).

Step 2.2: Install Necessary Linux Packages
Inside the HiSH terminal, update the package manager and install git and curl, as the Alpine Linux rootfs is very minimal.

• Action: Run the following commands in the HiSH terminal:

  bash

apk update
apk add git curl bash

Step 2.3: Clone the OpenHarmony Flutter SDK
Now, clone the specific branch of the Flutter SDK for OpenHarmony directly into your shared folder.

• Action: Navigate to your shared folder (e.g., cd /mnt/shared) and run the following command to get the current stable version (3.27.x branch):

  bash

git clone -b br_3.27.4-ohos-1.0.4 https://gitcode.com/openharmony-tpc/flutter_flutter.git

Step 2.4: Configure Environment Variables for the Linux Shell
You must tell the system inside HiSH where to find the Flutter and BiSheng JDK binaries. Since the BiSheng JDK is installed on the HarmonyOS host, you will need to locate its installation path from within HiSH. It is often accessible through the shared folder or a specific mount point. For this guide, we assume you have copied or linked the JDK into a path inside HiSH, for example, /home/openharmony/libs/bisheng-jdk17-oh.

• Action: Edit the .bashrc file in your HiSH Linux environment (or run these commands directly in the session) to set the necessary paths. Use nano ~/.bashrc if nano is installed, or vi ~/.bashrc.
  Add the following lines, adjusting the paths to match your actual directories inside HiSH:

  bash

# Flutter OH SDK Path
export FLUTTER_HOME=/mnt/shared/flutter_flutter
export PATH=”$FLUTTER_HOME/bin:$PATH”

# BiSheng JDK 17 Path (inside the HiSH Linux environment)
export JAVA_HOME=/home/openharmony/libs/bisheng-jdk17-oh
export PATH=”$JAVA_HOME/bin:$PATH”

# Optional but recommended: Use Chinese mirrors for faster package downloads
export FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn
export PUB_HOSTED_URL=https://pub.flutter-io.cn

• Load the configuration: Run source ~/.bashrc to apply the changes.

Step 2.5: Link BiSheng JDK to the Flutter Toolchain
This is the most important command. You must explicitly tell the Flutter toolchain where to find the BiSheng JDK.

• Action: In the HiSH terminal, run the following command:

  bash

flutter config --jdk-dir=$JAVA_HOME

Step 2.6: Verify Your Setup Inside HiSH
Run the verification command to ensure everything is correctly configured within the Linux emulator.

• Action: Execute flutter doctor -v in the HiSH terminal.

• Expected Outcome: You should see a green checkmark next to the Java binary path, confirming it is using the BiSheng version. The output should also indicate that the OpenHarmony toolchain is available. You might see warnings about other platforms (Android, iOS), but the key is to see no errors for the OpenHarmony environment.

Phase 3: Project Creation and Migration (The Code)

Your Linux environment (HiSH) is now ready. You can create a new Flutter project or bring in an existing codebase.

Step 3.1: Generate the Project “Bridge” Inside HiSH
The Flutter toolchain needs to create the native HarmonyOS project files (the ohos folder) that DevEco Studio understands.

• Action: Navigate to your desired project directory inside the shared folder (e.g., cd /mnt/shared/my_flutter_app) in the HiSH terminal. Then run:

  bash

flutter create --platforms ohos .

• This command generates the ohos folder, which acts as a native wrapper for your Flutter code. Critically, this folder is generated inside the shared folder, making it immediately visible to the HarmonyOS file system and DevEco Studio.

Step 3.2: Import Your Existing Flutter Code (Optional)

If you have an existing Flutter project, you can easily migrate it to your HarmonyOS environment.

1. Copy your code: Using the HarmonyOS file manager or the command line inside HiSH, copy your existing lib/ folder, assets/ folder, and pubspec.yaml file into the root of the project you just initialized (the one containing the ohos folder).

2. Merge dependencies: Open your pubspec.yaml file and ensure any OpenHarmony-specific plugins (e.g., flutter_ohos) are added. You may need to add specific git dependencies for plugins that support OpenHarmony.

3. Resolve dependencies: Run flutter pub get in the HiSH terminal, inside your project directory. This downloads your packages and updates the bridge files inside the ohos folder to point to your existing Dart logic.

Phase 4: Signing, Building, and Deployment (Using DevEco Studio)

This phase uses the native DevEco Studio IDE on HarmonyOS to handle the final signing and deployment. Because your project exists in the shared folder, both HiSH and DevEco Studio can access it seamlessly.

Step 4.1: Import the Project into DevEco Studio

• Action: Open DevEco Studio on your HarmonyOS PC. Choose “Open Project” and navigate to the ohos sub-folder inside your Flutter project’s root directory (the one you just created in the shared folder). Click “Open”.

Step 4.2: Perform the “Auto-Signing” Handshake
For the app to run on a real device (your HarmonyOS PC itself counts as a device), it must be signed with a digital certificate.

• Action: In DevEco Studio:

  1. Go to File > Project Structure > Project > Signing Configs.

  2. Check the box for “Automatically Generate Signature”.

  3. Log in with your Huawei Developer account when prompted.

  4. Click “Apply” and then “OK”.

• How it works: The Rust-based IDE will securely communicate with the HarmonyOS kernel to generate the necessary security certificates and profile for your app.

Step 4.3: Build and Run Your Flutter App
You are now ready to see your app in action on your HarmonyOS device.

• Action: In DevEco Studio, click the green “Run” button. Alternatively, you can run the flutter run command inside your project directory in the HiSH terminal.

• The Complete Process Explained:

  1. Compilation: If you click “Run” in DevEco Studio, it will invoke the Flutter toolchain. That toolchain, running inside the HiSH Linux environment, uses the BiSheng JDK to compile your Dart code and build a .hap (HarmonyOS Ability Package) file.

  2. Detection & Signing: DevEco Studio detects the newly built .hap file in the shared project folder. It then applies the auto-generated signature profile to the package.

  3. Deployment & Execution: Finally, DevEco Studio uses the HarmonyOS hdc tool to push the signed .hap file to your connected HarmonyOS PC (or a phone/tablet) and launches the app.

How the Components Work Together in Your Daily Workflow

For a smooth development experience, you will use different tools for different tasks, just as you would on a traditional OS:

• CodeArts IDE (Your Daily Driver for Coding): This is a lightweight, cloud-native inspired IDE (similar to VS Code). You can use it for the “heavy lifting” of writing all your Dart code, managing your project’s folder structure, and editing your UI logic. Since your project lives in the shared folder, CodeArts can open and edit it directly.

• DevEco Studio (The Deployment & Signing Specialist): You will primarily use this IDE for two specific tasks: generating the app’s security signature (once per project) and clicking the “Run” button to deploy the app to your devices. You don’t need to write code inside it.

• HiSH (The Linux Build Environment): This is where you run all Flutter command-line operations: flutter pub get to fetch dependencies, flutter build hap to create a release package, and even flutter run if you prefer the terminal. HiSH provides the essential Unix-like CLI and the complete Linux kernel that the Flutter toolchain requires.

• BiSheng JDK (The Build Engine): This is the essential Java runtime that powers Flutter’s internal build tools, and it must be correctly linked via flutter config --jdk-dir.

By following this corrected guide, you establish a self-contained, native development environment for Flutter on OpenHarmony using HiSH. You can now develop, build, and deploy Flutter applications entirely from your HarmonyOS PC, tablet, or phone, without needing a secondary machine or a virtual machine. This is true native development, following the classic Unix philosophy, on a modern, non-Linux operating system.

Let’s talk about the conclusion first: By this point in 2026, software manufacturers will be interested in the HarmonyOS system (especially HarmonyOS NEXT+/HarmonyOS 6 +The enthusiasm for adaptation has completely shifted from the early wait-and-see to the full speed sprint.

To put it simply, the current HarmonyOS adaptation is no longer a “plus” for manufacturers, but has become a “must-have option”. No one can ignore the hundreds of millions of devices, and the ecosystem of HarmonyOS native applications has crossed the key “life and death line”.

--Now 5kw, estimated to exceed 100 million at the end of the year, not bragging, but the actual situation, Huawei’s mobile phone equipment in 2026 is estimated to return to the king, and several friends in the mobile phone industry are under some pressure. In other words: as an ordinary cattle and horses, one more ecology will not lead to more social employment opportunities, which is definitely good for our cattle and horses, especially the Internet industry.

Comprehensive coverage of core applications: The main apps of leading Internet

manufacturers (such as Tencent, Alibaba, ByteDance, Meituan, etc.) have already completed native adaptation. Applications with 100 million daily active users such as WeChat, Alipay, Douyin, and Xiaohongshu have the same experience as Android/iOS versions, and even have advantages in distributed collaboration (such as cross-device circulation).

Explosion in the number of native applications: As of early 2026, the number of HarmonyOS native applications and cloud services has exceeded 75,000.

Overseas manufacturers take the initiative to enter the game: It is particularly noteworthy that international brands such as Tesla have also taken the initiative to launch native HarmonyOS versions, which marks the recognition of the value of the HarmonyOS ecosystem in the eyes of global developers.

The change in manufacturers’ attitudes is mainly due to the following three driving forces:

Of course, it is not without risk costs, and the maintenance cost of the application side is at least one-third higher than that of an additional set of ecosystems:

The cost of overturning and starting over: HarmonyOS NEXT has been completely

stripped away AOSP+(Android open source project), which means that manufacturers can no longer use Android code to “shell”, they must use it ArkTS+ language and ArkUI + Frameworks rewrite application logic. For large apps with heavy technical debt, this is tantamount to “tearing down and rebuilding”.

Talent premium: In 2024-2025, HarmonyOS development talents were in short supply, resulting in a surge in R&D investment costs in the early stage of adaptation.

Performance tuning: Unlike Android, manufacturers need to spend a lot of energy to deeply optimize the HarmonyOS base to achieve Huawei’s claimed “fluency improvement”.

4. Conclusion and insight

The current situation is: large factories are rolling performance, and small factories are catching up with the progress.

If two years ago, adapting to HarmonyOS still needed Huawei to “seek” manufacturers, then the current situation in 2026 is that manufacturers are queuing up to squeeze into Huawei’s developer support plan. For Internet veterans like you, HarmonyOS is no longer an “alternative system”, but a new growth pole with independent distribution logic and independent technology stack.

Source: Are software manufacturers highly motivated to adapt to the HarmonyOS system? - Did you know?

OpenHarmony — the open-source distributed operating system donated by Huawei to the OpenAtom Foundation — powers HarmonyOS NEXT versions of HarmonyOS 5 and current HarmonyOS 6, Huawei’s fully independent (no Android compatibility) OS. It’s already running on tens of millions of devices in China, with over 10 million registered developers and more than 350,000 apps/meta-services in its ecosystem as of early 2026 with 47.2 million users as 1st of March 2026. The open-source base has surpassed 1.2 billion smart devices across scenarios (phones, tablets, IoT, wearables, automotive, PCs and more). But the real game-changer for international developers isn’t just the scale — it’s the strategic integration with the world’s dominant front-end framework.

The Power Move: Huawei + React Native + React Foundation

Huawei didn’t just build yet another OS. They partnered deeply with leading React Native experts at Software Mansion (a top-tier Polish firm behind libraries like Reanimated, Gesture Handler, and Screens) to create React Native OpenHarmony (RNOH). This library lets React Native apps run natively on OpenHarmony devices with minimal changes. Key libraries have been ported for smooth performance, and real-world apps (including major Chinese platforms like YY, Xiaohongshu, and Ctrip) are already adopting it.

The collaboration started via projects like Oniro (Eclipse Foundation’s vendor-neutral OpenHarmony implementation) and escalated dramatically. On February 24, 2026, the Linux Foundation announced the formation of the React Foundation, with Meta donating React, React Native, and supporting components (like JSX) to neutral governance. The eight platinum founding members? Amazon, Callstack, Expo, Huawei, Meta, Microsoft, Software Mansion, and Vercel. Huawei explicitly stated their intent: to “deepen synergy” and “foster seamless and native interoperability between OpenHarmony and React technologies. ”This isn’t passive sponsorship, with Software Mansion already embedded from the RNOH work and now at the React Foundation table, Huawei secures influence over React’s future direction — ensuring OpenHarmony becomes a first-class citizen for React/React Native developers.

Why This Matters More Than Fragmented Linux Mobile Efforts

Traditional open-source mobile Linux projects (Jolla’s Sailfish OS, UBports’ Ubuntu Touch) struggled for years with tiny ecosystems, limited hardware support, and negligible app adoption. They lacked corporate scale, massive funding, and developer mindshare. OpenHarmony/HarmonyOS NEXT is different:

• Industrial backing — Huawei invests heavily, ships billions of devices globally, and partners aggressively.

• Massive momentum in China — Already the #2 mobile OS there (surpassing iOS in share at times), with plans for international expansion in 2026 (smartphones, tablets, PCs, wearables, cars, TVs, smart things etc.).

• Distributed, multi-device architecture — Designed for seamless experiences across phones, IoT, cars, TVs — a true “all-scenario” OS where React Native’s cross-platform strengths shine.

• Low-friction entry for devs — If you’re already using React Native, targeting OpenHarmony could mean code reuse with little extra effort. No need to learn entirely new stacks like ArkTS/Cangjie/ArkUI (though those remain options for native performance).

Huawei aims for global push in 2026, including potential stock HarmonyOS smartphones in markets like Europe among other parts of the world. The app gap is closing fast via tools like RNOH. Why Global Developers Should Pay Attention Now

1. Early-mover advantage — The ecosystem is young outside China. Being among the first to build/productionize React Native apps for OpenHarmony positions you as an expert in a rising platform with less competition.

2. Huge addressable market — Hundreds of millions (potentially billions) of devices long-term, especially in emerging markets and non-Google/Apple ecosystems.

3. Diversification beyond the duopoly — Android/iOS dominance is real, but geopolitical shifts, privacy concerns, and multi-device needs create openings for third paths. OpenHarmony offers one backed by real volume.

4. React ecosystem boost — With Huawei’s platinum role in the React Foundation, expect more official tools, docs, and community focus on OpenHarmony support — making it easier over time.

5. Innovation in distributed apps — Build once, deploy across form factors with native feel — a sweet spot for React Native devs eyeing IoT, wearables, or automotive.

The fragmented GNU/Linux mobile crowd couldn’t break through at scale. Huawei is taking a pragmatic, industry-backed approach — partnering with React giants to bootstrap adoption. If you’re a React/React Native developer, 2026 is the year to at least experiment: check out RNOH, explore DevEco Studio (Huawei’s IDE), and target OpenHarmony devices. The third major mobile/IoT platform might be arriving faster than expected — and React could be its on-ramp. What do you think — will OpenHarmony crack the global app developer barrier? Drop your thoughts below.

Please note that this article was written 173 days ago and last modified 171 days ago, and some of the information may be outdated.

Preface

I wrote an article on “Building a Flutter App for HarmonyOS NEXT / OpenHarmony with Fastforge”

But as a lazy dog, I suddenly thought that I had to upload it to the App Store - App Gallery after I finished building, which was still a bit troublesome.

Then I found out that App Gallery supports uploading built apps through the Publishing API, so I added support for uploading to App Gallery to Fastforge.

The PR has been merged and published in Releases0.6.5

Fastforge | Make your app distribution with ease.

How to use:

1. Create a Connect API client

Create an API client and get client_id and client_secret according to the documentation Create an AppGallery Connect API Client, as shown below

2025-08-25T10:48:26.png

2. Install Fastforge

You can refer to the installation tutorial in the previous article

Build Flutter apps for HarmonyOS NEXT / OpenHarmony with Fastforge

3. Instructions for use

Expose the client id and client secret of the Connect API in your environment

export APP_GALLERY_CLIENT_ID="your client id"
export APP_GALLERY_CLIENT_SECRET="your client secret"

Then execute the following command in the project to upload it to the App Gallery; where is the app in the App Gallery app-idAPP ID

fastforge publish \
  --path dist/1.0.0+1/hello_world-1.0.0+1-ohos.app \
  --targets appgallery \
  --appgallery-app-id <app-id>

--appgallery-app-id Pass the parameters to the publisher. You can also configure the same in (see example below).app-iddistribute_options.yamlapp-id

As mentioned above, you can actually build an app first and then upload it, you can refer to the following configuration to quickly build and upload it to the App Gallery.

output: dist/
variables:
  FLUTTER_ROOT: ./.fvm/flutter_sdk # 由于我项目使用 FVM 托管 SDK
  APP_GALLERY_CLIENT_ID: 'your client id'
  APP_GALLERY_CLIENT_SECRET: 'your client secret'
releases:
  - name: ohos-release
    jobs:
      - name: release-ohos-app
        package:
          platform: ohos
          # 应用市场仅支持 'app' 格式
          target: app
          build_args:
            # 可选，默认为 default, 对应 ohos 中的 product name
            flavor: release
        publish:
          target: appgallery
          args:
            # 应用在 AppGallery Connect 上的 APP ID
            app-id: 'your app id'

4. Presentation

If you don’t have a global Dart/Flutter environment, temporarily use the DART from the FVM Flutter SDK in your project

$env:PATH += ";$PWD\.fvm\flutter_sdk\bin" # Windows(powershell)
export PATH=$PATH:$PWD/.fvm/flutter_sdk/bin # Linux / macOS

Suppose a configuration item named releases is configured in the Executiondistribute_options.yamlohos-release

fastforge release --name ohos-release --skip-clean

2025-08-25T11:46:18.png

Open the App Gallery Connect platform and you will see that the app package has been uploaded

Source: Use Fastforge to automatically build and publish OHOS Flutter Apps to App Gallery - Night Glass Stack

Porting a web engine to a new platform is a deep dive into the platform’s inner workings—application lifecycle, scheduling, event handling, sandboxing, graphics, and media stacks. OpenHarmony, with its unique architecture and public SDK, presents both challenges and opportunities for bringing Mozilla’s Gecko engine to the ecosystem. While Jani Hautakangas’ WebKit for OpenHarmony used Cerbero and WPE, this guide focuses on leveraging Mozilla’s own build system, mach, for a Gecko port.

Why Gecko on OpenHarmony?

OpenHarmony’s default WebView is Chromium-based and not easily buildable from the public SDK. A Gecko port would offer an alternative, open-source rendering engine for developers, enabling greater flexibility and alignment with Mozilla’s web standards. The goal: compile and run Gecko (e.g., libxul) on OpenHarmony using only the public SDK, targeting available development boards and the emulator.

What Does It Take to Port Gecko?

Gecko is not a monolith. It relies on a chain of libraries (NSPR, NSS, ICU, etc.) and platform abstractions. Before integrating with OpenHarmony, you must:

1. Cross-compile Gecko’s dependencies for OpenHarmony’s toolchain.

2. Patch the build system to recognize OpenHarmony as a target platform.

3. Implement platform-specific abstractions (e.g., graphics, IPC, event loops).

4. Integrate with OpenHarmony’s ArkTS runtime for application lifecycle and UI.

Unlike WebKit’s WPE port, Gecko uses mach for build orchestration. This means adapting mozconfig and the build backend to use OpenHarmony’s LLVM/Clang toolchain, sysroot, and SDK.

Building Gecko Dependencies

1. Toolchain Setup

OpenHarmony’s toolchain is LLVM/Clang-based, typically found at:

Copy

//prebuilts/clang/ohos/linux-x86_64/llvm/bin/clang

Ensure this is in your PATH or referenced in your build configuration. The OpenHarmony SDK provides the necessary headers, libraries, and sysroot for cross-compilation.

2. Patching Build Systems

Gecko’s dependencies (e.g., NSPR, NSS) use Autotools or CMake. You’ll need to:

• Patch configure scripts to recognize OpenHarmony as a platform.

• Adjust compiler/linker flags for OpenHarmony’s sysroot and toolchain.

• Ensure shared libraries are unversioned (OpenHarmony does not support versioned .so files).

For example, a patch for NSPR’s configure might look like:

diff

Copy

--- a/configure
+++ b/configure
@@ -1234,6 +1234,9 @@ case "$target_os" in
;;
esac

+openharmony*)
+ OS_TARGET=OpenHarmony
+ ;;
*)
AC_MSG_ERROR([Unsupported target OS: $target_os])
;;

3. Cross-Compiling with mach

Use a custom mozconfig to specify the target platform and toolchain. Example for ARM64:

ini

Copy

# mozconfig for OpenHarmony (ARM64)
ac_add_options --target=aarch64-unknown-linux-ohos
ac_add_options --host=aarch64-unknown-linux-ohos
ac_add_options --with-ccache
ac_add_options --enable-application=libxul
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --with-clang-path=/path/to/openharmony/prebuilts/clang/ohos/linux-x86_64/llvm/bin/clang
ac_add_options --with-sysroot=/path/to/openharmony/prebuilts/ndk/sysroot

Replace /path/to/openharmony with your SDK path.

Run the build:

bash

Copy

./mach build

Platform Integration

1. Graphics and Buffer Sharing

Gecko’s WebRender or basic software rasterizer must integrate with OpenHarmony’s graphics stack. For GPU acceleration, you’ll need to share GPU buffers between processes. OpenHarmony uses OH_NativeBuffer, similar to Android’s AHardwareBuffer.

Key Challenge: The public OpenHarmony SDK lacks APIs for sending OH_NativeBuffer handles over sockets. You may need to implement a custom solution (e.g., native_buffer_socket) to enable this, as done in the WebKit port.

2. Event Loop and ArkTS Integration

OpenHarmony applications run in the ArkTS runtime, which supports ArkTS, TypeScript, and JavaScript. To embed Gecko:

• Implement a platform-specific widget backend for Gecko, similar to Android’s ANativeWindow or GTK’s GtkWidget.

• Create a glue layer to connect Gecko’s native side with ArkTS, handling events and lifecycle callbacks.

For now, you might run Gecko on its own thread, but deeper integration with ArkTS’s event loop is ideal.

Current Status and Next Steps

What Works

• Gecko dependencies cross-compile for OpenHarmony.

• Minimal libxul builds and links.

• Basic platform abstractions (e.g., logging, threading).

What’s Missing

• GPU-accelerated rendering (OH_NativeBuffer sharing).

• WebGL and media playback.

• Full ArkTS integration (event loop, lifecycle).

• Platform features (Bluetooth, Location, etc.).

Try It Yourself

The process is early-stage, but you can start experimenting:

1. Set up the OpenHarmony SDK.

2. Clone Gecko and apply the patches for OpenHarmony support.

3. Use the sample mozconfig above and run ./mach build.

For inspiration, see:

• WebKit for OpenHarmony

• Servo for OpenHarmony

Conclusion

Porting Gecko to OpenHarmony is a challenging but rewarding project. By leveraging mach and OpenHarmony’s public SDK, you can bring Mozilla’s engine to a new ecosystem—enabling open web standards and greater flexibility for developers. The groundwork laid by WebKit and Servo ports provides a roadmap, but Gecko’s unique architecture and build system require tailored solutions.

Next Steps: Would you like a deeper dive into patching Gecko’s graphics backend for OH_NativeBuffer, or are you more interested in the ArkTS integration layer? Let’s build this together!

OpenHarmony is an operating system designed for all-scenario, general terminal devices, and the strength of device memory performance directly affects user experience. Memory varies greatly among terminal devices. For devices with relatively small memory, memory optimization solutions are undoubtedly key to enhancing memory performance and improving user experience. To address the shortcomings of traditional memory solutions and management mechanisms, OpenHarmony has built a comprehensive memory solution—ESWAP.

1. Traditional memory solutions and management mechanisms

In traditional Linux memory optimization solutions, terminal devices typically use SWAP and ZRAM memory solutions.

1.1 SWAP

SWAP stands for Memory Swap technology or virtual memory technology. As shown in Figure 1, when the system’s physical memory is insufficient, it frees up a portion of the unused memory space to increase the system’s available memory for the currently running program. This freed data is temporarily saved to the SWAP partition, and when needed, it is restored from the swap partition to memory.

From Figure 1, it is clear that SWAP memory swapping technology increases the device’s internal memory, but swapping in and out of SWAP memory encounters IO performance bottlenecks, which in severe cases can affect user experience, and frequent read/write of flash memory devices also shortens their lifespan.

1.2 ZRAM

ZRAM is a memory compression technology. As shown in Figure 2, when the system’s physical memory is insufficient, a portion of the system’s physical memory is partitioned as ZRAM, and unused anonymous pages are compressed and placed in the ZRAM partition. This essentially sacrifices some CPU efficiency to increase the system’s available memory for running programs. When needed, extract the data from the ZRAM partition.

Figure 2: ZRAM memory compression technology

Although ZRAM increases the device’s internal memory to some extent, without proper memory management, the negative impact can be very obvious, causing frequent compression/decompression of memory pages, which takes up CPU time during normal business and increases system power consumption. Moreover, if the compression/decompression speed is not fast enough, it will directly affect the user experience.

1.3 Memory Management Mechanism

In addition to insufficient memory solutions, traditional memory allocation and management methods fail to recognize business characteristics and the importance of data. If multiple processes or services on a terminal device share a single memory block, as memory load increases and memory data collection is performed, frequent data migration and memory oscillations occur. These phenomena increase the overhead of kernel memory management and cause the system CPU to remain under high load for extended periods, thereby increasing system power consumption.

2. OpenHarmony memory solution

To address the shortcomings of existing memory solutions, OpenHarmony has built a comprehensive memory solution called ESWAP, which connects the upper-layer system to the kernel call stack, allowing the kernel to manage each memory block rationally under the guidance of upper-layer configuration.

Below, we will introduce the ESWAP solution and analyze its key technologies.

2.1 Introduction to the ESWAP Solution

ESWAP (Enhanced SWAP) is a comprehensive memory solution provided by OpenHarmony for memory optimization issues. It combines memory compression and memory swapping technologies, customizing a reasonable and efficient scheduling management strategy to make compression and swapping work efficient and balanced. ESWAP uses correlated data aggregation technology and upper-level guidance strategies to divide memory into different groups for management. By prioritizing recycling, it distinguishes memory activity levels under different groups, prioritizing compression and swapping out less active memory data to improve data exchange performance and reduce lifespan impact.

The overall framework of the ESWAP solution is shown in Figure 3:

Figure 3: ESWAP solution

The ESWAP solution adds a system resource scheduling module to the global resource scheduling subsystem. By subscribing changes to local accounts to the account subsystem, it senses the current account status and memory status. Then, based on the account status, it sets different recycling priorities, target available memory amounts, and compression and swap-out ratios for each account, sending these parameters to ZSWAPD. ZSWAPD determines the order of recycling based on the retrieval priority; The amount to be recovered is determined based on the difference between the target available memory and the current available memory; The amount of compression and swapping out is determined based on the ratio of compression to swapping, thereby achieving a balance of performance and power consumption while achieving memory expansion.

2.2 Key Technology Analysis

What key technologies does ESWAP’s memory solution use? Let me explain them one by one for you.

2.2.1 Customized ZRAM and Switching Partitions

ESWAP combines memory compression and memory swapping technologies, providing the ability to customize new storage partitions as memory swap partitions. It also creates a resident process in the kernel called ZSWAPD, which encrypts anonymous pages compressed from ZRAM and swaps them into ESWAP storage partitions, thereby completely freeing up a usable memory block to maintain the Memavailable waterline, as shown in Figure 4.

Figure 4: ESWAP technology

At the same time, the ESWAP module can record the hot and cold feature information of each anonymous page and store this data in correlation and hot and cold order, ensuring that anonymous pages stored continuously in the ESWAP exchange area have temporal and spatial locality. Therefore, when swapping anonymous pages, adjacent anonymous pages in the swap area can also be read into ZRAM to ensure data access speed and improve IO performance.

2.2.2 Dynamic Memory Recycling Mechanism

OpenHarmony provides an additional memory recycling mechanism called ZSWAPD and creates a “buffer” as an indicator to measure the current system’s memory capacity. A buffer refers to the maximum available memory that the current system can provide. ZSWAPD compresses anonymous pages based on the buffer amount and the various strategies described above to collect them. At the same time, ZSWAPD can dynamically balance ZRAM and ESWAP based on the rationality of memory hot and cold separation and memory recycling status, thereby achieving higher energy efficiency.

2.2.3 Flexible memory recovery strategies

OpenHarmony has enhanced its recycling strategy based on Memcg grouping, using recycling priorities to guide the order of ZSWAPD collections. The recycling strategy assigns the established buffer-related configuration to ZSWAPD to guide it in recovering the appropriate amount of memory. Additionally, since anonymous pages may be stored in RAM, ZRAM, and ESWAP modules, the upper layer can flexibly configure swap strategies as needed to control the storage ratio in these modules and avoid the negative impact of frequent swapping in and out.

That concludes the introduction to ESWAP’s three key technologies. Let’s summarize:

● Customized ZRAM and switching partitions: Data is stored in association and hot and cold sequential order, ensuring fast data access and improving IO performance.

● Dynamic memory recycling mechanism: Dynamically controls data collection from three dimensions: recycling priority, available memory volume, compression, and swap ratios to achieve higher energy efficiency.

● Flexible memory recycling strategy: Flexibly controls the data storage ratio of RAM, ZRAM, and ESWAP modules to ensure balance among modules.

2.3 ESWAP-related interfaces

The ESWAP solution allows system developers to customize their own recycling strategies and provides interfaces under /dev/memcg that are only visible to the upper-layer recycling policies. System developers can use these interfaces to customize their upper-level policies. The specific interfaces are as follows:

That’s all for this article. The ESWAP solution is still under construction, and we look forward to developers joining us to witness the infinite possibilities of the all-scenario intelligent era together!

作者：码量与发量对等
链接：https://juejin.cn/post/7395018314564157491
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Original article: OpenHarmony构建新的内存管理优化方案OpenHarmony是面向全场景泛终端设备的操作系统，终端设备内存性能的 - 掘金 (24th July 2024)

Open source Hongmeng cross-platform ecology ushered in a major breakthrough! From Kotlin to Flutter, from React Native to Electron, developers can migrate Android/iOS/Web to full-scenario devices at zero cost. This article will explain the core capabilities and application scenarios of each technology stack to help you quickly select and efficiently land.

With the rapid maturity of the open source OpenHarmony ecosystem, cross-platform development has become a mainstream solution for multi-terminal deployment. The SIG group of open source Hongmeng cross-platform framework has completed the deep adaptation of KMP, Cordova, React Native, Flutter, Ionic, Chromium, Electron, Qt and other mainstream technology stacks, so that Android/iOS/Web/desktop applications can migrate to the full-scenario devices in Hongmeng.

Based on the official warehouse of atomgit, this article systematically combs through the 9 major cross-platform SIG core capabilities, applicable scenarios and technical highlights to help you quickly select and efficiently land Hongmeng applications.

KMP‐CMP: Kotlin Multi-platform native base

Warehouse address: https://atomgit.com/CPF-KMP-CMP-CMP

Positioning: Kotlin Multiplatform Hongmeng native adaptation, the main shared business logic, native rendering

Core competencies

• Hongmeng KMP tool chain plug-in: support engineering creation, construction, operation, commissioning full link

• Basic library matrix: kotlinx‐crypto, SQLiter, sqldelight, Kermit, etc.

• Lightweight DI:Koin Cross-Platform Dependency Injection

Technical highlights

• Natural fusion with Hongmeng ArkUI, performance close to pure native

• Once written, Android/iOS/Hung-Mongolian Tri-Terminated Shared Logic

Suitable for scenarios: Android/Kotlin native team, financial/tools-type strong logic applications

Cordova: Web Hybrid Application Extremely Fast Migration

Warehouse address: https://atomgit.com/CPF-Cordova

Location: Apache Cordova official SIG, Web hybrid application zero-code migration scheme

Core competencies

• One-click generation of Hongmeng native APP, the original Android/iOS project to complete the migration in a few minutes

• Full plug-in ecology: files, cameras, gyroscopes, batteries, navigation bar, scan code, positioning, etc.

• Command-line tool hcordova: engineering management, compilation, and operation

Technical highlights

• Fully compliant with official interfaces with no additional learning costs

• Low/zero code migration for significant workforce savings

Suitable for the scene: H5 mixed application, information display class, low threshold fast on-line project

OpenHarmony‐RN: React Native High Performance Adaption

Warehouse address: https://atomgit.com/OpenHarmony-RN

Location: React Native Hongmeng system-level rendering backend, RN ecological integrity landing

Core competencies

• Full Fabric new architecture support, Hermes engine optimization

• Deep integration ArkUI NDK, performance close to native

• Version Matrix: 0.72 LTS / 0.77 LTS / 0.82 Stable / 0.84 Preview

NPM package: @react‐native‐oh/react‐native‐harmony

Technical highlights

• Reuse RN Ecology and Development Habits

• Dynamic capability, thermal update support

Suitable for scenarios: React technology stack, strong demand for dynamic, e-commerce / social applications

OpenHarmony‐Flutter: Eco-compatible self-drawn engine

Warehouse address: https://atomgit.com/OpenHarmony-flutter

Positioning: Flutter SDK/Engine official adaptation, Dart cross-end preferred

Core competencies

• Full Flutter engine port, self-drawn UI unfit loss

• A large number of official plugins have been adapted: image_picker, camera, webview_flutter, shared_preferences, path_provider, etc. 30+

• Multi-version support: 3.7 / 3.22 / 3.27 / 3.35/3.41

Technical highlights

• Pure Dart library without modification, direct reuse

• Consistent UI, high performance, cross-device fluency full

For scenarios: Flutter team, strong interaction/animation/cross-device consistency applications

CPF‐Ionic: Capacitor Cross-End Migration Exclusive

Warehouse address: https://atomgit.com/CPF-Ionic

Positioning: based on Cordova, focusing on Ionic + Capacitor

Core competencies

• Core framework: openHarmony-capacitor + capacitor-cli

• Capacitor official plugins full coverage: app, camera, device, filesystem, geolocation, network, status‐bar, etc.

• Ionic Native plugins are suitable for: file, camera, clipboard, network, etc.

Technical highlights

• Aligning the Capacitor interface for painless migration

• For web front-end/hybrid application developers

Suitable for scenarios: Ionic/Capacitor existing projects, PWA migration to Hongmeng

CPF‐Chromium: Browser and Rendering Kernel Support

Warehouse address: https://atomgit.com/CPF-Chromium

Positioning: Hongmeng Platform Chromium Kernel and Graphics Rendering Infrastructure

Core projects

chromium, angle, dawn, skia, ffmpeg, webrtc, pdfium

Value

• Provides the underlying capabilities for WebView, browser, video, and Canvas rendering

• Web/graphics/sound and video infrastructure supporting cross-platform frameworks

Suitable for scenarios: browser, video player, graphics rendering, web engine secondary development

CPF‐ApplicationTPC: A collection of general-purpose three-party libraries

Warehouse address: https://atomgit.com/CPF-ApplicationTPC

Positioning: Hongmeng general three-party library hosting, complementing tools/components/network/storage/media capabilities

Representative projects

• ohos_vlc: Media playback core library

• ohos_ksoap2: SOAP Network Communication

• ohos_logan: front-end log collection analysis

• ohos_onnxruntime: A framework for machine learning inference

• View animations, status bars, APNG renderings, calendar components, and more

Value: quickly complement the common ecological components of Hongmeng, reduce the repeated wheel

Suitable for scenarios: all Hongmeng applications, fast integration of basic capabilities

CPF-Electron: Cross-Platform portal for desktop applications

Warehouse address: https://atomgit.com/CPF-Electron

Positioning: Electron Hongmeng desktop adaptation, Web technology stack development PC applications

Core Values

• Multiplex Web stack to build Hongmeng desktop native applications

• Support for windows, menus, system trays, local files and other desktop capabilities

Scenario: desktop tools, client software, existing Electron project migration

CPF‐qt: C++ High Performance Desktop/Embedded Solutions

Warehouse address: https://atomgit.com/CPF-qt

Positioning: Qt official Hongmeng adaptation, C++ high-performance graphical interface framework

Core Values

• Mature stable, strong rendering, low latency, suitable for industrial/embedded/desktop

• The longest cross-platform history and extremely perfect ecology

Suitable for scenarios: industrial software, desktop tools, in-vehicle, embedded, high-performance graphics applications

Cross-Platform Framework Selection Quick Checker (2026 Latest)

Summary and recommendations

OpenHarmony Cross-Platform SIG has formed a full coverage, multi-technology stack, low-threshold migration system:

• Web Front End → Priority RN / Cordova / Ionic

• Mobile Native → Priority KMP / Flutter

• Desktop/Embedded → Priority Electron / Qt

• Basic Capability Complements → Direct ApplicationTPC Tripartite Library

All frameworks follow the open source specification, continue to iterate, and are the best path to the existing application.

Collaborate with global open source Eclipse Oniro project here:

https://oniroproject.org/

Original (CN) source

Project Warehouse:

• Air series software

• Harmony-krita / AirDraw

• Harmony-Audacity / AirAudio

I personally pay close attention to the porting of Qt/KDE apps to HarmonyOS, so this time I mainly tried Krita and Audacity.

My testing equipment

Currently, two devices are used for testing:

• Huawei MateBook Pro（2-in-1 / PC）

• Huawei MatePad Pro Max（Tablet）

These two devices represent typical PC and tablet usage scenarios and are also suitable for observing the actual experience of desktop applications on HarmonyOS.

Harmony-krita / AirDraw

Harmony-Krita was completed relatively early, around mid-August.

In actual use, I have basically encountered no obvious problems for about two consecutive weeks. What impressed me most was that both the fingers and stylus could draw normally, making the overall user experience quite complete.

Judging from the code and project structure, this version should be based on Qt 5’s Krita.

KDE ECM handling methods

Krita itself is a large application within the KDE ecosystem, so a key issue to watch when porting Krita is:

How is KDE Extra CMake Modules (ECM) handled?

Upstream ECM:

https://github.com/KDE/extra-cmake-modules

So far, I haven’t found a clear ECM approach in Harmony-krita.

Currently, the Harmony-krita repository has only two commits:

1. The first commit: the main code, imported content, and modifications are basically concentrated here.

2. Second commit: mainly modifying the README.

In other words, the core porting work is basically all placed in the first commit.

This approach is relatively straightforward for quickly completing a single port, but from the perspective of subsequent maintenance and upstream review, it is harder to trace the history.

I refreshed the submission history

So, I compared Krita’s upstream warehouse:

https://invent.kde.org/graphics/krita

Then I reorganized the Harmony-Krita submission history, hoping to to:

• Upstream code

• HarmonyOS related modifications

• Build related modifications

The relationship between them becomes clearer.

The new submission history is located at:

https://github.com/liangqi/krita/commits/Harmony-krita/

Currently, I haven’t finished local compilation for this version, and further verification is needed.

However, from a code organization perspective, this approach should be more conducive to subsequent analysis and maintenance, and is closer to the upstream + patch development model commonly used in open source projects.

Harmony-Audacity / AirAudio

Harmony-Audacity was completed around August 25.

I conducted actual tests on the equipment, and the overall situation was a bit more advanced than simply “being able to start.”

The first launch question

The first time you open the app, there is no prompt prompt immediately asking “Do you want to allow the app to use the microphone?”

At the same time, the app also feels somewhat stuttering.

At that time, the application appeared to have not been fully initialized.

My approach is:

1. End the application process;

2. Restart;

3. This time, a microphone permission request appeared;

4. After allowing microphone permissions, recording and playback functions can work properly.

So at present, it seems there may still be some issues with permission initialization during the first startup.

Tablet mode

There is still a relatively obvious problem with tablet devices:

The app cannot be fullscreen.

For desktop apps like Audacity, the window size and display on tablets are still areas worth further optimization.

The technology stack behind Audacity

From the code perspective, Audacity involves many professional third-party libraries in the audio field.

Among these, the following are particularly noteworthy:

• PortAudio

• and other audio processing dependencies

This makes me feel that HarmonyOS’s support for desktop software is no longer just a simple GUI porting issue.

For an application to truly run, it actually means the following infrastructure must gradually be established:

Desktop Applications

│

├── GUI Framework

│ └── wxWidgets / Qt

│

├── Audio Framework

│ └── PortAudio

│

├── Codec / DSP Libraries

│

├── File / Thread / Network

│

└── HarmonyOS Platform

Especially for low-level libraries like PortAudio, if they can already work properly on HarmonyOS, it will be very valuable for future porting of more professional desktop software.

Additionally, Audacity 3.7.8 uses wxWidgets.

This itself is a very interesting signal:

If Audacity can basically run on HarmonyOS, it means that the wxWidgets layer is already somewhat feasible on HarmonyOS.

Therefore, in the future, it may not only be Qt/KDE applications; other traditional Linux/Windows desktop application frameworks may also have opportunities to gradually enter HarmonyOS.

Looking at the code repository, Audacity goes a step further than Krita

If you look purely at “whether the app can run,” both Krita and Audacity have made good progress.

But from the perspective of the code repository itself, I think Harmony-Audacity has made clear progress over Harmony-krita.

Harmony-Audacity has recorded the following content more comprehensively:

• Upstream code sources

• HarmonyOS patch

• Build the script

• The construction process

• Third-party dependency

In other words, it’s not just about “compiling the software,” but starting to record step by step:

How this software is built from upstream source into a HarmonyOS application.

This is very important for subsequent maintenance.

Especially for third-party libraries, a fairly unified approach has now emerged.

This could become a very important step in the future migration of HarmonyOS desktop software.

From Krita to Audacity, a change can be observed

Looking at these two projects together, you can actually spot an interesting trend.

Harmony-Krita is more like an early quick port:

上游代码

↓

引入 HarmonyOS 修改

↓

完成构建和运行

Meanwhile, Harmony-Audacity began to pay more attention:

Upstream

│

├── Source

│

├── Patch

│

├── Build Script

│

└── Third-party Dependencies

│

↓

HarmonyOS Build

This means the project focus is shifting from:

“Can I run?”

Gradually shifting to:

“How to Maintain and Build Properly”

For large desktop open-source software, the latter is actually even more important.

Because the real difficulty is often not getting the program running for the first time, but rather the following:

• How to track upstream;

• How to maintain the HarmonyOS patch;

• How to resolve third-party dependencies;

• How to make the build process repeatable;

• How to continuously synchronize with new versions;

• How to ultimately contribute changes back to the upstream.

I’m quite looking forward to the next step

From my own interests, what I should continue to focus on is the ecosystem issue of Qt/KDE applications on HarmonyOS.

For example, Krita is just one example.

If Qt, KDE Frameworks, ECM, and common third-party libraries gradually establish stable HarmonyOS support, then theoretically, more KDE/Qt desktop applications may enter HarmonyOS in the future.

Projects like Audacity offer another path:

Besides Qt, traditional desktop application frameworks + third-party libraries in specialized fields are also starting to be portable.

If these two paths continue to develop, the open-source desktop application ecosystem on HarmonyOS will be more meaningful than simply porting a few GUI applications.

Summary

This time, I mainly experienced two activities:

ProjectSoftwareApproximate completion timeMain frameworkCurrent experienceHarmony-kritaKrita / AirDrawMid-AugustQt 5 / KDEFinger and stylus drawing is basically normalHarmony-AudacityAudacity / AirAudioAround August 25wxWidgetsRecording and playback are basically usable

Personally, I think what deserves attention right now is not “a certain app has already started,” but the changes behind it:

Porting open-source desktop software on HarmonyOS is gradually evolving from one-time code modifications to a systematic approach of upstreams, patches, build scripts, and third-party dependency management.

Especially as third-party libraries begin to adopt unified processing approaches, this may become an important foundation for large-scale migration of Qt, KDE, and other desktop applications in the future.

For me, this was also the most interesting part of this test.

Related links

• Air series software

• Harmony-krita / AirDraw

• Harmony-Audacity / AirAudio

• Krita upstream

• KDE Extra CMake Modules

• Refreshed Krita Harmony-Krita branch

Credit: Experience the Air series software on HarmonyOS devices: Krita and Audacity’s Qt/KDE observations | Enjoy Life! – Liang Qi

OpenHarmony ecology ushered in a heavy weapon! Harmonybrew, as an open source package manager, is the perfect port for Homebrew mature system, providing out-of-the-box command line solutions for all-scenario devices in HarmonyOS. It not only retains the native operation logic to reduce learning costs, but also achieves 60% Homebrew formula is directly compatible, and completely solves the pain point of ecological incompleteness of domestic tools. This article explains in detail its installation and configuration process and technical advantages, and reveals how to make up for the development of the short board through the power of open source.

I. Preface

After a year of polishing, the Harmonybrew open source project is officially launched!

Harmonybrew is a Homebrew port for the OpenHarmony platform, designed to provide out-of-the-box, simple and efficient package manager and supporting software repositories for all-scenario devices in Hongmeng. The project is fully adapted to the HarmonyOS PC, OpenHarmony development board, HarmonyOS/OpenHarmony container and other HarmonyOS/OpenHarmony device forms, complementing the core shortcomings of the OpenHarmony command-line ecology.

Open source community address: https://atomgit.com/Harmonybrew

Second, the quick start tutorial (Hongmeng PC HiShell environment)

This article takes the HarmonyOS PC HiShell environment as an example, organizes the complete installation and configuration process, and the steps are simple and the whole process is deployed one-click.

2.1 Uninstalling conflict software

If the two software GitNext and DevBox are installed on the device, they need to be uninstalled in advance to avoid environmental conflicts and cause installation failure.

2.2 Open system security and developer privileges

To ensure the normal installation and operation of Harmonybrew, two system permissions need to be opened:

1. Open the developer option: Settings → System → Developer Options, turn on the developer switch;

2. Allow non-app market expansion: Set up → Privacy and Security → Advanced, open “Run extensions from non-app markets.”

2.3 One-click installation of Harmonybrew

Open the terminal and execute the following official installation commands to automatically complete the full set of deployments:

zsh -c “$(curl -fsSL https://harmonybrew.atomgit.com/install.sh)”

2.4 Configuring environment variables

After the installation is complete, follow the script prompt to execute the following command to write the brew tool to the system environment variable, which takes effect globally:

echo >> ~/.zshrc

After the configuration is complete, you can use the full set of brew commands directly at any terminal to manage the package normally.

III. Core characteristics of the project

3.1 Refuse ineffective self-research and reuse the mature ecology of the industry

In the early days of the project, we abandoned the ineffective development idea of “self-research for self-research”, not repeated the wheel, but directly ported the industry’s most mature and widely used Homebrew package manager system.

For a long time, many domestic tools have problems such as poor logic, ecological disability, and poor adaptability, which has greatly improved the threshold for developers to use. Harmonybrew perfectly retains the operation logic of the native Homebrew, and developers do not need to learn new instructions and follow the original usage habits to effectively manage packages on the HarmonyOS device.

The ecological advantages are even more prominent: the project is directly compatible with most Homebrew software recipes, and more than 60% of the Homebrew formula can be compiled, tested and run directly on the Harmonybrew pipeline, without the need to adapt to the HarmonyOS platform separately, and the OpenHarmony command-line software ecosystem is expanded at a speed.

3.2 Deeply plowing open source OpenHarmony, full equipment form adaptation

Unlike most of the HarmonyOS commercial-focused HarmonyOS tool projects, Harmonybrew has made it the highest priority adaptation platform for Tier 1 with OpenHarmony as the core.

The design of the architecture allows the project to completely break away from the hardware manufacturer binding, not only to adapt to the HarmonyOS PC, but also to fully compatible with the OpenHarmony development board (dayu200 rk3568), Hongmeng container (DockerHarmony) and other device forms. Among them, the development board and container environment are the highest level of support, the system restrictions are small, the compatibility is optimal.

Developers can use the open environment such as development boards and containers to complete the development, debugging, and problem investigation work, greatly reducing the threshold of hardware adaptation, and improving the development and troubleshooting efficiency.

Additional Notes: HarmonyOS, as an OpenHarmony commercial distribution, is compatible with this project, but due to system security policy restrictions, the functions of the HarmonyOS PC HiShell environment are slightly limited, which is a system-native restriction and non-project adaptation problems.

3.3 Massive software packages, continuous high-speed iterative updates

At present, the Harmonybrew software warehouse has included 2000+ commonly used software packages, and continues to add and update at hundreds of daily speeds, covering the development, compilation, operation and maintenance, debugging and other full-scenario requirements.

Developers can view the list of all packages through the brew formulae command, the core categories are as follows:

✅ Compiler/interpreter

ohos-sdk, Node.js (22/24/26), OpenJDK (17/21/25), Python (3.12/3.13/3.14), Go, Rust, Perl, Ruby

✅ Build tools

Make, CMake, Ninja, Meson, m4, autotools (autoconf, automake, libtool)

✅ Database services

PostgreSQL, MariaDB, Redis

GNU Basic Toolset

Coreutils, Diffutils, Grep, Gawk, Gnu-tar, Gzip

✅ Commonly used development tools

Git, Strace, Patchelf, Vim, JQ3.4 are not only tools, but also the learning ground for Hongmeng developers

Harmonybrew is worth much more than a set of package managers.

All scripts, documents, and adaptation cases in the open source community of the project are written in accordance with the OpenHarmony live-action teaching standards, which not only serves the package management function, but also serves as a free learning material for new developers to get started with Hongmeng Ecology and enhance practical ability.

All technology precipitation, adaptation experience, and pneumatic solutions are all open source, helping more developers to quickly integrate into the OpenHarmony open source ecosystem and reduce the learning and practice threshold of HarmonyOS development.

Commonly used core commands

Follow the native Homebrew simple instructions, hands zero cost:

# Install the Homebrew Edition

5, written at the end.

Harmonybrew has always adhered to the concept of pragmatic open source, reuse mature ecology, service developer, refused to formalize self-research, and focused on filling the command line ecological shortcomings for OpenHarmony.

In the future, the project will continue to expand the number of software packages, optimize the compatibility of the whole device, and improve the open source documents and cases to provide HarmonyOS developers with a more efficient and worry-free development experience. Welcome to the developer experience, Star, Fork, participate in the co-construction, and improve the OpenHarmony open source ecosystem together!

Open source: https://github.com/HarmonybrewGlobal

Reference: https://blog.csdn.net/hqzing/article/details/161371004

This article by everyone is the product manager author [nutpi], WeChat public number: [nutpi], original / authorized published to everyone is a product manager, without permission, prohibited from reprinting.

The diagram is from Unsplash, based on the CC0 protocol.

Source: https://www.woshipm.com/share/6402426.html

Developing on HarmonyOS or OpenHarmony has historically forced a massive compromise. While the system’s native HongMeng Kernel provides slick execution for front-end apps, the command-line ecosystem lacked a unified way to handle backend software. Installing developer essentials, text editors, or database engines often required messy, manual toolchain setups.

That bottleneck is officially gone. Harmonybrew has launched as an open-source, 3rd-party port of macOS’s iconic Homebrew package manager. It is built specifically to download, manage, and execute headless software on HarmonyOS hardware.

What is Headless Software, and Why Do We Need It?

Headless software refers to utilities, daemons, and application binaries that run entirely in the background without a Graphical User Interface (GUI). In a standard developer ecosystem, you use these tools constantly:

• Background Security Engines: Tools like openssl for handling encrypted handshakes.

• Command Line Text Editors: Lightweight text environments like nano or vim for editing configurations.

• Database Cores: Micro-instances of SQL storage engines like sqlite.

Because HarmonyOS lacks a traditional terminal-based software store, installing these packages meant manually compiling raw source code against Huawei’s toolchains. Harmonybrew strips that friction away entirely.

Enter Harmonybrew: Homebrew, Reimagined

Harmonybrew clones the workflow of Homebrew. It handles dependency resolution, downloads source packages, and compiles them so they run natively on the HarmonyOS architecture.

• 60% Native Formula Compatibility: Harmonybrew is built to naturally adapt existing Homebrew scripts, making it immediately compatible with a massive library of developer dependencies.

• 2,000+ Available Packages: The centralized repository already includes thousands of headless developer utilities, operational scripts, and compilation tools.

• Cross-Device Agnostic: It works uniformly whether you are targeting a HarmonyOS PC environment, an open-source development board, or a sandbox container system.

Step-by-Step: Setting Up Your Headless Environment

Ready to start deploying headless tools via your terminal? Follow this quick-start pipeline:

1. Clear Conflicting Systems

If your device is running early emulation packages like GitNext or DevBox, uninstall them to avoid environmental path overlap and installation errors.

2. Elevate System Permissions

To allow Harmonybrew to provision system binaries, unlock the local kernel permissions:

• Open Settings → Your Device e.g. ‘LIH’s MateBook Pro’ for About page → tap on software version to activated Turn on ”Developer Options” dialog prompt.

• Open Settings → Privacy and Security → Advanced and toggle on “Run extensions from non-app markets”.

3. One-Click Automated Deployment

Open your terminal (or the integrated terminal window inside Huawei DevEco Studio) and run the native installation script:

bash

zsh -c "$(curl -fsSL https://harmonybrew.atomgit.com/install.sh)"

Use code with caution.

4. Configure Environment Variables

Once the installer finishes, write the binary path to your configuration profile to execute commands globally:

bash

echo 'eval "$(/storage/Users/currentUser/.harmonybrew/bin/brew shellenv)"' >> ~/.zshrc
source ~/.zshrc

Use code with caution.

Running Your First Headless Tool

With your terminal configured, you bypass all app stores. Downloading and managing headless tools becomes as simple as typing a singular string:

bash

# Pull down the latest package formulas from the community repository
brew update

# Fetch and auto-compile a headless background utility
brew install <package-name>

KaihongOS Desktop Edition is a domestically produced, highly secure all-scenario AI operating system innovatively built on open-source OpenHarmony. It is commonly referred to as KaihongOS. Based on open-source OpenHarmony, it innovates and develops in core areas such as the system kernel, system framework, and performance optimization. Through capability enhancement and technological innovation, it strengthens the system’s foundation, while also providing flexible industry-customized construction capabilities tailored to the differentiated characteristics of different industries. It comprehensively ensures the safety, completeness, real-time, and reliability of system operation, realizing multi-device intelligent connectivity and scenario-based intelligent services, injecting core momentum into the industry’s digital transformation.

Currently, Kaihong OS is developed by ShenKaihong based on OpenHarmony’s underlying architecture, sharing the same origin as Huawei’s HarmonyOS PC system, and inheriting core features such as microkernel design and distributed collaboration. This release breaks the limitation that HarmonyOS is only compatible with ARM architecture devices, offering deep optimization for X86_64 architecture. At the same time, the system is completely free for ordinary individual users, requiring no invitation codes, real-name authentication, or payment, and supports coexisting with Windows without forcing formatting the original hard drive. The new version introduces the OpenClaw crayfish feature, supporting natural language instructions for file automation and code assistance, while optimizing hardware compatibility and system security, making development more efficient and experience smoother.

Kaihong OS system features

1. Security: Multiple authentication ensures full data lifecycle protection

KaihongOS’s LiteOS-M operating system kernel received the EAL5+ security certification from the China Cybersecurity Review Technology and Certification Center (CCRC), and is also the first open-source OpenHarmony secure OS distribution to pass the Ministry of Public Security’s security testing certification nationwide. Ensuring security from the source, KaihongOS achieves system-level security through formal kernels, distributed security defense, distributed encrypted data storage, secure transmission within domains, and tiered security for end-to-end, edge-edge cloud, and application hierarchical security, comprehensively resisting various security threats.

2. Comprehensive: Flexible deployment, covering all devices of all sizes

Based on a microkernel plug-in architecture, KaihongOS integrates system capabilities into individual “block-like” components, which can be flexibly deployed to a vast number of devices of different sizes and types. This meets the needs of a single system for devices ranging from 20KB to GB, enabling data generation and collection across all physical devices, and supports multiple upgrade methods such as edge distribution and OTA upgrades, adapting to the needs of different industries and scenarios.

3. Real-time: Hybrid deployment with microsecond-level real-time response

KaihongOS adopts a single-chip, multi-core hybrid deployment, featuring both real-time and intelligent cores, meeting diverse human-computer interaction scenarios while supporting microsecond-level response in industrial control, aerospace, emergencies, and other scenarios. The KaihongOS industrial real-time operating system kernel has passed testing and certification by China’s Thier Laboratory. It is the first operating system in the open-source OpenHarmony field to achieve hardware real-time capabilities, achieving interrupt response delay of ≤ 1 microsecond and task switching delay of ≤ 1 microsecond, ensuring the system can respond promptly and accurately to task requests in scenarios with high real-time requirements.

4. Reliable: Stable operation, zero downtime and zero interruption during long-term pressure testing

KaihongOS boasts outstanding reliability, with no system downtime, memory leak detection and recovery capabilities, ensuring zero system downtime; Business uninterrupted: Through dual-machine hot standby technology, real-time business takeover is achieved, with zero service interruption during switchover, providing strong support for business continuity in key industries and avoiding losses caused by system failures or interruptions.

5. Smart connectivity: integrated communication, compatible with multiple ecosystem applications

KaihongOS soft bus supports multi-link converged communication, including Sparklink, Wi-Fi, Ethernet, BLE, and other communication methods; Supports interoperability with HarmonyOS devices; Supports compatibility with Linux and Android multi-system application ecosystems.

6. Al Native, Al Agent proactive service

The KaihongOS operating system fully embraces AI, evolving toward “distributed AIOS.” Supports native AI, built-in on-cloud large model framework, and provides users with an Agentic agent framework and development tools, enabling industry users and developers to create personalized intelligent assistants. Based on AIOS, KaihongOS can provide high-quality data, allowing data to flow freely and deeply within a unified intelligent framework. Agents on AIOS can intelligently call various resources based on users’ overall needs and behavior patterns, providing personalized services that collaborate across terminals, applications, and multiple agents, driving industries to upgrade toward intelligence.

Kaihongos Desktop Version Installation Tutorial:

1. Hardware requirements

1. CPU: Intel 64-bit processor (dual-core or multi-core), clock speed above 1GHz.

2. RAM: 4GB or more of memory.

3. Storage: Storage devices of 30GB or more, supporting SATA and NVMe.

4. System firmware: Supports UEFI system firmware booted from external USB boots.

5. Graphics Card: Intel HD Graphics series 5th generation and above integrated graphics, some Intel UHD Graphics series integrated graphics, some Intel Iris architecture integrated graphics, some Intel Xe architecture discrete graphics, NVIDIA GeForce 8 and above dedicated graphics.

6、USB：USB 3.0 / 2.0。

2. Preparation of installation environment

1. The USB drive used for burning images must have a capacity of at least 10GB, and all data on the USB drive must be cleared.

2. The KaihongOS image file used for installation.

3. Rufus USB flash burning software.

4. A Windows x86 physical machine, with KaihongOS image files and Rufus USB burning software stored on this device.

3. Start installing the Honghong OS

1. Enter the X86 physical machine in the Windows environment, insert a USB drive, and then open the Rufus burning software.

2. Click “Select” to select the KaihongOS image file locally.

3. For “Partition Type,” select “GPT” and click “Start.”

KaihongOS images only support installation via UEFI/GPT

4. Choose to write in ISO image mode and click “OK”.

5. Click “OK” to clear the data and start burning the USB drive.

6. After burning is complete, insert the USB drive into the computer where KaihongOS will be installed. Turn on the computer (if the computer has already been turned on, restart it). When the logo lights up on the screen, press F12 to enter the boot menu (the key position for boot menu varies by brand of computer; you can check this key online according to your computer type), then select USB drive to boot

7. Boot using a USB drive, select “Install KaihongOS (amd64)” from the boot menu to boot.

If not selected, it will automatically start after 5 seconds according to the Install KaihongOS (amd64) boot item.

8. After entering the LiveCD desktop, the KaihongOS installer will automatically launch. Click “Next.” Change the language on the list box from Chinese/Mandarin to English before proceeding.

If the KaihongOS installer fails to open automatically, you need to right-click the terminal on the desktop and enter the following command to manually start the installer.

cd /kh_calamares

sudo calamares-d-c

9. Disk configuration.

Use the built-in installation disk layout and do not encrypt it. Figure 2-9 shows the configuration for erasing a single disk as a whole.

Note that when the x86 physical machine has only a single hard drive and does not erase the disk, you can choose the “replace a partition” option to install (see Figure 2-10) to avoid installation errors. On the currently displayed disk partition diagram, click the partition you want to replace as the installation path; unpartitioned space (gray) can also be selected.

Note:

Only one KaihongOS can be installed on the same x86 physical machine at the same time. If the target x86 physical machine already has KaihongOS systems, you need to delete the KaihongOS partition and manually partition it before installing.

10. After disk configuration is complete, click “Next” to confirm the installation information, then click “Install” to start installing KaihongOS.

When the “Continue Installation” prompt pops up, click “Start Installation Now.”

11. After installation is complete, click “Finish”.

12. When prompted “Please remove the live-medium,” unplug the USB drive and press Enter. If the prompt “Please remove the live-medium” does not appear, you can remove the USB drive and manually restart.

13. When entering the boot menu, select the “KaihongOS” boot option to enter the KaihongOS system.

If the x86 physical machine is installed with Windows and KaihongOS running in parallel, the boot menu will display the “Windows Boot Manager” boot item for entering the Windows system.

Press E to enter edit mode. You can follow the method below to open the required graphics card driver (set to 1) and disable the unused driver (set to 0) to avoid conflicts.

The method is as follows:

i915.modeset=1 (set to 1 to enable Intel integrated graphics, set to 0 to turn off Intel integrated graphics)

amdgpu.modeset=1 (set to 1 to open the new AMD graphics card, set to 0 to turn off the new AMD graphics card)

radeon.modeset=1 (set to 1 to open old AMD graphics cards, set to 0 to turn off old AMD graphics cards)

nouveau.modeset=1 (Set to 1 to turn on NVIDIA graphics card, set to 0 to turn off NVIDIA graphics card

After setting up, press F10. If the boot is normal, you can enter the kernel boot interface shown in Figure 2-18.

Note: The monitor must be connected to the correct graphics card

After booting, enter the KaihongOS system interface.

Note: OpenClaw requires more than 4GB of memory

14. Alright, Kaihong OS has been successfully installed.

Product architecture

The KaihongOS standard system software technical architecture follows a layered design, from bottom to top: kernel layer, system service layer, framework layer, and application layer. System functions are deployed stepwise according to “system > subsystem > components.” In multi-device deployment scenarios, it supports trimming certain unnecessary components according to actual needs. As shown below:

Here, the subsystem is a logical concept composed of corresponding components.

A component is a further breakdown of a subsystem, a reusable software unit containing source code, configuration files, resource files, and compilation scripts. It can be independently constructed and integrated in binary form, making it a binary unit with independent verification capabilities.

1. Kernel layer

- Kernel Subsystem: The KaihongOS standard system software uses a Linux kernel design. The Kernel Abstract Layer (KAL) provides the underlying kernel capabilities for the upper layer by masking multikernel differences, including process/thread management, memory management, file systems, network management, and peripheral management.

- Driver Subsystem: The Driver Framework (HDF, Hardware Driver Foundation) is the foundation for the open hardware ecosystem of the system, providing unified peripheral access capabilities and a framework for driver development and management.

2. System service layer

The system service layer is the core capability set of KaihongOS standard system software, providing services to applications through the framework layer. This layer consists of the following parts:

- System Basic Capability Subsystem Set: Provides foundational capabilities for running, scheduling, migration, and other operations in distributed applications across multiple devices. It consists of subsystems such as distributed soft bus, distributed data management, distributed task scheduling, public base library, multi-mode input, graphics, security, AI, and more.

- Basic Software Service Subsystem Set: Provides public, general-purpose software services, consisting of event notifications, telephone, multimedia, DFX (Design For X), and other subsystems.

- Enhanced Software Service Subsystem Set: Provides differentiated capability enhancement software services for different devices, consisting of proprietary smart screen services, wearable proprietary services, IoT proprietary services, and other subsystems.

The KaihongOS standard system software software service subsystem set provides customized enhanced software services for KaihongOS standard system software, consisting of end-cloud connectivity, near-field sensing services, wearable services, financial security, IoT services, and other subsystems.

- Hardware Service Subsystem Set: Provides hardware services, consisting of location services, user IAM, wearable proprietary hardware services, IoT proprietary hardware services, and other subsystems.

Depending on the deployment environment of different device forms, the basic software service subsystem set, enhanced software service subsystem set, and hardware service subsystem set can be internally segmented by subsystem granularity, and each subsystem can be segmented by function granularity.

3. Frame layer

The framework layer provides multilingual user programming frameworks and Ability frameworks for application development, ArkUI frameworks for JS, and multilingual framework APIs for various software and hardware services that are open to the public. Depending on the degree of component-based trimming of the system, the APIs supported by the device will also differ.

4. Application layer

The application layer includes system applications and third-party non-system applications. System applications include those essential to the system such as desktop and settings, and are composed of one or more FA (Feature Capabilities) or PAs (Particle Capabilities). Among them, FA has a UI interface that provides the ability to interact with users; PA, on the other hand, has no UI interface, providing the ability to run tasks in the background and providing unified data access abstraction. Applications developed based on FA/PA can implement specific business functions, support cross-device scheduling and distribution, and provide users with a consistent and efficient application experience.

Kaihongos Desktop Edition Scope and Positioning

1. Positioning

For developers, it offers an open-source desktop operating system version developed through OpenHarmony learning.

2. Characteristics

Provides open-source OpenHarmony system learning and development, southbound device and northbound application development and validation, and offers new interaction, new security, new intelligence, and new ecosystem experiences.

3. Application

Laptops, MiniPCs, desktops, etc.

Update log

v5.0.2.30

1. Added camera services and document editor;

2. Optimized video decoder, resolution adjustment, and screen zoom functions.

Caution: This desktop OS is not polished as Huawei HarmonyOS computer system for MateBooks, Apple Macs, Microsoft Windows and Linux. Still new infertile ecosystem that is yet to be fully polished and more experimental and developer centric target, you will experience missing apps, unpolished apps, missing audio/graphical drivers etc. I recommend you dual-booting KaihongOS with your current desktop set up of Windows or Linux x86 computer/laptop or QEMU virtual machine at best.

Download the zipped ISO file here for KaihongOS x86 (Translate the web page with your browser)

A few months ago, I bought a Huawei tablet and have been hoping to take the opportunity to develop HarmonyOS, but since DevEco does not support Linux, I started considering whether a port might be possible.

Preparation

Get the Windows version of DevEco Studio

Here, we download the Windows version installation package from Huawei’s official website (at the time of writing, the downloadable version is DevEco Studio 6.0.2 Release) and install it via wine. If all installation configurations remain by default, the DevEco program main body should be located below. We enter this directory.~/.wine/drive_c/Program Files/Huawei/DevEco Studio

Get IDEA

Since the current DevEco Studio is based on modifications of IDEA, we need a Linux version of IDEA as a reference. The version I downloaded is 2025.3.2.

After extracting and organizing the directory, our directory format is as follows:

.  
├── DevEco Studio  
│   ├── bin  
│   ├── ......
│   └── tools  
└── idea-IU-253.30387.90  
	├── bin  
	├── ......
	└── plugins

bash

Transplant environment

Transplanting JBR

JBR (Jetbrains Runtime) is a JDK update created by JetBrains, and it was included when we downloaded IDEA. Simply copy and replace the jbr directory in DevEco Studio.

Of course, the JBR versions used by IDEA and DevEco are not necessarily the same. If you want the JBR versions to match exactly, you can print the DevEco JBR version using wine and download it from Github.

Port Node

Huawei’s build tools are either written in Nodejs or Python. Checking tools/node, I found that NodeJS version is v18.20.1 LTS, so I downloaded that version from the official website, extracted it, and replaced the original directory. (To keep the Windows version directory structure consistent, I softlinked all files in the node/bin subdirectory to the node directory.)

At this point, there should be a node folder in the directory.tools

Replace libs

Go to the directory, copy the three directories from the IDEA sample, and replace the directories in DevEcolibnative, pty4j, jna

Replace the OpenHarmony SDK

Here, you can replace it with the downloaded OpenHarmony SDK. (As for how to download it, you can directly use the download tool provided by DevEco. You can skip this step and complete the other steps. After that, you should be able to open it on Linux and download the SDK.)sdk/default/openharmony

Reverse official launcher

Since Huawei most likely directly copied the official launcher, here I directly used IDA to reverse bin/idea. The most useful function should be. The conclusions drawn with the help of GPT are as follows:xplat_launcheer::main_lib

1. The launcher is written in Rust, the world’s best language

2. When the launcher loads, it regressively reads files from the upper level of the current directory, with a maximum depth of 5product-info.json

3. The launcher loads the properties file, specifically the one that loads is

Therefore, by writing and , we can complete the final porting work.product-info.jsondevecostudio.vmoption

Write the relevant configuration files

I won’t elaborate on this part; here are some VMOption & product-info & idea properties you can copy from:

// product-info.json
{  
"name": "DevEco Studio",  
"version": "6.0.2.640",  
"versionSuffix": "",  
"buildNumber": "243.24978.46.36.602640",  
"productCode": "DS",  
"envVarBaseName": "DEVECOSTUDIO",  
"dataDirectoryName": "DevEcoStudio6.0",  
"svgIconPath": "bin/devecostudio.svg",  
"productVendor": "Huawei",  
"launch": [  
{  
"os": "Linux",  
"arch": "amd64",  
"launcherPath": "bin/devecostudio",  
"javaExecutablePath": "jbr/bin/java",  
"vmOptionsFilePath": "bin/devecostudio64-lin.vmoptions",  
"startupWmClass": "deveco-studio",  
"bootClassPathJarNames": [  
"platform-loader.jar",  
"util-8.jar",  
"util.jar",  
"util_rt.jar",  
"opentelemetry.jar",  
"app.jar",  
"stats.jar",  
"jps-model.jar",  
"external-system-rt.jar",  
"rd.jar",  
"bouncy-castle.jar",  
"protobuf.jar",  
"forms_rt.jar",  
"lib.jar",  
"externalProcess-rt.jar",  
"groovy.jar",  
"annotations.jar",  
"hwlib.jar",  
"idea_rt.jar",  
"kotlinx-coroutines-slf4j-1.8.0-intellij.jar",  
"nio-fs.jar",  
"trove.jar"  
],  
"additionalJvmArguments": [  
"-Djava.system.class.loader=com.intellij.util.lang.PathClassLoader",  
"-Didea.vendor.name=Huawei",  
"-Didea.paths.selector=DevEcoStudio6.0",  
"-Djna.boot.library.path=$IDE_HOME/lib/jna/amd64",  
"-Dpty4j.preferred.native.folder=$IDE_HOME/lib/pty4j",  
"-Djna.nosys=true",  
"-Djna.noclasspath=true",  
"-Dintellij.platform.runtime.repository.path=$IDE_HOME/modules/module-descriptors.jar",  
"-Didea.platform.prefix=DevEcoStudio",  
"-Dsplash=true",  
"-Daether.connector.resumeDownloads=false",  
"-Dcompose.swing.render.on.graphics=true",  
"--add-opens=java.base/java.io=ALL-UNNAMED",  
"--add-opens=java.base/java.lang=ALL-UNNAMED",  
"--add-opens=java.base/java.lang.ref=ALL-UNNAMED",  
"--add-opens=java.base/java.lang.reflect=ALL-UNNAMED",  
"--add-opens=java.base/java.net=ALL-UNNAMED",  
"--add-opens=java.base/java.nio=ALL-UNNAMED",  
"--add-opens=java.base/java.nio.charset=ALL-UNNAMED",  
"--add-opens=java.base/java.text=ALL-UNNAMED",  
"--add-opens=java.base/java.time=ALL-UNNAMED",  
"--add-opens=java.base/java.util=ALL-UNNAMED",  
"--add-opens=java.base/java.util.concurrent=ALL-UNNAMED",  
"--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED",  
"--add-opens=java.base/java.util.concurrent.locks=ALL-UNNAMED",  
"--add-opens=java.base/jdk.internal.vm=ALL-UNNAMED",  
"--add-opens=java.base/sun.net.dns=ALL-UNNAMED",  
"--add-opens=java.base/sun.nio.ch=ALL-UNNAMED",  
"--add-opens=java.base/sun.nio.fs=ALL-UNNAMED",  
"--add-opens=java.base/sun.security.ssl=ALL-UNNAMED",  
"--add-opens=java.base/sun.security.util=ALL-UNNAMED",  
"--add-opens=java.desktop/com.sun.java.swing=ALL-UNNAMED",  
"--add-opens=java.desktop/com.sun.java.swing.plaf.gtk=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.dnd.peer=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.event=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.font=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.image=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.peer=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.text=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.text.html.parser=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt.datatransfer=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt.image=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.font=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.java2d=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.swing=ALL-UNNAMED",  
"--add-opens=java.management/sun.management=ALL-UNNAMED",  
"--add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED",  
"--add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED",  
"--add-opens=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED",  
"--add-opens=jdk.jdi/com.sun.tools.jdi=ALL-UNNAMED"  
],  
"mainClass": "com.intellij.idea.Main"  
}  
],  
"bundledPlugins": [],  
"modules": [],  
"fileExtensions": [],  
"layout": []  
}

json

# devecostudio64-lin.vmoptions
-Xms256m  
-Xmx2048m  
-XX:ReservedCodeCacheSize=512m  
-XX:CICompilerCount=2  
-XX:+HeapDumpOnOutOfMemoryError  
-XX:-OmitStackTraceInFastThrow  
-XX:+IgnoreUnrecognizedVMOptions  
-XX:+UnlockDiagnosticVMOptions  
-XX:TieredOldPercentage=100000  
-ea  
-Dfile.encoding=UTF-8  
-Dsun.java2d.metal=true  
-Dawt.lock.fair=true  
-Dsun.io.useCanonCaches=false  
-Djdk.nio.maxCachedBufferSize=2097152  
-Djava.util.zip.use.nio.for.zip.file.access=true  
-Djava.nio.file.spi.DefaultFileSystemProvider=com.intellij.platform.core.nio.fs.MultiRoutingFileSystemProvider  
-Djdk.attach.allowAttachSelf=true  
-Dsun.tools.attach.tmp.only=true  
-Djdk.http.auth.tunneling.disabledSchemes=""  
-Djdk.module.illegalAccess.silent=true  
-Djbr.catch.SIGABRT=true  
-Dkotlinx.coroutines.debug=off  
-Djava.security.manager=com.intellij.platform.core.nio.fs.CoreBootstrapSecurityManager

bash

# idea.properties

# ---------------------------------------------------------------------  
# DevEco Studio - Linux
# Based on IntelliJ Platform 243.x  
# ---------------------------------------------------------------------  
  
# Use ${idea.home.path} macro to specify location relative to IDE installation home.  
# Use ${xxx} where xxx is any Java property (including defined in previous lines of this file)  
# to refer to its value.  
  
# ---------------------------------------------------------------------  
# Paths (use defaults unless you really need to override)  
# ---------------------------------------------------------------------  
# idea.config.path=${user.home}/.DevEcoStudio/config  
# idea.system.path=${user.home}/.DevEcoStudio/system  
# idea.plugins.path=${idea.config.path}/plugins  
# idea.log.path=${idea.system.path}/log  
  
# ---------------------------------------------------------------------  
# File size limits  
# ---------------------------------------------------------------------  
idea.max.intellisense.filesize=2500  
idea.max.content.load.filesize=20000  
  
# ---------------------------------------------------------------------  
# Console & process behavior  
# ---------------------------------------------------------------------  
idea.cycle.buffer.size=4096  
idea.no.launcher=false  
idea.dynamic.classpath=false  
  
# ---------------------------------------------------------------------  
# UI / Window manager behavior  
# ---------------------------------------------------------------------  
idea.popup.weight=heavy  
  
# ---------------------------------------------------------------------  
# Graphics & rendering (Linux-safe)  
# ---------------------------------------------------------------------  
sun.java2d.d3d=false  
sun.java2d.pmoffscreen=false  
swing.bufferPerWindow=true  
sun.java2d.uiScale.enabled=false  
javax.swing.rebaseCssSizeMap=true  
  
# ---------------------------------------------------------------------  
# Accessibility & stability (JBR)  
# ---------------------------------------------------------------------  
javax.swing.JTree.excludeAccessibleChildrenFromClosedNodes=true  
sun.awt.mac.a11y.tableAccessibleRowCountThreshold=1000  
sun.lwawt.macosx.LWCToolkit.invokeAndWait.disposeOnEDTFree=true  
  
# ---------------------------------------------------------------------  
# Smooth scrolling (disabled by default, stable choice)  
# ---------------------------------------------------------------------  
# idea.true.smooth.scrolling=true  
  
# ---------------------------------------------------------------------  
# DevEco specific: plugin compatibility baseline  
# IMPORTANT: keeps DevEco plugins from behaving like pure IDEA plugins  
# ---------------------------------------------------------------------  
idea.plugins.compatible.build=IC-243.24978.46  
  
# ---------------------------------------------------------------------  
# HarmonyOS / DevEco toolchain (keep even if commented)  
# ---------------------------------------------------------------------  
# ide.harmonyos.sdk.location=/path/hosdk/  
# ide.ohpm.location=/path/ohpm  
# ide.hvigor.location=/path/hvigor  
# ide.node.location=/path/node  
# ide.emulator.location=/path/emulator  
  
# ---------------------------------------------------------------------  
# ArkTS / Node related limits (optional)  
# ---------------------------------------------------------------------  
# arkts.server.max.intellisense.filesize=10240  
# arkts.server.max.old.space.size=8192  
  
# ---------------------------------------------------------------------  
# Error handling  
# ---------------------------------------------------------------------  
idea.fatal.error.notification=disabled

properties

One fun fact worth noting here: if you enable IDEA’s recommended Scale by OS, Huawei’s strange plugin loading mechanism will mess everything up! So set it to false here, and we’ve completed the entire port.sun.java2d.uiScale=true

Handling signature issues

At this point, DevEco seems to be developing normally, but strange issues arise during signing:

2026-02-05 22:20:54,000 [ 490226]   WARN - #com.huawei.deveco.projectmgmt.hos.s  
ignature.sign.utils.AutoGenerateKeyCSRUtil - No available JDK is found.  
2026-02-05 22:21:00,716 [ 496942]   WARN - #com.huawei.deveco.projectmgmt.hos.s  
ignature.sign.utils.AutoGenerateKeyCSRUtil - No available JDK is found.

plaintext

We use Recaf to reverse this component. (If you have friends working on Java reverse engineering, I sincerely recommend Recaf. So far, it’s the best Java decompilation and bytecode modification tool I’ve used—absolutely a legendary tool.) The component location is, and the related code is:plugins/harmony/lib/hos-project-mgmt-6.0.2.640.jar

String toolPath = homePath + TOOL_PATH;              // /jbr/bin
if (SystemInfo.isMac || SystemInfo.isLinux) {
    toolPath = homePath + MAC_TOOL_PATH;             // /jbr/Contents/Home/bin
}

java

In other words, Linux is directly grouped with Mac, component search is , and the actual path is.jbr/Contents/Home/bin/keytooljbr/bin/keytool

Therefore, we will “disguise the path,” and the specific method will not be elaborated here.

Porting “Simulator”

Since HarmonyOS’s emulator is not open source, we obviously cannot force compatibility with it, so here we use Oniro Emulator. Install and configure according to the requirements.

Effect

GitHub Link: alex3236/devecostudio-linux: Bring DevEco Studio to Linux

Credit: ChrisQ (China) - DevEco Studio Port Notes • Cris.Q

In a recent and controversial move, the United States government, in collaboration with its allies in Western Europe and NATO-aligned countries, has intensified efforts to block Huawei’s HarmonyOS. This decision has sparked significant backlash from various stakeholders, including consumers, tech enthusiasts, and market competition advocates.

The Problem

The push to block Huawei’s HarmonyOS raises substantial concerns about market competition and consumer choice. Critics argue that such actions could stifle innovation and limit technological advancement. In a marketplace that thrives on diversity and competition, the outright blocking of HarmonyOS could lead to a monopolistic environment, ultimately affecting consumer satisfaction and economic growth.

Market Competition and Innovation

Market competition is a driving force behind continuous innovation and improvement. When consumers have multiple options, companies are compelled to innovate and offer better products and services. HarmonyOS, developed by Huawei, offers a distinctive alternative to dominant operating systems, potentially fuelling further innovation and providing more choices for tech-savvy consumers.

Security Concerns and Alternative Solutions

While security concerns related to Huawei’s technology are valid, so are American counterparts’ such as iOS and Android security concerns on data gathering and privacy in the world of AI emergence. Many argue that blanket blocking without exploring alternative solutions or collaborations may not be the most effective approach. A dialogue between stakeholders could lead to transparent solutions that address security issues while still allowing innovation to flourish. Constructive engagement, rather than isolation, might help address security concerns without compromising competition.

A Balanced Approach

Advocates for a balanced approach argue that HarmonyOS should be given the opportunity to compete in the market, allowing consumers to decide. This perspective is echoed in a recent petition urging lawmakers to reconsider the decision to block HarmonyOS. The petition emphasizes the importance of promoting a competitive, diverse, and innovative market environment.

Consumer Choice and Economic Growth

Every consumer deserves the ability to navigate a marketplace that offers variety, fosters innovation, and encourages competitive pricing. Blocking HarmonyOS outright could limit these benefits, ultimately affecting consumer satisfaction and economic growth. Encouraging debates and solutions that address security concerns while nurturing market competition is essential for progress.

Conclusion

The backlash against the US government’s decision to block Huawei’s HarmonyOS highlights the importance of market competition and consumer choice. As the debate continues, it is crucial to seek a balanced approach that addresses security concerns while promoting innovation and competition.

Original source: Backlash Against US Government's Block on Huawei's HarmonyOS - HarmonyOSHub

The full package for HarmonyOS 5.0.5 Release is as follows:

The following table compares the mappings of released versions of HarmonyOS:

HarmonyOS 5.0.5 (17) Beta1 adds and enhances the following features (same as the Release version):

Ability

• Added support for specifying the size of the new window (minWindowWidth, minWindowHeight, maxWindowWidth, maxWindowHeight) via the startAbility property StartOptions.

• C API added support for passing StartOptions when starting Ability.

• C API added support for obtaining sub-process startup parameters.

• C API adds support for setting the display mode of window and dock bar icons when starting Ability.

ArkData

• UDMF adds support for converting incoming data into multi-style data structures. If the original data uses multiple records to carry different styles of the same data, you can use this API to convert the original data into a multi-style data structure.

AR Engine

• Depth estimation is added to provide 3D perception capabilities, which can realize measurement, volume estimation, and more.

ArkUI

• Added APIs related to mouse axis events.

• NavDestination adds onActive and onInactive lifecycles.

• The event capability of the C API has been enhanced, and the ability to obtain the width, height, X coordinates, and Y coordinates of components hit by an event has been added.

• Added support for clearing the current pre-screen text content in the base type definition.

• UIContext adds support for creating UI instances that don’t depend on windows.

• Added support for setting the callback parameter of the event to limit its execution interval.

• The ImageAnimator component supports setting whether to determine whether to pause and play the component by the visibility of the system onVisibleAreaChange.

• The picture-in-picture window supports the creation of the parameter LocalStorage to achieve a page-level UI state storage unit, which can be used to track the main window instance under multiple instances.

• Added support for the size memory function of the main window in the window management of PC / 2in1 devices.

• Added support for setting the blur radius of shadows on the edge of a sub-window or floating window for PC / 2in1 devices and tablet devices.

• Added support for window management for PC/2in1 devices and tablets to set whether a child window can be displayed across multiple screens at the same time when its parent window is in the process of dragging and moving or drag-and-zoom.

Audio Kit

• Added support for Float32 audio stream sampling format.

AVCodec Kit

• Video decoding supports MPEG2, MPEG4, and H.263 software decoding.

AVSession Kit

• Added support for single-sentence/single-lyric display property singleLyricText.

Background Tasks Kit

• The background sub-process management module is added to provide the ability for applications to suppress and decompress sub-processes, so as to prevent sub-processes from occupying too much system resources and causing system lag.

Connectivity Kit

• The Bluetooth socket module adds the ability to obtain the address of the peer device through clientSocket.

File Manager Service Kit

• 【New Kit】File Manager Service Kit provides developers with file management capabilities, such as deleting files to the recycle bin and obtaining file icons, to meet the diverse demands of users for file management.

IME Kit

• The input method framework adds support for setting the callback when the preview text is displayed, and supports subscribing to the event of the input method application operation text preview content.

Media Kit

• When you call AVPlayer to set a playback policy, the first frame of the video after Prepare (showFirstFrameOnPrepare) is displayed.

Payment Kit

• Added the ability to guide users to bind cards.

PDF Kit

• Added support for encrypting PDF documents.

Preview Kit

• Added file opening acceleration preload state awareness.

Vision Kit

• A status code is added to the document scan result callback interface to determine whether all the input image URLs are invalid.

Profiles

• Added Hook configuration file module.json5: You can use the abilitySrcEntryDelegator to identify the name of the UIAbility of the current module that needs the hook, and use the abilityStageSrcEntryDelegator You can identify the AbilityStage (the value of which is configured to correspond to the name of the module) that the current module needs to hook, and the two are used in combination to specify the target object of the hook.

The new version notes are as follows:

• For the system version, please visit the “Settings> Device Name >Software Version” of the device, and go to “About This Mac” for inquiries. You must check whether the open capabilities described in the current version are supported in the API Version section of the page.The devices that are available in the current system version include: Mate 60, Mate 60 Pro, Mate X5, MatePad Pro 13.2-inch, MatePad Pro 11-inch 2024, etc. Please upgrade to the companion version for application development.It is not excluded that other models of devices can be upgraded to the above system software (ROM) version through other channels, but the open capabilities supported by the device are subject to the “API version” displayed on the “About this machine” page.

• For the DevEco Studio version, please select “Help > About DevEco Studio” from the DevEco Studio interface menu. Please click here for the latest DevEco Studio software release.

• The SDK is built into DevEco Studio, and the companion version of the SDK is automatically installed when you install DevEco Studio. For more information, choose Help > About HarmonyOS SDK from the DevEco Studio menu.

---

Global Aggegrate Source: The software performance and stability have been improved, and Huawei HarmonyOS 5.0.5 (17) Release has been released - HarmonyOSHub

Original Source: Software performance and stability improvement, Huawei HarmonyOS 5.0.5 (17) Release released – IT Home

According to reports, mobile police terminal products based on open source Hongmeng are widely used in the following scenarios:

• Daily patrol and public security prevention and control: Handheld law enforcement PDA, law enforcement recorder and other equipment support face recognition, license plate capture and real-time video backhaul to help the police complete daily patrol and public security prevention and control.

• Emergency response and counter-terrorism: In emergencies, terminals support multi-modal communication and multi-department coordinated operations.

• Smart case handling and administrative quick handling are applied to functions such as electronic transcription, video inquiry, and automatic document generation.

IT Home learned from the Open Atom Open Source Foundation that the series of products are based on the chip certified by industry specifications and the FlyHong OS Smart system, and are adapted to the OpenHarmony 5.0 Release version and Jinghong.

• There is a full-process security protection, based on the chip certified by industry standards, using hardware encryption, trusted boot, data isolation and other technologies, in line with the Ministry of Public Security's mobile police terminal security specifications, to ensure system security.

• Based on the distributed soft bus technology of open-source HarmonyOS, it builds efficient and secure cross-terminal collaboration capabilities.

Source: The mobile police terminal based on the open source HarmonyOS was unveiled, adapted to the OpenHarmony 5.0 Release version and the Police Harmony - IT Home

Introduction

In this article, we’ll walk through the creation of a simple Note App using ArkUI and ArkTS on HarmonyOS. We’ll demonstrate how ArkUI’s modern UI capabilities integrate seamlessly with a relational database for efficient data management. By the end of this guide, you’ll have a foundational understanding of how to develop a functional app that allows users to add, update, delete, and view notes in a local database.

Understanding HarmonyOS and its Development Tools

HarmonyOS, developed by Huawei, is designed to provide a seamless experience across a wide range of devices, from smartphones to wearables and smart home products. For developers, HarmonyOS offers a robust set of tools and APIs optimized for creating apps within this ecosystem.

Key tools for HarmonyOS app development include:

• ArkUI: A UI framework for building modern, dynamic user interfaces that allow for easy navigation and interaction.

• ArkTS: A TypeScript-based programming language specifically tailored for HarmonyOS, providing syntax to work with ArkUI and integrate seamlessly with the system’s APIs.

In this tutorial, we’ll focus on using ArkUI and ArkTS to build our Note App, creating a responsive and smooth experience for users on HarmonyOS.

What You Need to Get Started with HarmonyOS App Development

To start developing apps for HarmonyOS, you will need the HarmonyOS SDK and DevEco Studio, which is the recommended IDE. DevEco Studio simplifies the app creation process, from building and debugging to testing.

The SDK provides tools in the following key areas:

• Application Framework: Includes ArkUI for UI development and Ability Kit for program services.

• System Services: Key management and networking libraries.

• Media Services: Tools for managing audio and media files.

• Graphics Services: ArkGraphics for 2D graphics and acceleration.

• Application Services: Libraries for game and location services.

• AI Capabilities: AI tools like the HiAI Foundation Kit.

These tools allow developers to create powerful, cross-platform apps that provide a consistent experience across HarmonyOS devices.

App Overview

Now that we’ve covered the basics of HarmonyOS development, let’s dive into building our Note App using ArkUI and ArkTS. This Note App provides an intuitive, minimalist user interface with a tabbed layout. Users can easily navigate through different sections to add, view, update, and delete notes.

The app’s core features are organized under various tabs, offering a streamlined and straightforward experience. Users can quickly manage their notes, making the app ideal for everyday use.

Note: To build this app, you should use SDK 5.0.0 (12) as the framework and DevEco Studio NEXT Developer Beta1 as the development environment.

Preparing Database Operations

Before diving into the UI, let’s set up the database operations that our Note app will rely on for data management. In this section, we’ll create functions to create, insert, update, delete, and retrieve notes from a local database.

Step 1: Create the Database

Start by creating a new file named DBUtils to encapsulate all database operations. We’ll use ArkData relational database (RDB) APIs in DBUtils.

In DBUtils, we’ll define functions for each key operation in our Note app.

The createDb() function defines the database configuration (STORE_CONFIG) and creates a table named NOTE_TABLE if it doesn’t already exist. This ensures our database is ready for subsequent operations.

Step 2: Insert a New Note

The insertNote() function inserts a new note into the NOTE_TABLE by creating a noteData object, where "NOTE" is the column name, and its value is the note content.

Step 3: Update an Existing Note

The updateNote() function updates an existing note in the NOTE_TABLE. It creates an updatedNoteData object with the new content and applies a condition to match the old content.

Step 4: Delete a Note

The deleteNote() function deletes a note from the NOTE_TABLE. It creates a delete condition based on the note content and executes the delete operation.

Step 5: Get All Notes

The getAllNotes() function retrieves all notes from the NOTE_TABLE. It queries the database and extracts the note content into a list of notes, which is then returned.

Integrating Database Operations in UI Component

Now that our database is set up, we can focus on the UI component, where users will interact with the app, view their notes, and manage them through a tabbed interface.

Step 1: Initial Setup in Index.ets

In the Index.ets file, we initialize core UI elements, tabs, and set up initial states.

State Variables:

• currentIndex: Keeps track of the current tab.

• notes: Stores the list of notes fetched from the database.

• content, buttonText, oldNote: Used for managing note input, button labels, and previous note content for updates.

Step 2: Initializing the Database

The aboutToAppear() method initializes the database when the component first loads. This lifecycle method ensures that the database setup happens just before the app appears on the screen.

Step 3: Loading Notes with loadNotes

The loadNotes() function uses the getAllNotes() method from DBUtils to fetch all notes from the database. It then updates the notes state with the list of notes.

Step 4: Handling Tabs with changeTab

The changeTab function is responsible for switching between different tabs (e.g., “Add Note” and “My Notes”).

Step 5: Building the Tab Bar with tabBarBuilder

The tabBarBuilder() function creates a tab bar with icons and titles for each tab. It allows users to navigate between tabs and highlights the active tab.

Step 6: Saving or Updating Notes with saveOrUpdateNote

The saveOrUpdateNote() function checks whether to save a new note or update an existing one based on the input and button state (“Save” or “Update”).

The function:

• Ensures the content isn’t empty.

• In the update flow, calls updateNote() to modify the note in the database and refresh the list.

• In the save flow, calls insertNote() to add the note to the database.

• Calls resetNoteState() to clear input fields after saving or updating.

Now that all steps have been covered, we hope this guide has provided a clear and complete path to building your own Note App on HarmonyOS.

Conclusion

This Note App demonstrates how to build a functional, user-friendly app using ArkUI and ArkTS on HarmonyOS. By combining ArkUI’s component-based UI design with ArkTS’s powerful data management capabilities, developers can efficiently create apps that deliver smooth and responsive user experiences. With this foundational structure, you are now ready to extend your app with more advanced features or customizations that meet your users’ needs.

Happy coding!

Original Source: Building a Note App With ArkUI and ArkTS on HarmonyOS | by Emine İNAN | Huawei Developers | Medium

This article aims to deeply explore the technical details of the Huawei HarmonyOS Next system (up to API 12 as of now) in terms of application internationalization and localization, and is summarized based on actual development practices. It mainly serves as a carrier for technical sharing and communication. Mistakes and omissions are inevitable. Colleagues are welcome to put forward valuable opinions and questions so that we can make progress together. This article is original content, and any form of reprint must indicate the source and the original author.
In today's era of globalization, application internationalization and localization have become key factors in enhancing user experience and expanding market share. The Huawei HarmonyOS Next system provides powerful tools and functions for developers to help create cross-language and cross-cultural applications. This article will introduce in detail the concepts, advantages, processes, and key steps of internationalization and localization of HarmonyOS Next applications, helping developers embark on the road to application globalization.

I. Concepts and Differences between Internationalization and Localization

(I) Internationalization (Internationalization, I18n)

Internationalization refers to the process of designing and developing an application so that it can adapt to different languages, regions, and cultures. It involves not only simple language translation but also the adaptation of various formats such as dates, times, numbers, currencies, weights and measures, as well as the universal design of interface layouts, icons, colors, and other elements. The goal of internationalization is to create an application that can be used globally without extensive code modifications. For example, in an internationalized application, the date format may be displayed in different styles depending on the user's region, such as "YYYY-MM-DD" (China) or "MM/DD/YYYY" (United States).

(II) Localization (Localization, L10n)

Localization is the process of customizing and optimizing an application for a specific target language and region on the basis of internationalization. This includes translating the interface text of the application into the local language, adjusting the interface layout to adapt to different text lengths and reading habits, and using local cultural elements and symbols. Localization ensures that the application can provide a natural, smooth, and user-expected experience in each target market. For example, when localizing an English application to Japan, not only should the text be translated into Japanese, but the interface layout may also need to be adjusted to adapt to the display of Japanese characters, and Japanese cultural elements may be used to enhance user affinity.

(III) Differences between the Two

Internationalization focuses on building the general framework and infrastructure of an application to enable it to support multiple languages and cultures; while localization is the personalized adaptation and optimization of an application for specific languages and regions. Internationalization is a global and forward-looking design concept, while localization is the actual implementation for specific markets on the basis of internationalization.

II. Advantages of Internationalization and Localization of HarmonyOS Next Applications

(I) Expanding the Global Market

Through internationalization and localization, applications can break through language and cultural barriers, attract users from different countries and regions, greatly expand market coverage, and increase the potential user base.

(II) Enhancing User Experience

Providing users with interfaces and functions that conform to their language habits and cultural backgrounds enables them to use the application more naturally and conveniently, thereby increasing user satisfaction and loyalty.

(II) Strengthening Competitiveness

In the global market competition, applications with internationalization and localization capabilities have an advantage, can better meet user needs, compete with local competitors, and enhance brand image and market share.

(IV) Reducing Development Costs

Adopting internationalization and localization design methods and following certain norms and standards during the development process can reduce the costs of separate development and maintenance for different languages and regions in the later stage.

III. Processes of Internationalization and Localization of HarmonyOS Next Applications

(I) Requirement Analysis

1. Target Market Research: Understand the potential markets of the application, including factors such as languages, cultures, user habits, and laws and regulations in different regions. For example, certain regions may have different cultural meanings for specific colors or icons, which need to be considered in the design.

2. Function Requirement Evaluation: Determine the functions that the application needs to support in different language and cultural environments, such as multi-language input, payment methods in different regions, and localized push notifications. ### (II) Design Stage

3. Interface Layout Design: Adopt a flexible layout method and reserve sufficient space to adapt to the length changes of different language texts. At the same time, consider functions such as interface mirroring to support the display requirements of right-to-left (RTL) languages such as Arabic.

4. Resource Separation: Separate interface texts, pictures, audio, and other resources from the code logic to facilitate subsequent translation and replacement. For example, store all string resources in independent files instead of hard-coding them in the code. ### (III) Development Stage

5. Using the Internationalization Framework: Utilize the internationalization and localization development services provided by HarmonyOS Next, such as the Localization Kit, to perform language and region-related settings, resource loading, and format conversions.

6. Function Implementation and Adaptation: According to the requirement analysis, implement functions that support multiple languages, such as displaying the corresponding interface according to the user's language setting and handling date and time formats in different regions. ### (IV) Testing Stage

7. Language Testing: Have local language experts or users test the translation accuracy, language fluency, and interface display of the application to ensure the quality of the application in different language environments.

8. Localization Testing: Include interface layout testing, function compatibility testing, and cultural adaptability testing to check whether the application can operate normally in each target region and meet the expectations of local users.

9. Pseudo-Localization Testing: Before formal localization, simulate the localization process by using pseudo-translated texts and special test regions (such as en-XA) to discover potential localization problems such as interface truncation and incorrect text direction. ### (V) Release and Maintenance Stage

10. Multi-Language Version Release: Release the application in corresponding language versions according to different target markets.

11. Continuous Optimization: Collect user feedback, promptly fix localization-related problems, and continuously update and optimize the internationalization and localization content of the application according to market changes and user needs. ## IV. Key Steps of Internationalization and Localization of HarmonyOS Next Applications ### (I) Setting the System Language and Region

12. Obtaining the System Language and Region: Use the methods i18n.System.getSystemLanguage() and i18n.System.getSystemRegion() to obtain the language and region information of the current system.

13. Setting the Application Preferred Language: The method i18n.System.setAppPreferredLanguage() can be used to set a specific preferred language for the application, so that the application loads the corresponding resources according to the user's setting or the default language when it starts. For example:

import { i18n } from '@kit.LocalizationKit';
import {BusinessError } from '@kit.BasicServicesKit';
try {
    i18n.System.setAppPreferredLanguage("zh-Hans"); // Set the application preferred language to Simplified Chinese
} catch(error) {
    let err: BusinessError = error as BusinessError;
    console.error(`Failed to set the application preferred language, error code: ${err.code}, message: ${err.message}.`);
}

(II) Resource File Configuration and Management

1. Determining the Target Region: Clearly define the languages and regions that the application needs to support, referring to the region identifier (consisting of language, script, country/region, and extension parameters).

2. Creating Resource Directories and Files: - Resource directories include the default (base) directory and qualifier directories (such as resources/en_GB-vertical-car-mdpi). The default directory stores general resources, and the qualifier directories are customized according to languages, scripts, etc., and are used to store resources for specific regions. - Create resource files (such as .json files) in the corresponding directories and classify and store resources such as strings, pictures, and audio. For example, store string resources in different languages in the strings.json file in the corresponding language directory.

3. Resource Matching Rules: The application matches the user's language preference list with the resource directories and displays the most matching resources first. If no matching resources are found, the content in the default directory is used. ### (III) Interface Text Processing

4. Avoiding Hard Coding: Extract all the text displayed on the interface to resource files and load them using relevant interfaces, avoiding directly hard-coding strings in the code. For example, define in the strings.json file:

{
    "name": "welcome_message",
    "value": "欢迎使用应用"
}

Then obtain and display this string in the code through the resource loading mechanism.

1. Supporting Singular and Plural Forms: According to the singular and plural rules of different languages, use methods such as getPluralStringValueSync to correctly handle the singular and plural forms of nouns or unit expressions. For example, in English, for the word "apple", display "apple" (singular) or "apples" (plural) depending on the quantity. ### (IV) Internationalization of Dates, Times, Numbers, and Weights and Measures

2. Date and Time Formatting: - Use the format interface of the DateTimeFormat class to format date and time objects into appropriate strings according to the language and cultural habits of the user's region. For example:

import { intl } from '@kit.LocalizationKit';
let date = new Date(2021, 8, 17, 13, 4, 0);
let dateFormat1 = new intl.DateTimeFormat('zh-CN', {dateStyle: 'full', timeStyle: 'full'});
let formattedDate1 = dateFormat1.format(date); // Friday, September 17, 2021 China Standard Time 13:04:00

- At the same time, pay attention to handling daylight saving time transitions to ensure that the application displays the correct time during daylight saving time. The Calendar class can be used to obtain and set time zones, calculate time offsets related to daylight saving time, etc.

1. Number and Weights and Measures Formatting: - Through the format interface of the NumberFormat class, format numbers according to the user's region settings, including decimal separators, grouped displays, and currency symbols. For example:

import { intl } from '@kit.LocalizationKit';
let numberFormat1 = new intl.NumberFormat('zh-CN', {notation:'scientific', maximumSignificantDigits: 3});
let formattedNumber1 = numberFormat1.format(123400); // 1.23E5

- For weights and measures conversion, use the unitConvert interface of the I18NUtil class to perform unit conversion and formatting according to different weights and measures systems.

(V) Localization Testing and Optimization

1. Comprehensive Testing: Conduct language testing, localization testing, and pseudo-localization testing to cover all functions and interface elements of the application. During the testing process, check issues such as translation accuracy, interface layout rationality, and cultural adaptability.

2. Problem Fixing and Optimization: According to the testing results, promptly fix the discovered problems and optimize the application. This may include adjusting the interface layout, modifying the translation text, optimizing resource loading, etc. At the same time, continuously monitor user feedback and continuously improve the internationalization and localization quality of the application. ### (VI) Continuous Update and Maintenance

3. Language and Resource Updates: With the changes in the market and the evolution of user needs, promptly update the language resources of the application, including the update of translation texts and the support of new languages.

4. Function Adaptation and Optimization: According to the user feedback and market needs in different regions, adapt and optimize the functions of the application to ensure that the application always maintains a good user experience globally. Through the above steps, we can gradually realize the internationalization and localization of HarmonyOS Next applications and create high-quality applications that adapt to the global market. In the actual development process, various language and cultural differences need to be fully considered, attention should be paid to details, and continuous optimization should be carried out to meet the diverse needs of users in different regions.

Original source: The Road to Globalization of HarmonyOS Next Applications: Internationalization and Localization - DEV Community