DEV Community: GeorgeGcs

【HarmonyOS 5】Detailed Guide to Using Progress Bars in HarmonyOS

GeorgeGcs — Mon, 30 Jun 2025 16:11:09 +0000

【HarmonyOS 5】Detailed Guide to Using Progress Bars in HarmonyOS

##HarmonyOS Development Capabilities ##HarmonyOS SDK Application Services##HarmonyOS Financial Applications （Financial Management#

一、Types of Progress Bars in HarmonyOS

HarmonyOS's ArkUI framework provides developers with various types of progress bars, each with unique styles to meet different design needs. Here are several common progress bar types:

Linear Progress Bar: This is the most common progress bar style, displaying progress in a straight line. Starting from API version 9, when the component height is greater than the width, it adapts to vertical display; when the height and width are equal, it remains horizontally displayed.
Ring Progress Bar (without Scale): This progress bar is circular, showing progress through gradual filling of a circular ring. The default foreground color is blue, and the default strokeWidth (progress bar width) is 2.0vp.
Scale Ring Progress Bar (with Scale): It displays a progress effect similar to clock scales. The progress display at the arc ends (head and tail) is the same as the Eclipse style, while the middle section shows a rectangular long bar similar to the Linear style. Starting from API version 9, when the outer scale overlaps, it automatically converts to a ring progress bar without scales.
Eclipse Progress Bar: It displays a progress effect similar to the phases of the moon, changing from a crescent to a full moon.
Capsule Progress Bar: The progress display at the arc ends (head and tail) is the same as the Eclipse style, and the middle section is the same as the Linear style. When the height is greater than the width, it adapts to vertical display.

三、Creating and Configuring Progress Bars with ArkTS

（一）Creating a Progress Bar

In ArkTS, we create a progress bar by calling the Progress interface. The basic syntax for creating a progress bar is as follows:

Progress({ value: number, total?: number, type?: ProgressType })

（二）Setting Progress Bar Styles

When creating a progress bar, we can specify different progress bar types by setting the ProgressType enumeration type for the type optional parameter, achieving diversified styles. Here are setting examples for different types of progress bars:

Linear Progress Bar:

Progress({ value: 50, total: 100, type: ProgressType.Linear })

Ring Progress Bar (without Scale):

Progress({ value: 30, total: 100, type: ProgressType.Ring })

Scale Ring Progress Bar (with Scale):

Progress({ value: 70, total: 100, type: ProgressType.ScaleRing })

Eclipse Progress Bar:

Progress({ value: 10, total: 100, type: ProgressType.Eclipse })

Capsule Progress Bar:

Progress({ value: 45, total: 100, type: ProgressType.Capsule })

（三）Dynamically Updating Progress

One of the key functions of a progress bar is to dynamically update the progress during task execution, reflecting the real-time progress of the task.

In the HarmonyOS Progress component, the progress update effect is achieved through the value and total attributes. The source code is as follows:

Here, value sets the initial progress value, total sets the total progress length, and type determines the Progress style. If type is not set, the linear progress bar style is used by default.

Progress({ value: 24, total: 100, type: ProgressType.Linear })

import prompt from '@ohos.prompt';

@Entry
@Component
struct DownloadProgressBar {
  // Download progress, initial value is 0
  @State progress: number = 0;
  // Download status prompt information
  @State status: string = 'Waiting for download';

  // Simulated download function
  startDownload() {
    // Simulate the download process, use setInterval to update progress periodically
    let intervalId = setInterval(() => {
      this.progress += 10;
      if (this.progress >= 100) {
        this.status = 'Download completed';
        clearInterval(intervalId);
        prompt.showToast({ message: 'Download completed' });
      } else {
        this.status = `Downloading, progress: ${this.progress}%`;
      }
    }, 1000);
  }

  build() {
    Column({ space: 20 }) {
      Text('Download Progress Bar Example')
        .fontSize(20)
        .fontWeight(FontWeight.Bold);

      Progress({ value: this.progress, total: 100 })
        .width('90%')
        .height(20);

      Text(this.status)
        .fontSize(16);

      Button('Start Download')
        .width('60%')
        .height(40)
        .backgroundColor(Color.Blue)
        .fontColor(Color.White)
        .onClick(() => {
          this.startDownload();
        });
    }
    .width('100%')
    .height('100%')
    .alignItems(HorizontalAlign.Center)
    .justifyContent(FlexAlign.Center);
  }
}

【HarmonyOS 5】Detailed Guide to Sensitive Information Local Storage

GeorgeGcs — Mon, 30 Jun 2025 15:56:53 +0000

【HarmonyOS 5】Detailed Guide to Sensitive Information Local Storage

##HarmonyOS Development Capabilities ##HarmonyOS SDK Application Services##HarmonyOS Financial Applications (Financial Management#

Preface

HarmonyOS already ensures the security of user sensitive information through multi-layered security mechanisms. However, on this basis, third-party applications often need to further encrypt sensitive user information for local storage.

This article will expand on HarmonyOS's inherent security mechanisms and finally explain common solutions for local storage of sensitive information.

一、Hardware-Level Security Isolation and Encryption

Trusted Execution Environment (TEE)

TEE, as an independent secure area, is isolated from the main operating system and is used to store core sensitive data such as encryption keys and biometric templates. For example, user fingerprint information is verified within TEE to prevent man-in-the-middle attacks.

Key Management: Key generation, storage, and usage are all completed within TEE. For example, AES encryption keys are generated by a hardware random number generator and stored in TEE's secure storage area to ensure keys are not exposed to the main system.

Full Disk Encryption (FDE)

All data stored on the device is encrypted by default, including user files and application data. Even if the device is lost or cracked, attackers cannot directly read the original data.

Dynamic Encryption: Data is real-time encrypted when written to storage media and automatically decrypted when read, transparent to the user.

二、Software-Level Security Mechanisms

Sandbox Isolation

Each application has an exclusive sandbox directory (/data/data/), which cannot be directly accessed by other applications. For example, a bank application's transaction records stored in the sandbox cannot be read by a social application.

Path Isolation: Applications can only access files within their own sandbox; system files and other application data are strictly restricted.

Data Encryption and Key Management

Symmetric Encryption

Uses the AES algorithm to encrypt local files, databases, etc. For example, user chat records are encrypted and stored using AES-256, with keys managed by TEE.

Asymmetric Encryption

Used for key exchange and digital signatures. For example, when an application synchronizes data across devices, it uses RSA to encrypt session keys to ensure transmission security.

Full Lifecycle Key Management

Key generation, distribution, update, and destruction are uniformly managed by the system. For example, encryption keys are rotated regularly to reduce leakage risks.

Dynamic Permission Management

Principle of Least Privilege

Applications can only apply for necessary permissions. For example, when a map application requests location permission, the system defaults to recommending a blurred location (1km accuracy) instead of precise location.

Real-time Permission Monitoring

When a background application abnormally calls the camera or microphone, the system triggers a "privacy shield" to intercept and notify the user.

Permission Transparency: Users can view the application's 24-hour device usage records in the control center, including camera and microphone activation duration.

三、Privacy Enhancement Technologies

Privacy Space

Independent Encrypted Storage

Users can create a privacy space accessed via fingerprint or password to store highly sensitive data (such as ID cards and bank card information). The privacy space is completely isolated from the main space, with data encrypted and stored.

Hidden Entry

The privacy space entry can be hidden and only activated via a specific fingerprint or password, enhancing concealment.

Secure Erasure

Physical Destruction

When data is deleted, the system uses secure erasure technology (such as multiple overwrites) to ensure data cannot be recovered. For example, after a user deletes chat records, the storage block is overwritten with random data.

Cloud Synchronized Erasure

When a device is lost, users can remotely erase local data through the "Find Device" function to prevent leakage.

四、Distributed Security and Compliance

Cross-Device Data Synchronization

Encrypted Transmission

Data is encrypted using the TLS protocol when synchronized between devices. For example, when contacts are synchronized between a phone and tablet, data is transmitted via SSL encryption.

Device Security Level Matching

Based on device security levels (e.g., phone as SL2, watch as SL1), it restricts the synchronization of data security labels. For example, a watch cannot synchronize confidential-level data.

五、Developer Solutions for Local Sensitive Information Storage

In summary, HarmonyOS constructs an end-to-end sensitive information protection system through multi-dimensional security mechanisms such as hardware isolation, encryption technology, dynamic permissions, and privacy spaces. Its core design philosophy is "least privilege, deep isolation, hardware encryption, and user control," ensuring the security and privacy of user data during storage, transmission, and usage. Developers can easily implement applications that meet the highest security standards through the security APIs and toolchain provided by the system.

1. Encrypt Data Using System Encryption Libraries

HarmonyOS provides encryption and decryption modules supporting algorithms such as AES and RSA. For details, refer to the official documentation: Encryption/Decryption Introduction and Algorithm Specifications.

2. Complete DEMO for Encrypting User IDs Using National Cryptography SM2

The financial industry generally implements encryption through national cryptography or third-party encryption SDKs. The operation logic is consistent with the following example, which uses SM2 encryption combined with preference storage to encrypt and decrypt user IDs locally. This DEMO generates an SM2 key pair, encrypts the user ID with the public key and stores it in preferences, then decrypts the encrypted data using the private key:

import { preferences } from '@ohos.data.preferences';
import { BusinessError } from '@ohos.base';
import { huks } from '@ohos.security.huks';
import { util } from '@ohos.util';
import { common } from '@ohos.app.ability';

// Preference file name
const PREFERENCES_NAME = 'user_id_storage';

// Encryption algorithm enumeration
enum EncryptionAlgorithm {
  SM2 = 'SM2',
  // More algorithms can be added as needed
}

/**
 * Encryption utility class
 */
class EncryptionUtils {
  private keyAlias: string;

  constructor(keyAlias: string) {
    this.keyAlias = keyAlias;
  }

  /**
   * Generate encryption key
   * @param algorithm Encryption algorithm
   */
  async generateKey(algorithm: EncryptionAlgorithm) {
    let properties: Array<huks.HuksParam>;
    switch (algorithm) {
      case EncryptionAlgorithm.SM2:
        properties = [
          {
            tag: huks.HuksTag.ALGORITHM,
            value: huks.HuksKeyAlg.SM2
          },
          {
            tag: huks.HuksTag.KEY_SIZE,
            value: huks.HuksKeySize.SM2_256
          },
          {
            tag: huks.HuksTag.PURPOSE,
            value: huks.HuksKeyPurpose.ENCRYPT | huks.HuksKeyPurpose.DECRYPT
          }
        ];
        break;
      default:
        throw new Error(`Unsupported algorithm: ${algorithm}`);
    }
    const options: huks.HuksOptions = {
      properties
    };
    await huks.generateKeyItem(this.keyAlias, options)
      .then((data) => {
        console.info(`Generate ${algorithm} key success, data = ${JSON.stringify(data)}`);
      })
      .catch((error: Error) => {
        console.error(`Generate ${algorithm} key failed, ${JSON.stringify(error)}`);
        throw error;
      });
  }

  /**
   * Encrypt data
   * @param data Data to be encrypted
   * @param algorithm Encryption algorithm
   * @returns Encrypted data
   */
  async encrypt(data: string, algorithm: EncryptionAlgorithm): Promise<string> {
    let properties: Array<huks.HuksParam>;
    switch (algorithm) {
      case EncryptionAlgorithm.SM2:
        properties = [
          {
            tag: huks.HuksTag.ALGORITHM,
            value: huks.HuksKeyAlg.SM2
          },
          {
            tag: huks.HuksTag.KEY_SIZE,
            value: huks.HuksKeySize.SM2_256
          },
          {
            tag: huks.HuksTag.PURPOSE,
            value: huks.HuksKeyPurpose.ENCRYPT
          },
          {
            tag: huks.HuksTag.DIGEST,
            value: huks.HuksKeyDigest.SM3
          }
        ];
        break;
      default:
        throw new Error(`Unsupported algorithm: ${algorithm}`);
    }
    const options: huks.HuksOptions = {
      properties,
      inData: new Uint8Array(data.split('').map(c => c.charCodeAt(0)))
    };
    let handleObj = await huks.initSession(this.keyAlias, options)
    const result = await huks.finishSession(handleObj.handle, options)
      .catch((error: Error) => {
        console.error(`Finish ${algorithm} encryption session failed: ${JSON.stringify(error)}`);
        throw error;
      });

    const base64Helper = new util.Base64Helper();
    const retStr = base64Helper.encodeToStringSync(result.outData as Uint8Array);
    return retStr;
  }

  /**
   * Decrypt data
   * @param encryptedData Encrypted data
   * @param algorithm Encryption algorithm
   * @returns Decrypted data
   */
  async decrypt(encryptedData: string, algorithm: EncryptionAlgorithm): Promise<string> {
    let properties: Array<huks.HuksParam>;
    switch (algorithm) {
      case EncryptionAlgorithm.SM2:
        properties = [
          {
            tag: huks.HuksTag.ALGORITHM,
            value: huks.HuksKeyAlg.SM2
          },
          {
            tag: huks.HuksTag.KEY_SIZE,
            value: huks.HuksKeySize.SM2_256
          },
          {
            tag: huks.HuksTag.PURPOSE,
            value: huks.HuksKeyPurpose.DECRYPT
          },
          {
            tag: huks.HuksTag.DIGEST,
            value: huks.HuksKeyDigest.SM3
          }
        ];
        break;
      default:
        throw new Error(`Unsupported algorithm: ${algorithm}`);
    }
    const base64Helper = new util.Base64Helper();
    const inData = base64Helper.decodeSync(encryptedData);
    const options: huks.HuksOptions = {
      properties,
      inData
    };
    let handleObj = await huks.initSession(this.keyAlias, options)
    const result = await huks.finishSession(handleObj.handle, options)
      .catch((error: Error) => {
        console.error(`Finish ${algorithm} decryption session failed: ${JSON.stringify(error)}`);
        throw error;
      });

    const retStr = base64Helper.encodeToStringSync(result.outData as Uint8Array);
    return retStr;
  }
}

