小村軟體有限公司
聯絡我們
選單

OpenHarmony是什麼 ── 整理與HarmonyOS、HarmonyOS NEXT之間的差異

· · OpenHarmony, HarmonyOS, 嵌入式, OS選型, 開放原始碼, ArkTS, 技術諮詢, 裝置嵌入式

更新紀錄(僅初版,2026年07月26日 發布)
初次發布
引用本文(DOI（已登錄存檔）: 10.5281/zenodo.22175171)

以下 DOI 指向先前登錄的存檔，內容可能與目前正文不同。引用目前正文時，請使用本頁網址。

Go Komura(2026)。〈OpenHarmony是什麼 ── 整理與HarmonyOS、HarmonyOS NEXT之間的差異〉。小村軟體有限公司。 https://comcomponent.com/zh-TW/blog/openharmony-vs-harmonyos-explained/

DOI（已登錄存檔）
10.5281/zenodo.22175171
DOI（上次登錄版本）
10.5281/zenodo.22175172

「OpenHarmony和HarmonyOS是同一樣東西嗎」、「HarmonyOS NEXT還能不能執行Android應用程式」。這兩件事必須分開來思考。

OpenHarmony是開放原始碼的作業系統專案，HarmonyOS則是華為的商用作業系統產品。HarmonyOS NEXT則是這套商用作業系統移除Android相容性之後那一世代的稱呼。先把專案和產品分開，接著確認產品的世代，這三個名字相近的東西就能整理清楚。

以日文撰寫的資訊常常把這幾件事混在一起，「鴻蒙(Hongmeng)＝中國版Android」、「裝了OpenHarmony就能執行HarmonyOS的應用程式」之類的誤解已經根深柢固。從評估裝置該搭載哪一種作業系統的立場來看，這種混亂會造成實際的損害。因為無論是要向採購對象確認的內容、法務需要留意的授權，還是開發者要學習的語言，全都會因為指的是哪一個而完全不同。

本文以嵌入式設備與業務系統的技術人員為對象，依據OpenHarmony官方文件與華為的官方發表這兩類第一手資料，整理OpenHarmony／HarmonyOS／HarmonyOS NEXT之間的關係。「是否能成為裝置搭載的選項」這項實務判斷，留待姊妹文作為裝置搭載的OS，OpenHarmony能否成為選項討論。

本文整理的是2026年7月時點的資訊。以下的數值、版本表、維護時程，也請當成這個時點的敘述來讀。尤其是世代的稱呼(NEXT／5／6／7)、智慧型手機與應用程式市場的地區布局、社群的分支維護時程，都是變化快速的領域。在用於採購或設計判斷之前，請先開啟各節註腳所列的出處確認日期。

1. 先講結論

OpenHarmony和HarmonyOS，公開範圍與使用前提都不同。OpenHarmony是由OpenAtom基金會(開放原子開源基金會)培育、營運的專案，原始碼任何人都能取得。HarmonyOS則是在這個基礎上加入華為自有框架、應用程式發布平台、雲端服務的商用產品，原始碼並未整體公開。12

談到HarmonyOS時，要一併指明世代。部署到智慧型手機上的2～4.x世代，是AOSP(Android Open Source Project)與OpenHarmony組合而成的架構。請把它與移除Android相容性的NEXT(＝HarmonyOS 5)以後分開來看。1.0則是更早之前、面向智慧螢幕的世代。另外，即使應用程式模型有共通之處，也不保證HarmonyOS的應用程式能在OpenHarmony的裝置上直接執行(第4、5章)。34

要把它用在裝置上時，該確認的不是名字，而是架構與維護。要採用三種系統類型中的哪一種、應用程式由誰開發、需要的年限由誰維護、要遵循哪個元件的授權，這些才是判斷材料。歐洲系的Eclipse Oniro也當成另一個系統來整理(第3、5、7～9章)。

依目的挑選閱讀方式

想知道的事 該讀的地方
想先掌握OpenHarmony、HarmonyOS、NEXT之間的關係 第2章：系譜與世代年表
想了解核心與設備的架構 第3章：四層結構與三種系統類型
想了解Android應用程式的支援情況，以及NEXT之後的地區布局 第4章：世代差異與裝置的種類
想知道為HarmonyOS開發的應用程式能不能用在自家裝置上 第5章：共通的應用程式模型與不同的發布平台
想確認版本與API等級、維護期限 第6章：編號的解讀方式、第7章：維護期間
想確認授權並取得原始碼 第8章：授權與取得管道
想了解Eclipse Oniro的定位 第9章：歐洲系的分支

如果只是想知道差異，讀第2、4、5章即可；若要考慮把它用在裝置上，請一路讀到第3、6～8章。具體的採用判斷則另外分到開頭介紹的姊妹文。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 39 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 用一張圖整理系譜

