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

The Problem

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

Market Competition and Innovation

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

Security Concerns and Alternative Solutions

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

A Balanced Approach

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

Consumer Choice and Economic Growth

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

Conclusion

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

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

The full package for HarmonyOS 5.0.5 Release is as follows:

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

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

Ability

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

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

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

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

ArkData

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

AR Engine

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

ArkUI

• Added APIs related to mouse axis events.

• NavDestination adds onActive and onInactive lifecycles.

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

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

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

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

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

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

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

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

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

Audio Kit

• Added support for Float32 audio stream sampling format.

AVCodec Kit

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

AVSession Kit

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

Background Tasks Kit

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

Connectivity Kit

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

File Manager Service Kit

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

IME Kit

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

Media Kit

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

Payment Kit

• Added the ability to guide users to bind cards.

PDF Kit

• Added support for encrypting PDF documents.

Preview Kit

• Added file opening acceleration preload state awareness.

Vision Kit

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

Profiles

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

The new version notes are as follows:

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

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

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

---

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

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

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

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

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

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

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

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

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

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

Introduction

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

Understanding HarmonyOS and its Development Tools

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

Key tools for HarmonyOS app development include:

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

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

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

What You Need to Get Started with HarmonyOS App Development

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

The SDK provides tools in the following key areas:

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

• System Services: Key management and networking libraries.

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

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

• Application Services: Libraries for game and location services.

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

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

App Overview

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

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

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

Preparing Database Operations

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

Step 1: Create the Database

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

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

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

Step 2: Insert a New Note

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

Step 3: Update an Existing Note

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

Step 4: Delete a Note

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

Step 5: Get All Notes

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

Integrating Database Operations in UI Component

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

Step 1: Initial Setup in Index.ets

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

State Variables:

• currentIndex: Keeps track of the current tab.

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

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

Step 2: Initializing the Database

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

Step 3: Loading Notes with loadNotes

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

Step 4: Handling Tabs with changeTab

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

Step 5: Building the Tab Bar with tabBarBuilder

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

Step 6: Saving or Updating Notes with saveOrUpdateNote

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

The function:

• Ensures the content isn’t empty.

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

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

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

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

Conclusion

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

Happy coding!

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

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

I. Concepts and Differences between Internationalization and Localization

(I) Internationalization (Internationalization, I18n)

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

(II) Localization (Localization, L10n)

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

(III) Differences between the Two

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

II. Advantages of Internationalization and Localization of HarmonyOS Next Applications

(I) Expanding the Global Market

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

(II) Enhancing User Experience

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

(II) Strengthening Competitiveness

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

(IV) Reducing Development Costs

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

III. Processes of Internationalization and Localization of HarmonyOS Next Applications

(I) Requirement Analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(II) Resource File Configuration and Management

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

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

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

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

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

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

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

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

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

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

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

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

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

(V) Localization Testing and Optimization

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

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

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

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

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

In daily development, manually switching signature files and package names when dealing with multi-signature and multi-product build outputs is error-prone and time-consuming. HarmonyOS provides custom hvigor plugins and multi-target product building capabilities. We can use hvigor plugins to dynamically modify project configurations, ensuring that a single codebase can switch between different package names while maintaining core functionality. This allows us to generate customized build products through multi-target product building.

I. Understanding Multi-Target Product Building

1. What is Multi-Target Product Building?

Simply put, multi-target products refer to highly customized output modules. Developers can build different HAP, HAR, HSP, APP, etc., by defining different build configurations to achieve differentiation between products. For detailed customization options, see: https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-multi-target#section19846433183815

2. Build Schematic Diagram

II. Implementing Multi-Target Product Building in a Project

(Source code reference branch: feature/multiTargetProduct)

1. Configuring Multi-Target Product Building

Multi-target product building requires modifying configuration files like build-profile.json5 and module.json5 to define different product and target entries. Developers can specify device types, source sets, resources, and assign different targets to products. The build tool generates targets based on these configurations and combines them into customized products.

Configure Signing Configs for Different Projects:

Define default, demo_debug, and demo_release signing configurations for debugging and release builds:

"signingConfigs": [
  {
    "name": "default", // Default certificate
    "type": "HarmonyOS",
    "material": { /* ... default certificate details ... */ }
  },
  {
    "name": "demo_debug", // Debugging certificate
    "type": "HarmonyOS",
    "material": { /* ... debug certificate details ... */ }
  },
  {
    "name": "demo_release", // Release certificate
    "type": "HarmonyOS",
    "material": { /* ... release certificate details ... */ }
  }
]

Define Products with Different Signing Configs:

Each product uses a specific signing configuration to generate differentiation outputs:

"products": [
  {
    "name": "default",
    "signingConfig": "default", // Default product uses default certificate
    "compatibleSdkVersion": "5.0.1(13)",
    "runtimeOS": "HarmonyOS",
    "buildOption": { /* ... build options ... */ }
  },
  {
    "name": "products_debug",
    "signingConfig": "demo_debug", // Debug product uses debug certificate
    "compatibleSdkVersion": "5.0.1(13)",
    "runtimeOS": "HarmonyOS",
    "buildOption": { /* ... build options ... */ }
  },
  {
    "name": "products_release",
    "signingConfig": "demo_release", // Release product uses release certificate
    "compatibleSdkVersion": "5.0.1(13)",
    "runtimeOS": "HarmonyOS",
    "buildOption": { /* ... build options ... */ }
  }
]

Link Products to Targets in HAP/HSP Modules:

Configure targets in modules to associate products with build outputs:

"modules": [
  {
    "name": "entry",
    "srcPath": "./entry",
    "targets": [
      {
        "name": "default",
        "applyToProducts": [
          "default",
          "products_debug",
          "products_release"
        ]
      }
    ]
  }
]

2. Switching Product Configurations and Output Packages

Manual Switching Interface:

III. Building Different Package Names and Configurations on Multi-Target Products

(Source code reference branch: feature/differentPackageConfigurations)

1. Adding Signing and Product Configs for a Second App

New Signing Configuration for Second App:

"signingConfigs": [
  // ... existing configs ...
  {
    "name": "demo_debug_test2", // Signing for the second app
    "type": "HarmonyOS",
    "material": { /* ... testDemo2 certificate details ... */ }
  }
]

Define a New Product with Unique Identifiers:

Configure label, icon, bundleName, and output for differentiation. Use buildProfileFields for custom parameters:

"products": [
  // ... existing products ...
  {
    "name": "products_debug_test2",
    "signingConfig": "demo_debug_test2",
    "compatibleSdkVersion": "5.0.1(13)",
    "runtimeOS": "HarmonyOS",
    "label": "$string:app_name_test2", // Second app's name
    "icon": "$media:app_icon_test2", // Second app's icon
    "bundleName": "com.atomicservice.6917571239128090930", // Second app's package name
    "buildOption": { /* ... build options ... */ },
    "output": { "artifactName": "products_debug_test2" } // Unique output directory
  }
]

2. Implementation Results After Configuration

Output Product Information:

Desktop icon and application name after it takes effect:

3. Querying and Using Custom Constants

Use buildProfileFields to define product-specific parameters for code differentiation.

Configure Custom Constants in Products:

"products": [
  {
    "name": "default",
    "buildOption": {
      "arkOptions": {
        "buildProfileFields": {
          "isStartNet": false,
          "isDebug": true,
          "productsName": "default"
          // ... other custom parameters ...
        }
      }
    }
  },
  // ... repeat for other products with unique values ...
]

Access Custom Configs in Code:

Import BuildProfile and use parameters in UI:

import BuildProfile from 'BuildProfile';  
Column() {  
  Text(`productsName:${BuildProfile.productsName}`)  
  // ... other Text components for custom fields ...  
}  

UI Display of Custom Parameters:

IV. Conclusion

Multi-target product building allows rapid switching between different build configurations and solves package name differentiation for scenarios like multi-entity app submissions (e.g., domestic vs. foreign entities on AG). While this covers basic customization, advanced needs (e.g., dynamic client_id/app_id in module.json5) require integration with hvigor plugins. Future articles will explore using custom scripts to modify hard-coded configurations during builds.

VI. Source Code Repository

Repository Address

VII. Reference Materials

Multi-Target Product Building Practice - Huawei HarmonyOS Developers
HarmonyOS Multi-Environment Building Guide - Juejin

Original source links: HarmonyOS Next： Build Application with Different Package Names - Discuss - LeetCode redirected from HarmonyOS Next： Build Application with Different Package Names | Hacker News

Cangjie Language: A key technological breakthrough in the OpenHarmony ecosystem

In the technical forum of the conference, Feng Xinyu, director of OpenHarmony programming language TSG and professor of Nanjing University, delivered a technical report entitled "A New Generation of Programming Language for All-Scenario Applications - Cangjie". The technical advantages and ecological planning of Cangjie language are systematically explained:

1. Technical advantages

• Efficient development and performance balance: Static typing and automatic memory management are supported, and real-time response on mobile devices is ensured through concurrent garbage collection and a lightweight thread model.

• Full-stack optimization: The language, compiler, and runtime are co-designed, and the performance is significantly improved compared with similar languages, meeting the needs of smooth interaction of HarmonyOS native applications.

• Multi-paradigm fusion: Integrates functional and object-oriented features, and has built-in metaprogramming capabilities to support rapid DSL development in scenarios such as declarative UI and intelligent agent.

2. Ecological planning

• At present, the Cangjie language has been implemented in scenarios such as device-side HarmonyOS native applications and cloud-side microservices, and has built an IDE plug-in ecosystem to achieve intelligent programming coordination with large models.

• Cangjie plans to promote the construction of developer ecology through the "Cangjie Cup" competition, and carry out joint research on the cutting-edge technology of compilers with major universities to accelerate the maturity of the independent programming language system.

Technology Club: The practice base of Cangjie language

Liu Qin, executive director of the OpenHarmony Technology Club of Nanjing University, clearly mentioned in the plan that the club will focus on the following actions around the Cangjie language:

• Source Code Study and Project Incubation: Set up a special research group for Cangjie language, combine enterprise-level projects and academic resources to promote its technical iteration.

• Talent training: Through summer training camps and open source competitions (such as "Cangjie Cup"), we will cultivate compound talents with open source system research and development capabilities.

• Ecosystem co-construction: Collaborate with Huawei and other enterprises to apply the Cangjie language to cutting-edge fields such as RISC-V and AI test frameworks.

Industry, university and research work together to create a new highland of domestic technology

Lu Yanqing, Vice President of Nanjing University, and Chen Haibo, Chairman of the OpenHarmony Technical Steering Committee, both emphasized that the establishment of the club is an important step to promote the innovation of domestic basic software. Relying on the advantages of multidisciplinary interdisciplinarity, Nanjing University will break through the "bottleneck" problem in key OpenHarmony technologies (such as Cangjie language and distributed architecture), and help China occupy a dominant position in the global operating system field.

Chen Haibo and Wu Gangshan jointly unveiled the establishment of the OpenHarmony Technology Club of Nanjing University. Subsequently, Chen Haibo awarded Liu Qin a plaque.