/**
 * Preference utility class
 */
class PreferencesUtils {
  private preFs: preferences.Preferences | null = null;
  private context: common.UIAbilityContext;

  constructor(context: common.UIAbilityContext) {
    this.context = context;
  }

  /**
   * Initialize preference instance
   */
  async init() {
    const options: preferences.Options = { name: PREFERENCES_NAME };
    this.preFs = await preferences.getPreferences(this.context, options);
  }

  /**
   * Store data
   * @param key Key
   * @param value Value
   */
  async put(key: string, value: string) {
    await this.preFs?.put(key, value)
      .then(() => console.info(`Data ${key} stored successfully`))
      .catch((err: BusinessError) => {
        console.error(`Storage failed: ${err.code}, ${err.message}`);
      });
    await this.preFs?.flush();
  }

  /**
   * Read data
   * @param key Key
   * @returns Value or null
   */
  async get(key: string): Promise<preferences.ValueType> {
    const res = await this.preFs?.get(key, 'default') || "";
    return res;
  }
}

Key Considerations for Sensitive Information Storage

Key Management Best Practices:
- Never hardcode keys in code; use TEE or secure storage provided by the system.
- Implement key rotation policies (e.g., update keys quarterly).
Encryption Algorithm Selection:
- For financial applications, use national cryptography algorithms (SM2, SM4) or industry-standard AES-256.
- Avoid using outdated algorithms (e.g., DES).
Data Classification and Protection:
- Classify data by sensitivity (confidential, private, public) and apply different encryption policies.
- Do not store plaintext sensitive data (e.g., credit card numbers, ID cards).
Compliance and Audit:
- Comply with local data protection regulations (e.g., GDPR, China's Personal Information Protection Law).
- Log encryption/decryption operations for audit purposes, ensuring non-repudiation.

By combining HarmonyOS's native security mechanisms with proper encryption practices, developers can build a robust sensitive information protection system that balances security and user experience.

【HarmonyOS 5】Detailed Explanation of px, vp, and fp Concepts in HarmonyOS Applications

GeorgeGcs — Mon, 30 Jun 2025 15:55:01 +0000

【HarmonyOS 5】Detailed Explanation of px, vp, and fp Concepts in HarmonyOS Applications

## HarmonyOS Development Capabilities ## HarmonyOS SDK Application Services ## HarmonyOS Financial Applications (Financial Management #

一、Preface

Most current HarmonyOS developers transition from front-end or traditional mobile development backgrounds to HarmonyOS application development.

Front-end developers are familiar with development paradigms but may feel uncomfortable with work processes and development methods. The biggest differences between mobile application development and front-end development lie in UI adaptation and performance optimization.

Today, we will analyze the UI adaptation specifications and tips in HarmonyOS.

二、What Are vp, px, and fp in HarmonyOS?

Developers new to HarmonyOS are familiar with pixels (px) but may be confused about vp and fp, only knowing they are required by code specifications or technical guidance:

"Use fp for font sizes and vp for UI values; never use pixels (px) to set controls in UI."

However, the underlying principles are not well understood.

Let's elaborate on the reasons behind this.

1. vp (Virtual Pixel)

The concept of vp is simple: vp is a screen density-related pixel that converts to physical screen pixels based on screen pixel density, maintaining a logical proportional value.

Since vp does not deform across multiple devices, it ensures consistent visual dimensions. When HarmonyOS API interfaces lack unit specifications, the default unit is vp, indicating it is the officially recommended unit.

2. fp (Font Pixel)

Similar to vp, fp adapts to screen density changes and scales with system font size settings, serving as a dedicated unit for font pixels in HarmonyOS.

3. px (Pixel)

Pixels (px) are familiar to mobile developers. Design prototypes and UI renderings typically use px units, which are often converted to dp for proportional use. In HarmonyOS development, to adapt to various devices and screen pixel densities, concepts similar to dp exist—namely, vp and fp.

In HarmonyOS application development, similar to Android, adapting to multiple device types (including foldables) is essential. One of HarmonyOS's features is flexible multi-device adaptation, requiring a single codebase to fit various device displays. Thus, using screen pixel units (px) for UI values is not recommended: different device screen pixel densities would cause UI layout distortion if px were used.

Conclusion: Use vp for component values and fp for font sizes in HarmonyOS application development.

How to Convert px to vp or fp?

Why convert? Design tools still use px units, so we must convert design values. The official provides convenient conversion functions: px2vp and px2fp.

Note the latest API updates: Directly using vp2px/px2vp/fp2px/px2fp/lpx2px/px2lpx may cause UI context ambiguity. It is recommended to use getUIContext() to obtain a UIContext instance and then use instance-bound interfaces like UIContext.px2vp.

Code example:

// Recommended: this.getUIContext().px2vp()  
.width(px2vp(200))

三、UI Development Specification References

UI Design Communication: Before designers slice images from renderings, developers should confirm: slicing styles, whether icons are hollow, whether icons have white edges, icon dimensions, etc.
Image Resource Review: After designers provide sliced images, developers should verify their validity to avoid rework, ensuring they meet development requirements.
Control Dimensions: Convert px dimensions to vp using px2vp(value: number): number.
Font Sizes: Convert px dimensions to fp using px2fp(value: number): number.
Colors: Prefer existing enumeration formats (e.g., Color.Black, Color.White). For custom colors, use 16-digit hexadecimal notation provided by UI designers (e.g., '#FFFFFF').
UI Self-Testing: Developers should self-test dimensions against renderings and conduct UI joint debugging after verification.
UI Joint Debugging: Developers submit the APP UI for testing. Designers obtain functional interface screenshots through the pipeline, compare them with renderings, and verify dynamic multi-device interaction effects after static validation.

【HarmonyOS 5】Detailed Explanation of VisionKit Face Liveness Detection

GeorgeGcs — Mon, 30 Jun 2025 13:48:25 +0000

【HarmonyOS 5】Detailed Explanation of VisionKit Face Liveness Detection

##HarmonyOS Development Capabilities ##HarmonyOS SDK Application Services ##HarmonyOS Financial Applications (Financial Management #

I. What is VisionKit Face Liveness Detection?

VisionKit is a scenario-based visual service toolkit provided by HarmonyOS.

Huawei integrates common solutions, which typically require third-party applications to use SDKs, in the HarmonyOS system in the form of Kits to facilitate rapid development and empowerment for third-party applications.

VisionKit includes the interactiveLiveness function interface for face liveness detection. As the name suggests, face liveness detection is mainly used to detect whether the current person is a real person rather than a photo, silicone mask, or AI-simulated video.

Although this algorithm interface has passed the CECA (China Financial Certification Authority) certification, the official recommendation is to add additional security measures before using this face detection interface, and it is not recommended to directly use it in high-risk payment and financial scenarios. It is recommended for use in low-risk scenarios such as login, attendance, and real-name authentication.

Note: Face liveness detection does not support emulators or previewers.

For details, refer to the official interfaces:

https://developer.huawei.com/consumer/cn/doc/harmonyos-references/vision-interactive-liveness

https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/vision-interactiveliveness

II. How to Use Face Liveness Detection?

The face liveness detection function interactiveLiveness, available from version 5.0.0 (API 12), can be imported via the @kit.VisionKit module. It supports the interactive live detection mode (INTERACTIVE_MODE), with the number of actions configurable as 3 or 4, including 6 actions such as nodding, opening the mouth, and blinking.

Configure detection modes, jump paths, voice announcements, and other parameters through InteractiveLivenessConfig, and provide startLivenessDetection and getInteractiveLivenessResult interfaces to resist photo and video fraud. It is suitable for identity verification scenarios and requires applying for the ohos.permission.CAMERA permission. For error codes, refer to the Vision Kit error code documentation.

Vision Kit Error Code Documentation:

https://developer.huawei.com/consumer/cn/doc/harmonyos-references/vision-error-code

1. Core Interface for Invoking the Face Page:

interactiveLiveness.startLivenessDetection, which requires configuring config to set face modes, actions, etc.

(1) Promise mode: Only returns the jump result (boolean).

interactiveLiveness.startLivenessDetection(routerOptions).then((DetectState: boolean) => {
  hilog.info(0x0001, "LivenessCollectionIndex", `Succeeded in jumping.`);
}).catch((err: BusinessError) => {
  hilog.error(0x0001, "LivenessCollectionIndex", `Failed to jump. Code：${err.code}，message：${err.message}`);
})

(2) Promise + callback mode: Returns both the jump result and detection result (only applicable to BACK_MODE).

interactiveLiveness.startLivenessDetection(routerOptions, (err: BusinessError, result: interactiveLiveness.InteractiveLivenessResult | undefined) => {
  if(err.code !== 0 && !result) {
    hilog.error(0x0001, "LivenessCollectionIndex", `Failed to detect. Code：${err.code}，message：${err.message}`);
    return;
  }
  hilog.info(0x0001, 'LivenessCollectionIndex', `Succeeded in detecting result：${result}`);
})

2. InteractiveLivenessConfig Configuration Interface:

To invoke face liveness detection, this configuration object must be filled in for related settings. For parameters, refer to the following table:

DetectionMode

| Name | Value | Description |

| ----------------- | ------------------- | ------------ |

| SILENT_MODE | "SILENT_MODE" | Silent liveness detection (not yet supported) |

| INTERACTIVE_MODE | "INTERACTIVE_MODE" | Action liveness detection (default mode) |
ActionsNumber

| Name | Value | Description |

| ------------- | ----- | ---------------------------------------- |

| ONE_ACTION | 1 | Random 1 action (not yet supported) |

| TWO_ACTION | 2 | Random 2 actions (not yet supported) |

| THREE_ACTION | 3 | Random 3 actions ([blink, gaze] not present simultaneously and not adjacent, adjacent actions not repeated) |

| FOUR_ACTION | 4 | Random 4 actions (blink only 1 time, gaze at most 1 time, [blink, gaze] not adjacent, adjacent actions not repeated) |
RouteRedirectionMode

| Name | Value | Description |

| ------------- | --------- | -------------------------------- |

| BACK_MODE | "back" | After detection, call router.back to return to the previous page |

| REPLACE_MODE | "replace" | After detection, call router.replaceUrl to jump (default mode) |
InteractiveLivenessConfig

| Name | Type | Required/Optional | Description |

| ------------------ | -------------------- | -------- | ----------------------------------------------- |

| isSilentMode | DetectionMode | Required | Detection mode (default INTERACTIVE_MODE) |

| actionsNum | ActionsNumber | Optional | Number of actions (3 or 4, default 3) |

| successfulRouteUrl | string | Optional | Successful detection jump path (uses system default page if not filled) |

| failedRouteUrl | string | Optional | Failed detection jump path (uses system default page if not filled) |

| routeMode | RouteRedirectionMode | Optional | Jump mode (default REPLACE_MODE) |

| challenge | string | Optional | Security camera scenario challenge value (16-128 bits, empty value means not used) |

| speechSwitch | boolean | Optional | Voice announcement switch (default on) |

| isPrivacyMode | boolean | Optional | Privacy mode (requires applying for ohos.permission.PRIVACY_WINDOW permission, default off) |

The configuration object for face liveness detection requires isSilentMode, with other properties optional:

import { interactiveLiveness } from '@kit.VisionKit';

let isSilentMode = "INTERACTIVE_MODE" as interactiveLiveness.DetectionMode;
let routeMode = "replace" as interactiveLiveness.RouteRedirectionMode;
let actionsNum = 3 as interactiveLiveness.ActionsNumber;
let routerOptions: interactiveLiveness.InteractiveLivenessConfig = {
  isSilentMode: isSilentMode,
  routeMode: routeMode,
  actionsNum: actionsNum,
  failedRouteUrl: "pages/FailPage",
  successfulRouteUrl: "pages/SuccessPage"
}

3. getInteractiveLivenessResult to Obtain Face Liveness Detection Results:

After successfully invoking face liveness detection, use this interface to obtain detection results. The result content is as follows:

Name	Type	Read-Only	Optional	Description
livenessType	LivenessType	Yes	No	Liveness detection mode, values include: - `0` (INTERACTIVE_LIVENESS, action liveness detection) - `1` (SILENT_LIVENESS, silent liveness detection, not yet supported) - `2` (NOT_LIVENESS, non-live)
mPixelMap	image.PixelMap	Yes	Yes	The most characteristic live image returned after successful detection (such as a feature map including face key points), no data when detection fails.
securedImageBuffer	ArrayBuffer	Yes	Yes	Secure stream data (encrypted image feature data) returned in security camera scenarios, no data in non-security scenarios.
certificate	Array	Yes	Yes	Certificate chain returned in security camera scenarios (used to verify the legitimacy of the secure stream), no data in non-security scenarios.

let successResult = interactiveLiveness.getInteractiveLivenessResult();
successResult.then(data => {
  hilog.info(0x0001, "LivenessCollectionIndex", `Succeeded in detecting.`);
}).catch((err: BusinessError) => {
  hilog.error(0x0001, "LivenessCollectionIndex", `Failed to detect. Code：${err.code}，message：${err.message}`);
})

III. DEMO Source Code Example

import { interactiveLiveness } from '@kit.VisionKit';
import { BusinessError } from '@kit.BasicServicesKit';
import { hilog } from '@kit.PerformanceAnalysisKit';
import { abilityAccessCtrl, common } from '@kit.AbilityKit';

@Entry
@Component
struct FaceLivenessDemo {
  @State userGrant: boolean = false // Permission status
  @State detectionResult: string = "" // Detection result display
  @State actionCount: interactiveLiveness.ActionsNumber = interactiveLiveness.ActionsNumber.THREE_ACTION; // Number of actions (3 or 4)
  @State speechEnabled: boolean = true // Voice announcement switch
  // Indicates returning to the previous page using router.back after face liveness detection is completed.
  @State routeMode: interactiveLiveness.RouteRedirectionMode = interactiveLiveness.RouteRedirectionMode.BACK_MODE; // Jump mode

  // Permission application logic
  private async requestPermissions() {
    const context = getContext() as common.UIAbilityContext;
    const atManager = abilityAccessCtrl.createAtManager();
    const results = await atManager.requestPermissionsFromUser(context, ["ohos.permission.CAMERA"]);
    this.userGrant = results.authResults.every(status => status === 0);
  }

  // Detection configuration generation
  private generateDetectionConfig(): interactiveLiveness.InteractiveLivenessConfig {
    return {
      // Represents the face liveness detection mode, default action liveness detection mode.
      // INTERACTIVE_MODE represents the action liveness detection mode.
      isSilentMode: interactiveLiveness.DetectionMode.INTERACTIVE_MODE,

      // Represents the number of actions for action liveness detection, with a range of 3 or 4, default 3 actions. Randomly generated with the following rules:
      //
      // When actionsNum=3, actions in the [blink, gaze] combination will not exist simultaneously, and adjacent actions will not be the same.
      //
      // When actionsNum=4, the blink action occurs exactly once, the gaze action occurs at most once, actions in the [blink, gaze] combination are not adjacent, and adjacent actions are not the same.
      //
      // This parameter is only valid when isSilentMode is INTERACTIVE_MODE.
      actionsNum: this.actionCount,
      // Represents the page path to jump to after successful face liveness detection. If not filled, the system has a default successful detection page.
      // successfulRouteUrl: "pages/result/success", // Custom successful jump path (page needs to be created in advance)

      // Represents the page path to jump to after failed face liveness detection. If not filled, the system has a default failed detection page.
      // failedRouteUrl: "pages/result/fail", // Custom failed jump path (page needs to be created in advance)

      routeMode: this.routeMode, // Jump mode

      // Voice announcement switch.
      //
      // true indicates enabling voice announcement.
      // false indicates disabling voice announcement.
      // Voice announcement is enabled by default.
      speechSwitch: this.speechEnabled, // Voice announcement control

      // Challenge value. Only used for liveness detection in security camera scenarios (corresponding to the "userData" field in the initializeAttestContext method).
      //
      // Using security camera scenarios requires enabling the Device Security service.
      //
      // The length range is between 16-128 (challenge passed as empty or undefined means not using a security camera).
      // challenge: "自定义挑战值1234567890abcdef", // Optional for security camera scenarios

      // Whether to set privacy mode.
      //
      // true: Set privacy mode.
      // false: Do not set privacy mode.
      // The default value is false.
      // isPrivacyMode: true // Privacy mode requires additional permissions. When setting privacy mode, apply for the ohos.permission.PRIVACY_WINDOW permission.
    };
  }

  // Start detection
  private async startDetection() {
    if (!this.userGrant) {
      this.detectionResult = "Please apply for camera permission first";
      return;
    }

    const config = this.generateDetectionConfig();

    try {
      const jumpSuccess = await interactiveLiveness.startLivenessDetection(config);
      if (jumpSuccess) {
        hilog.info(0x0001, "Detection", "Successfully jumped to the detection page");
        // Obtain the result after detection is completed (needs to be called when returning to the page)
        const result = await interactiveLiveness.getInteractiveLivenessResult();
        this.processResult(result);
      }
    } catch (err) {
      const error = err as BusinessError;
      hilog.error(0x0001, "Detection", `Detection failed: error code ${error.code}, message ${error.message}`);
      this.detectionResult = `Detection exception: error code ${error.code}`;
    }
  }

  // Result processing
  private processResult(result: interactiveLiveness.InteractiveLivenessResult) {
    let status = "";
    let livenessType = result.livenessType;
    switch (livenessType) {
      case 0: // Action liveness detection successful
        status = "Liveness detection passed";
        // Process feature images or secure data here
        break;
      case 2: // Non-live
        status = "Non-live detected (photo/video fraud)";
        break;
      default:
        status = "Detection result exception";
    }
    this.detectionResult = status;
  }

  build() {
    Column({ space: 40 })
    {
      // Permission application button
      Button(this.userGrant ? "Permission authorized" : "Apply for camera permission")
        .fontSize(18)
        .margin(10)
        .padding(12)
        .backgroundColor(this.userGrant ? Color.Green : Color.Blue)
        .onClick(() => this.requestPermissions())

      // Action count selection
      Row({ space: 20 }) {
        Text("Number of actions:")
          .fontSize(16)

        Button("3 actions")
          .backgroundColor(this.actionCount === 3 ? Color.Blue : Color.White)
          .border({ width: 1, color: Color.Gray })
          .onClick(() => this.actionCount = 3)

        Button("4 actions")
          .backgroundColor(this.actionCount === 4 ? Color.Blue : Color.White)
          .border({ width: 1, color: Color.Gray })
          .onClick(() => this.actionCount = 4)
      }

      // Voice announcement switch
      Toggle({ type: ToggleType.Checkbox, isOn: this.speechEnabled })
        .onChange((isOn: boolean) => {
          this.speechEnabled = isOn;
        })

      // Jump mode selection
      Row({ space: 20 }) {
        Text("Jump mode:")
          .fontSize(16)

        Button("Replace page")
          .backgroundColor(this.routeMode === "replace" ? Color.Blue : Color.White)
          .border({ width: 1, color: Color.Gray })
          .onClick(() => {
            this.routeMode = interactiveLiveness.RouteRedirectionMode.REPLACE_MODE;
          })

        Button("Return to previous page")
          .backgroundColor(this.routeMode === "back" ? Color.Blue : Color.White)
          .border({ width: 1, color: Color.Gray })
          .onClick(() => {
            this.routeMode = interactiveLiveness.RouteRedirectionMode.BACK_MODE;
          })
      }

      // Start face liveness detection button
      Button("Start face liveness detection")
        .fontSize(20)
        .padding(16)
        .backgroundColor(Color.Orange)
        .onClick(() => this.startDetection())

      // Result display
      Text(this.detectionResult)
        .fontSize(16)
        .margin({
          top: 30
        })
        .foregroundColor(this.detectionResult.includes("通过") ? Color.Green : Color.Red)
    }
    .width("100%")
    .height("100%")
    .justifyContent(FlexAlign.Center)
    .alignItems(HorizontalAlign.Center)
  }
}

Notes:

1. Two supported modes for face liveness detection

INTERACTIVE_MODE (action liveness detection): The default mode requires the user to complete 3 or 4 random actions (such as blinking, nodding, etc.), verifying liveness through action combinations with rules to avoid repeated adjacent actions or specific combinations (e.g., blinking and gazing are not adjacent).
SILENT_MODE (silent liveness detection): Not yet supported, detects liveness through other technologies (such as micro-expressions, light reflection) without user actions.

2. Configuring the number of actions and jump logic for face liveness detection

Configure via actionsNum in InteractiveLivenessConfig, with optional values 3 (default) or 4. For 3 actions, [blink, gaze] do not exist simultaneously and are not adjacent; for 4 actions, blink occurs only once, gaze at most once.
Configure the jump mode via routeMode (BACK_MODE to return to the previous page or REPLACE_MODE to replace the jump, default REPLACE_MODE).
Set custom jump paths for success/failure via successfulRouteUrl and failedRouteUrl (uses system default pages if not filled).

3. Common errors and handling:

201 (Permission denied): ohos.permission.CAMERA permission not applied.
1008301002 (Route switching failed): Incorrect route configuration. Check if successfulRouteUrl/failedRouteUrl paths are correct or if routeMode matches page routing.
1008302000-1008302004 (detection-related errors): Algorithm initialization failure, timeout, or actions not conforming to rules during detection. Catch error codes via callbacks or Promise's catch, prompt the user to re-detect, and check action compliance.

【HarmonyOS 5】Detailed Explanation of UIAbility in HarmonyOS (Part 1)

GeorgeGcs — Mon, 30 Jun 2025 13:47:43 +0000

【HarmonyOS 5】Detailed Explanation of UIAbility in HarmonyOS (Part 1)

HarmonyOS Development Capabilities ##HarmonyOS SDK Application Services##HarmonyOS Financial Applications (Financial Management#

一、What is UIAbility?

UIAbility is a component type name in the Stage model. The UIAbility component includes a UI and provides the capability to display the UI, mainly used for interacting with users.

UIAbility is similar to Activity or Fragment in traditional Android mobile development, and analogous to UIViewController in iOS development. It is a core component of the HarmonyOS application framework, responsible for managing the user interface lifecycle and context information of the application.

二、Setting a Specified Launch Page

The launch page must be set; otherwise, the application will show a white screen after launching.

To avoid a white screen after application launch, set the default loading page in the onWindowStageCreate lifecycle. Use the loadContent() method of WindowStage to specify the page path.

export default class EntryAbility extends UIAbility {
  onWindowStageCreate(windowStage: window.WindowStage): void {
    windowStage.loadContent('pages/Index', (err, data) => { /* Handle callback */ });
  }
}

DevEco Studio automatically loads the Index page for default-generated projects, which can be modified as needed.

三、Obtaining Context Information (UIAbilityContext)

Obtain application configuration information (such as package name, Ability name, etc.) or call methods to operate on Abilities (such as starting or terminating an Ability) by directly accessing this.context.

export default class EntryAbility extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    const context = this.context; // Directly obtain the context
  }
}