這裡依序看「誰提供的什麼東西」以及「屬於哪一個世代」。OpenHarmony是專案，HarmonyOS是商用產品。NEXT並不是與OpenHarmony並列的另一個專案，而是用來區分HarmonyOS世代的稱呼。

首先，把專案和商用產品分開

不要只憑「鴻蒙(HarmonyOS)」這個名字就往下談，先確認指的是下表的哪一列。

名稱 實體 歸屬 原始碼公開情況 主要用途
OpenHarmony 開放原始碼作業系統專案 OpenAtom基金會1 公開(Apache 2.0等)5 物聯網設備、工業設備、嵌入式、教育
HarmonyOS 1.0 華為的商用作業系統(OpenHarmony公開前的世代) 華為 不公開 智慧螢幕(Honor Vision)
HarmonyOS 2～4.x 華為的商用作業系統(AOSP＋OpenHarmony混成) 華為 不公開(僅基礎的OpenHarmony部分公開) 華為製智慧型手機、平板電腦等
HarmonyOS NEXT／5／6／7 華為的商用作業系統(移除AOSP) 華為 不公開 華為製智慧型手機、PC、車用等

接著，把HarmonyOS的世代分開

把表格的列依時間軸重新排列，就能一眼看出「同一個名稱的作業系統，內容是在哪裡被替換的」。

2019HarmonyOS 1.0面向智慧螢幕2021-2024HarmonyOS 2～4.xAOSP 與OpenHarmony 混成Android應用程式可執行2024HarmonyOS NEXT即 5移除源自 AOSP的程式碼Android應用程式無法執行2025HarmonyOS 6不再使用「NEXT」稱呼2026HarmonyOS 7於 HDC 2026發表開發者 BetaHarmonyOS 的世代與 AOSP 存廢

圖1：HarmonyOS的世代，以及Android應用程式能否執行的分界線436

分界線是2024年的NEXT(＝5)。請先確認在這條線之前接觸過的世代經驗，與之後世代的說法，是否在公司內部混為一談。

從同一個基礎分出去的Oniro也要區分開

以OpenHarmony為基礎、另成一系的還有Eclipse Oniro。詳細的定位在第9章說明。

名稱 實體 歸屬
Eclipse Oniro for OpenHarmony 以OpenHarmony為基礎、源自歐洲的發行版 Eclipse Foundation7

換句話說，OpenHarmony是「素材」，HarmonyOS與Oniro則是「用這個素材做出來的不同產品」。可以聯想Linux核心之於Red Hat Enterprise Linux與Debian的關係，粒度會比較接近。不過與Linux不同的是，OpenHarmony不只包含核心，還一路涵蓋UI框架乃至應用程式模型，是相當垂直堆疊的一整套體系。

3. OpenHarmony的實體 ── 裡面到底有什麼

OpenHarmony官方文件把這個專案說明為「由OpenAtom基金會培育、營運的開放原始碼專案，目標是為各種使用情境下的智慧裝置，打造開放原始碼的分散式作業系統框架」。1

這一章依序看元件的名稱→作業系統的層次結構→各類設備的組態→設備間協作→開發板。雖然同樣叫「使用OpenHarmony」，但搭載的設備不同，要選的組態也不一樣。

先確認術語

專有名詞集中出現，先在此放一份最小限度的對照表。

術語 意義
LiteOS 面向資源受限設備的核心。有面向MCU的LiteOS-M，以及面向Cortex-A的LiteOS-A1
KAL(Kernel Abstraction Layer) 核心抽象層。隱藏Linux與LiteOS之間的實作差異，向上層提供共通的API1
HDF(Hardware Driver Foundation) OpenHarmony自有的統一驅動程式基礎架構。裝置驅動程式都寫在這上面1
DSoftBus(分散式軟體匯流排) 發現並連接鄰近設備、不受通訊方式限制傳輸資料的設備間協作共通基礎架構1
Ability 表示應用程式執行單元的模型。有具備畫面的類型，也有在背景負責處理或提供資料的類型
ArkTS 擴充TypeScript而成、面向宣告式UI的應用程式開發語言
ArkUI 以ArkTS組建畫面的宣告式UI框架

四層架構

架構由下而上依序為核心層、系統服務層、框架層、應用程式層這四層。1

  • 核心層：採用多核心設計，依裝置的資源限制選擇Linux或LiteOS。核心抽象層(KAL)隱藏實作差異，向上層提供共通的處理程序、記憶體、檔案系統、網路、周邊裝置管理。驅動程式則以名為HDF(Hardware Driver Foundation)的自有統一驅動程式基礎架構撰寫。
  • 系統服務層：分散式軟體匯流排(DSoftBus)、分散式資料管理、分散式排程器、多模態輸入、圖形、安全性、AI等。
  • 框架層：面向C/C++/JS的應用程式框架與Ability框架，以及面向JS的ArkUI框架。
  • 應用程式層：系統應用程式與第三方應用程式。