OpenHarmony is an open source project incubated and operated by the OpenAtom Foundation, with the goal of building a framework and platform for the operating system of smart terminal devices in an open-source manner for the all-scenario, full-connected, and all-intelligent era, so as to promote the prosperity and development of the Internet of Everything industry. Over the past three years since OpenHarmony was open sourced, the community has grown rapidly, with more than 70 co-builders and more than 8,200 co-builders contributing more than 120 million lines of code. Up to now, under the leadership of the Technical Steering Committee of the OpenHarmony Project Group, the OpenHarmony community has jointly established OpenHarmony Technology Clubs or Developer Associations with more than 100 leading universities in China, by attracting teachers and students to participate in technology research and focusing on the cultivation of innovative talents, continuously deepening industry-university-research collaboration, and working with all sectors of society to promote the technological development and community prosperity of OpenHarmony.

Original source: 南京大学OpenHarmony技术俱乐部正式揭牌 仓颉编程语言引领生态创新2025年4月24日，南京大学OpenHarm - 掘金

In Android and iOS development, dependencies and collaborations are often carried out in the form of binary products. Android uses Maven as the repository, and iOS has Pod as the repository. We can use open libraries provided by others on the officially provided platforms, which greatly improves everyone's development efficiency. However, some libraries related to a company's business do not want to be used by external personnel. Uploading them to external common repositories is not very safe. Many companies have built private repositories internally. On the one hand, it is more secure, and on the other hand, pushing and pulling products is usually faster.

HarmonyOS has the same issue. We can conveniently use open products from third parties on the official repository platform, but for a company's internal business, it still needs to rely on private repositories. This article builds its own private repository based on the tools provided by the official.

Introduction to HarmonyOS Shared Packages

HarmonyOS shared packages are divided into static shared packages and dynamic shared packages:

• HAR (Harmony Archive) is a static shared package that can contain code, C++ libraries, resources, and configuration files. Through HAR, multiple modules or multiple projects can share relevant codes such as ArkUI components and resources. HAR is different from HAP and cannot be independently installed and run on devices. It can only be referenced as a dependency of application modules.

• HSP (Harmony Shared Package) is a dynamic shared package. Static shared packages will be packaged into each dependent HAP, resulting in a large package size and repeated packaging of multiple copies of public resources and codes into the application. Dynamic shared packages allow multiple HAPs to share the same public resource code. HSP only supports sharing within an application and does not support cross-application sharing.

Building a Private Repository with the ohpm-repo Private Repository Tool

The official provides the ohpm-repo tool to help developers quickly build lightweight ohpm private repositories. It is compatible with the ohpm package manager and caches all dependencies on demand to accelerate installation in a private network.

ohpm-repo supports single-point deployment and multi-instance deployment:

• Single-point deployment: ohpm-repo is only deployed and used on one machine.

• Multi-instance deployment: ohpm-repo will be deployed on multiple machines with the same configuration content and shared data storage space.

Installation of the Dependent Environment