Obtaining in page components:

Convert via getUIContext().getHostContext() to UIAbilityContext.

@Entry
@Component
struct Page {
  private context = this.getUIContext().getHostContext() as common.UIAbilityContext;
  startAbilityTest() { this.context.startAbility(want); } // Start another Ability
}

Code Example for Launch Page Setting and Context Usage

// UIAbility definition
export default class EntryAbility extends UIAbility {
  onWindowStageCreate(windowStage: window.WindowStage) {
    windowStage.loadContent('pages/Main', () => {}); // Set the launch page
  }

  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) {
    const context = this.context; // Obtain the context
    context.startAbility({ abilityName: 'OtherAbility' }); // Start another Ability
  }
}

// Using context in page components
@Entry
@Component
struct MainPage {
  private context = this.getUIContext().getHostContext() as common.UIAbilityContext;
  build() {
    Button('Terminate Current Ability').onClick(() => this.context.terminateSelf());
  }
}

四、UIAbility Lifecycle and Operations

The UIAbility lifecycle includes four core states: Create, Foreground, Background, and Destroy, as well as sub-states related to the window (WindowStage). Through lifecycle callback hooks, you can listen for state changes and perform corresponding operations.

Lifecycle State Flow Chart

Instance creation      Window creation      Enter foreground        Switch to background        Window destruction      Instance destruction
  ↓                   ↓                    ↓                      ↓                          ↓                      ↓
onCreate() → onWindowStageCreate() → onForeground() → onBackground() → onWindowStageDestroy() → onDestroy()
         ↑       ↖                    ↗                    ↖                    ↑
         └─────── WindowStageWillDestroy() ────────────────────────┘

1. onCreate

Triggered when the UIAbility instance is created. Use it to initialize page data and load resources (such as defining variables and obtaining the context this.context).

export default class EntryAbility extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) {
    // Initialization operations (e.g., obtaining context, configuring data)
    const context = this.context; 
  }
}

2. onWindowStageCreate

Triggered when the system creates a WindowStage after the UIAbility instance is created and before it enters the foreground. Use it to set the launch page (loadContent()) and subscribe to window events (such as foreground/background switching and focus changes).

onWindowStageCreate(windowStage: window.WindowStage) {
  windowStage.loadContent('pages/Index'); // Set the launch page
  windowStage.on('windowStageEvent', (event) => { // Subscribe to window events
    switch (event) {
      case window.WindowStageEventType.SHOWN: // Switch to foreground
        console.log('Window switched to foreground');
        break;
    }
  });
}

3. onWindowStageWillDestroy

Triggered before the WindowStage is destroyed (the window is still usable at this time). Release resources obtained through the WindowStage and unsubscribe from events (off('windowStageEvent')).

4. onWindowStageDestroy

Triggered when the WindowStage is destroyed (UI resources are released). Release UI-related resources (such as temporary files and graphic objects).

5. onForeground

Triggered before the UIAbility switches to the foreground and the UI becomes visible. Use it to apply for system resources (such as location and sensor permissions) and restore resources released in the background.

onForeground() {
  // Enable location function
  location.start(); 
}

6. onBackground

Triggered after the UIAbility switches to the background and the UI is completely invisible. Use it to release unused resources and perform time-consuming operations (such as data persistence).

onBackground() {
  // Stop location and save the current state
  location.stop(); 
  saveDataToLocal();
}

7. onDestroy

Triggered when the UIAbility instance is terminated (such as by calling terminateSelf()). Use it to release global resources and clean up memory (such as closing network connections and unsubscribing from listeners).

onDestroy() {
  // Release database connection and cancel the timer
  db.close(); 
  clearInterval(timer);
}