核心並沒有固定成一種

這裡重要的是，「多核心」這個設計決定了OpenHarmony的性格。雖然名稱相同，但在MCU上執行的是LiteOS-M，在資源充裕的設備上執行的則是Linux核心。面對「OpenHarmony的核心是什麼」這個問題，需要反問一句「你說的是哪一種系統類型」。

三種系統類型

「四層」是作業系統內部的職責分工，「三種系統類型」則是配合設備所做的組態區分。這是兩個不同的軸。官方文件定義了三種基本系統類型。8

系統類型 處理器 最小記憶體 提供的功能 預期產品
輕量系統(Mini) Arm Cortex-M、32位元RISC-V等MCU 128 KiB 輕量網路協定、輕量圖形、面向IoT匯流排的讀寫元件 連網模組、感測器、穿戴式裝置
小型系統(Small) Arm Cortex-A等應用處理器 1 MiB 更高的安全功能、標準圖形框架、影片編碼／解碼 IP攝影機、門眼、路由器、行車記錄器
標準系統(Standard) Arm Cortex-A等應用處理器 128 MiB 完整的應用程式框架、3D GPU、硬體合成器、豐富的動畫 帶高階螢幕的家電

從128 KiB起步，是這套作業系統獨特之處。官方文件也寫道「支援從數百KiB到GiB級的RAM」。1 它採用元件化設計，可以把不需要的元件從組態中拿掉，再依需求往上堆疊。

作為核心概念的分散式功能

官方最先舉出的OpenHarmony特徵，是以DSoftBus(分散式軟體匯流排)為中心的設備間協作。1 這是一套能發現、連接近距離設備並組成網路、且不受通訊方式限制傳輸資料的共通基礎架構，其上再疊加分散式資料管理(跨設備的資料同步)與分散式排程器(跨設備的應用程式啟動與轉移)。

用在單一裝置上時，要看清真正需要的功能

這種「把多台設備當成一台超級裝置來對待」的理念，也是HarmonyOS在智慧型手機、平板電腦、車用之間協作體驗的基礎。反過來說，如果只是嵌入單一裝置獨立使用，OpenHarmony的招牌功能大概有一半用不上。這一點在採用判斷時會產生影響。

開發板與硬體

本文參照的2026年7月時點官方清單中，社群支援的開發板共22款。9 依系統類型分開來看，大致如下。

  • 面向標準系統：搭載Rockchip RK3568的HiHope HH-SCDAYU200、搭載NXP i.MX8M Mini的MILOS_Standard0。
  • 面向小型系統：搭載STM32MP157A的BearPi-HM Micro。
  • 面向輕量系統：Hi3861、STM32F407、ESP32、RISC-V的HPM6750等。

其中不僅有中國系SoC，也包含ST與NXP的晶片。也有產品載明了以工業用途為前提的說明，例如MILOS_Standard0列出的用途就包括「工業與醫療用高效能量測儀器、工業控制與HMI、交通、防災、大樓」。9

4. HarmonyOS的實體 ── AOSP混成期與NEXT之後

HarmonyOS是華為的商用作業系統產品。這裡要掌握的重點是，同樣名為「HarmonyOS」，內容卻依世代而異。

HarmonyOS 1.0(2019年)

最初搭載的並非智慧型手機，而是智慧螢幕(Honor Vision)。這是OpenHarmony捐贈給OpenAtom基金會之前的世代，並不是以智慧型手機用作業系統的身分在市面流通。4

HarmonyOS 2～4.x(2021～2024年)

這是部署到智慧型手機上的世代。採用AOSP與OpenHarmony組合而成的架構，這一世代的裝置能同時執行Android應用程式(APK)與HarmonyOS應用程式。日本之所以流傳「HarmonyOS就是Android的中國版」這種理解，正是因為這一世代的實際情況看起來確實如此。3

HarmonyOS NEXT(＝HarmonyOS 5，2024年)

AOSP相容層與Android函式庫被移除，Android應用程式無法再執行。能執行的只有HarmonyOS原生應用程式。3

「HarmonyOS原生應用程式」並不表示只能用ArkTS撰寫。可以組合以C/C++撰寫的Native API(NDK)模組，華為自主開發的語言倉頡(Cangjie)也作為HarmonyOS應用程式開發的選項提供。1011

HarmonyOS 6以後(2025年～)

「NEXT」這個稱呼被拿掉，直接稱為HarmonyOS 6。2026年6月12日在東莞舉辦的HDC 2026上，發表了HarmonyOS 7開發者Beta啟動，並公布HarmonyOS 6的裝置數量突破6,600萬台、註冊開發者超過1,100萬人、應用程式商店可取得的應用程式與服務超過40萬個，以及HarmonyOS已成為中國第二大智慧型手機作業系統。6

不要把HarmonyOS的普及數量與OpenHarmony的商用版本數混為一談

