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

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

· · OpenHarmony, HarmonyOS, 嵌入式, 作業系統選型, 開源, ArkTS, 技術諮詢, 裝置嵌入

被問到「華為的HarmonyOS是開源的吧」時，你能準確地回答嗎？答案是「一半對，一半不對」。開源的是OpenHarmony，HarmonyOS則是華為以此為基礎打造的商用產品。而且HarmonyOS在發展過程中內部構成經過更替，依世代不同，Android應用程式有時能運作、有時不能。

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

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

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

1. 先講結論

  • OpenHarmony是由OpenAtom基金會(開放原子開源基金會)培育、營運的開源作業系統專案。它不是華為的產品，而是基金會的專案，原始碼任何人都能從公開儲存庫取得。12
  • HarmonyOS是華為的商用作業系統產品，與OpenHarmony是不同的東西。它以OpenHarmony為基礎，在其上加入華為自有的框架、應用程式發布平台、雲端服務。HarmonyOS的原始碼並未全部公開。
  • HarmonyOS的內容隨世代而改變。1～4.x世代是AOSP(Android Open Source Project)與OpenHarmony組合而成的架構，能運作Android應用程式，但HarmonyOS NEXT(＝HarmonyOS 5)以後移除了源自AOSP的程式碼，Android應用程式無法運作。3
  • 「NEXT」這個稱呼在HarmonyOS 6上不再使用。2026年6月的HDC 2026上發表了HarmonyOS 7的開發者Beta，同時說明「OpenHarmony已發布超過100個商用版本」。4
  • OpenHarmony並非單一作業系統產品，而是擁有「三種系統類型」的框架。從最小128 KiB的MCU適用(輕量系統)，到128 MiB以上應用處理器適用(標準系統)，都在同一體系內切換組態。5
  • 授權方面，程式碼以Apache License 2.0為主要構成。LiteOS-A核心採用BSD 3條款，文件則採用CC BY 4.0，依部分而不同。採用時請逐一確認相應儲存庫的LICENSE。678
  • 社群的維護期間為Release分支2年、LTS分支3.5年。而且LTS分支最後一個是2021年9月的3.0-LTS，3.1以後發布的分支全部都是Release。這與裝置10年生命週期的前提並不吻合。91011
  • HarmonyOS的智慧型手機與應用程式市場，實質上以中國為中心。華為的全球消費者網站截至2026年7月仍是HarmonyOS 2的介紹頁面，HarmonyOS 6則是在中國網站上公布。不過穿戴式裝置等品項在中國以外地區也有配送HarmonyOS 5系・6系，並非「HarmonyOS 5以後＝僅限中國」。121314
  • 歐洲有一個以OpenHarmony為基礎的另一系統。Eclipse Foundation的Oniro專案，正以OpenHarmony為基礎，推動面向歐洲及全球市場的擴充(截至2026年7月為Incubating階段)。15

2. 用一張表整理系譜

先看整體樣貌。被稱為「鴻蒙(HarmonyOS)」的東西，至少存在3個不同的實體。

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

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

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應用程式能否運作的分界線1634

分界線是2024年的NEXT(＝5)。請先確認在這條線之前的世代所累積的經驗，是否與之後世代的說法在公司內部混淆。

另外，最近還有一個值得掌握、能拓展視野的系統。

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

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

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

OpenHarmony官方文件將這個專案描述為「由OpenAtom基金會培育、營運的開源專案，目標是為全場景智慧裝置打造開源的分散式作業系統框架」。1

這一章專有名詞較多，先在此提供一份最小限度的對照表。

術語 意義
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的核心是什麼」這個問題，需要反問一句「說的是哪一種系統類型」。

三種系統類型

官方文件定義了三種基本系統類型。5