Note: In API 13+, if the user clears the application through the recent tasks list, onDestroy() will not be triggered; instead, the process will be terminated directly.

四、Common Functional Operations of UIAbility

1. Terminating the UIAbility Instance

Call terminateSelf() to terminate the current Ability.

context.terminateSelf((err) => {
  if (err) { console.error('Termination failed:', err); } 
  else { console.info('Termination successful'); }
});

2. Obtaining Caller Information

When UIAbilityA starts UIAbilityB via startAbility, UIAbilityB can obtain information about the caller.

export default class UIAbilityB extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    console.log(`Caller Pid: ${want.parameters?.['ohos.aafwk.param.callerPid']}`);
  }
}

Code Example for Cross-Ability Information Transfer

// Starting UIAbilityB in UIAbilityA
@Entry
@Component
struct UIAbilityAPage {
  private context = this.getUIContext().getHostContext() as common.UIAbilityContext;
  build() {
    Button('Launch UIAbilityB').onClick(() => {
      this.context.startAbility({ 
        bundleName: this.context.abilityInfo.bundleName, 
        abilityName: 'UIAbilityB' 
      });
    });
  }
}

// Obtaining caller information in UIAbilityB
export default class UIAbilityB extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) {
    console.log(`Caller package name: ${want.parameters?.['ohos.aafwk.param.callerBundleName']}`);
  }
}

Note

When the UIAbility is set to the singleton launch mode, repeatedly calling startAbility() to launch the same instance will not trigger the onCreate and onWindowStageCreate processes again, but will trigger the onNewWant callback.

onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam) {
  // Update page data based on new Want parameters
  this.data = want.parameters?.data; 
}

【HarmonyOS 5】Detailed Explanation of Stage Model and FA Model in HarmonyOS

GeorgeGcs — Mon, 30 Jun 2025 13:41:29 +0000

【HarmonyOS 5】Detailed Explanation of Stage Model and FA Model in HarmonyOS

HarmonyOS Development Capabilities ## HarmonyOS SDK Application Services ## HarmonyOS Financial Applications (Financial Management #

一、Preface

In the application development model of HarmonyOS 5, featureAbility is the usage of the old FA model (Feature Ability), while the Stage model adopts a brand-new application architecture, recommending the use of componentized context acquisition methods instead of relying on featureAbility.

The FA model was used before API 7. A development model refers to the system container and interfaces on which you develop after creating a HarmonyOS development project.

When I first developed OpenHarmony, I used the FA model. Due to its inconveniences, the official introduced the Stage model around API 8 for initial replacement. As the name suggests, the Stage model develops applications on a stage container provided by the system, featuring better low coupling, high cohesion, and more reasonable and efficient application process management.

This article focuses on the differences between the Stage model and the FA model, as well as how to obtain context in the Stage model.

二、Core Differences Between Stage Model and FA Model

The following table is sorted from official documentation. It is recommended to have a general understanding of the FA model while focusing on the Stage model.

Feature	Stage Model (Recommended)	FA Model (Legacy)
Application Unit	Based on `AbilityStage`, manages UI components through `UIAbility`	Focuses on `FeatureAbility` and `PageAbility`
Context Acquisition	Through the component `context` property or `@ohos.app.ability.Context`	Uses `featureAbility.getContext()`
Lifecycle Management	Lifecycle callbacks based on `UIAbility` (`onCreate`/`onDestroy`)	Lifecycle based on `FeatureAbility`

In HarmonyOS 5 Stage model development, featureAbility belongs to outdated FA model interfaces, and context must be obtained through the component or the context property of UIAbility. This change reflects the Stage model's design philosophy of "everything is a component," ensuring a simpler code structure, more thorough componentization, and avoiding coupling with legacy APIs.

三、Correct Context Acquisition in Stage Model

In the Stage model, the context of a component (Context) is directly obtained through the context property of the component instance, without using featureAbility.

Code Example:

// In the Stage model, directly obtain context via this.context within the component  
@Entry  
@Component  
struct FileStorageDemo {  
  // File writing  
  async writeToFile() {  
    try {  
      // Correct way: Use the component's context property  
      const filesDir = await this.context.getFilesDir();  
      const filePath = `${filesDir}/example.txt`;  
      const fd = await fileio.open(filePath, 0o102); // 0o102 represents write mode (O_WRONLY | O_CREAT)  
      const data = 'File storage example under Stage model';  
      await fileio.write(fd, data);  
      await fileio.close(fd);  
      console.log('File written successfully');  
    } catch (error) {  
      console.error('File writing failed:', error);  
    }  
  }  

  // File reading  
  async readFromFile() {  
    try {  
      const filesDir = await this.context.getFilesDir();  
      const filePath = `${filesDir}/example.txt`;  
      const fd = await fileio.open(filePath, 0o100); // 0o100 represents read mode (O_RDONLY)  
      const buffer = new ArrayBuffer(1024);  
      const bytesRead = await fileio.read(fd, buffer);  
      const data = new TextDecoder('utf-8').decode(buffer.slice(0, bytesRead));  
      await fileio.close(fd);  
      console.log('File content:', data);  
    } catch (error) {  
      console.error('File reading failed:', error);  
    }  
  }  

  build() {  
    Column() {  
      Button('Write to File').onClick(() => this.writeToFile())  
      Button('Read from File').onClick(() => this.readFromFile())  
    }  
  }  
}

Context Acquisition Principles

Directly use this.context within components (context property inherited from Component).
Use this.context in UIAbility (representing the context of the current Ability).
Avoid any legacy APIs starting with featureAbility.

【HarmonyOS 5】Detailed Explanation of Privacy Protection in HarmonyOS Applications

GeorgeGcs — Sun, 29 Jun 2025 16:41:58 +0000

【HarmonyOS 5】Detailed Explanation of Privacy Protection in HarmonyOS Applications

HarmonyOS Development Capabilities ## HarmonyOS SDK Application Services ## HarmonyOS Financial Applications (Financial Management #

一、Preface

In today's era where smartphones are indispensable, we use our devices for payments, communication, and daily records, unknowingly storing vast amounts of personal information. But have you ever considered the consequences of privacy data leaks? From spam calls to identity theft, the risks are significant. Fortunately, HarmonyOS has implemented comprehensive privacy protection measures.

Imagine strangers accessing your health data, chat logs, or payment passwords—terrifying, isn't it? Privacy breaches not only violate personal rights but also pose financial risks. Moreover, privacy protection is a legal requirement and a corporate responsibility. HarmonyOS prioritizes privacy at every level, from the system core to application development.

二、Six Golden Principles of HarmonyOS Privacy Protection

HarmonyOS provides developers with strict privacy protection guidelines, acting as a "security manual" to ensure every application safeguards user privacy:

Transparency & Disclosure

Applications must explicitly inform users about collected data and its purposes, avoiding hidden practices.
Data Minimization

Collect only necessary data. For example, a weather app only needs your city, not precise location.
User Consent

All data processing requires user authorization, with the right to revoke consent at any time.
Enhanced Security

Data is encrypted throughout storage and transmission, protected by advanced encryption.
Local Processing Priority

Process data locally whenever possible. Cloud uploads must adhere to the "minimum necessary" principle.
Special Protection for Minors

Applications targeting minors must comply with relevant laws, requiring parental consent for data collection.

三、Developer's "Privacy Protection Toolkit"

To implement these principles, HarmonyOS offers developers practical security tools:

1. Privacy Statement Dialog: Empowering User Awareness

When launching an app, the privacy statement dialog (though seemingly verbose) serves to inform users: "We collect this data for these purposes—proceed only with your consent." This transparency allows users to make informed decisions and retain control.

Key Developer Considerations:

(1) Clearly specify collected data.

(2) Explain data usage.

(3) Obtain explicit user consent.

Code Example:

Implementing a privacy statement dialog in the "HMOS World" app (SafePage.ets):

// Assume dialog components and logic are defined here  
@Entry  
@Component  
struct SafePage {  
  build() {  
    // Dialog layout and interaction logic  
    if (!this.isAgreed) {  
      Dialog()  
        .title('Privacy Statement')  
        .message('This app collects basic information to enable features...')  
        .button('Agree', () => {  
          this.isAgreed = true;  
          // Navigate to the main interface  
          router.pushUrl({  
            url: '/pages/MainPage'  
          });  
        })  
        .button('Disagree', () => {  
          // Handle disagreement (e.g., exit app)  
          exit();  
        });  
    } else {  
      // User agreed; display app content  
      Column() {  
        // Main interface components  
      }  
    }  
  }  
}

2. Fuzzy Location: Protecting Your Movements

Many are unaware that location services offer both "precise" and "fuzzy" options. For apps that don’t require exact coordinates (e.g., music players), HarmonyOS recommends fuzzy location, which reveals only city/region-level information. This balances functionality with privacy.

Location Permission Application对照表:

| Target API Level | Permission Requested | Result | Location Precision |

|------------------|------------------------------|----------------|----------------------------|

| <9 | ohos.permission.LOCATION | Success | Precise (meter-level) |

| ≥9 | ohos.permission.LOCATION | Failure | No access |

| ≥9 | ohos.permission.APPROXIMATELY_LOCATION | Success | Fuzzy (5km precision) |

| ≥9 | Both permissions | Success | Precise (meter-level) |

Code Example:

Declare permissions in module.json5:

{  
  "module": {  
    // ...  
    "requestPermissions": [  
      {  
        "name": "ohos.permission.APPROXIMATELY_LOCATION",  
        "reason": "$string:location_reason",  
        "usedScene": {  
          "abilities": [  
            "EntryAbility"  
          ],  
          "when": "inuse"  
        }  
      },  
      // ...  
    ],  
  }  
}

Dynamically request permissions and retrieve location:

import geoLocationManager from '@ohos.geoLocationManager';  
import abilityAccessCtrl from '@ohos.abilityAccessCtrl';  
import Logger from '@ohos.hilog';  

let atManager = abilityAccessCtrl.createAtManager();  
atManager.requestPermissionsFromUser(getContext(this), ['ohos.permission.APPROXIMATELY_LOCATION'])  
  .then((data) => {  
    Logger.info(`request permissions result: ${JSON.stringify(data)}`);  
    let requestInfo: geoLocationManager.LocationRequest = {  
      'priority': geoLocationManager.LocationRequestPriority.FIRST_FIX,  
      'scenario': geoLocationManager.LocationRequestScenario.UNSET,  
      'timeInterval': 1,  
      'distanceInterval': 0,  
      'maxAccuracy': 0  
    };  

    geoLocationManager.getCurrentLocation(requestInfo).then((result) => {  
      Logger.info(`geoLocationManager current location: ${JSON.stringify(result)}`);  
      // Process location data  
    }).catch((error: BusinessError) => {  
      Logger.error(`geoLocationManager promise, getCurrentLocation: error: ${JSON.stringify(error)}`);  
    });  
  });

3. Picker Selector: Avoiding "Data Sweeps"

Previously, storage permissions gave apps unrestricted access to all files. With the Picker selector, users can now grant access to specific files or photos, similar to selecting items in a supermarket. For example, when sharing a photo on social media, the app only accesses the selected image, leaving other data untouched.

Code Example:

import { photoAccessHelper } from '@kit.MediaLibraryKit';  
import { BusinessError } from '@kit.BasicServicesKit';  

const photoSelectOptions = new photoAccessHelper.PhotoSelectOptions();  
photoSelectOptions.MIMEType = photoAccessHelper.PhotoViewMIMETypes.IMAGE_TYPE;  
photoSelectOptions.maxSelectNumber = 5;  
const photoViewPicker = new photoAccessHelper.PhotoViewPicker();  
photoViewPicker.select(photoSelectOptions).then((photoSelectResult) => {  
  this.imageUri = photoSelectResult.photoUris[0];  
  console.log(`PhotoViewPicker.select successfully, uris: ${JSON.stringify(photoSelectResult)}`);  
}).catch((err: BusinessError) => {  
  console.error(`PhotoViewPicker.select failed with err: ${JSON.stringify(err)}`);  
});

4. Dynamic Permission Requests: Authorizing Only What’s Needed

When requesting sensitive permissions (e.g., camera, contacts), apps must explicitly state their purpose: "Camera access is required for QR code scanning." Developers should only request essential permissions, preventing overreach.

Code Example:

Declare camera permission in module.json5:

{  
  "module": {  
    // ...  
    "requestPermissions": [  
      {  
        "name": "ohos.permission.CAMERA",  
        "reason": "$string:camera_reason",  
        "usedScene": {  
          "abilities": [  
            "EntryAbility"  
          ],  
          "when": "inuse"  
        }  
      }  
    ],  
  }  
}

Define permission rationale in string.json:

{  
  "string": [  
    {  
      "name": "camera_reason",  
      "value": "QR code scanning requires camera access to capture images"  
    }  
  ]  
}

Dynamically request permission in code:

import abilityAccessCtrl from '@ohos.abilityAccessCtrl';  
import Logger from '@ohos.hilog';  

let atManager = abilityAccessCtrl.createAtManager();  
atManager.requestPermissionsFromUser(getContext(this), ['ohos.permission.CAMERA'])  
  .then((data) => {  
    let grantStatus: Array<number> = data.authResults;  
    if (grantStatus.length > 0 && grantStatus[0] === 0) {  
      // Permission granted; proceed  
      Logger.info('request permissions granted');  
      // Execute QR code scanning logic  
    } else {  
      // Permission denied  
      Logger.info('request permissions denied');  
      // Handle denial (e.g., show prompt)  
    }  
  });

Summary: Three Key Points of Privacy Protection