在同一場發表中，華為也提到OpenHarmony這一側「已發布超過100個商用版本」。6 換句話說，對華為而言，OpenHarmony既是自家智慧型手機的基礎，同時也是其他公司打造工業用產品的供應來源。

地區特性要依「裝置的種類」分開思考

從日本的角度來看，實務上有影響的是地區特性，但若把裝置一概而論就會誤判。應該分開來看的是智慧型手機與應用程式發布生態系，以及穿戴式裝置等周邊裝置的韌體。

  • 智慧型手機與應用程式市場以中國為中心。HarmonyOS 6的產品頁面設置在中國網站上，12 另一方面，華為的全球消費者網站(consumer.huawei.com/en/harmonyos/)截至2026年7月仍停留在HarmonyOS 2的介紹頁面。13 面向NEXT系智慧型手機的HarmonyOS原生應用程式及其發布市場，實質上視為中國國內的事較為妥當。
  • 另一方面，HarmonyOS這個品牌也搭載在中國以外地區的裝置上。華為向全球市場的智慧型手錶也配送了HarmonyOS 5系、6系的韌體更新，因此還不能斷言「HarmonyOS 5以後＝僅限中國國內」。14

因此，如果日本企業要討論「開發並發布HarmonyOS應用程式」，那就必然要與面向中國市場的事業判斷綁在一起。另一方面，OpenHarmony則是不分地區、任何人都能取得原始碼使用，這兩者在決策上應該當成完全不同的事情來處理。

5. 「OpenHarmony應用程式」與「HarmonyOS應用程式」是同一回事嗎

有共通的語言與應用程式模型，跟應用程式能直接搬過去，是兩回事。這一章把共通的部分與華為自有的部分分開。

共通的是應用程式模型的骨架

共通之處在於ArkTS(擴充TypeScript而成、面向宣告式UI的語言)、ArkUI(宣告式UI框架)、Ability(應用程式執行單元)這套應用程式模型的骨架。查看OpenHarmony 6.0 Release的版本說明可以看到，ArkUI的版面配置功能擴充、ArkWeb的Chromium核心從114更新到132、新增AppServiceExtensionAbility、支援資訊站(Kiosk)模式等項目，與HarmonyOS的功能新增內容十分相似。15

不同的是SDK、發布平台與雲端API

不同的是周邊。HarmonyOS應用程式是以華為的HarmonyOS SDK與DevEco Studio，以及AppGallery這個發布平台和HMS(Huawei Mobile Services)的雲端API為前提所開發。單獨的OpenHarmony並不會附上華為的整套商用環境。因此，

  • 在搭載OpenHarmony的自家裝置上，無法安裝AppGallery的應用程式。
  • 為HarmonyOS開發的應用程式，也不保證能在OpenHarmony實機上直接執行。必須逐一確認所依賴的API究竟是華為的擴充功能，還是OpenHarmony的標準功能。

在裝置上要確認應用程式由誰開發、依賴哪些API

裝置若採用OpenHarmony，正確做法是在規劃階段就假設其上執行的應用程式由己方(或所採用發行版的供應商)開發。如果抱著「能沿用中國製的應用程式資產」這種期待來做採用判斷，就會落空。

6. 版本與API等級的解讀方式

這一章把確認版本編號與API等級，和確認OpenHarmony與HarmonyOS之間的相容性分開。編號相近，並不代表就是同一個環境。

把OpenHarmony的版本與API等級對應起來

OpenHarmony的版本有對應的API等級，官方文件儲存庫的README中列有清單。16

下表是2026年7月時點所參照的README清單。「最新版」是那份README上的分類，單憑這張表並不能確定目前的最新發行版或維護狀態。

OpenHarmony版本 API等級 文件上的狀態
master ─ 最新開發版
6.0 Release 20 最新版
5.1.0 Release 18 最新版
5.0.3 15 最新版
5.0.2 14 最新版
5.0.1 13 最新版
5.0.0 Release 12 最新版
4.1 Release 11 已停止維護(Historical Versions No Longer Maintained)
4.0 Release 10 已停止維護
3.2 Release 9 已停止維護

把README與版本說明索引對照著看

這份清單來自文件儲存庫的README，但同一個儲存庫的版本說明索引中，還列有更新的6.1 Release(2026年3月8日)，以及6.0.0.1／6.0.0.2。17 即使是官方文件，「最新版」的標示也有跟不上的時候，所以要確定版本時，請不要只看README，也要看版本說明索引。

即使API等級相同，也未必是同一套API集合

HarmonyOS這一側同樣編有API等級，華為的開發者文件公開了各版本的版本說明。18 由於編號體系相近而容易混淆，但OpenHarmony的API Level 20與HarmonyOS的API Level 20，未必指的是同一套API集合。核對規格時，請隨時留意自己正在讀的是哪一邊的文件。

7. 維護期間 ── 設備業者最該優先確認的數字