1. ohpm-repo depends on node to run and supports node.js 16.x and above versions. Nodejs needs to be installed first, and the environment needs to be configured. NodeJs can be downloaded from the official website (https://nodejs.org/download/release/latest/).

Downloading the ohpm-repo Tool

1. Download the ohpm-repo tool. The download address is: https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/ide-software-download-0000001507075446

2. Unzip the ohpm-repo tool.

Configuring the ohpm-repo Environment Variables

1. Configure the path of the bin directory in the unzipped directory of the ohpm-repo tool package to the system environment variable path: export PATH=$OHPM-REPO-PATH/bin:$PATH

2. Execute the command ohpm-repo -v to view the version number and verify that the unzipped package is intact.

Configuration of the ohpm-repo Service Configuration File

Enter the conf directory in the unzipped directory, open the config.yaml file. The default configuration is as follows:

##### server configuration section #####
listen: 0.0.0.0:8088
# listen:
# - localhost:8088            # Listen to the local loopback address
# - http://localhost:8088     # Listen to the local loopback address
# - 0.0.0.0:8088              # Listen to all local addresses (INADDR_ANY)
# Protocol Configurable http or https，default http
# port: 1-65535(Windowssystems)/ 1024-65535(LinuxmaybeMacsystems）

# selectable (listen because of https You must configure the)
https_key: ''                 # https service-usable key pathways  (No configuration defaults to'')
https_cert: ''                # https service-usable crt pathways  (No configuration defaults to'')

##### server deploy root section #####
deploy_root: ''                # Installation root directory (No configuration defaults to `<existing userhomedirectory (on computer hard drive)>/ohpm-repo`)，Only absolute paths are supported，and the path directory must exist

##### server numeric limit section #####
max_package_size: 100          # Upload packet size limit inMB (0, 100]，不配置默认为 100
max_extract_size: 500          # Unpacked zip size limit，The unit isMB [max_package_size, 500]，No configuration defaults to 500
max_extract_file_num: 10240    # Limit the number of files in a zip archive after decompression (0, 102400]，No configuration defaults to 10240
user_rate_limit: 100           # User access frequency control in times/s (0, 10000]，No configuration defaults to 100
fetch_timeout: 60              # Request/response timeout in seconds (0, 3600]，No configuration defaults to 60
keep_alive_timeout: 60         # TCP Hold connection timeout，In seconds. (0, 3600]，不配置默认为 60
api_timeout: 60                # apitimeout，In seconds.(0, 3600]，No configuration defaults to 60
upload_lock_hour: 24           # After taking down all versions of a package, a time-limited ban on uploads of packages with the same name will be imposed.，单Bit is the hour. (0, 168]，non-configuration，default 24
upload_max_times: 100          # Limit on the number of uploads in a 24-hour period for a single user (0, 10000]，No configuration defaults to 100

##### metadata storage section #####
## Data storage type filedb respond in singing mysql Either/or, not both
db:                         # must yaml Writing in array form
  type: filedb
  config:                   # If you want to change the storage path and keep the old data, you need to change the number under the old path to the new path. Migration of documents to new paths
    path:./db              # Local data storage path, not configured defaults to <deploy_root>/db;

#db:                        # Must be written in yaml array form
#  type: mysql
#  config:
#    host: "localhost"      # Database host address
#    port: 3306             # database port (0,65535]
#    username: root         # User name of the database
#    password: "password"   # User password for the database (please configure it in plaintext, it will eventually be converted to ciphertext in the deployment directory)
#    database: "repo"       # database name

##### storage section #####
## File storage typefs,sftp 和 custom Three choices, not more.

store:                               # Must be written in yaml array form
  type: fs
  config:                            # If you want to change the storage path after uploading a resource, you need to migrate the data under the old path to the new path.
    path:./storage                  # The path to the triple repository store that has been shelved, without configuration the default is  <deploy_root>/storage;
    #server: http://localhost:8088   # Tripartite library download link, no default value configured

# The file storage type is sftp 时，Configure up to three sftp services
#store:                               # Must be written in yaml array form
#  type: sftp                         # if and only if db The type of the mysql hour，store It is only when the type of the sftp
#  config:
#    location:
#      -
#        name: test_one_sftp          # Host name, name cannot be duplicated with other sftp configurations
#        host: "localhost"            # host address
#        port: 22                     # host port (0,65535]
#        read_username: "read"        # Name of the user with read access to the host
#        read_password: "password"    # Passwords for users with read access to the host (please configure plaintext, it will be converted to ciphertext in the deployment directory)
#        write_username: "write"      # Name of the user with write access to the host
#        write_password: "password"   # Passwords for users with write access to the host (please configure plaintext, it will be converted to ciphertext in the deployment directory)
#        path: /source22              # Path to a file relative to the sftp root directory, starts with / only, and the path folder must exist.
#      -
#        name: test_two_sftp
#        host: "localhost"
#        port: 24
#        read_username: "read"
#        read_password: "password"
#        write_username: "write"
#        write_password: "password"
#        path: /source24
#    #server: http://localhost:8088   # The address of the local repository download link, without configuring the default value of listen,
#store:
#  type: custom                                            # is a custom storage plugin type, the custom storage plugin development process is described in the guidance document
#  config:
#    export_name: CustomStorage                            # Class name of the plugin export
#    plugin_path:../plugins/CustomStorage.js              # The absolute path of the plugin or the path relative to the ohpm-repo package, it is recommended to place the plugin in the plugins directory of the package
#    custom_field: "test"                                  # Custom fields, get the value of a custom field by introducing the getStorageConfigInfo method of libs/common/getStorageConfigInfo.js
#    #server: http://localhost:8088                        # Local repository download link address, not configured to take the default value of listen
##### uplink section #####
uplink_cache_path:./uplink      # Cache path, no configuration defaults to <deploy_root>/uplink
uplink_cache_time: 168           # Remote packet metadata cache time, in hours, default 168 hours, range (0, 8760]

##### log section #####
logs_path:./logs                # log path, no configuration defaults to <deploy_root>/logs

##### log level section #####
# Log Levels: In descending order, the levels are all、trace、debug、info、warn、error、fatal、mark、off
# run，operate respond in singing access Not configured or misconfigured, defaults to info
loglevel_run: info
loglevel_operate: info
loglevel_access: info

It includes listening ports, https configuration, the private repository deployment directory deploy_root, service-related configurations, storage configurations, logs, etc. Just configure it according to the actual situation.

Regarding the storage module:
The db is the configuration item for metadata storage. The db supports local storage of fileDB and storage in the mysql database.
The store is the configuration item for file storage. The store supports local storage, sftp storage, and custom plugin storage.

Methods for Modifying the Configuration File After the Private Repository is Successfully Started:

• When starting the private repository for the first time, execute the install command to specify the configuration file: Find the specified configuration file to modify its content, then re-execute install to specify the modified configuration file, and then execute start to start the private repository.

• When starting the private repository for the first time, execute the install command without specifying the configuration file: The configuration file in the conf directory under the unzipped path of the private repository compression package is used by default. Modify the content of this file, and then re-execute the install and start operations.

Installation and Startup

Execute ohpm-repo install to install. After the installation is completed, set the environment variables according to the configuration. After the setting is completed, execute ohpm-repo start to start the service.

Using Private Repository Shared Packages

By default, the client ohpm tool only pulls dependency packages from the official public repository. To pull from a private repository, additional configuration is required. There are two configuration methods:

1. Configure this private repository for all projects: ohpm config set registry <Configured Private Warehouse Service Address>/repos/ohpm

2. Configure for a certain dependency installation: ohpm install @ohos/lottie --registry <Configured Private Warehouse Service Address>/repos/ohpm

The configured private repository service address above refers to the address information of store.config.server in the configuration file. For example, if store.config.server is

http://127.0.0.1:8088

, then the registry is: http://127.0.0.1:8088/repos/ohpm. If store.config.server is not configured, the default value will be taken.

Publishing Shared Packages

Locally developed shared packages, whether static shared packages or dynamic shared packages, can be published through the ohpm command tool or using the Web page. For convenience and efficiency in general development work, we usually use the command line to publish.

1. Generate an ssh key locally: ssh-keygen -m PEM -t RSA -b 4096 -f <your_key_path>

2. Log in to the ohpm-repo private repository management address, click on the personal center in the upper right corner of the home page, and add a new public key. Paste the content of the public key file (<your_key_path>.pub) into the public key input box.

3. Set the private key path: ohpm config set key_path <your_key_path>

4. Log in to the ohpm-repo private repository management address, click on the personal center in the upper right corner of the home page, and copy the publishing code.

5. Configure the publishing code to the.ohpmrc file: ohpm config set publish_id <your_publish_id>

6. Publish the static shared library: ohpm publish demo.har

7. Publish the dynamic shared package: ohpm publish demo.tgz

   1. The HSP package of the dynamic shared package cannot be directly published in the private repository and needs to be converted into a.tgz package first.

   2. Switching the compilation mode to the release mode will package out a.taz package.

Module Configuration

In the library module (at the same level as the src folder), add the following files:

• Newly create a README.md file: In the README.md file, it must include the introduction and reference method of the package, and more detailed introductions can also be added according to the content of the package.

• Newly create a CHANGELOG.md file: Fill in the version update record of HAR.

• Add a LICENSE file: The LICENSE license file.

The README.md file will eventually be displayed on the private repository web platform, and the dependent users can use it directly according to the description in README.md, so it is best to describe it clearly.

Explanation of the oh_package.json5 configuration file:

{  
    "parameterFile": "../dependencies.json5",  
    "keywords": [  
        "asr"  
    ],  
    "name": "@xx/base-asr",  
    "version": "1.0.0-rc.9",  
    "repository": "http://gerrit.google.com/mobile_harmony/base_asr",  
    "description": "asr sdk",  
    "main": "Index.ets",  
    "author": "qingkouwei",  
    "license": "Apache-2.0",  
    "dependencies": {  

    }  
}

The module name, version number, and description must meet the requirements. Otherwise, the upload to the private repository will fail. The version number can only increase sequentially and cannot be overwritten infinitely like a SNAPSHOT in Android.

Best Practices

In the actual development process, an engineering project may have multiple SDKs. After the SDKs are developed, they need to be integrated into other engineering projects. Sometimes, when locating problems and debugging, they may need to be frequently uploaded to the private repository, and other engineering projects rely on the packaged ones for debugging. In this way, it is particularly cumbersome and inefficient to compile the SDK each time and then execute commands to upload it, especially when an engineering project has multiple SDKs and these SDKs also have dependencies.

The best way is to be able to compile and upload to the private repository with one click through scripts, and upload them one by one according to the dependency relationship. It is also possible to package and upload a certain module separately.

First, create a version.json5 to store the SDK version:

{  
  "project": {  
    "sdk_version": "1.1.0-rc.1",  
  }  
}

Automatic packaging:

def run_commands(modulename, productname):  
    hvigor_home = '/Applications/DevEco-Studio.app/Contents/tools/hvigor'  

    # Packing Command
    command1 = 'node %s/bin/hvigorw.js --mode module -p product=default -p module=%s@default -p buildMode=debug assembleHar --analyze --parallel --incremental --daemon' %(hvigor_home,modulename)  

    # Wait for the first command to complete    
    process1.wait()  

    # Upload command   
    ohpm publish productname
    process2.wait()

Automatically modify the version number:

python
def changeVersionAModule():  
    with open('version.json5', 'r') as f:  
        data = json5.load(f)  
        versionName = data['project']['sdk_version']  

        with open('AModule/oh-package.json5', 'r') as f:  
            aData = json5.load(f)  
            aData['version'] = versionName  
            with open('AModule/oh-package.json5', 'w') as f:  
                json.dump(aData, f, indent=4)  

        with open('dependencies.json5', 'r') as depf:  
            depData = json5.load(depf)  
            depData

Original source: HarmonyOS Next Private Repository Construction in Practice - DEV Community

Open source and self-hosted solutions help businesses reduce reliance on single vendors, which is crucial when supply chains are unstable and licensing costs can suddenly rise due to geopolitical events. By self-hosting, companies gain full control over their data, security, and compliance, avoiding risks tied to third-party providers and ensuring they can meet strict regulatory requirements. Open source software also enables rapid innovation and customization, allowing organizations to adapt quickly without waiting for commercial vendors to update their products.

Finally, these solutions offer long-term financial predictability, as businesses avoid recurring subscription fees and unexpected price hikes, which is especially important in a volatile economic environment

An open source application is software whose source code is publicly available. This means anyone can look at it, tweak it, improve it, or share it – all depending on the type of license it comes with (like MIT, GPL, Apache, etc.). Unlike closed-source (a.k.a. proprietary) software, there are no secrets here – developers and users alike can see exactly how the app works and even help shape its future. Most open source apps are free to use, and you're generally allowed to use them for personal, educational, or even commercial purposes. Pretty sweet, right?

FOSS (Free and Open Source Software) takes this even further by offering not just transparency but also the flexibility to customize and build software that perfectly fits your needs. It allows organizations to innovate rapidly, without waiting for commercial vendors to update their products, and it’s backed by a supportive community that helps shape its evolution. With FOSS, businesses can enjoy the freedom to modify, distribute, and use the software in any way they see fit, making it a powerful alternative to proprietary solutions.

So, why are open source apps such a hit?

For starters, they help keep costs down – making them a great choice for startups, schools, and nonprofits that want to avoid pricey software licenses without sacrificing quality. Thanks to large, active communities around many open source projects, development tends to move quickly – bugs get fixed fast, and new features are released regularly. Open source is also a fantastic resource for learning; if you're getting into programming, there’s no better way to explore real-world code and even contribute to meaningful projects. And that’s why we like it!

And what do we also like?

Self-hosting. Many open source apps can be hosted on your own server or infrastructure, giving you full control over your data, performance, and privacy. Whether it’s a project management tool, a file storage platform, or a web analytics dashboard – self-hosted solutions let you run things your way, without relying on third-party services. That’s especially valuable for teams that are privacy-conscious, working in regulated industries, or just want to avoid being dependent on external providers.

Some examples

When you combine these two things – open source and self-hosting – you get something like Mattermost. Think of it as a privacy - first alternative to Slack or Microsoft Teams – but with a lot more control and flexibility. It offers everything you'd expect from a messaging platform: real-time chat, private and group messaging, file sharing, channel organization, and integrations. But it also goes a step further.

Another great example? Nextcloud. It’s like having your own personal Dropbox, Google Drive, and Microsoft Office suite all rolled into one – but totally under your control. You can host it yourself, sync files across devices, share documents securely, and even collaborate on text, spreadsheets, and video calls – all without handing over your data to big tech. It’s perfect for individuals, teams, or organizations that want powerful cloud features without the cloud compromise.

You can also find GIMP - a free and open-source image editor that offers everything you need for image editing. Whether it's basic tasks like cropping and adjusting colors or more advanced features like layers, masking, and plugin support, it’s all there. And the best part? You don’t need to worry about paying for licenses or sharing your data.

For servers, there's Proxmox – a solution that stands out for its simplicity and rich feature set. With Proxmox, you get a user-friendly web interface that makes managing virtual environments a breeze. It lets you easily monitor performance, set up storage, and run multiple virtual machines or containers on a single physical host. Whether you're running a small business or managing a larger enterprise environment, it offers the flexibility and ease of use you need to keep everything running smoothly.

So, the next time you're selecting software or a tool for your business, take a look under the hood. If it’s open source, that’s usually a good sign. It’s more than just cost savings - it’s about gaining control, boosting flexibility, and staying ahead in a world that’s constantly shifting. Why settle for less when you can take the wheel and shape your own tech future?

Original source: Why Open Source Apps Are a Big Deal and the Role of Self-Hosting | LinkedIn, Milan Puvaca, PhD.

Taking the release of the open source OpenHarmony 5.1 Release as an opportunity, the conference invited open source operating system technology leaders and cutting-edge practice experts to showcase the technical innovation and phased achievements of the open source OpenHarmony to developers and ecological partners.

This conference will usher in the launch of the open source OpenHarmony 5.1 Release product, the co-construction of application technology components, and the launch of a large screen ecological SIG.

The official version of the open-source OpenHarmony 5.1.0 Release was released on April 30 and launched on the Gitee platform, upgrading API 18, further enhancing ArkUI and media capabilities, and improving standard web capabilities.

The agenda of the event is as follows:

Original source: The open source HarmonyOS Developer Conference 2025 will be officially announced on May 24, and the 5.1 Release version will be released - IT Home

According to reports, the Hongzhi automotive cockpit system is based on the open source Hongmeng 5.0 deep customization, innovative integration of the open source Hongmeng distributed architecture and Zhida Chengyuan's core technology in the field of automotive electronics, with efficient transplantation capabilities, can quickly adapt to Ouyeel Longquan 560, RK3588 and other chip platforms.

The cockpit system of Hongzhi Automobile is deeply optimized by the open source Hongmeng, and adopts the microkernel architecture to achieve a more streamlined kernel design and improve the execution efficiency and security. The system ensures reliability through multi-level permission management and hardware-level access control mechanisms, and has automotive-grade security protection, and supports Bluetooth, Wi-Fi, audio, video, and camera functions, and provides expansion interfaces to meet the needs of multi-modal interaction and high-bandwidth data throughput in the intelligent cockpit.

In addition, Hongzhi Automotive Cockpit System realizes multi-terminal collaborative experience of terminals, watches, IoT devices and PC devices through distributed soft bus (DSoftBus) capabilities. For example, the driver can check the vehicle status in real time through the smart watch and control it remotely, and the navigation information on the mobile phone can also be transferred to the central control with one click.

IT Home learned from ArcherMind Technology that the desktop of Hongzhi Automobile Cockpit System adopts a minimalist style, including navigation bar, multimedia card and map function module. The multimedia card supports song playback control, and the map module supports swipe browsing, gesture zoom, path planning, and display mode switching. In addition, the system is equipped with a convenient control bar for quick setting of various vehicle statuses.

Original source: In-depth customization based on open source HarmonyOS 5.0: Zhida Chengyuan, a subsidiary of ArcherMind Technology, launched Hongzhi Automotive Cockpit System - IT Home

IT Home reported on May 4 that the open source HarmonyOS OpenHarmony is an open source project incubated and operated by the Open Atom Open Source Foundation, with the goal of building a framework and platform for the operating system of intelligent terminal devices for the era of full scenarios, full connections, and full intelligence, so as to promote the prosperity and development of the Internet of Everything industry.

The official version of OpenHarmony 5.1.0 Release was released on April 30 and the Gitee platform was launched, and API 18 was upgraded.

Compared with the previous Release version (OpenHarmony 5.0.3, API 15), OpenHarmony 5.1.0 Release focuses on the following new features or enhancements:

• ArkUI is further enhanced to provide richer component property settings, support more exquisite animations, and continue to supplement the ability of components to be called through C APIs.

• Further enhance media capabilities, providing richer encoding and decoding capabilities, broadcast control capabilities, and media session management capabilities;

• It further enriches the ability to set the details of application launch;

• Further enhance the data processing capabilities of UDMF and RDB for distributed data management;

• Standard web capabilities have been further refined, and more.

The official release notes attached to IT Home are as follows, which will be listed in the order of API versions:

Apply the framework

• Added support for creating an application context based on a specified data encryption level to obtain the corresponding path.

• Added support for obtaining the process name of the current process synchronously.

• Added support for getting the reason why the app is pulled up (LAUNCH_REASON_MESSAGE).

• Added support for HAR/HSP and so files to the startup framework.

• Added support for specifying the maximum width and height (maxWindowWidth / maxWindowHeight) and minimum width and height (minWindowWidth / minWindowHeight) of the main window when starting Ability.

• Added support for obtaining the detailed reason for the last exit of an app.

• Added support for setting the color mode of UIAbility.

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

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

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

• A new batch of C API functions is added to obtain the file directories in the application-level sandbox.

Application package management

Added a new redirection configuration file module.json5: use the abilitySrcEntryDelegator to identify the name of the UIAbility that the current module needs to be redirected to, and use the abilityStageSrcEntryDelegator Identifies the name of the Module corresponding to UIAbility to which the current Module needs to be redirected (not the name of the current Module), and the two are used in combination to specify the target object of the redirect.

ArkUI

• Enhancements to the text and input components. Include:

  • The text component supports the NODE_IMMUTABLE_FONT_WEIGHT property, which does not change with the system font weight.

  • The text component supports sharing services for selected text and line wrapping by syllables.

  • Added support for setting the text selection menu to be displayed in a separate window.

  • The RichEditor component allows you to set the maximum number of lines.

  • The TextInput component supports setting the text omitted position.

  • The TextInput / TextArea / Search / RichEditor component supports splitting text lines evenly to the top and bottom of lines.

  • The TextInput / TextArea component extends the autofill type to include: license plate number, passport number, and so on.

  • The RichEditor component supports vibration effects when you press and hold the preview menu.

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

• Added the ability to fit round screens. Include:

  • A new crown rotation event has been added, where the component is focused and twists the crown to obtain timestamp, angular velocity, angle of rotation, and crown action.

  • The arc list components, ArcList and ArcListItem, have been added to present continuous, multi-row data of the same type.

  • ArcAlphabetIndexer, a curved index bar component, is added, which can be sorted alphabetically for quick positioning.

  • ArcScrollBar has been added to add an external scrollbar to the arc list.

  • ArcButton, a curved button component, has been added, which provides highlight, normal, and warning buttons.

• Universal drag and drop capability enhanced. Include:

  • Support encapsulation of custom placement animations.

  • Customizable controls trigger auto-scrolling when dragging to the edge of a scrollable component.

• The pop-up window capability has been enhanced. Include:

  • You can set levelOrder to manage the display order of pop-up boxes, so that the pop-up boxes with higher levels are overlaid on top of the pop-up boxes with lower levels.

  • You can create and disable custom pop-up windows in custom content.

  • The Popup component supports setting the maximum width via maxWidth.

  • The half-modal popup-style pop-up window supports setting the display position relative to the target through placement, and setting whether the pop-up window can be overlaid on the target node through placementOnTarget.

  • Menu and Dialog support setting custom background blur via backgroundBlurStyleOptions and backgroundEffect.

  • Modal Transitions and MenuItem support!! Bind variables in both directions.

  • After a custom pop-up supports keyboard avoidance, use keyboardAvoidDistance to set the minimum distance between the pop-up window and the keyboard.

  • You can use showInSubWindow to set whether the half-modal is displayed in the sub-window, and you can use effectEdge to set the effect of scrolling on the edge of the half-modal panel.

  • The Menu supports vibration effects when popped up.

• The ability of the form selection component has been enhanced. Include:

  • The SegmentButtonV2 component is added to create tab, single, or multi-select capsule segment buttons.

  • The TextPicker / TimePicker option triggers an event callback when the selected area is entered.

  • TimePicker / CalendarPicker supports configuring start and end times via start and end.

  • TimePicker supports setting 12-hour clock time through enableCascade to follow the time in the morning and afternoon.

• Scrolling and sliding components have been enhanced. Include:

  • The Swiper / Tabs component adds a callback that is triggered when a selected element on the page changes, returning the index value of the currently selected or hidden element.

  • The Swiper component adds the ability to control whether a subcomponent stops autoplay when a finger or mouse is pressed on the screen, for example.

  • The Swiper component CAPI capability has been enhanced to set whether the cache node is displayed, the style of the numeric navigation points, and the navigation arrows.

  • The List component supports setting layout styles and scrolling effects (NODE_LIST_SCROLL_TO_INDEX_IN_GROUP, NODE_LIST_LANES, NODE_LIST_SCROLL_SNAP_ALIGN, NODE_LIST_MAINTAIN_VISIBLE_CONTENT_POSITION).

• The C API is added to support the gesture interruption event callback function that can be configured with user-defined data.

• The C API is added to support obtaining the width, height, and coordinates of the event hit component.

• Supports setting custom focus logic for components.

• Gesture configuration parameters can be dynamically obtained, and the threshold of consecutive clicks can be returned.

• Gesture event information can be returned in the onActionCancel callback triggered when the gesture is canceled.

• Accessibility supports customizing the focus order, controlling the screen reading mode of the component, and setting the screen reading scrolling operation.

• You can set the occupancy event of the EmbeddedComponent or UIExtensionComponent component to specify how the gesture event is responded.

• You can move the current FrameNode to the specified location of the target FrameNode to implement cross-instance node migration.

• NodeController adds lifecycle callback APIs (onAttach, onDetach, onWillBind, onWillUnbind, onBind, onUnbind, onUnbind, onUnbind) before and after the node is unbound.

• Screenshots of UI components built by ComponentContent are supported.

• Added APIs related to mouse axis events.

• NavDestination adds OnActive and OnInActive lifecycles.

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

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

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

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

Window management

• Added a monitoring callback for the completion of the pop-up animation of the soft keyboard.

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

• Added support for creating virtual screens in window management.

Graphic images

A new batch of C API functions and enums have been added to support GPU rendering capabilities that draw directly to the screen buffer.

Distributed data management

• RelationalStore adds rootDir configuration, which supports opening databases in non-database directories.

• ArkData RDB provides a vector data storage approximation query solution.

• Relational databases (RDS) support for obtaining column data types based on specified column indexes or column names.

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

media

audio

• Added support for Float32 audio output.

• Added support for spatial audio management.

Audio and video codecs

• Added support for MPEG2, MPEG4, and H.263 for video decoding.

Playback controls

• The player supports transparent transmission of SEI field data to applications, which is suitable for HTTP-FLV live streaming.

• When you call AVPlayer to set a playback policy, you can add support for displaying playback policies such as showFirstFrameOnPrepare and preferredBufferDurationForPlaying after Prepare.

• The player supports playing pre-downloaded video data.

• When you call AVPlayer to set a playback policy, thresholdForAutoQuickPlay is supported.

• Enhancements: Apps can create multiple SoundPool instances.

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

• Added support for setting the target loop mode (setTargetLoopMode) through AV session command passing, and provides event listening callbacks for setting actions.

• Added support for single-sentence/single-lyricText property for audio conversations.

Image

• Added C API support for getting editable flags for images.

Recording

• Added an enumeration of video fill modes during screen recording.

• Added support for configuring the stable recording mode enableStableQualityMode18 in the audio and video recording configuration file.

The language compiler runtime

• TaskPool supports the concurrency of task execution and the queuing policy of the specified task.

• TaskPool supports canceling tasks in a task pool by task ID.

• collections (ArkTS pods) adds support for the following methods in API 18: Array: from, isArray, of, copyWithin, lastIndexOf, some, reduceRight, reverse, toString, every, toLocaleStringTypedArray：toString、toLocaleString、lastIndexOf、reduceRight

• Sendable allows you to replace the least recently used data with new data when you don’t have enough cache space.

• Workers allow you to specify the priority of a task when you create it.

safe

Added group-based access control for critical assets. By setting group attributes, multiple apps developed by the same developer can share data.

DFX

Added support for dumping raw heap snapshots of virtual machines for the current thread.

Enterprise customization

• Disable/enable feature restrictions: add MTP (mtpClient / mtpServer) and factory reset (resetFactory).

• Added support for installing user certificates by system account.

• Added support for adding, deleting, and switching system events for subscribing accounts.

Basic communication

• Added the function of obtaining the virtual MAC address of the peer Bluetooth device on the Bluetooth socket server

• Added the ability to obtain the original name of the peer Bluetooth device.

• Added the ability to connect to the available profiles of peer Bluetooth devices, such as A2DP, HFP, HID and other protocol profiles.

• Added the ability to persistently store the virtual MAC address of the peer Bluetooth device.

• The new Bluetooth BLE scanning fence mode allows you to report a BLE broadcast packet to the fence when it is first scanned, and to leave the fence when it does not scan a BLE broadcast packet, and carry the BLE broadcast packet information.

• Improve the device information searched by Bluetooth, and add RSSI (signal strength), name, and category information to obtain the device RSSI.

• Added the function of reading and sending Bluetooth socket data asynchronously, and if the link is disconnected, an IO exception will be reported.

Location Services

Added support for subscribing to Bluetooth scanning information reporting events for auxiliary positioning.

Network management

Added support for obtaining file descriptors for TLSSocket.

clipboard

The clipboard supports getting the number of times the content of the clipboard has changed.

Input

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

Web

• You can get the element information of the last clicked area.

• You can set whether the font weight is enabled for web components to change according to the system settings.

• Support the audio and video in the web can be connected to the broadcast control center.

• Compatible with W3C specifications, you can specify the type of file to be uploaded by accepting.

• Provides a static method to clear the resource cache files in your app.

• Added support for elements rendered on the same layer with a fixed width and height.

Multimode inputs

Added support for setting callbacks for the specified button of the app operation in the foreground.

Upload and download

• Upload and download supports the ability to cache and download applications, and supports caching files to the sandbox directory or memory in advance.

• The API for uploading and downloading the agent allows you to set the maximum speed limit of the task and the content-type field of the file to be uploaded in the form.

Resource scheduling

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

• The new growth time mission car key subtype CAR_KEY. The new growth time mission car key subtype CAR_KEY.

• In the background agent reminder, you can set the resource ID for the reminder title and reminder content fields for global adaptation.

globalization

• Added support for obtaining the user’s preferred temperature unit and the start day of the week.

• Added support for refined formatting of date/number, which is convenient for more flexible use of formatting capabilities.

• Added support for number formatting that returns rich text.

• Added the ability to display paths locally, which can determine whether the path needs to be mirrored based on the input language.

Test the framework

• Added the ability to find the ID and type of the widget that meet the requirements according to fuzzy matching/regular matching.

• Added support for getting control prompt text and finding control based on control prompt text.

• Added support for horizontal and vertical search controls, which is only applicable to controls that support swiping.

Source: OpenHarmony 5.1.0 (API 18) is officially launched: further enhancing ArkUI and media capabilities, and improving standard web capabilities - HarmonyOSHub + ITHome (China)

With the goal of "making buildings evolve into intelligent organic lifeforms", this project reconstructs the building management model through open-source HarmonyOS technology.

Shenzhen Kaihong said that the urban and rural construction general and Shenzhen Kaihong in-depth cooperation, with open source Hongmeng technology as the core, with the "Kaihong security digital base" as the basic base, the smart building is like a "smart phone", to achieve cross-terminal interconnection of heterogeneous equipment in the building, unified data scheduling and efficient service collaboration.

Based on the open-source Hongmeng KaihongOS and KaihongOS Meta, the "smart brain" is installed for the construction of the building, so that it can perceive the environment like a human and make automatic decisions and adjust based on the full data collected by the device. After intelligent transformation, the construction of the general building has realized the real-time monitoring and linkage of the management module, and implemented multiple scenarios:

• Energy consumption management: Intelligent monitoring of water and electrical equipment, combined with AI energy-saving models, automatic adjustment of lighting and air conditioning, is expected to achieve an overall energy saving rate of 10%-15%, and reduce carbon emissions by nearly 100 tons per year.

• Smart meeting room: Through the one-click switching of the conference mode through the Kaihong conference control terminal, the intelligent control of the equipment, the second-level projection and the automatic release of resources after the meeting are realized, the utilization rate of the meeting room is improved, and the green self-service conference mode reduces energy consumption and improves human efficiency;

• Visitor and security management: Visitors can make an appointment through the mini program, face recognition to enter the building and real-time trajectory tracking; During fire emergency drills, the digital twin platform pushes escape routes in real time to improve emergency response efficiency.

• Asset and vehicle management: visual management of the whole process of assets, real-time statistics of vehicle entry and exit data, and improvement of parking space efficiency;

• User-side empowerment: Customize the "General Construction Mini Program" to integrate work order management, remote light control, air conditioning presets and other functions to achieve "people-oriented" service upgrades.

IT Home learned from the announcement of Shenzhen Kaihong that the results of the project show that the introduction of open source HarmonyOS technology has greatly improved the operation and maintenance efficiency of the building, and the energy consumption expenditure of the building has been significantly reduced. In addition, through data-driven decision-making, the life of building equipment is extended by 10%~15%.

Shenzhen Kaihong revealed that in the future, buildings and buildings, buildings and surrounding roads, and urban infrastructure will be interconnected based on the distributed capabilities of open source Hongmeng, which can be combined into a larger "super phone", and there will be unlimited innovation possibilities based on "super phones".

Original source: The country's first open-source HarmonyOS smart building model was released: automatic adjustment of lighting and air conditioning, real-time tracking of visitor trajectories - IT Home

This achievement marks a key step in the commercialization exploration of open source HarmonyOS in the oil and gas field, injecting new momentum into the digital transformation of the traditional oil and gas industry.

In terms of core technology applications, the tanker is equipped with LightBeeOS, an industry distribution based on open source HarmonyOS, which has obtained EAL4+ security certification.

Thanks to the technical characteristics of the open-source HarmonyOS distributed architecture, the fuel dispenser can also realize the interconnection with other IoT terminals, optimize the user's operation process in the refueling scenario, and realize the comprehensive upgrade of the human-computer interaction experience.

Taking the Gongbin Road gas station as an example, the four smart fuel dispensers deployed in the station are equipped with multimedia intelligent screens, and are equipped with hardware equipment such as voice intercom, voice broadcast, receipt printing, and QR code scanners.

IT Home noticed that with the blessing of open source Hongmeng, the device supports the synchronization of indoor EPS payment functions to the screen of the refueling terminal, and can call the payment information of the oil gun, which is convenient for users to realize outdoor scan code payment.

In addition, the fuel dispenser is also compatible with a variety of payment methods such as WeChat, Alipay, UnionPay, PetroChina e-Sharing Card, etc., and supports barcode recognition of non-oil commodities and mixed payment of oil and non-oil commodities.

▲ Synchronize the indoor EPS payment function to the large screen of the intelligent interactive terminal of the fuel dispenser, and the payment information of the fuel gun can be retrieved to realize the outdoor direct scanning code payment

▲ Support WeChat Pay, Alipay, UnionPay, and PetroChina e-Card Member Payment

▲ Support scanning the barcode payment of non-oil commodities and mixed payment of oil and non-oil commodities

At the O&M level, with the help of the open-source HarmonyOS system base and equipment management capabilities, the smart fuel dispenser supports remote status monitoring, component life cycle management and other functions, and will combine industry data models to achieve a higher level of intelligent O&M in the future.

Original source: The open-source Hongmeng smart fuel dispenser is online and can be directly scanned to pay outside the gas station - IT Home

Welcome everyone to join the nut pie and build the HarmonyOS ecosystem: https://gitcode.com/nutpi

Flutter 3.22. We’re bringing WebAssembly to the stable channel, a fully featured Vulkan backend for Impeller on Android, promising smoother graphics and a major performance boost. We’re also introducing streamlined workflows with new widget state properties, dynamic view sizing, and improved form validation. But that’s not all — you’ll find flavor-conditional asset bundling, a preview of Vertex AI for Firebase in Dart, and updated DevTools to make your life easier.

In just a few months since our last update, we’ve merged an impressive 1595 pull requests from the Flutter community, with 37 new community members contributing to Flutter for the first time!

So, dive in and discover all the new features and enhancements that the Flutter community has brought to this latest release!

WebAssembly

With the release of Flutter 3.22, Wasm is now available on the stable channel, offering significant performance improvements. In our internal benchmarks using Chrome on an M1 MacBook, the Wonderous app’s frame rendering time improved by 2x on average and 3x in worst-case scenarios.

These enhancements are vital for apps with animations and rich transitions, where maintaining a smooth frame rate is essential. Wasm helps achieve this by reducing performance bottlenecks, resulting in smoother animations and transitions. To start using Wasm with your Flutter web apps, check out our Dart Wasm documentation and Flutter Wasm documentation. For the full announcement, visit the Flutter at Google I/O blog post.

Engine

Flutter 3.22 introduces significant updates to Impeller, the rendering engine that powers your Flutter applications. Key highlights include the completion of the Vulkan backend on Android for smoother graphics and improved performance, ongoing optimizations for blur effects and complex path rendering, and a new experimental API for testing with Impeller. In line with our roadmap, we’re committed to enhancing Impeller’s quality and performance, including completing the iOS migration to Impeller and expanding Android support.

Impeller

Vulkan backend feature complete on Android

In this release, Impeller’s Vulkan backend for Android is feature complete. In particular, in the past few months, the team has been hard at work completing the implementation of fast advanced blends, support for custom fragment shaders with the FragmentProgram API, PlatformView support (though it requires a small API migration), and fully implementing all blur styles.

Android preview

In the 3.19 stable release, after releasing improvements in Impeller’s OpenGL backend, we invited users to try out Impeller on Android devices both with and without Vulkan support. Over the past few months, after evaluating the performance of the OpenGL backend and estimating the remaining work on the Vulkan backend, we have decided to focus our efforts on making the Vulkan backend production ready first.

Impeller solves the issue of shader compilation jank. Additionally, in our benchmarks it outperforms the legacy renderer on average, 90th, and 99th percentile frame times. We therefore believe that the performance of the Vulkan backend on Android is acceptable. In this release (3.22), an app that opts-in to Impeller will use the Vulkan backend where available. In a future release, this will become the default. When an app that opts-in to Impeller runs on a device that doesn’t support Vulkan, Flutter will gracefully fall back automatically to using OpenGL ES with Skia. No action is necessary on your part. In the future, when we believe the OpenGL ES Impeller backend is production ready, this fallback will also use Impeller.

As the Impeller preview on Android continues through the 3.22 stable cycle, we request that Flutter developers upgrade to the latest stable version, and file issues about any shortcomings noticed when Impeller is enabled. Feedback at this stage is invaluable to ensuring that Impeller is successful on Android and that we will be able to confidently make it the default renderer in a release later this year. The Android hardware ecosystem is very diverse. For that reason, the most helpful feedback about Impeller should include detailed information about the specific device and Android version where issues occurred.

Blur performance improvements

Blur has been reimplemented in Impeller for both iOS and Android. In particular, the new approach, which is similar to Skia’s, reduces the CPU and GPU time of blurs by nearly half in benchmarks.

The chart below shows worst-case, 99%-ile, 90%-ile, and average frame rasterization times and GPU frame times in ms on an iPhone 11 device in a pathological benchmark intended to highlight blur performance. After rewriting Impeller’s blur, both the CPU and GPU cost of backdrop filter blurs has been nearly halved. This scale of this improvement translates to non-pathological cases as well, as would appear in typical apps.

Stencil-then-Cover

Impeller on both iOS and Android has moved to a new rendering strategy based on the Stencil-then-Cover approach described in the chapter “Drawing Filled, Concave Polygons Using the Stencil Buffer” in the OpenGL Redbook. Team members discussed more on this technique as it applies to Flutter in GitHub issue #123671.

This approach solves the issue where the raster thread was spending too much time calculating tessellations for complex paths on the CPU for example, SVGs and Lottie animations. After the change, the total frame time (UI thread on the CPU + raster thread on the CPU + GPU work) is much lower for frames that contain complex paths. Users will notice that Lottie animations and other complex paths render more smoothly, with lower CPU utilization, and slightly higher GPU utilization.

While pleased with these improvements, there is still more work to do. Among other opportunities, we are aware that polyline generation remains prominent in CPU profiles, and we intend to investigate shifting this work to the GPU, as well.

New API

While still experimental, flutter test now accepts the --enable-impeller flag, which exercises Impeller using the Vulkan backend.

Framework

Widget state properties

MaterialState has been moved outside of the Material library and renamed WidgetState, in order to make it available to Cupertino, the base Flutter framework, and package authors. For more information on migrating to the new WidgetState, see the migration guide.

Dynamic view sizing

Enhancements to dynamic view sizing benefits developers building responsive layouts, ensuring better UI adaptability across various device screens.

Improved form validation

Thanks to the contributions of Flutter community member SharbelOkzan, Flutter 3.22 comes with more flexible form validation methods allowing developers to create more robust user input handling, enhancing both usability and security.

Covariants in 2D APIs

Reducing the need for type casts in 2D graphics APIs simplifies development workflows and enhances performance, important for games and complex animations.

Flavor-conditional asset bundling

Developers using the flavors feature can now configure individual assets to be bundled only when building for a specific flavor. For more information, check out Conditionally bundling assets based on flavor.

Transformation of assets using Dart packages

Users can now configure Dart packages to transform their app’s assets as they are bundled. For more information, check out Transforming assets at built time.

Android

Deep linking

Deep links can significantly improve the user experience in your Flutter app, acting as shortcuts that seamlessly guide users to specific content within your app, boosting engagement, and driving sales. While Universal Links for iOS and App Links for Android are highly recommended for their security and user-friendly nature, setting them up can be a bit tricky.

In the last Flutter stable release, we introduced a deep link validator tool within DevTools that supports checking web configuration for Android apps. In this version, we added a new set of features to help verify setups within your Android manifest files.

For more information on using this tool, check out Validate deep links.

Predictive back gesture

Flutter now adds more support for Android’s upcoming predictive back feature, where users can peek at the previous route or even the previous app during a back gesture. This is still behind a feature flag on Android devices, but you can find details on how to try it out yourself on GitHub.

Flutter tool enforces version requirements on Gradle, AGP, Java, and Kotlin

In this release, the Flutter tool enforces a policy regarding the versions that it supports for Gradle, the Android Gradle Plugin (AGP), Java, and Kotlin. Initially, the tool only provides warnings.

Currently, the supported version ranges are as follows:

• Gradle — Fully supported 7.0.2 to current, warn otherwise

• AGP — Fully supported 7.0.0 to current, warn otherwise

• Java — Fully supported Java 11 to current, warn otherwise

• Kotlin — Fully supported 1.5.0 to current, warn otherwise

In the next major release these warnings will become errors, which can be overridden with the flag --android-skip-build-dependency-validation. More generally speaking, the tool provides a warning for at least one release before fully dropping support (generating an error) for a given version of these dependencies.

This policy was discussed in an associated design spec. Comments and feedback are always welcome.

Support for using Gradle Kotlin DSL in Gradle build scripts on Android

Gradle Kotlin DSL is now supported in Flutter, providing an alternative to the traditional Gradle Groovy DSL. This support allows for a better code editing experience, featuring auto-completion, quick access to documentation, source navigation, and context-aware refactoring.

This initial support was contributed by GitHub user bartekpacia. Developers can now choose to rewrite their Gradle build scripts in Kotlin to take advantage of these benefits, although the Flutter tool doesn’t yet allow for selecting Kotlin over Groovy when using flutter create.

For more details, check out the PR 140744 by bartekpacia.

Platform views improvements

Heads up for all Flutter app developers! If you’re using Flutter to build apps that rely on native Android components (like maps, web views, or certain UI elements), we have some important news.

Due to a bug in Android 14, apps built with older versions of Flutter might not work properly on devices running this new Android version.

Flutter 3.22 fixes this issue and improves the overall performance of these native components in your Android apps. So, to ensure your app runs smoothly on all Android devices, make sure to rebuild and release your app with Flutter 3.22.

This update also includes behind-the-scenes improvements to make platform views on Android more reliable and performant overall.

End of support for KitKat

Flutter’s minimum supported Android version is now Lollipop (API 21). Beginning with Flutter’s 3.22 stable release, Flutter will no longer work on devices running Android KitKat (API 19). For more details, see our deprecation guide.

iOS

Platform view performance

We understand that platform view performance on iOS has been a pain point for many Flutter developers. This has been especially noticeable within scroll views when using platform views.

Recent updates directly address these concerns, with significant improvements in scenarios like embedding multiple inline ads within an article. Here are some key improvements in our benchmark:

• Reduced GPU usage: GPU usage has been reduced by 50%, leading to less power consumption and a potentially smoother user experience.

• Improved frame rendering: Average frame render times have decreased by 1.66ms (33%).

• Minimized jank: Worst-case frame render times have been reduced by 3.8ms (21%).

If you’ve previously experienced performance challenges when using multiple platform views (like ads, maps, etc) within scrolling views, these optimizations offer the potential for a more fluid and responsive scrolling experience. Please give it a try and let us know what you think.

Ecosystem

Vertex AI for Firebase Dart SDK preview release

The Vertex AI for Firebase product has been released to public preview and includes the Dart SDK. This enables you to use the Gemini API to build generative AI features for your Dart or Flutter app, with production, performance and enterprise scale in mind. The SDK is integrated with Firebase App Check, which protects your API calls, and safeguards your backend infrastructure from serious threats like billing fraud, phishing, and app impersonation. Jump into the Getting Started for Dart and start using it with no cost with a promo code

The Google AI Dart SDK remains available, and is recommended for prototyping only. Google AI has free-of-charge access (within limits and where available) and pay-as-you-go pricing. If you have been prototyping with the Google AI Dart SDK, and are ready to migrate to Vertex AI for Firebase, check out the migration guide.

DevTools updates

We continue to improve DevTools, the suite of performance and debugging tools for Dart and Flutter. This release includes performance improvements, general polish, and new features like including CPU samples in the timeline, advanced filtering, and support for importing and exporting memory snapshots.

Other notable improvements were shipped with the devtools_extensions and devtools_app_shared packages that support DevTools extension authors. We added support for connecting an extension to the new Dart Tooling Daemon (DTD), which allows DevTools extensions to access public methods registered by other DTD clients, such as an IDE, as well as allowing access to a minimal file system API for interacting with the development project.

To learn more about all the updates included in Flutter 3.22 check out the release notes for DevTools 2.32.0, 2.33.0, and 2.34.1.

Google Mobile Ads SDK for Flutter

For those of you monetizing your Flutter apps with Ads, we’ve got some exciting news: Google Mobile Ads for Flutter has just released a major update to version 5.0.1!

Enhanced support for User Messaging Platform (UMP) SDK: The update adds support for the latest APIs from the Android UMP SDK version 2.2.0 and iOS UMP SDK version 2.4.0. The UMP SDK is crucial for complying with privacy regulations, making it easier for you to obtain user consent for personalized ads. This new version introduces several new APIs to simplify the consent gathering process.

Expanded mediation partners: We’ve broadened your ad monetization horizons by offering integrations with popular ad partners, including Unity, Meta, AppLovin, Iron Source, Mintegral, Pangle, DT Exchange, InMobi, and Liftoff. You can now maximize your app revenue with expanded mediation options and simplified implementation.

We encourage you to try out these new features in your Flutter apps and let us know which other mediation partners you’d like to see us support. Your feedback is invaluable as we continue to enhance the Google Mobile Ads SDK for Flutter.

Breaking Changes and Deprecations

Removal of v1 Android embedding

Deletion of version one of the Android embedding is under way. This will likely have no effect on most apps, as

1. Version two has been the default for many years

2. The Flutter tool would already block building version one apps, unless specifically overridden with the flag -- ignore-deprecation.

This release breaks Flutter tool support for v1 apps completely. It is no longer possible to override.

Plugin authors, please note: when the v1 android embedding was initially deprecated a migration doc was written for plugin authors at https://docs.flutter.dev/release/breaking-changes/plugin-api-migration. As part of this migration, it was recommended that plugin authors keep support for apps using the v1 embedding, by including in their *Plugin.java a method with the signature

public static void registerWith(@NonNull io.flutter.plugin.common.PluginRegistry.Registrar registrar)

We plan to fully delete the v1 Android embedding in the next release, at which point plugins that include a method with this signature will no longer compile (as it makes reference to a type from the v1 android embedding).

It currently serves no purpose, as this release has broken apps using the v1 embedding. We recommend that plugin authors release updated versions of their plugins with the v1 code removed as soon as possible, to avoid breakage in future versions of Flutter. For an example, check out PR 6494, which removed the plugins maintained by the Flutter team.

Deprecations removed in 3.22

Breaking changes in this release include deprecated APIs that expired after the release of v3.19. To see all affected APIs, along with additional context and migration guidance, see the deprecation guide for this release. Many of these are supported by Flutter fix, including quick fixes in the IDE. Bulk fixes can be evaluated and applied with the dart fix command-line tool.

As always, many thanks to the community for contributing tests — these help us identify these breaking changes. To learn more, check out Flutter’s breaking change policy.

Conclusion

At the heart of Flutter’s success is you — our amazing community. This release wouldn’t be possible without your countless contributions and unwavering passion. From the bottom of our hearts, thank you.

Ready to explore Flutter 3.22? Dive into the full release notes and changelog, fire up your terminal, and run flutter upgrade. We can’t wait to see what you build!

HarmonyOS Next API 16 for HarmonyOS Flutter 3.22.0 is released

Welcome everyone to join the nut pie and build the HarmonyOS ecosystem: https://gitcode.com/nutpi

Flutter 3.22.1 to the stable channel; This hotfix release addresses the following issues:

dart/55714 - Fixes a bug in the CFE which could manifest as compilation errors of Flutter web apps when compiled with dart2wasm.

dart/55758 - Fixes a bug in the pub client, such that dart run will not interfere with Flutter l10n (at least for most cases).

What’s new in Flutter 3.22

WebAssembly, Graphics rendering enhancements, and more options for AI integration - Flutter app framework development up to May 2024 https://medium.com/flutter/whats-new-in-flutter-3-22-fbde6c164fe3

3.29.2[2] Edit this on Wikidata / 13 March 2025; 40 days ago current version https://en.wikipedia.org/wiki/Flutter_(software)

Implementing a Custom Keyboard

Overview

This sample introduces how to implement a custom keyboard. The custom keyboard can be bound to the system keyboard so that they can switch to each other. The onAreaChange function can be used to obtain the custom keyboard height and set layout avoidance. This sample also describes technical scenarios such as keyboard switching, custom keyboard cursor, and custom keyboard layout avoidance.

Preview

Layout avoidance

Keyboard Switching

How to Use

1. On the home page, tap the text box for binding a custom keyboard. The custom keyboard is displayed, with layout avoidance upwards.

2. Tap the 123, ABC, and Chinese tabs on the keyboard to switch between the numeric keypad, English keyboard, and system keyboard. In this way, a text box can be bound to both the custom keyboard and system keyboard.

3. Common keyboard operations are supported, including text input, cursor setting, uppercase/lowercase change, copy, paste, and deletion.

├──entry/src/main/ets	                 // Code area
│  ├──constants
│  │  └──Constants.ets                   // Common constants
│  ├──entryability
│  │  └──EntryAbility.ets                // Entry ability
│  ├──model
│  │  └──KeyboardController.ets          // Custom keyboard controller
│  ├──pages
│  │  └──MainPage.ets                    // Main page
│  ├──view
│  │  ├──CustomKeyboard.ets              // Custom keyboard
│  │  ├──EnglishKeyboard.ets             // English keyboard
│  │  ├──NumberKeyboard.ets              // Numeric keyboard
│  │  ├──TabButton.ets                   // Tab button on the top of the keyboard
│  │  ├──TabView.ets                     // Tab component on the top of the keyboard
│  │  └──TextInputComponent.ets          // TextInput component bound to the custom keyboard
│  └──viewmodel
│     └──MenuModel.ets                   // Keyboard button data
└──entry/src/main/resources              // App resource directory

How to Implement

1. To implement a custom keyboard, the customKeyboard attribute of the TextInput component is bound to builder.

2. To switch between the custom keyboard and the system keyboard, the customKeyboard attribute of the TextInput component is set to null and is bound to the system keyboard.

3. To set the cursor position, the system listens for the onTextSelectionChange and onChange events of the TextInput component.

4. To implement the copy and paste functions, the system listens for the onPaste and onCut events of the TextInput component.

5. To implement layout avoidance, the keyboardHeightChange event of the window module is used to obtain the system keyboard height, and the onAreaChange event is used to obtain the custom keyboard height.

Permissions

N/A

Dependencies

N/A

Constraints

1. The sample is only supported on Huawei phones with standard systems.

2. The HarmonyOS version must be HarmonyOS 5.0.0 Release or later.

3. The DevEco Studio version must be DevEco Studio 5.0.0 Release or later.

4. The HarmonyOS SDK version must be HarmonyOS 5.0.0 Release SDK or later.

Original source: HarmonyOS_Samples/CustomizeKeyboard via Gitee

Technical architecture

This article is applicable to the migration and adaptation of Flutter applications to the HarmonyOS system, and the technical solution is based on:

• Flutter OHOS branch (of company, river etc) (3.13.9+)

• HarmonyOS SDK 5.0.0(12)

• OpenHarmony API 10

• HVigor build system

Environment preparation

1. Basic environment configuration

subassemblyrequestVerify the commandDevEco Studio≥4.0 Beta2hdc -vHarmonyOS SDK≥5.0.0(12)hvigor -vNode.js≥18.15.0node -v

2. Signature configuration template

json5

// build-profile.json5 { "signAlg": "SHA256withECDSA", "storeFile": "${user directory}/.ohos/config/default_ohos_xxx.p12", "keyAlias": "debugKey", "profile": "${user directory}/.ohos/config/default_ohos_xxx.p7b", "compatibleSdkVersion": "5.0.0(12)" }

3. Flutter OHOS environment configuration

3.1 Install the Flutter OHOS branch

bash

# Customised branches of cloning git clone -b ohos https://gitee.com/openharmony-sig/flutter.git export FLUTTER_HOME="D:/flutter_ohos" export PATH="$PATH:$FLUTTER_HOME/bin" # Verify Installation flutter --version # The expected output contains：Channel ohos • Framework Revision xxxx

Key adaptation steps

1. Project Initialization Configuration

Step 1: Create a HarmonyOS module

bash

# In the Flutter project root directory, run flutter create --template=module --platforms=ohos .

Step 2: Configure the hybrid project

json5

// ohos/oh-package.json5 { "name": "flutter_harmony", "version": "1.0.0", "dependencies": { "@ohos/flutter_module": "file:./entry" } }

2. Renovation of entrance documents

HarmonyOS ingress ability configuration

typescript

// ohos/entry/src/main/ets/entryability/EntryAbility.ts import flutter from '@ohos/flutter_module'; export default class EntryAbility extends Ability { onCreate(want: Want) { flutter.init(this.context); flutter.run({ entry: 'lib/main.dart' }); } }

3. Key points of the Flutter project transformation

3.1 Platform Conditional Compilation

dart

// Platform judgement logic const bool kIsOHOS = bool.fromEnvironment('dart.library.ohos'); void initPlatform() { if (kIsOHOS) { // Initialisation of the Hongmeng platform initOHOSComponents(); } else { // Other platform initialisation initMobileComponents(); } }

3.2 Platform channel adaptation

dart

// Native Communication Adaptation const _channel = MethodChannel('com.example/native'); Future<void> callNativeFeature() async { if (kIsOHOS) { return _channel.invokeMethod('ohos_feature'); } return _channel.invokeMethod('android_feature'); }

3.3 Resource File Adjustments

yaml

# pubspec.yaml Adjustment example flutter: assets: - assets/images/common/ - assets/images/ohos/ # Resources earmarked for Hong Kong - assets/fonts/ohos/ # Hongmeng Font Optimisation

4. Hybrid engineering build configuration

4. Project configuration implications

4.1 Multi-platform configuration management

bash

# Project restructuring lib/ ├── common/ # Cross-platform common code ├── ohos/ # Hongmeng-specific realisation │ ├── services/ │ └── widgets/ └── android/ # Native Android Implementation

4.2 HarmonyOS module build.gradle configuration

groovy

// ohos/entry/build.gradle ohos { compileSdkVersion 5 buildTypes { release { proguardOpt { enable true rulesFiles 'proguard-rules.pro' } } } }

4.3 Plug-in Compatibility

yaml

# pubspec.yaml conditionally dependent dependencies: shared_preferences: ^2.2.1 shared_preferences_ohos: ^1.0.0 url_launcher: ^6.1.9 url_launcher_ohos: ^2.0.0 dependency_overrides: shared_preferences: ohos: shared_preferences_ohos url_launcher: ohos: url_launcher_ohos

4.4 Build Configuration Changes

groovy

// android/build.gradle Need to comment out Android specific configurations // android { // compileSdkVersion 33 // ndkVersion "25.1.8937393" // }

Fourth, build the deployment process

1. Standard build commands

bash

# debug mode hvigor assembleDebug --mode module # production environment hvigor assembleRelease --mode module

2. Device deployment requirements

projectrequestSystem versionOpenHarmony ≥4.0Device typeDevices powered by the ArkUI engineSignature verificationA debugging certificate needs to be preset

5. Best Practices

1. Recommendations for environment configuration

bash

# Configuring Huawei Mirror Sources npm config set registry https://repo.huaweicloud.com/repository/npm/

2. Example of permission adaptation

dart

Future<void> checkHarmonyPermission() async { final status = await PermissionHandlerOhos.requestPermission( Permission.ohosPermission(permissionId: 'ohos.permission.INTERNET') ); if (!status.isGranted) { throw Exception('Requires authorisation of network access'); } }

6. Test and verification

1. Test the framework configuration

json5

// oh-package.json5 "devDependencies": { "@ohos/hypium": "^1.0.6" }

2. Key verification items

• Cross-platform component rendering consistency

• System-level function calls (camera, positioning, etc.)

• Hybrid Stack Management(Flutter+HarmonyOS)

7. Description of common dependencies

Dependency typeRecommended componentsFeature descriptionBasic framework@ohos/flutter_ohosFlutter runtime environmentSystem interactionurl_launcher_ohosHarmonyOS IntentHardware accesspermission_handler_ohosPermission management adaptationBlended renderingwebview_flutter_ohosSystem WebView integration

postscript

Initial learning of Flutter and HarmonyOS NEXT hybrid development, in the hybrid development architecture, the design quality of the Platform Abstraction Layer directly affects the subsequent maintenance cost. It is recommended to establish a unified platform difference handling specification at the beginning of the project.

Original Link：https://juejin.cn/post/7481217307647836187

Introduction to LiteOS

The ancestor of HarmonyOS and OpenHarmony shared lineage of distributed operating systems. LiteOS was an open-source, lightweight operating system designed specifically for Internet of Things (IoT) devices and embedded systems. It was developed and maintained by Huawei for 5 years on the Chinese Gitee repo site from 2015 to its disbandment in December 2020, with 50 million units of Huawei IoT products from smart devices to smart wearables, 3 months after the first OpenHarmony 1.0 version under OpenAtom that carried the LiteOS kernel built for microcontrollers on the LiteOS M kernel module variant and ARM-based development boards called LiteOS A kernel module variant derived from the original operating system. LiteOS is optimized for low-power consumption, high-performance networking, and flexible connectivity in smart devices. It offers a rich middleware framework that facilitates rapid application development, making it suitable for a wide range of IoT applications.

Key Features of LiteOS

LiteOS offers a variety of features tailored for IoT environments:

1. Lightweight Design: With a minimal footprint, LiteOS is ideal for devices with limited memory and processing power.

2. Real-Time Capabilities: Ensures low latency and fast response times, crucial for time-sensitive applications.

3. Scalability: LiteOS can run on small embedded devices as well as larger systems with complex requirements.

4. Flexible Connectivity: Supports multiple communication protocols, including Wi-Fi, Bluetooth, ZigBee, and LoRa.

5. Security Features: Offers data encryption, secure boot mechanisms, and access control to ensure device security.

6. Middleware Integration: LiteOS simplifies integration with cloud platforms and third-party services.

7. Cross-Platform Compatibility: Supports ARM Cortex-M, RISC-V, and other architectures commonly used in IoT devices.

Architecture of LiteOS

LiteOS follows a layered architecture that improves modularity and efficiency. The core layers include:

• Kernel Layer: Provides real-time scheduling, memory management, and hardware abstraction.

• Middleware Layer: Offers libraries and APIs for communication protocols, device management, and data synchronization.

• Application Layer: Includes customizable applications for specific IoT use cases, supporting both user-defined code and pre-built templates.

• Driver Layer: Facilitates hardware integration by providing standardized driver interfaces.

Development Environment

LiteOS is designed for easy development and integration with multiple hardware platforms. The development environment includes:

• IDE Support: Compatible with common IDEs like Keil, IAR, and GCC for streamlined coding and debugging.

• API Libraries: Provides extensive libraries for networking, security, and peripheral control.

• Device Drivers: Pre-built drivers simplify development by handling sensor, actuator, and communication module interfacing.

• Cloud Integration: Seamlessly integrates with Huawei Cloud, AWS, and other IoT cloud platforms for data storage and remote management.

Applications of LiteOS

LiteOS is widely adopted across various industries that require reliable, energy-efficient IoT solutions. Common applications include:

• Smart Home Devices: For controlling lighting, security cameras, and appliances.

• Wearable Devices: Provides lightweight functionality for fitness trackers and health-monitoring gadgets.

• Industrial IoT (IIoT): Enables predictive maintenance, asset tracking, and automation systems.

• Smart Cities: Supports traffic monitoring, environmental sensors, and public safety systems.

• Automotive Systems: Manages in-vehicle data communication and sensor networks.

Advantages of LiteOS

• Minimal Resource Consumption: Designed to operate efficiently on devices with limited RAM and processing power.

• Fast Boot Time: Optimized for rapid system startup, crucial for time-sensitive applications.

• Flexible Deployment: Its modular structure enables developers to customize features as per device requirements.

• Strong Security Framework: Provides encryption, secure communication protocols, and authentication mechanisms.

• Extensive Ecosystem: Supports a wide range of hardware platforms, enabling flexibility for developers.

Challenges of LiteOS

Despite its strengths, LiteOS faces a few challenges:

• Limited Community Support: Compared to established platforms like FreeRTOS or Zephyr, LiteOS has a smaller developer community.

• Learning Curve: Developers unfamiliar with Huawei’s ecosystem may require additional time to master LiteOS features.

• Vendor Dependency: Some advanced features are optimized for Huawei hardware and cloud services, limiting cross-platform flexibility in certain cases.

Conclusion

LiteOS was a powerful and lightweight operating system designed to meet the demands of modern IoT devices. With its real-time performance, flexible connectivity options, and secure framework, LiteOS is an excellent choice for developers creating energy-efficient and scalable IoT solutions. By leveraging LiteOS’s middleware capabilities and cloud integration features, businesses can accelerate their IoT deployments while ensuring robust performance and security.

Huawei's in-house independent open-source LiteOS was RTOS rich and POSIX compatible, targeted solely for the Internet of Things with its 10KB footprint that can power on AA batteries, competing with POSIX-based NuttX but didn’t have any Unix-like roots. It was once mistaken as a fork of a different Unix-like RTOS operating system of the same name from the University of Tennessee.

The “two sides of the same coin” of Hongmeng

OpenHarmony: Open Source Empowerment

OpenHarmony has basic code contributed by Huawei and is incubated and operated by the Open Atom Open Source Foundation. It is completely free and open source, providing an open source operating system base for the entire industry.

It is positioned for the entire industry and supports free customization by third-party manufacturers, from mobile phones to IoT devices, automobiles, etc., to build a neutral and open distributed operating system ecosystem.

HarmonyOS: Business closed loop

HarmonyOS is a closed-source commercial system under the Huawei brand, which requires authorization for use and focuses on Huawei's "1+8+N" full-scenario strategy.

Deeply optimize the collaborative experience of Huawei hardware, such as mobile phones, tablets, PCs, wearable devices, etc., create the core operating system for high-end smart devices, and support Huawei's closed ecological loop.

Goal difference

OpenHarmony aims to build a neutral and open distributed operating system ecosystem to promote the prosperity and development of the Internet of Things industry.

The goal of HarmonyOS is to create a core operating system for high-end smart devices, support Huawei's closed ecological loop, and provide users with the ultimate full-scenario smart experience.

It was given to the Atomic Foundation for incubation and operation.

The same technical foundation

01

code sharing

The basic functions of HarmonyOS (such as distributed architecture, kernel, and driver) are derived from OpenHarmony born out of Open Source Technology Center division since 2012 R&D with LiteOS in parallel and 2015 development at Huawei after standalone original LiteOS real time operating system released as the original author and then donated to OpenAtom Foundation in June 2020 to maintain development and repo officially went live in September 2020, as 1.0 after HarmonyOS launch in August 2019 with HarmonyOS 2.0 beta underlining dual-frame OpenHarmony enhancement technologies together during the same month of September 2020 with accessible open source LiteOS kernel derived from LiteOS and shortly accessible Linux kernel on 1.1.0 LTS (after HarmonyOS 1). The underlying technologies of the two are highly interoperable, and the cost for developers to switch between the two is low to zero.

For example, distributed soft bus technology is used in both to achieve seamless interconnection between devices, quickly discover and connect devices, and efficiently transmit tasks and data.

02

Unified development language

ArkTS (Ark Language) is used as the main development language to support cross-device application development. Developers only need to master one language to develop applications on different devices. ArkTS language has the characteristics of high performance and easy development, and can meet the development needs from lightweight IoT devices to high-end smart devices.

03

Distributed capabilities

Share the distributed technology of "device as a service, service as a device" to achieve seamless multi-terminal collaboration, such as file transfer and cross-terminal screen projection.

For example, on OpenHarmony and HarmonyOS devices, users can quickly transfer files on their phones to tablets or computers to achieve efficient office work.

Technical differences - system architecture and customizability

openness

OpenHarmony is completely open source and supports deep third-party customization, such as modifying the kernel and adding hardware drivers. It is suitable for manufacturers with technical strength to carry out personalized development.

HarmonyOS is closed source, and only Huawei and authorized partners can optimize it based on the framework. Customization is limited, but it can ensure the stability and security of the system.

Hardware adaptation

OpenHarmony supports all categories of devices, from MCU-level sensors to high-end mobile phones. It is highly flexible and can meet the hardware requirements of different industries and scenarios.

HarmonyOS focuses on the hardware of Huawei and a few partners, such as Kirin chips and Hongmeng cockpit, giving priority to adapting to its own devices and providing a deeply optimized hardware collaboration experience. System update

OpenHarmony is community-driven, and version iterations rely on open source contributions, such as participation from universities and enterprises. The speed of updates is affected by community activity.

Huawei leads the update of HarmonyOS to ensure long-term maintenance of devices, such as the 3-year (5-6)* system upgrade policy, to provide users with a stable user experience.

Technological Differences——Ecology and Compatibility

Application ecology

OpenHarmony requires third parties to build their own ecosystem to support native Hongmeng applications and some Android applications (through virtual machines). Ecosystem construction takes time.

HarmonyOS was compatible with Android applications in the early days and quickly enriched its ecosystem. In 2025, HarmonyOS NEXT completely abandoned Android compatibility and turned to a pure-blooded Hongmeng ecosystem, with the proportion of native applications increasing to more than 80%.

Device collaboration

OpenHarmony provides basic distributed interfaces, and manufacturers need to independently develop cross-device functions. It is suitable for manufacturers with technical strength to conduct in-depth customization.

HarmonyOS is deeply integrated with Huawei's "Super Terminal", connecting multiple devices with one click, such as mobile phone + tablet + car machine, seamlessly flowing, providing users with the ultimate multi-device collaborative experience.

business characteristics

OpenHarmony does not have pre-installed Huawei services (such as HMS Core) libraries, and manufacturers need to integrate them themselves. It is suitable for manufacturers with independent service needs.

HarmonyOS has built-in HMS Core (Huawei Mobile Services) libraries, supports exclusive features such as Petal Maps, Harmony Intelligence Celia (Pangu-MindSpore) and Huawei Wallet, and provides users with a wealth of Huawei-specific services.

Ecological differentiation and typical scenes

OpenHarmony Ecosystem

Participants: Third-party manufacturers such as JD.com, OPPO, Midea, and Gree, who build their own brand systems. For example, OPPO's Pantanal system is based on OpenHarmony.

Scenarios: IoT terminals (smart home appliances, industrial equipment), educational equipment, and in-vehicle systems (such as BAIC Arcfox Hongmeng car machine), promoting the intelligent upgrade of various industries.

HarmonyOS Ecosystem

Core equipment: Huawei mobile phones (Mate/P series), tablets (MatePad), notebooks (MateBook), smart watches (Watch GT), smart screens (Vision), etc.

Advantageous scenarios: multi-terminal collaborative office (such as dragging mobile phone files to PC for editing), distributed photography (combined shooting of multiple device lenses), and Hongmeng cockpit (Wenjie series cars), providing users with a seamless full-scenario intelligent experience.

Developer entrance and technical route

OpenHarmony (Oniro) Development

Official website: Gitee Open Source Community

Oniro: GitHub Open Source Community

Development direction:

Northbound (application layer): ArkUI interface development and distributed application design to meet application requirements in different scenarios.

Southbound (device layer): hardware driver development, embedded device adaptation, such as MCU-level chips, to promote the intelligence of hardware devices.

System layer: kernel optimization and framework expansion require community contribution review to improve system performance and stability.

HarmonyOS development

Official website: Huawei Developer Alliance

China: 华为开发者联盟-HarmonyOS开发者官网，共建鸿蒙生态

Development direction: Focus on application development and leverage HMS Core capabilities

(such as AI, payment, and maps), adapted to Huawei's full-scenario devices, and providing users with a rich application experience.

Tool chain: DevEco Studio is a one-stop development platform that supports low-code development and cross-end deployment to improve development efficiency.

Key trends and milestones

Core Actions for 2025

HarmonyOS NEXT has been fully launched, and the pure-blooded HarmonyOS ecosystem has taken shape. It no longer relies on Android applications, and the proportion of native applications has increased to more than 80%, marking the maturity of the HarmonyOS ecosystem.

The OpenHarmony ecosystem is expanding, and it is expected that the number of third-party devices will exceed 1 billion, covering smart homes, industrial Internet and other fields, and promoting the development of the Internet of Everything. The OpenHarmony overseas plan has been launched this year.

01

long term goals

Breaking the iOS/Android monopoly, forming the world's third largest operating system ecosystem driven by the dual wheels of "open source OpenHarmony + commercial HarmonyOS", providing more choices for global users.

Promote the implementation of "Internet of Everything" and realize the ultimate form of device as a service, such as seamless integration of smart cars and smart homes, to provide users with a more convenient and intelligent life experience. 1+8+N ecosystem.

Core conclusion

symbiotic relationship

OpenHarmony is the cornerstone of the ecosystem, providing an open source foundation for the entire industry; HarmonyOS is a business pioneer, creating a high-end device ecosystem. The two complement each other rather than oppose each other, and jointly promote the development of the Hongmeng ecosystem.

Select suggestions

Third-party manufacturers: Build their own brand systems based on OpenHarmony to lower technical barriers and quickly enter the market.

Developers: Prioritize HarmonyOS development to access Huawei's high-end device ecosystem, or participate in the OpenHarmony community to contribute underlying technologies and enhance your own technical capabilities.

Industry impact

The Hongmeng dual-track system is expected to reshape the global operating system landscape, provide strategic support for "Chinese chips + Chinese systems", and promote the independent and controllable development of China's technology industry.

A cornerstone of incubation

How to balance the openness of the open source ecosystem and the closedness of the commercial ecosystem is the key to whether Hongmeng can challenge iOS/Android in the future. It is necessary to find a suitable balance between openness and closedness to ensure the prosperity of the ecosystem and protect commercial interests.

Thinking is actually walking on this leg.

Differences and commonalities between HarmonyOS and OpenHarmony

Differences and commonalities between HarmonyOS and OpenHarmony

Gone through Tencent, BMW, research institute, finance. Worked in private enterprises, foreign companies, and central enterprises. Ten years of deep cultivation in the field of large application development. OpenHarmony，HarmonyOS，Flutter，H5，Android，iOS. He is currently working as an application architect at HarmonyOS. Officially certified as a creator by HarmonyOS.

Since the release of the Java (Java SDK) version of HarmonyOS in 2021, I have continued to pay attention to the development of the HarmonyOS ecosystem. In the process of in-depth understanding, I became more and more interested in HarmonyOS, and in 2023, I officially devoted myself to the development of open source HarmonyOS, learning ArkUI and ArkTS. Now, I'm further involved in the development of HarmonyOS head apps.

In the past few years of development, I have accumulated a wealth of experience and many profound insights. I am well aware that "the truth becomes clearer the more it is debated", and good learning, summary and communication can not only promote the improvement of the knowledge framework, but also highly consistent with the concept of open source code.

Only through full exchange, learning and summarization can the truth be tested in practice, just as advocated by the Feynman learning method. Therefore, I hope to share what I have learned, felt, and understood with my peers who are also learning about HarmonyOS development, so as to provide you with useful references. If you have any comments or questions, please feel free to communicate with me.

Translated from -

Original source BiliBili: Differences and commonalities between HarmonyOS and OpenHarmony (China, Mandarin) by GeorgeGcs_ 2025-04-16

Huawei Developer Conference HDC 2025 single-day ticket is 198 yuan, and the highest VIP early bird ticket is 4298 yuan.

https://developer.huaweicloud.com/hdc/hdc2025/hdc2025.html

The invitation letter attached to IT Home is as follows:

Dear Developers,

Every line of code is the spark that changes the world; With every attempt, a footnote is written for the digital future. From the beginning of Hongmeng to the sea of stars, from the opening of Pangu to the tide of intelligence, we always believe that the power of technology begins with small and becomes persistent. In June 2025, we sincerely invite you to Songshan Lake, Dongguan, to work with developers around the world to weave the warp and weft of the intelligent era with code at the Huawei Developer Conference (HDC 2025).

It's not just a tech summit, it's a "home field" for developers

Zero distance from the future

• Experience the advanced design of the latest version of HarmonyOS

• Discover the evolution of Ascend AI and the Pangu model, and witness how AI is reshaping industries such as healthcare, manufacturing, and finance

Your love deserves to be shared

• CodeLabs: Huawei engineers support you from a line of Hello World to complete meta-services and HUAWEI CLOUD applications

• HarmonyOS Innovation Race:HarmonyOS opens up a new future

• AI Application Development Center: HUAWEI CLOUD provides a solid foundation for you to develop the latest AI applications

Here, small forces will converge into a galaxy

We tailor the stage to every passion

• Independent Developer Zone: Full-cycle technical guidance + exclusive development resource support to open up the fast lane of HarmonyOS ecological docking

• Accessible technology: Practice digital inclusion with code, and let technology warm everyone

Inspiration collides

• HarmonyOS Open Class: Sowing Dreams and Hopes for Future Developers

• Sweeping Monk Meeting: Dialogue with HUAWEI CLOUD experts and top open source contributors to debunk technical myths

• Zone: Immerse yourself in the world's top 100 HarmonyOS application cases, unlock the creative boundaries of AI-generated applications, and experience the achievements of the world's top developers

In the summer of 2025, let's use code as a contract to ask why technology came about – under the stars of the Huawei Developer Conference, there is no commercial hustle and bustle, only the pure answer of thousands of lines of code: make the world a better place.

After the HarmonyOS 5 build, consumers are eagerly looking forward to HarmonyOS 6. The company may introduce a new software version at the HDC 2025 event. HDC 2025 may have a global format within the China hosted event in English next to Mandarin like HDC 2024. The only difference last year only hosted Pangu AI, Business to Business stuff while HarmonyOS NEXT development was China-focused. This year may be different with pure HarmonyOS fully transitioned in China and globally.

Original source: HUAWEI Developer Conference HDC 2025 is scheduled for June 20~22, and early bird tickets will go on sale tomorrow - IT Home (China)