Transparency & Control: Users understand data usage.
Data Minimization: Collect only essential data.
Full-Stack Encryption: Secure data from storage to transmission.

【HarmonyOS 5】Detailed Explanation of Laya Game Building and Publishing for HarmonyOS

GeorgeGcs — Sun, 29 Jun 2025 16:41:20 +0000

【HarmonyOS 5】Detailed Explanation of Laya Game Building and Publishing for HarmonyOS

##HarmonyOS Development Capabilities ##HarmonyOS SDK Application Services ##HarmonyOS Financial Applications (Financial Management #

I. Preface

LayaAir engine is one of the most powerful cross-platform engines in China. When H5 mini-games became popular, Tencent invested in Laya. When I was working in a game company in 2017, I developed H5 mini-games using Laya, and I still miss the time spent solving problems with Laya colleagues.

From using TypeScript as the development language to interface component encapsulation and cross-platform publishing, Laya's journey is similar to that of HarmonyOS, with many design concepts closely aligned. As an open-source foundation with customized commercialization for cross-platform development, Laya holds a significant market share in the H5 engine sector.

Founded in 2014, Layabox released its open-source engine product LayaAir in 2016, which now has over a million global developers, making it a leading 3D engine in the HTML5 and mini-game fields.

In addition to H5 3D mini-games, Laya can also develop H5 applications or H5 2D mini-games through its 2D engine.

As a new operating system, HarmonyOS can greatly enrich its ecosystem with the support of H5 mini-games and applications. Moreover, Laya's simple development and entry-level learning curve offer broad future prospects for mini-game and H5 developers in the HarmonyOS market.

This article focuses on Laya's background, development environment installation, and HarmonyOS build and release processes.

II. LayaAir Environment Installation

Official environment setup article, click to jump

LayaAir consists of two parts: the game engine and coding tools. Initially, it used a self-developed IDE, but later switched the coding environment to VSCode.

Therefore, to set up the Laya environment, we first need to install LayaAirIDE and VSCode.

Since Laya uses TypeScript as the programming language, we need to install the Node development environment and TSC (TypeScript Compiler) to convert TS code into JS code. Ultimately, Laya's code is in JavaScript.

npm install -g typescript

A browser is required for debugging (optional). For Windows systems, the built-in Edge browser can be used, or Google Chrome can be installed.

The following image shows the effect after creating and opening a 2D sample project using LayaAirIDE:

III. HarmonyOS Build and Release

Click File > Build & Release, select HarmonyOS NEXT, make no changes to the right-side settings, and click Build HarmonyOS NEXT.
For the rendering mode, considering that HarmonyOS has a separate rendering process for the web, select WebGL instead of OpenGL.
After clicking Build & Release, wait for the progress bar to complete (this may take some time).
Once the progress bar is complete, the HarmonyOS project code will appear. Click the arrow to navigate to the source project, then use DevEco Studio to automatically sign the HarmonyOS project and run the Laya mini-game.

The above image is a static screenshot of the Laya 2D sample project running on a HarmonyOS device. Currently, the automatically built HarmonyOS SDK uses API 11. Attempts to modify it to API 2 or API 17 result in errors, so we need to wait for official updates. The overall effect is promising.

From the built HarmonyOS project's Index entry file, we can see that official collaboration with Laya has introduced many supporting custom Component components, such as LayaEditBox, LayaWebview, and TextInputDialog.

import laya from 'liblaya.so'
import { ContextType } from '@ohos/libSysCapabilities'
import { TextInputInfo } from '@ohos/libSysCapabilities/src/main/ets/components/EditBox'
import { TextInputDialogEntity } from '@ohos/libSysCapabilities'
import { WebViewInfo } from '@ohos/libSysCapabilities/src/main/ets/components/webview/WebViewMsg'
import { VideoPlayerInfo } from '@ohos/libSysCapabilities/src/main/ets/components/videoplayer/VideoPlayer'
import { WorkerMsgUtils } from '@ohos/libSysCapabilities/src/main/ets/utils/WorkerMsgUtils'
import { WorkerManager } from '../workers/WorkerManager'
import { LayaEditBox } from '../components/LayaEditBox'
import { LayaWebview } from '../components/LayaWebview'
import { LayaVideoPlayer } from '../components/LayaVideoPlayer'
import { TextInputDialog } from '../components/TextInputDialog'
import { GlobalContext, GlobalContextConstants } from "@ohos/libSysCapabilities"
import { NapiHelper } from "@ohos/libSysCapabilities/src/main/ets/napi/NapiHelper"
import { Dialog } from "@ohos/libSysCapabilities"
import deviceInfo from '@ohos.deviceInfo';
import promptAction from '@ohos.promptAction'
import process from '@ohos.process';
import { LayaHttpClient } from '@ohos/libSysCapabilities/src/main/ets/system/network/LayaHttpClient'

const nativePageLifecycle: laya.CPPFunctions = laya.getContext(ContextType.JSPAGE_LIFECYCLE);
NapiHelper.registerUIFunctions();

let layaWorker = WorkerManager.getInstance().getWorker();
@Entry
@Component
struct Index {
  xcomponentController: XComponentController = new XComponentController();
  // EditBox
  @State editBoxArray: TextInputInfo[] = [];
  private editBoxIndexMap: Map<number, TextInputInfo> = new Map;
  // WebView
  @State webViewArray: WebViewInfo[] = [];
  private webViewIndexMap: Map<number, number> = new Map;
  // videoPlayer
  @State videoPlayerInfoArray: VideoPlayerInfo[] = [];
  private videoPlayerIndexMap: Map<number, VideoPlayerInfo> = new Map;

  // videoPlayer
  @State layaHttpClientArray: LayaHttpClient[] = [];
  private layaHttpClientIndexMap: Map<number, LayaHttpClient> = new Map;

  private pro = new process.ProcessManager();
  private m_nBackPressTime = 0;
  // textInputDialog
  showMessage: TextInputDialogEntity = new TextInputDialogEntity('');
  dialogController: CustomDialogController = new CustomDialogController({
    builder: TextInputDialog({
      showMessage: this.showMessage
    }),
    autoCancel: true,
    alignment: DialogAlignment.Bottom,
    customStyle: true,
  })
  // PanGesture
  private panOption: PanGestureOptions = new PanGestureOptions({ direction: PanDirection.Up | PanDirection.Down });

  onPageShow() {
    console.log('[LIFECYCLE-Page] onPageShow');
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_EDIT_BOX_ARRAY, this.editBoxArray);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_EDIT_BOX_INDEX_MAP, this.editBoxIndexMap);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_WORKER, layaWorker);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_WEB_VIEW_ARRAY, this.webViewArray);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_WEB_VIEW_INDEX_MAP, this.webViewIndexMap);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_VIDEO_PLAYER_ARRAY, this.videoPlayerInfoArray);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_VIDEO_PLAYER_INDEX_MAP, this.videoPlayerIndexMap);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_DIALOG_CONTROLLER, this.dialogController);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_SHOW_MESSAGE, this.showMessage);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_HTTP_CLIENT_ARRAY, this.layaHttpClientArray);
    GlobalContext.storeGlobalThis(GlobalContextConstants.LAYA_HTTP_CLIENT_INDEX_MAP, this.layaHttpClientIndexMap);
    nativePageLifecycle.onPageShow();
    Dialog.setTitle(getContext(this).resourceManager.getStringSync($r('app.string.Dialog_Title').id));
  }

  onPageHide() {
    console.log('[LIFECYCLE-Page] onPageHide');
    nativePageLifecycle.onPageHide();
  }

  onBackPress() {
    console.log('[LIFECYCLE-Page] onBackPress');
    layaWorker.postMessage({ type: "exit" });
    let curtm = Date.now();
    let MaxDelay = 3500;
    if (this.m_nBackPressTime == 0 || (this.m_nBackPressTime > 0 && curtm - this.m_nBackPressTime > MaxDelay)) {
      this.m_nBackPressTime = Date.now();
      promptAction.showToast({
        message: $r('app.string.text_backpress_toast'),
        duration: 1000
      });
    } else {
      this.pro.exit(0);
    }
    return true;
  }

  onMouseWheel(eventType: string, scrollY: number) {
    // layaWorker.postMessage({ type: "onMouseWheel", eventType: eventType, scrollY: scrollY });
  }

  build() {
    // Flex({ direction: FlexDirection.Column, alignItems: ItemAlign.Center, justifyContent: FlexAlign.Center }) {
    Stack() {
      XComponent({
        id: 'xcomponentId',
        type: 'surface',
        libraryname: 'laya',
        controller: this.xcomponentController
      })
        .focusable(true)
        .gesture(
          PanGesture(this.panOption)
            .onActionStart(() => {
              this.onMouseWheel("actionStart", 0);
            })
            .onActionUpdate((event: GestureEvent) => {
              if (deviceInfo.deviceType === '2in1') {
                this.onMouseWheel("actionUpdate", event.offsetY);
              }
            })
            .onActionEnd(() => {
              this.onMouseWheel("actionEnd", 0);
            })
        )
        .onLoad((context) => {
          console.log('[laya] XComponent.onLoad Callback');
          layaWorker.postMessage({
            type: "abilityContextInit",
            context: GlobalContext.loadGlobalThis(GlobalContextConstants.LAYA_ABILITY_CONTEXT)
          });
          layaWorker.postMessage({ type: "onXCLoad", data: "XComponent" });
          layaWorker.onmessage = WorkerMsgUtils.recvWorkerThreadMessage;
        })
        .onDestroy(() => {
        })
      ForEach(this.editBoxArray, (item: TextInputInfo) => {
        LayaEditBox({ textInputInfo: item });
      }, (item: TextInputInfo) => item.viewTag.toString())

      ForEach(this.webViewArray, (item: WebViewInfo) => {
        LayaWebview({ viewInfo: item })
      }, (item: WebViewInfo) => item.uniqueId.toString())

      ForEach(this.videoPlayerInfoArray, (item: VideoPlayerInfo) => {
        LayaVideoPlayer({ videoPlayerInfo: item })
      }, (item: VideoPlayerInfo) => item.viewTag.toString())

    }
    .width('100%')
    .height('100%')
  }
}

【HarmonyOS 5】Detailed Explanation of HarmonyOS mPaaS

GeorgeGcs — Sun, 29 Jun 2025 16:34:16 +0000

【HarmonyOS 5】Detailed Explanation of HarmonyOS mPaaS

##HarmonyOS Development Capabilities ##HarmonyOS SDK Application Services ##HarmonyOS Financial Applications (Financial Management #

I. What is mPaaS?

mPaaS is the abbreviation for Mobile Platform as a Service, namely a mobile development platform.

The Ant Mobile Development Platform mPaaS integrates Alipay's technological capabilities, providing end-to-end one-stop solutions for mobile application development, testing, operation, and maintenance. With more than a decade of technical accumulation and iteration, it possesses mature and efficient capabilities.

It can effectively enhance the interactive experience of apps, ensure app compliance and security, and assist enterprises in achieving business growth with refined operation and marketing scenario capabilities.

Mobile development platforms similar to mPaaS include JD mPaaS, etc. Essentially, these are business profit points created by the middle-platform departments of large tech companies. As the foundational department for business in large companies, the middle platform almost always develops the underlying frameworks for all apps within the same ecosystem. Against this backdrop, it is a natural progression to provide general solutions for commercial use externally.

This article will elaborate on the integration, tool usage, and initialization process of mPaaS in HarmonyOS development, combining official documentation.

II. Main Functions and Advantages of mPaaS

Containerization technology, plugin-based architecture, hotfix capabilities, dynamic deployment:

1. Containerization Technology: Unifying Application Runtime Environments

mPaaS abstracts the runtime environments of native applications (iOS/Android) into a unified container through containerization technology, achieving the following capabilities:

Cross-platform compatibility: The container layer shields the underlying differences of iOS, Android, and HarmonyOS systems, allowing business code (such as H5, mini-programs, Flutter, etc.) to run in a unified environment, reducing cross-platform development costs.
Dynamic loading mechanism: The container supports dynamic loading of plugins, pages, resources, etc., enabling function updates without reapplying. For example:
- Loading new H5 pages or mini-program modules;
- Dynamically replacing static resources like images and fonts.
Sandbox isolation: Provides independent runtime sandboxes for each business module, ensuring data isolation and resource non-interference between modules, thereby enhancing application stability and security.

Differences in containerization technology between HarmonyOS mPaaS and Android/iOS platforms:

Feature	HarmonyOS mPaaS	Traditional Android/iOS mPaaS
Underlying container technology	Based on ArkTS componentization + Stage model	Based on WebView (Android/iOS) or native containers (such as React Native)
Dynamic loading granularity	In units of HAP/Ability	In units of plugins (such as JS Bundle, Native modules)
Isolation mechanism	Process/thread isolation based on HarmonyOS system	Sandbox based on WebView or custom Native containers
Hot update method	Dynamic update via HAP packages (requires system permissions)	Update via JS script injection or Native code replacement (such as Android Dex loading)
Performance overhead	Lower (ArkTS compiled into Native code)	Higher (WebView or cross-language bridging)

2. Plugin-based Architecture: Modular Development and Hot Deployment

mPaaS adopts a plugin-based architecture, splitting applications into host containers and independent plugins (such as functional modules and business components). Core mechanisms include:

Dynamic plugin loading: The host container dynamically loads plugins at runtime, enabling new functions without restarting the application. For example:
- E-commerce apps can dynamically load the "live broadcast" plugin without releasing a new version;
- Financial apps can dynamically update the logic of the "payment" module.
Plugin lifecycle management: The container manages the lifecycle of plugins (loading, initialization, activation, destruction, etc.), ensuring reasonable resource release and avoiding memory leaks.
Inter-plugin communication mechanism: Provides a unified message bus (such as EventBus), supporting safe and efficient communication between plugins to decouple module dependencies.