能取得原始碼，跟能在需要的年限內持續獲得修正，是兩回事。這一章依序確認社群的維護方針、個別分支的日期，以及裝置的運作年限。

首先，確認Release與LTS的維護方針

OpenHarmony社群把分支的生命週期(從發布到維護結束的期間)定義如下。19

  • Release分支的生命週期為2年(主動維護1年＋被動維護1年)
  • LTS分支的生命週期為3.5年(主動維護2年＋被動維護1.5年)
  • 主動維護期是社群按計畫發布標籤(tag)版本、修正缺陷與安全漏洞的期間
  • 被動維護期是不再規劃、發布標籤版本，只修正嚴重以上的安全漏洞與缺陷的期間

接著，確認所採用分支的維護期限

本文參照的2026年7月時點維護時程表如下。20 這是已刊載分支的清單，並不表示OpenHarmony整體已經結束維護。

分支 類型 發布 主動維護結束 維護結束
1.0.1-Release Release 2021-03-30 2022-03-30 2023-03-30
3.0-LTS LTS 2021-09-30 2023-09-30 2025-03-30
3.1-Release Release 2022-03-30 2023-03-30 2024-03-30
3.2-Release Release 2023-04-09 2024-04-09 2025-04-09
4.0-Release Release 2023-10-26 2024-10-26 2025-10-26
4.1-Release Release 2024-03-30 2025-03-30 2026-03-30

把這張表與版本說明索引合起來看，有三件事要確認。

  1. LTS分支最後一個是3.0-LTS(2021年9月)。在此之前也曾有LTS，1.1.0 LTS(2021年4月)及其系列(1.1.x LTS)仍留在版本說明中。17 但3.1以後發布的分支全部都是Release，也就是維護期只有2年。
  2. 表中列出的分支，截至2026年7月全部已結束維護。5.x系與6.0 Release尚未列入這張表中。
  3. 與運作10年的裝置前提相比，數量級完全不同。與Windows 11 IoT Enterprise LTSC 2024支援到2034年10月、長達10年的支援期相比，就能看出兩者的設計思路本來就不同。

最後，決定由誰來支撐裝置的運作年限

這並不是說OpenHarmony比較差，而是說它並未預設「把社群版原封不動搭載到產品上就放著不管」這種用法。實際的工業採用中，是由商用發行版的供應商自行維護分支，再把這份維護以有償方式賣出。華為所說的「OpenHarmony已發布超過100個商用版本」，指的正是這一層的厚度。6

8. 授權與取得管道

授權

OpenHarmony並非單一授權的專案，各儲存庫的授權並不相同。

對象 授權
建置系統(build)、ArkUI引擎(arkui_ace_engine)等多數元件 Apache License 2.05
LiteOS-A核心(kernel_liteos_a) BSD 3條款授權21
標準系統的Linux核心部分 遵循Linux核心的授權(GPLv2)
官方文件(docs) Creative Commons Attribution 4.022

要整合進產品時，原則是逐一確認自家實際連結範圍內各儲存庫的LICENSE。如果籠統地認為「OpenHarmony是Apache 2.0所以沒問題」，就會漏掉核心部分的GPL義務。

把修改、再散布的條件與出貨時的標示分開確認

修改與再散布本身，任何一種授權都沒有禁止。不過，必須依使用到的部分分別滿足各自的條件。

Apache 2.0在允許修改與再散布的同時，要求隨附完整授權文本、保留著作權標示等歸屬標示、在修改過的檔案中明示變更內容，以及若有NOTICE檔案就一併承接。5

BSD 3條款要求再次列出著作權標示、條件文字與免責條款(只發布二進位檔時，會改以使用說明書等隨附物的形式呈現)，並禁止以權利人的名稱做背書宣傳。21

也就是說，嵌入裝置出貨時，一定會產生「在產品端準備授權標示」這項工作。要放在使用說明書末尾、機器設定畫面的「授權資訊」，還是隨附的文字檔案，請在設計階段就決定好用哪一種來滿足。

核心的原始碼提供與文件的姓名標示也要確認

如果要修改並散布標準系統的Linux核心，依GPLv2會另外產生提供對應原始碼的義務。若要把文件轉載到公司內部資料，則需要依CC BY 4.0標示姓名。22

原始碼的取得

區分取得開發版的範例與固定到發行版

原始碼使用與Android相同的repo工具取得。官方文件記載的步驟如下。2 這個範例是以-b master取得開發版。若要固定到發行版，請改用後述的分支名稱或標籤。

repo init -u https://gitcode.com/openharmony/manifest.git -b master --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'

託管方面提供gitcode.com、gitee.com、GitHub鏡像，SSH與HTTPS兩種方式都有。2 若想固定取得某個發行版本，可以把分支名稱換成OpenHarmony-6.0-Release這樣的版本名稱，或是換成標籤(refs/tags/OpenHarmony-v6.0-Release)。不需要特別的註冊或授權手續。