系統類型 處理器 最小記憶體 提供的功能 預期產品
輕量系統(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的招牌功能大概有一半用不上。這一點會對採用與否的判斷產生影響。

開發板與硬體

社群公布支援的開發板共22款。17 面向標準系統的有搭載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、交通、防災、大樓」。17

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

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

  • HarmonyOS 1.0(2019年)：最初搭載的並非智慧型手機，而是智慧螢幕(Honor Vision)。這是OpenHarmony捐贈給OpenAtom基金會之前的世代，並非以智慧型手機用作業系統的身分流通。16
  • HarmonyOS 2～4.x(2021～2024年)：這是部署到智慧型手機上的世代。採用AOSP與OpenHarmony組合而成的架構，這一世代的終端裝置能同時運作Android應用程式(APK)與HarmonyOS應用程式。日本會流傳「HarmonyOS就是中國版Android」這種理解，正是因為這一世代的實際情況看起來確實如此。3
  • HarmonyOS NEXT(＝HarmonyOS 5，2024年)：AOSP相容層與Android函式庫被移除，Android應用程式無法運作。能運作的只有HarmonyOS原生應用程式。3 這裡所說的原生應用程式並不只限於ArkTS。可以組合以C/C++撰寫的Native API(NDK)模組，華為自主開發的語言倉頡(Cangjie)也作為HarmonyOS應用程式開發的選項之一提供。18
  • HarmonyOS 6以後(2025年～)：「NEXT」這個稱呼被拿掉，直接稱為HarmonyOS 6。2026年6月12日在東莞舉辦的HDC 2026上，發表了HarmonyOS 7開發者Beta啟動，並公布HarmonyOS 6的終端裝置數量突破6,600萬台、註冊開發者超過1,100萬人、應用程式商店可取得的應用程式與服務超過40萬個、HarmonyOS已成為中國第二大智慧型手機作業系統。4

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

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

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

  • 智慧型手機與應用程式市場以中國為中心。HarmonyOS 6的產品頁面設置在中國網站上，13 另一方面，華為的全球消費者網站(consumer.huawei.com/en/harmonyos/)截至2026年7月仍停留在HarmonyOS 2的介紹頁面。12 面向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的功能新增內容十分相似。19

不同的地方在於周邊生態。HarmonyOS應用程式是以華為的HarmonyOS SDK與DevEco Studio，以及名為AppGallery的發布平台和HMS(Huawei Mobile Services)的雲端API為前提所開發。OpenHarmony並不具備這些條件。因此，

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

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

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

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

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，但同一個儲存庫的版本說明索引中，還列有更新的6.1 Release(2026年3月8日)，以及6.0.0.1／6.0.0.2。11 官方文件內部「最新版」的標示有時會沒有及時更新，所以確定版本時請不要只看README，也要查看版本說明索引。

HarmonyOS方面同樣有編列API等級，華為的開發者文件中公開了各版本的版本說明。21 由於編號體系相近，容易混淆，但OpenHarmony的API Level 20與HarmonyOS的API Level 20，並不一定指的是同一套API集合。核對規格時，請隨時留意自己看的是哪一方的文件。

7. 維護期間 ── 裝置廠商最應優先確認的數字

OpenHarmony社群將分支的生命週期定義如下。9

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

而實際公開的各分支維護時程如下。10

分支 類型 發布 主動維護結束 維護結束
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)仍留在版本說明中。11 但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個商用版本」，指的正是這一層供應商生態的厚度。4

8. 授權與取得管道

授權

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

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

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

那麼業務使用中實際會出現什麼問題，用三點來概括。首先，修改與再散布本身，無論哪種授權都不禁止。Apache 2.0在允許修改與再散布的同時，要求隨附完整授權文本、保留著作權標示等歸屬標示、在修改過的檔案中明示變更內容，以及如果有NOTICE檔案就一併承接。6 BSD 3條款要求再次列出著作權標示・條件文字・免責條款(僅發布二進位檔時，會以隨附使用說明書等物品的形式呈現)，並禁止用權利人的名稱做推薦標示。7 也就是說，把它嵌入裝置出貨時，必定會產生「在產品端準備授權標示」這項工作(要放在使用說明書末尾、本體設定畫面的「授權資訊」、還是隨附的文字檔案，請在設計階段就決定好由哪一種方式滿足)。而如果修改並散布標準系統的Linux核心，則會依GPLv2另外產生提供對應原始碼的義務。若要把文件轉載到公司內部資料，則需要標示CC BY 4.0的出處。8

原始碼的取得

原始碼透過與Android相同的repo工具取得。官方文件記載的步驟如下。2

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上執行的途徑。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)的模擬執行步驟。22

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

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

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

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

  • OpenHarmony是OpenAtom基金會的開源作業系統專案。從128 KiB的MCU到128 MiB以上的高階裝置，都由同一體系涵蓋，原始碼任何人都能取得。這才是需要評估是否採用到裝置上的對象。
  • HarmonyOS是華為的商用作業系統產品。1～4.x世代與AOSP混成，能運作Android應用程式，但NEXT(＝5)以後移除了AOSP，變成只有ArkTS應用程式的世界。實質上是面向中國市場的產品。
  • Eclipse Oniro是以OpenHarmony為基礎、源自歐洲的系統。目前仍處於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. 華為, HarmonyOS 7 開發者Beta 正式啟動，全場景智慧操作系統再升級。關於2026年6月12日在東莞舉辦的HDC 2026上發表HarmonyOS 7開發者Beta，HarmonyOS 6終端裝置數量突破6,600萬台，註冊開發者超過1,100萬人・應用程式商店可取得的應用程式與服務超過40萬個，HarmonyOS已成為中國第二大智慧型手機作業系統，以及OpenHarmony已發布超過100個商用版本等說明內容。 ↩ ↩2 ↩3 ↩4 ↩5

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

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

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

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

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

  10. 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日)等內容。 ↩ ↩2

  11. 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 ↩3

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

  13. 華為, HarmonyOS 6 - 華為官網。關於HarmonyOS 6產品頁面設置在中國網站上的內容。 ↩ ↩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以後＝僅限中國國內」這項判斷依據引用。 ↩ ↩2

  15. 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 ↩3

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

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

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

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

  20. 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」的內容。 ↩

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

  22. 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