The core of containerization technology in HarmonyOS mPaaS is the componentization and isolation capabilities provided by the ArkTS language, mainly reflected in HarmonyOS splitting application functions into independent Abilities (similar to Android's Activity/Fragment), each running in an independent sandbox environment:

Resource isolation: UI rendering, memory usage, and data storage between Abilities are mutually isolated, preventing the entire application from abnormal behavior due to the crash of a single component.
Dynamic loading: Abilities support on-demand loading, allowing specific functional modules to be activated without starting the entire application. For example:

  // Dynamically load and start a specified Ability  
  import abilityAccessCtrl from '@ohos.abilityAccessCtrl';  
  const aac = abilityAccessCtrl.createAbilityAccessCtrl();  
  aac.startAbility(request)  
    .then(() => console.log('Ability started successfully'))  
    .catch((err) => console.error(`Failed to start ability: ${err}`));

HarmonyOS's Stage model splits applications into HAP (HarmonyOS Ability Package), each HAP can contain multiple Abilities:

Independent deployment: HAP supports dynamic downloading and installation for hot updates of functions. For example:

  // Configure the HAP module in config.json  
  {  
    "module": {  
      "name": "entry",  
      "deviceTypes": ["phone"],  
      "reqPermissions": [],  
      "abilities": [...]  
    },  
    "subModules": [  
      {  
        "name": "feature-module",  
        "description": "Dynamic feature module",  
        "deliveryWithInstall": false, // Supports on-demand downloading  
        "installationFree": true  
      }  
    ]  
  }

3. Hotfix and Dynamization: Quickly Fixing On-line Issues

mPaaS achieves rapid on-line issue fixing and function iteration through hotfix and dynamic technology. Underlying mechanisms include:

Code hotfix:
- iOS: Utilizes Objective-C's dynamic features (such as Method Swizzling) or Fishhook technology to replace incorrect function implementations at runtime;
- Android: Fixes bugs in Java/Kotlin code dynamically through class loading (Dexposed) or Native layer replacement (such as AndFix). The fix package can be delivered via the cloud, taking effect without users reinstalling the app.
Dynamic resource update: Supports dynamic updating of resources such as images, layout files (such as XML/JSON), and fonts. For example:
- Fixing UI display anomalies (such as incorrect button colors);
- Adjusting page layouts to adapt to new device models.
Script-based dynamic logic: Supports embedding script languages such as JavaScript and Lua to achieve dynamic adjustment of business logic. For example:
- Dynamically modifying the interaction logic of H5 pages through JS scripts;
- Injecting script code into native pages to adjust business processes in real-time.

4. Cloud-end Integration: Data-driven and Remote Configuration

The mPaaS underlying layer deeply integrates with Alibaba Cloud services, achieving real-time linkage between the client and the cloud. Core mechanisms include:

Remote Config: Dynamically delivers business parameters through the cloud configuration center. For example:
- Adjusting function switches (such as temporarily closing high-risk modules);
- Modifying operation strategies (such as adjusting activity rules and interface copy). Configuration changes take effect in real-time without releasing a new version.
A/B testing and gray release: Based on cloud分流 strategies, users are divided into different groups to test different function versions (such as interface styles and business logic), optimizing the user experience through data monitoring (such as click-through rate and crash rate).
Logging and monitoring: The client collects runtime logs (such as crash stacks and performance indicators) in real-time and reports them to the cloud monitoring platform, supporting rapid positioning and analysis of on-line issues.

5. Performance Optimization and Stability Assurance

The mPaaS underlying layer integrates a series of performance optimization and stability enhancement technologies:

Memory management: Isolates memory usage of different modules through the plugin-based architecture and sandbox mechanism, reducing memory leaks and OOM (Out of Memory) issues by optimizing automatic garbage collection (GC).
Network optimization: Provides a unified network request framework, supporting connection pool reuse, HTTP/2 protocol, dynamic DNS resolution, etc., improving network request efficiency and stability.
Offline package mechanism: Pre-downloads commonly used H5 pages and mini-program code to the local device, reducing dependence on the network and improving page loading speed, especially in weak network environments.
Crash protection: Built-in Crash capture and recovery mechanisms monitor application crashes in real-time and quickly restore normal operation through hotfix technology.

6. Security Mechanisms: Data and Communication Protection

The mPaaS underlying layer attaches great importance to security. Core mechanisms include:

Data encryption: Encrypts locally stored data (such as user privacy and configuration information), supporting encryption algorithms such as AES and RSA.
Communication security: Adopts HTTPS two-way authentication (SSL Pinning) and anti-packet capture technology to ensure that data communicated between the client and the cloud is not tampered with or stolen.
Application hardening: Integrates technology such as code obfuscation, anti-decompilation, and anti-debugging to enhance application security and resist malicious attacks.

III. Architectural Principle Analysis of mPaaS

mPaaS in HarmonyOS does adopt containerization technology, but its implementation differs from traditional Android/iOS platforms, mainly based on HarmonyOS's ArkTS language features, Stage model, and Ability componentization framework. The specific analysis is as follows:

IV. How to Integrate mPaaS in HarmonyOS?

Click to access the official HarmonyOS NEXT integration documentation

1. Precondition Preparation

Development environment: Install the latest HarmonyOS NEXT development environment, requiring support for API 12 and above.
Device requirements: Prepare a real device or emulator with HarmonyOS 3.0.0.22 or above (emulator usage refers to official documentation).
Configuration file: Create an application in the mPaaS console, download the HarmonyOS NEXT version .config configuration file, which needs to be renamed to mpaas.config and placed in the specified project directory.

2. Key Operation Process

Configuration file processing

Rename the downloaded .config file to mpaas.config and copy it to the entry/resource/rawfile directory of the main project to store key application configuration information.
Install the mppm tool

mppm is an SDK management tool provided by mPaaS, supporting functions such as dependency installation, cache cleaning, and baseline management. Installation steps are as follows:

   # Globally install mppm  
   npm install @alipay-inc/oh-mpaas-cli -g  
   # Check the version (current version is v2.0.0)  
   mppm -v

Note for Windows users: Need to configure npm-global and npm-global/bin environment variables, which can be viewed via npm config get prefix for the default path.

Initialize the project

Execute the mppm init command in the DevEco Studio terminal, and select the baseline version (such as 10.2.3) and components to install as prompted. After initialization, a .mprc file will be generated in the project root directory, recording baseline information (such as "baseline":"10.2.3").
Obtain security images

Generate security images through the mppm tool, requiring the application signature fingerprint (fingerprint) and appsecret:

   mppm fetch-image --finger <fingerprint value> --secret <appsecret>

Fingerprint acquisition method:

Certificate extraction: Use the keytool tool to parse the .cer certificate file to obtain the SHA-256 value.
Code acquisition: Call the HarmonyOS API bundleManager.getBundleInfo to obtain signature information.
bm command: Query on a real device via hdc shell bm dump -n <package name> | grep fing.

V. Core Functions and Commands of the mppm Tool

1. Tool Positioning and Function List

As an SDK management tool, mppm is mainly used to simplify the dependency management of mPaaS components in HarmonyOS projects. Core functions include:

Dependency installation: Automatically executes ohpm install to install required dependencies for each module.
Cache cleaning: Clears hvigor and oh_modules caches (command: mppm clean; dependencies need to be resynchronized after execution).
Baseline management: Supports baseline upgrade (mppm upgrade), customized baseline installation (mppm sdk --custom <baseline name>), and manual synchronization (mppm sync, taking effect after modifying .mprc).

2. Common Command Examples

Operation Scenario	Command	Description
Installing a customized baseline	`mppm sdk --custom 10.2.3.isec`	Installing a specified version of the customized baseline
Synchronizing the baseline version	`mppm sync`	Updating project dependencies to the target baseline version based on the `.mprc` file
Cleaning and reinstalling dependencies	`mppm clean && ohpm install`	Solving dependency installation errors (such as ENOENT), requiring use with the ohpm command

VI. mPaaS Initialization and Framework Integration

1. Dependency Introduction and Configuration

Repository configuration: Add the mPaaS repository address in the project .ohpmrc:

   @mpaas:registry=https://mpaas-ohpm.oss-cn-hangzhou.aliyuncs.com/meta

Core dependencies: Add framework and C++ shared library dependencies in oh-package.json5:

   {  
     "dependencies": {  
       "@mpaas/framework": "0.0.2",   // Core framework dependency  
       "@mpaas/cpp-shared": "1.0.0"   // C++ shared library (non-repeating installation)  
     }  
   }

2. Framework Initialization Code Implementation

Create an AbilityStage component: Create a new ArkTs file EntryAbilityStage.ets as the component container for the application.
Initialization logic: Call MPFramework.create(app) in the onCreate callback of AbilityStage to initialize the framework:

   import { MPFramework } from '@mpaas/framework';  
   export default class EntryAbilityStage extends AbilityStage {  
     async onCreate() {  
       const app = this.context;  
       MPFramework.create(app); // Initialize the mPaaS framework  
       const instance = MPFramework.instance;  
       // Subsequent calls to APIs to obtain udid, set user ID, etc.  
     }  
   }

Component registration: Configure srcEntry to point to the initialization component path in module.json5:

   {  
     "module": {  
       "name": "entry",  
       "srcEntry": "./ets/EntryAbilityStage.ets"  
     }  
   }

3. Core API Usage

Obtain device UDID: MPFramework.instance.udid (asynchronous interface, requiring await).
User identity management: Set or obtain the user ID through MPFramework.instance.userId.
Security information configuration: Manage sensitive appSecret information through MPFramework.instance.appSecret.

【HarmonyOS 5】Detailed Explanation of HarmonyOS NearLink

GeorgeGcs — Sun, 29 Jun 2025 16:33:46 +0000

【HarmonyOS 5】Detailed Explanation of HarmonyOS NearLink

## HarmonyOS Development Capabilities ## HarmonyOS SDK Application Services ## HarmonyOS Financial Applications (Financial Management #

一、Preface

The HarmonyOS NearLink Kit provides short-range communication services, supporting connections and data interaction between NearLink devices. For example, a mobile phone can act as a central device to connect with peripheral devices (such as mice, styluses, smart home appliances, car keys, etc.) via NearLink.

二、Access and Usage of NearLink Kit

Click to jump to the official documentation address

The following is a basic access code example for HarmonyOS NearLink, including core processes of device discovery, connection, and data transmission:

// NearLink device management service example  

import nearlink from '@ohos.nearlink';  
import nearlinkSle from '@ohos.nearlink.sle';  
import common from '@ohos.app.ability.common';  

// NearLink service management class  
export class NearLinkManager {  
  private context: common.UIAbilityContext | undefined;  
  private deviceManager: nearlinkSle.SleDeviceManager | undefined;  
  private connectedDeviceId: string | null = null;  
  private dataChannel: nearlinkSle.SleDataChannel | undefined;  

  constructor(context: common.UIAbilityContext) {  
    this.context = context;  
  }  

  // Initialize NearLink service  
  async initNearLinkService() {  
    try {  
      // Check and request NearLink permission  
      await this.checkAndRequestNearLinkPermission();  

      // Create device manager instance  
      this.deviceManager = await nearlinkSle.getSleDeviceManager(this.context!);  

      // Register device state change listener  
      this.registerDeviceStateListener();  

      console.info('NearLink service initialized successfully');  
    } catch (error) {  
      console.error(`Failed to initialize NearLink service: ${error}`);  
      throw error;  
    }  
  }  

  // Check and request NearLink permission  
  private async checkAndRequestNearLinkPermission() {  
    // Permission check logic  
    // ...  
  }  

  // Start scanning for nearby NearLink devices  
  async startDiscovery() {  
    if (!this.deviceManager) {  
      throw new Error('Device manager not initialized');  
    }  

    try {  
      // Configure scan parameters  
      const discoveryConfig = {  
        mode: nearlinkSle.SleDiscoveryMode.ACTIVE,  
        duration: 30, // Scan duration (seconds)  
        filter: {  
          deviceTypes: [nearlinkSle.SleDeviceType.ALL]  
        }  
      };  

      // Register device discovery callback  
      const callback = {  
        onDeviceFound: (device: nearlinkSle.SleDevice) => {  
          console.info(`Found device: ${device.deviceName}, type: ${device.deviceType}`);  
          // Process the discovered device, e.g., update UI  
          this.onDeviceDiscovered(device);  
        },  
        onDiscoveryStateChanged: (state: number) => {  
          console.info(`Discovery state changed: ${state}`);  
        }  
      };  

      // Start scanning  
      await this.deviceManager.startDiscovery(discoveryConfig, callback);  
      console.info('NearLink device discovery started');  
    } catch (error) {  
      console.error(`Failed to start discovery: ${error}`);  
      throw error;  
    }  
  }  

  // Process the discovered device  
  private onDeviceDiscovered(device: nearlinkSle.SleDevice) {  
    // Add device filtering logic here  
    // ...  

    // Notify UI to update device list  
    // ...  
  }  

  // Connect to the specified NearLink device  
  async connectToDevice(deviceId: string) {  
    if (!this.deviceManager) {  
      throw new Error('Device manager not initialized');  
    }  

    try {  
      // Create connection parameters  
      const connectParams = {  
        timeout: 10000, // Connection timeout (milliseconds)  
        connectionType: nearlinkSle.SleConnectionType.DATA_CHANNEL  
      };  

      // Connect to the device  
      const connectionResult = await this.deviceManager.connect(deviceId, connectParams);  
      if (connectionResult.resultCode === 0) {  
        this.connectedDeviceId = deviceId;  
        this.dataChannel = connectionResult.dataChannel;  
        console.info(`Connected to device: ${deviceId}`);  

        // Register data receive callback  
        this.registerDataReceiveListener();  
      } else {  
        console.error(`Failed to connect device, error code: ${connectionResult.resultCode}`);  
        throw new Error(`Connection failed: ${connectionResult.resultCode}`);  
      }  
    } catch (error) {  
      console.error(`Failed to connect device: ${error}`);  
      throw error;  
    }  
  }  

  // Register data receive listener  
  private registerDataReceiveListener() {  
    if (!this.dataChannel) return;  

    this.dataChannel.on('dataReceived', (data: ArrayBuffer) => {  
      // Process received data  
      const decoder = new TextDecoder();  
      const message = decoder.decode(data);  
      console.info(`Received data: ${message}`);  

      // Notify UI of new data arrival  
      // ...  
    });  
  }  

  // Send data to the connected device  
  async sendData(message: string) {  
    if (!this.dataChannel) {  
      throw new Error('Data channel not initialized');  
    }  

    try {  
      const encoder = new TextEncoder();  
      const data = encoder.encode(message).buffer;  

      // Send data  
      await this.dataChannel.send(data);  
      console.info(`Data sent successfully: ${message}`);  
    } catch (error) {  
      console.error(`Failed to send data: ${error}`);  
      throw error;  
    }  
  }  

  // Disconnect from the device  
  async disconnect() {  
    if (!this.deviceManager || !this.connectedDeviceId) return;  

    try {  
      await this.deviceManager.disconnect(this.connectedDeviceId);  
      this.connectedDeviceId = null;  
      this.dataChannel = undefined;  
      console.info('Device disconnected');  
    } catch (error) {  
      console.error(`Failed to disconnect device: ${error}`);  
      throw error;  
    }  
  }  

  // Register device state change listener  
  private registerDeviceStateListener() {  
    if (!this.deviceManager) return;  

    this.deviceManager.on('deviceStateChanged', (params) => {  
      console.info(`Device state changed: ${JSON.stringify(params)}`);  
      // Process device state changes  
      // ...  
    });  
  }  

  // Release resources  
  async release() {  
    await this.disconnect();  

    if (this.deviceManager) {  
      try {  
        await this.deviceManager.release();  
        console.info('NearLink resources released');  
      } catch (error) {  
        console.error(`Failed to release resources: ${error}`);  
      }  
    }  
  }  
}

三、Technical Indicator Comparison of HarmonyOS NearLink

The following table compares HarmonyOS NearLink, Bluetooth, and NFC in terms of technical performance, application scenarios, cost, and ecosystem:

Comparison Item	HarmonyOS NearLink	Bluetooth	NFC
Transfer Rate	Up to 2.5Gbps, peak rate in low-power mode reaches 12Mbps	Bluetooth 5.2 has a transfer rate of 400Mbps; asynchronous connections allow data transfer rates of up to 721kbps in one direction and 57.6kbps in the reverse direction	No (data transfer rate is typically much lower than the former two)
Latency Performance	Transmission latency as low as 20 microseconds, response latency 0.25ms	Latency about 600 microseconds, response latency about 10ms	No (mainly used for close-range quick interaction, latency indicators are not emphasized)
Number of Connected Devices	Supports up to 4,096 devices connected simultaneously	Generally can only connect 8 devices; one Bluetooth device can join 8 different piconets simultaneously	No (generally used for one-to-one quick connections, not emphasizing multi-device connections)
Anti-Interference Capability	Adopts multiple anti-interference technologies, anti-interference capability improved by more than 10dB compared to Bluetooth	Adopts frequency-hopping spread spectrum technology, strong anti-interference, not easy to eavesdrop	No (short working distance, relatively small interference)
Power Consumption	Adopts advanced power management strategies, power consumption only 60% of Bluetooth	Low power consumption, suitable for various low-power devices	Low power consumption (short working time)
Applications in Consumer Electronics	Enables high-definition lossless audio transmission and low-latency interactive experience, such as Huawei MatePad Pro 13.2-inch tablet and FreeBuds Pro 3 wireless headphones	Widely used for audio transmission in wireless headphones, speakers, and other devices	Can be used for fast pairing and data transmission between devices, such as quick connection between mobile phones and speakers/headphones
Applications in Smart Home	Enables seamless connection of multiple smart devices, supports more devices online simultaneously	Used to connect smart home appliances for remote control and other functions	Can quickly switch mobile phone modes or control smart home switches/modes via NFC tags
Applications in Smart Vehicles	Enables high-speed, low-latency data exchange between in-vehicle and external devices, enhancing the safety and efficiency of autonomous driving	Used to connect in-vehicle devices, such as in-vehicle Bluetooth calls and Bluetooth music playback	Can be used for car key functions, realizing vehicle unlocking/starting via mobile phone NFC
Applications in Industrial Manufacturing	Meets the needs of high-precision control and large data transmission, promoting the realization of Industry 4.0	Used for wireless connection between industrial devices, such as sensor data transmission	No (generally not used in industrial manufacturing scenarios)
Cost	Costs of related solutions and chip modules are still relatively high	Mature technology, low cost	Relatively low cost
Ecosystem	Ecosystem is not yet perfect, with relatively few devices supporting NearLink technology	Has a huge and mature ecosystem, with almost all electronic devices supporting Bluetooth	Widely used in mobile payment, transportation, and other fields, with a relatively mature ecosystem
Connection Method and Range	Coverage is about twice that of Bluetooth, with a conventional coverage distance of up to 20 meters; device connections require pairing and connection within a certain range	General effective transmission distance is 10cm - 10m, which can reach 100m with increased transmission power; requires pairing and connection operations	Very short working distance, generally within a few centimeters, usually used for close-range quick touch connections between devices

【HarmonyOS 5】Detailed Explanation of HarmonyOS Cross-Platform Development Solutions (Part 2)

GeorgeGcs — Sun, 29 Jun 2025 11:26:49 +0000

【HarmonyOS 5】Detailed Explanation of HarmonyOS Cross-Platform Development Solutions (Part 2)

HarmonyOS Development Capabilities ## HarmonyOS SDK Application Services ## HarmonyOS Financial Applications (Financial Management #

一、Flutter Adaptation for HarmonyOS

As one of the earliest cross-platform frameworks to achieve HarmonyOS adaptation, Flutter has formed a relatively complete technical solution driven by the community. The current HarmonyOS version of Flutter, 3.22.0-ohos, is based on the Flutter 3.22.0 core.

1、How to Connect System Capabilities?

System capabilities unique to HarmonyOS are integrated by modifying the embedding layer, including window management, input events, and various HarmonyOS Kits, which are integrated through platform channels.

(1) Window Management:

Adapt to HarmonyOS's window lifecycle management mechanism.

(2) Input Events:

Refactor the touch event processing flow to match HarmonyOS's input system.

Platform Channel:

The FlutterMethodChannel is similar to the JSBridge between H5 and native systems. The latest version optimizes the MethodChannel implementation to improve communication efficiency with HarmonyOS APIs.

Flutter-side Platform Channel Code

import 'package:flutter/services.dart';  

class HarmonyKit {  
  static const MethodChannel _channel =  
      MethodChannel('com.example/harmony_kit');  

  // Example: Invoke HarmonyOS Toast  
  static Future<String?> showToast(String message) async {  
    try {  
      return await _channel.invokeMethod('showToast', {'message': message});  
    } on PlatformException catch (e) {  
      return 'Error: ${e.message}';  
    }  
  }  
}

HarmonyOS-side Platform Channel Code

// index.ets  
import common from '@ohos.app.ability.common';  
import promptAction from '@ohos.promptAction';  
import mediaLibrary from '@ohos.multimedia.mediaLibrary';  
import { BusinessError } from '@ohos.base';  

@Entry  
@Component  
struct Index {  
  private context = getContext(this) as common.UIAbilityContext;  
  private flutterChannel: any = null;  

  aboutToAppear() {  
    this.initFlutterChannel();  
  }  

  // Initialize Flutter communication channel  
  initFlutterChannel() {  
    // Create a channel for communication with Flutter  
    this.flutterChannel = new FlutterMethodChannel(  
      this.context,  
      'com.example/harmony_kit',  
      StandardMethodCodec.INSTANCE  
    );  

    // Set method call handler  
    this.flutterChannel.setMethodCallHandler((call: MethodCall, result: MethodResult) => {  
      switch (call.method) {  
        case 'showToast':  
          this.showHarmonyToast(call.arguments.message);  
          result.success('Toast has been displayed');  
          break;  
        default:  
          result.notImplemented();  
      }  
    });  
  }  

  // Display HarmonyOS Toast  
  async showHarmonyToast(message: string) {  
    try {  
      await promptAction.showToast({  
        message: message,  
        duration: 3000  
      });  
    } catch (error) {  
      console.error(`Failed to display Toast: ${(error as BusinessError).message}`);  
    }  
  }  

  build() {  
    Column() {  
      // HarmonyOS UI components  
      Text('Flutter-HarmonyOS Communication Example')  
        .fontSize(20)  
        .fontWeight(FontWeight.Bold)  
        .margin({ top: 50, bottom: 30 })  
    }  
    .width('100%')  
  }  
}

2、Rendering Engine Adaptation

(1) Support for Dual Rendering Engines:

Skia Rendering:

Obtain the OHNativeWindow instance through XComponent and convert it to a Vulkan Surface for rendering.

Utilize the鸿蒙原生窗口系统xComponent.getOHNativeWindow() to reduce graphic data transmission loss. Leverage Vulkan's multi-threading parallel capabilities to enhance rendering efficiency in complex UI scenarios.

Flutter UI → Skia → OHNativeWindow → Vulkan Surface → Hardware-Accelerated Rendering

Impeller Rendering:

Utilize the Vulkan backend support of HarmonyOS ArkGraphics to optimize graphic rendering performance. Impeller is a new-generation rendering engine under development by Flutter, aiming to replace Skia.

Flutter UI → Impeller → ArkGraphics(Vulkan) → Hardware-Accelerated Rendering

Rendering Process:

The Flutter engine is compiled into libflutter.so, packaged into flutter.har, and then converted into an executable file through HarmonyOS's Clang/LLVM toolchain.

Comparison of the Two Solutions

Feature	Skia + OHNativeWindow	Impeller + ArkGraphics
Rendering Engine	Mature Skia	New-generation Impeller (still in development)
Integration Method	Indirect access to Vulkan via OHNativeWindow	Direct call to ArkGraphics' Vulkan backend
Performance	Good, relying on Skia optimizations	Higher, deeply optimized for HarmonyOS devices
Compatibility	Supports more HarmonyOS versions	Depends on ArkGraphics version, may be limited to new versions
Development Difficulty	Medium (requires window conversion)	Higher (requires adaptation to the new engine)

(2) Core Concepts:

Skia:

Flutter's default 2D rendering engine, responsible for drawing UI to the screen.

XComponent:

A cross-device component provided by HarmonyOS for accessing underlying graphic resources.

OHNativeWindow:

HarmonyOS's native window object, similar to Android's ANativeWindow.

Vulkan:

A new-generation cross-platform graphics API with better performance than OpenGL ES. Vulkan is a low-overhead, cross-platform graphics and computing API designed to provide more direct hardware access for high-performance applications (such as games, graphic rendering engines, scientific computing, etc.). Developed by the Khronos Group (the developer of OpenGL), as the successor to OpenGL, it focuses on improving the utilization of multi-core CPUs and modern GPUs while reducing driver-level overhead.

3、Hybrid Development Support

Layout mixing scheme for Flutter and ArkTS native components:

Create a rendering surface through XComponent  
Use ArkUI C API to attach the native component tree to OH_NativeXComponent  
Flutter manages it as a PlatformView to achieve hybrid layout

二、Technical Underlying Implementation Principles of Flutter Adaptation for HarmonyOS

In fact, traces of Flutter technology can be seen in the underlying implementation of ArkUI, and there is a compatibility foundation at the source code level. The coding styles of both are also quite similar, which is one of the reasons why I quickly transitioned to OpenHarmony's eTS.

1、Deep Integration of Graphics System

Collaboration mechanism between the Skia engine and HarmonyOS graphics system:

graph TD  
A[Flutter Rendering Instructions] --> B(Skia Engine)  
B --> C[XComponent Acquires OHNativeWindow]  
C --> D[VK_OHOS_surface Extension]  
D --> E[Vulkan Surface Rendering]  
E --> F[HarmonyOS Display System]

2、Advantages of Cross-Platform Architecture

Advantages of Flutter's self-rendering engine in HarmonyOS scenarios:

No dependency on platform-native UI components, with lower adaptation costs than React Native.
Unified rendering logic avoids UI inconsistency issues across platforms.
Combined with HarmonyOS's distributed capabilities, it enables consistent UI rendering across devices.

三、Evolution Path of Flutter Adaptation for HarmonyOS

Although the Flutter official team states that "there are no plans for native support for HarmonyOS," the community has a dedicated team supporting code modifications for HarmonyOS adaptation:

The Open Mobile Hub project plans to launch official Flutter support for HarmonyOS in 2026.
The HarmonyOS community's Flutter adaptation team maintains technical communication with Google's Flutter team.
Huawei internally has evaluated Flutter as one of the cross-platform solutions, but in the future, ArkUI-X will certainly be the main focus. Currently, with multi-line promotion and tight resources, the native mainline is prioritized. Once the mainline stabilizes and resources are allocated to支线, progress will naturally accelerate.

1、When Do Enterprises Tend to Choose Flutter?

(1) Enterprises that have built a Flutter technology stack for Android and iOS tend to expand to the HarmonyOS platform due to reduced adaptation costs.

(2) Applications with high UI consistency requirements, such as financial and utility products. Many bank and securities apps are implemented using the Flutter framework.

(3) Applications requiring cross-device deployment, as Flutter combined with HarmonyOS's distributed capabilities can achieve a better experience.

2、SWOT Analysis of Flutter HarmonyOS Solution

Dimension	Strengths	Weaknesses
Technical Architecture	Low adaptation cost due to self-rendering engine, high rendering performance	Lack of official support, dependent on community maintenance
Development Efficiency	Perfect hot reload mechanism, easy-to-learn Dart language	Custom development required for integrating HarmonyOS-specific capabilities
Performance	Fast startup speed, interaction response close to native	Higher memory usage than native applications
Ecosystem Status	Active community, rich plugin ecosystem	Insufficient HarmonyOS-specific plugins

Dimension	Opportunities	Threats
Ecosystem Development	Growing HarmonyOS device shipments driving application demand	Competition from other cross-platform solutions
Technical Integration	Possibility of deep integration with HarmonyOS's distributed capabilities	Substitution pressure from Huawei's native framework ArkUI-X
Enterprise Needs	Migration needs of existing Flutter teams	Higher maintenance costs than officially recommended solutions

The next article will expand on a multi-dimensional comparison of eight cross-platform solutions, establishing an evaluation system based on four key dimensions: development efficiency, performance, ecosystem maturity, and maintenance costs. Finally, comparing with native development, I still tend to prefer native development haha.

【HarmonyOS 5】Detailed Explanation of HarmonyOS Cross-Platform Development Solutions (Part 1)

GeorgeGcs — Sun, 29 Jun 2025 09:57:22 +0000

【HarmonyOS 5】Detailed Explanation of HarmonyOS Cross-Platform Development Solutions (Part 1)

HarmonyOS Development Capabilities ## HarmonyOS SDK Application Services ## HarmonyOS Financial Applications (Financial Management #

一、Why Do We Need HarmonyOS Cross-Platform Development Solutions?

2025 marks a critical development period for the HarmonyOS ecosystem. According to data from the recent 2025 HDC, the number of native HarmonyOS applications has grown from 2,000 in 2024 to 5,000, the installation volume of the HarmonyOS version of WeChat has exceeded 120 million, and the Ministry of Public Security's traffic management system has completed adaptation for 300 cities nationwide.

A report by the OS Testing Laboratory of the China Academy of Information and Communications Technology states that the response delay of the HarmonyOS system is less than 10ms (industrial-level deterministic latency), the security attack surface is only 1/1000 of Linux, and the microkernel codebase is 100,000 lines, far smaller than Android's 27 million lines of kernel code.

These figures confirm that the HarmonyOS ecosystem has entered a rapid growth phase, with explosive demand for enterprise-level application development.

However, although there are 8 million registered HarmonyOS application developers, most are初级 (junior), with few mid-to-senior developers and even fewer architect-level experts.

Moreover, business migration costs are high. If all applications are developed natively for HarmonyOS, the maintenance cost for multiple platforms alone is extremely high. Therefore, enterprises prefer cross-platform solutions for HarmonyOS development.

Of course, based on data analysis, I始终 believe (always believe) that cross-platform development solutions are less efficient than native development. However, the choice of solution depends on the team's technical accumulation, personnel reserves, business complexity, and historical debt. Therefore, there is no best solution, only the most suitable one.

However, if developing a new APP from scratch, I recommend native HarmonyOS development, as it has the fewest pitfalls. The main development path of HarmonyOS offers the best support for native development, which is beyond doubt.

ArkUI-X supports writing one codebase for HarmonyOS, Android, and iOS, but it is not yet mature, and I have not used it, so this series of articles does not organize content on this. If there are ArkUI-X experts, welcome to communicate.

二、Common Eight HarmonyOS Cross-Platform Solutions

The following is a table presenting the eight HarmonyOS cross-platform development solutions, categorized by solution name, owning entity, core positioning, technical characteristics, and ecological/performance highlights:

1、Comparison Table of HarmonyOS Cross-Platform Development Solutions

Solution Name	Owning Entity	Core Positioning	Technical Characteristics	Ecological/Performance Highlights
Flutter	Google	Cross-platform UI framework	The earliest community adaptation for HarmonyOS - Connects to HarmonyOS system services through the embedding layer - Supports dual rendering engines: Skia/Impeller	Released version 3.22.0-ohos, deeply integrated with HarmonyOS NEXT API16
React Native	Meta	JavaScript cross-platform framework	Based on JavaScript bridging with native components - Mature hot reload mechanism	Community-maintained HarmonyOS adaptation version - Over 30 community applications have adopted the HarmonyOS adaptation version
uni-app x	DCloud	One-code multi-terminal operation framework	Based on Vue syntax - Supports compilation into native HarmonyOS applications	Thousands of special plugins for HarmonyOS Next - Well-known e-commerce enterprises have implemented applications
KMP/CMP		Kotlin Multiplatform solution	Logic layer Kotlin code reuse - Independent UI layer implementation for each platform	Typical implementations: Tencent Kuikly, ovCompose
Taro	JD.com	Cross-terminal and cross-framework solution	Supports developing multi-terminal applications with React syntax - C-API version significantly improves rendering performance	JD.com's native HarmonyOS applications are developed using Taro
Hippy	Meituan	Open-source cross-platform framework	- Based on JavaScript engine - Bridge mode similar to React Native	Limited HarmonyOS support
ovCompose	Tencent	Compose Multiplatform ecological solution	- Adopts Jetpack Compose syntax - Adapts to HarmonyOS UI system
Kuikly	Tencent	Kotlin Multiplatform cross-terminal framework	Based on Kotlin Multiplatform architecture	- Kotlin/Native solution achieves FCP in 122ms, 6 times faster than React Native

The above data is what I could search; empty cells indicate a lack of relevant information. If there are experts on ovCompose, welcome to communicate.

Currently, my information channels confirm that Flutter, RN, and uni are relatively mature cross-platform solutions for HarmonyOS, and many large enterprises and central enterprises have used them in their APPs. Although the frameworks have many issues, they are continuously iterating and updated, with dedicated teams maintaining them, so the problems are manageable.

JD.com's Taro has been compatible with OpenHarmony for adaptation, but only JD.com uses it (as far as I know; if there are other companies, welcome to comment). Moreover, JD.com's early HarmonyOS APPs were developed with Taro, but due to too many compatibility issues, they should have recently switched back to native development.

2、Three Categories of Cross-Platform Directions:

(1) Flutter and uni-app x

Currently, these technologies are mature and widely used, with rich community ecosystems.

(2) Kuikly

Achieves performance breakthroughs with Kotlin/Native technology but requires teams to have Kotlin development capabilities.

(3) Taro and React Native

More suitable for teams migrating from front-end technologies.

These solutions have their own strengths in technical architecture, development experience, and performance, and subsequent articles will conduct in-depth comparisons from four dimensions: development efficiency, performance, ecology, and maintenance cost.

I am most familiar with Flutter because I used Flutter technology to develop APPs at Tencent and BMW from 2021 to 2022. Although I later switched to OpenHarmony, I have continued to follow the Flutter community.

As a cross-platform UI framework developed by Google, Flutter has outstanding support in the HarmonyOS community and is one of the earliest open-source cross-platform frameworks.

Due to the flexible architectural design of Flutter, it is convenient to migrate to different platforms, with application cases such as LG's WebOS and Toyota's in-vehicle systems.

Currently, the HarmonyOS version of Flutter has released version 3.22.0-ohos, which is deeply adapted to HarmonyOS NEXT API16, with significant improvements in stability and compatibility. From a technical implementation perspective, it connects to HarmonyOS system services by expanding the embedding layer and adjusts the engine layer to adapt to graphics, text rendering, and platform channel communication mechanisms. In terms of rendering support, it already supports Skia and Impeller rendering.

2、Development Data Comparison of Eight Solutions:

To more intuitively compare these solutions, I have created a table analyzing four key dimensions: development efficiency, performance, ecological maturity, and maintenance cost:

Solution	Development Efficiency	Performance	Ecological Maturity	Maintenance Cost
Flutter	Need to learn Dart, syntax similar to JS, supported by DevEco Studio, theoretical 100% code reuse, requires HarmonyOS adaptation, supports hot reload	Fast startup, higher memory usage, high rendering performance with Skia or Impeller, rapid interaction response, platform call overhead	Active community, has HarmonyOS adaptation team, rich plugins but limited special-purpose ones, few cases, frequent updates	Moderate cost to learn Dart, suitable for experienced teams, need to track Flutter official updates for adaptation, high cross-platform consistency but requires additional HarmonyOS adaptation
React Native	Uses JavaScript/TypeScript, low learning curve, community provides HarmonyOS support, mature toolchain, high code reuse rate, requires HarmonyOS adaptation, supports hot reload	Faster startup, moderate memory usage, native component rendering performance close to native, good interaction response, possible communication delay, TurboModule mechanism calls native code with better performance	Active community, has HarmonyOS adaptation version, rich plugins but limited special-purpose ones, over 30 application cases, relatively slow updates	Low learning cost, suitable for front-end teams, need to maintain HarmonyOS adaptation, good cross-platform consistency but with differences
uni-app x	Uses Vue syntax and UTS language, low learning cost, comprehensive support from HBuilderX, one code runs on multiple terminals, extremely high code reuse rate, supports hot reload	Fast startup, low memory usage, native components + native rendering performance close to native, logic layer and view layer share native process for rapid response, direct native API calls with high efficiency	Supported by DCloud official, active community, thousands of plugins supporting HarmonyOS next, well-known e-commerce application cases, frequent updates	Low learning cost, suitable for Vue teams, official continuous maintenance, high cross-platform consistency
KMP/CMP	Need to master Kotlin, higher learning cost, good support from IntelliJ IDEA and Android Studio, high logic layer code reuse, separate UI layer implementation for each platform, supports hot reload	Kotlin/Native starts fast, Kotlin/JS is relatively slow, low memory usage, native-based rendering performance close to native, rapid interaction response, direct native API calls with high performance	Gradually active community, supported by enterprises like Tencent, KMP ecosystem gradually enriching but limited HarmonyOS-specific resources, large enterprises have application cases, moderate update frequency	High learning cost, suitable for Android or Kotlin teams, need to maintain multi-platform UI implementations, high logic layer consistency, UI layer needs separate implementation
Taro	Uses React syntax, low learning curve, good support from DevEco Studio and Taro CLI, one code adapts to multiple platforms, supports hot reload	Faster startup, moderate memory usage, C-API version significantly improves rendering performance, runtime logic sinks to C++ for rapid response, high efficiency via C++-side calls to ArkUI C++ API	Active community, supported by enterprises like JD.com, mature ecosystem with rich plugins, HarmonyOS support gradually improving, JD.com HarmonyOS application cases, frequent updates	Low learning cost, suitable for React teams, maintained by official and community, high cross-platform consistency
ovCompose	Need to learn Compose DSL, certain cost, based on Android Studio and IntelliJ IDEA, good tool support, three-terminal one-code development, high code reuse rate, supports hot reload	Faster startup, moderate memory usage, good Skia rendering performance, good response but performance issues on HarmonyOS, good performance via NAPI for native code and CPP-side communication	Supported by Tencent official, community gradually forming, based on Compose Multiplatform with limited ecological resources, Tencent Video has application cases, moderate update frequency	Higher learning cost, suitable for Android or Kotlin teams, need to maintain multi-platform UI implementations, good cross-platform consistency but with differences
Kuikly	Uses Kotlin language, certain learning cost, provides special HarmonyOS debugging and build support and toolchain, supports one-code multi-terminal, high code reuse rate, supports hot reload	Kotlin/Native solution starts fast, page FCP takes only 122ms, 6 times faster than React Native, low memory usage, uses native OEM rendering with performance close to native, interaction response consistent with native, direct native API calls with high performance	Supported by Tencent official, community initially formed, built-in 30+ business UI components, community component platform under construction, multiple Tencent applications implemented, moderate update frequency	Higher learning cost, suitable for Android or Kotlin teams, maintained by Tencent official, high cross-platform consistency
Hippy	Uses JavaScript, low learning curve, relatively mature toolchain but limited HarmonyOS support, high code reuse rate, requires HarmonyOS adaptation, supports hot reload	Faster startup, moderate memory usage, good native rendering engine performance, good interaction response but possible communication delay, bridge mechanism calls native code with overhead	General community activity, limited HarmonyOS support, relatively limited ecosystem, few special plugins, few public cases, low update frequency	Low learning cost, suitable for front-end teams, community-maintained, good cross-platform consistency but with differences

三、Enterprise Real-World Demands for Cross-Platform Development

According to HarmonyOS community data, enterprises face three core demands in HarmonyOS application development:

Cost Control: 62% of enterprises hope to reduce development costs by more than 50% through cross-platform solutions
Multi-Terminal Adaptation: 89% of applications need to support HarmonyOS, Android, and iOS simultaneously
Performance Balance: Require both cross-platform efficiency and user experience close to native

Therefore, large and medium-sized enterprises will prioritize cross-platform solutions. Which solution to choose is a key link in enterprise architecture decision-making, and subsequent series of articles will focus on in-depth analysis of Flutter and multi-solution comparisons.