買開發板之前先用QEMU確認結構

若想在購買實機開發板之前先確認結構，也備有在QEMU上執行的途徑。device_qemu儲存庫備有Arm Virt(LiteOS-A／Linux)、Cortex-M4(mps2-an386)、Cortex-M55(mps3-an547)、RISC-V(riscv32_virt)、Xtensa(esp32)、C-SKY(SmartL_E802)的模擬步驟。23

9. 歐洲系的分支 ── Eclipse Oniro

以OpenHarmony為基礎、另行推進擴充的專案

對日本的技術人員來說容易忽略的，是由Eclipse Foundation營運的Oniro專案。專案頁面明確寫道「Eclipse Oniro for OpenHarmony建構在OpenAtom基金會培育、營運的開放原始碼專案OpenHarmony的基礎層之上」，並揭示了面向歐洲及全球市場，加入React Native支援、以Eclipse Theia為基礎的IDE、Servo網頁引擎等的方針。授權為Apache 2.0與MIT，專案狀態在2026年7月時點為Incubating。7

治理的差異與採用風險要分開評估

對於有「來自中國的作業系統在採購方針上難以採用」這種限制的組織而言，知道還存在一個處於歐洲基金會治理之下的同系統選項，光是作為考量的廣度就有價值。不過它仍處於Incubating階段，社群規模也無法與OpenHarmony本體相提並論，這些都會直接構成採用風險。

10. 總結 ── 把三者分開來談

  • OpenHarmony是OpenAtom基金會的開放原始碼作業系統專案。從128 KiB的MCU到128 MiB以上的高階裝置，都由同一體系涵蓋，原始碼任何人都能取得。需要評估是否採用到裝置上的，就是它。
  • HarmonyOS是華為的商用作業系統產品。部署到智慧型手機上的2～4.x世代與AOSP混成，能執行Android應用程式，但NEXT(＝5)以後移除了AOSP，變成只有HarmonyOS原生應用程式的世界。開發語言並不限於ArkTS。智慧型手機與應用程式市場以中國為中心，但要與穿戴式裝置等在中國以外地區的布局分開來看(第4章)。
  • Eclipse Oniro是以OpenHarmony為基礎、源自歐洲的一系。2026年7月時點仍處於Incubating階段，但就治理歸屬的觀點來看，是另一個選項。

把產品的名字分開之後，再依序確認架構、應用程式的依賴對象、維護負責人與授權。把這篇文章接到採用評估上時，這就是該有的讀法。

能夠把這三者不混著談之後，公司內部的討論就會具體許多。因為問題可以不再停留在「要不要採用HarmonyOS」，而是翻譯成「OpenHarmony的標準系統，要搭配哪一家商用發行版的維護，裝到哪一款SoC上」。至於再往後的實務判斷 ── 維護期間、硬體選項、開發環境、可採購性，以及把它們與Windows IoT、嵌入式Linux並列比較的內容，已分到姊妹文。

相關文章

相關諮詢領域

合同會社小村軟體承接裝置及業務系統所搭載作業系統、執行平台的選型，既有Windows應用程式移轉可行性的釐清，以及以長期運轉為前提的架構審查。從「新的作業系統成為候選，但判斷依據還不夠」這個階段開始，都歡迎諮詢。

參考連結

  1. OpenHarmony Documentation, OpenHarmony Project。關於OpenHarmony是由OpenAtom Foundation培育、營運的開放原始碼專案、核心層／系統服務層／框架層／應用程式層的四層架構、Linux與LiteOS的多核心設計與KAL、HDF驅動程式基礎架構、DSoftBus・分散式資料管理・分散式排程器・裝置虛擬化等各項功能、支援從數百KiB到GiB級RAM等內容。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  2. OpenHarmony Documentation, Source Code Acquisition。關於repo工具的設定步驟、透過repo init／repo sync -c／repo forall -c 'git lfs pull'取得原始碼，以及gitcode.com・gitee.com・GitHub各鏡像與SSH／HTTPS選項等內容。 ↩ ↩2 ↩3

  3. Wikipedia, HarmonyOS 5(二手資料)。關於部署到智慧型手機上的HarmonyOS 2～4.x世代，以整合AOSP與OpenHarmony的架構能執行Android應用程式，HarmonyOS NEXT(＝HarmonyOS 5)移除了AOSP相容層與Android函式庫、Android應用程式無法執行，以及HarmonyOS 6以後不再使用「NEXT」稱呼等內容。由於華為的官方文件為動態產生、無法直接引用，故以二手資料形式參考。 ↩ ↩2 ↩3 ↩4

  4. Wikipedia, HarmonyOS version history(二手資料)。關於HarmonyOS 1.0於2019年8月以Honor Vision(智慧螢幕)適用產品的身分公開的世代，並非以智慧型手機用作業系統的身分流通的世代等內容。1.0的內部構成(是否具備LiteOS・Linux・AOSP相容層)因資料而異，故本文僅敘述搭載產品方面的差異。 ↩ ↩2 ↩3

  5. OpenHarmony, arkui_ace_engine LICENSE及build LICENSE。關於ArkUI引擎及建置系統儲存庫以Apache License 2.0發布的內容。 ↩ ↩2 ↩3

  6. 華為, HarmonyOS 7 開發者Beta 正式啟動，全場景智慧操作系統再升級。關於2026年6月12日在東莞舉辦的HDC 2026上發表HarmonyOS 7開發者Beta，HarmonyOS 6裝置數量突破6,600萬台，註冊開發者超過1,100萬人・應用程式商店可取得的應用程式與服務超過40萬個，HarmonyOS已成為中國第二大智慧型手機作業系統，以及OpenHarmony已發布超過100個商用版本等說明內容。 ↩ ↩2 ↩3 ↩4

  7. Eclipse Foundation, Eclipse Oniro for OpenHarmony。關於Eclipse Oniro for OpenHarmony建構在OpenAtom Foundation的OpenHarmony基礎層之上、面向歐洲及全球市場加入React Native支援・以Eclipse Theia為基礎的IDE・Servo網頁引擎等方針、授權為Apache 2.0與MIT、專案狀態為Incubating等內容。 ↩ ↩2

  8. OpenHarmony Documentation, Quick Start Overview。關於輕量系統(MCU，最小128 KiB)、小型系統(Cortex-A，最小1 MiB)、標準系統(Cortex-A，最小128 MiB)這三種基本系統類型的定義，以及各自提供的功能・預期產品。 ↩

  9. OpenHarmony Documentation, OpenHarmony Development Boards List。關於社群支援的開發板共22款，面向標準系統的RK3568／i.MX8M Mini／A311D／RK3399等、面向小型系統的Hi3516DV300／STM32MP157A、面向輕量系統的Hi3861／STM32F407／ESP32／RISC-V HPM6750等清單，以及MILOS_Standard0的預期用途包含工業控制・醫療設備等內容。 ↩ ↩2

  10. South China Morning Post, Huawei to open-source self-developed programming language Cangjie to rival Java and Swift(二手資料)。關於華為自主開發的語言倉頡(Cangjie)已支援HarmonyOS NEXT應用程式開發、提供給所有HarmonyOS開發者，以及2025年開放原始碼化等內容。 ↩

  11. HUAWEI Developers, 設計與開發你的應用。關於HarmonyOS的開發環境備有Native C++的專案範本，並涵蓋以ArkTS・JS・C/C++進行開發的內容。作為本文「原生應用程式並不限於ArkTS」這項說明的補充出處。 ↩

  12. 華為, HarmonyOS 6 - 華為官網。關於HarmonyOS 6產品頁面設置在中國網站上的內容。 ↩

  13. Huawei, HarmonyOS 2 - Huawei Global。關於華為全球消費者網站的HarmonyOS介紹頁面，截至2026年7月仍是HarmonyOS 2頁面的內容。 ↩

  14. Huawei Central, Global Huawei Watch 5 claims HarmonyOS 6 software upgrade及同媒體關於全球版穿戴式裝置配送的其他報導(二手資料)。關於華為向中國以外地區的智慧型手錶(Watch 5、Watch GT 4、Watch Fit 3等)也配送HarmonyOS 5系・6系韌體更新的內容。作為「不能斷言HarmonyOS 5以後＝僅限中國國內」這項判斷依據引用。 ↩

  15. OpenHarmony Documentation, OpenHarmony 6.0 Release。關於6.0 Release中ArkUI的版面配置功能擴充(LayoutPolicy、安全區域相關)、ArkWeb的Chromium核心從114更新到132、新增AppServiceExtensionAbility、支援資訊站(Kiosk)模式等內容。 ↩

  16. OpenHarmony Documentation, README。關於OpenHarmony 6.0 Release(API Level 20)、5.1.0 Release(18)、5.0.3(15)、5.0.2(14)、5.0.1(13)、5.0.0 Release(12)被列為最新版，4.1 Release(11)以前被列為「Historical Versions No Longer Maintained」的內容。 ↩

  17. OpenHarmony Documentation, Release Notes 索引。關於3.0-LTS(2021年9月30日)及其系列(3.0.1～3.0.8 LTS)已列出、3.1以後全部為Release類型，1.x系也曾存在LTS(1.1.0 LTS等)但已被標記為End of Life，以及6.1 Release(2026年3月8日)・6.0.0.1・6.0.0.2作為比README「Latest Versions」清單更新的版本列出等內容。 ↩ ↩2

  18. HUAWEI Developers, HarmonyOS Versions。關於HarmonyOS各版本與API等級對應的版本說明，以華為開發者文件的形式公開的內容。 ↩

  19. OpenHarmony, OpenHarmony Version Lifecycle Management。關於Release分支的生命週期為2年(1+1)、LTS分支為3.5年(2+1.5)，以及主動維護期與被動維護期的定義(被動維護期僅修正嚴重以上的漏洞・缺陷)。 ↩

  20. OpenHarmony Documentation, OpenHarmony Version Definitions。關於Master／LTS／Release／Beta／標籤版的定義，以及LTS・Release分支的維護時程表(僅3.0-LTS為LTS類型，1.0.1／3.1／3.2／4.0／4.1為Release類型，4.1-Release的維護結束日期為2026年3月30日)等內容。 ↩

  21. OpenHarmony, kernel_liteos_a LICENSE。關於LiteOS-A核心以BSD 3條款授權(再散布時須保留著作權標示、散布二進位檔時須再次列出免責條款、禁止以權利人名稱做背書宣傳)發布的內容。 ↩ ↩2

  22. OpenHarmony, docs LICENSE。關於官方文件儲存庫以Creative Commons Attribution 4.0 International提供的內容。 ↩ ↩2

  23. OpenHarmony, device_qemu README。關於以QEMU模擬的對象包括Arm Virt(LiteOS-A)、Arm Virt(Linux)、Cortex-M4(mps2-an386)、Cortex-M55(mps3-an547)、RISC-V(riscv32_virt)、Xtensa(esp32)、C-SKY(SmartL_E802)的步驟已備妥的內容。 ↩

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

OpenHarmony和HarmonyOS是同一樣東西嗎？
不是同一樣東西。OpenHarmony是由OpenAtom基金會(開放原子開源基金會)培育、營運的開放原始碼作業系統專案，原始碼任何人都能取得，並以Apache License 2.0等開放原始碼授權釋出。另一方面，HarmonyOS是華為的商用作業系統產品，以OpenHarmony為基礎，在其上加入華為自有的框架、應用程式發布平台(AppGallery)以及雲端服務(HMS)。並不是「OpenHarmony公開了，所以HarmonyOS的原始碼就能全部讀到」，也不是「裝了OpenHarmony的裝置就能安裝AppGallery的應用程式」。如果把它想成Linux核心與商用Linux發行版之間的關係，會比較容易理解。
HarmonyOS NEXT是什麼？它和HarmonyOS 5、6是什麼關係？
HarmonyOS NEXT是移除了源自Android(AOSP)程式碼那一世代HarmonyOS的稱呼，就產品版本而言相當於HarmonyOS 5。部署到智慧型手機上的HarmonyOS 2～4.x世代，是AOSP與OpenHarmony組合而成的架構，也能執行Android應用程式(APK)(再往前的HarmonyOS 1.0，是2019年以智慧螢幕為對象登場的世代)。NEXT以後不再有AOSP相容層，能執行的只剩HarmonyOS原生應用程式。這裡所說的原生應用程式不限於ArkTS，以C/C++撰寫的Native API(NDK)，以及華為自主開發的語言倉頡(Cangjie)也都是選項之一。到了後續的HarmonyOS 6，「NEXT」這個稱呼本身也不再使用，直接稱為HarmonyOS 6。2026年6月的HDC 2026上，發表了HarmonyOS 7的開發者Beta。
用OpenHarmony製作的裝置，能安裝HarmonyOS的應用程式嗎？
請不要認為可以。OpenHarmony與HarmonyOS擁有ArkTS、ArkUI這條共同的技術脈絡，API等級的編號也相當接近，但HarmonyOS應用程式是以華為的HarmonyOS SDK與AppGallery為前提開發的，單獨的OpenHarmony環境並不具備這些條件。反過來說，為OpenHarmony開發的應用程式也不保證能在HarmonyOS實機上直接執行。若裝置採用OpenHarmony，請在規劃階段就假設其上執行的應用程式是由己方(或所採用發行版的供應商)針對OpenHarmony的API自行開發。
OpenHarmony的支援期間有多長？
根據社群的生命週期政策，Release分支為2年(主動維護1年＋被動維護1年)，LTS分支為3.5年(2年＋1.5年)。不過LTS分支最後一個是2021年9月發布的3.0-LTS(在此之前還有1.1.0 LTS)，3.1以後發布的分支全部都是Release。若要在如工業設備這類以運作10年為前提的產品上使用這個作業系統，光靠社群的維護期間並不足夠，需要購買商用發行版供應商的維護服務，或是由己方自行維護分支。
日本的開發者要接觸OpenHarmony該怎麼做？
原始碼可以透過repo工具，從gitcode.com／gitee.com／GitHub的鏡像取得，不需要帳號註冊或出口許可之類的特殊手續。官方文件備有中文與英文兩種版本，沒有日文版。在購買實機開發板之前，也可以先在QEMU上執行以確認結構。比較實際的做法是，先從英文文件「Device Development」的入口開始，決定要鎖定的系統類型(輕量／小型／標準)。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