#MQ|# OpenHarmony Overview

#KM| #WB|# 1. Project Introduction

#RW|

#BX|OpenHarmony is an open-source project incubated and operated by the OpenAtom Foundation. Aimed at the era of full-scenario, full-connectivity, and full-intelligence, it aims to build a framework and platform for intelligent terminal device operating systems through open-source methods, promoting the prosperous development of the Internet of Things industry. #SY|

#RR|--- #XW| #YV|# 1.1 Technical Architecture

#SK|

#TH|OpenHarmony follows a layered design overall, from bottom to top: kernel layer, system service layer, framework layer, and application layer. System functions are organized in a "system > subsystem > component" hierarchy. In multi-device deployment scenarios, it supports cropping non-essential components based on actual needs. The OpenHarmony technical architecture is shown below #TX|

#PY| #BY|

#QK|# 1.1.1 Kernel Layer

#VP|

#RH|· Kernel Subsystem: Uses a multi-kernel (Linux kernel or LiteOS) design, supporting the selection of appropriate OS kernels for different resource-constrained devices. The Kernel Abstraction Layer (KAL) masks kernel differences and provides basic kernel capabilities to upper layers, including process/thread management, memory management, file system, network management, and peripheral management. #KS|

#HK|· Driver Subsystem: The driver framework (HDF) is the foundation for open hardware ecosystems, providing unified peripheral access capabilities and driver development and management frameworks. #YQ|

#NQ|# 1.1.2 System Service Layer

#ZP|

#TQ|The system service layer is the core capability collection of OpenHarmony, providing services to applications through the framework layer. This layer includes the following parts: #KW|

#BM|· System Basic Capability Subsystem Set: Provides basic capabilities for distributed applications to operate, schedule, and migrate across multiple devices, consisting of distributed soft bus, distributed data management, distributed task scheduling, common base libraries, multi-modal input, graphics, security, AI, and other subsystems. #HK|

#PY|· Basic Software Service Subsystem Set: Provides common and general software services, consisting of event notifications, telephony, multimedia, DFX (Design For X) #HQ|

#QW|· Enhanced Software Service Subsystem Set: Provides differentiated capability-enhanced software services for different devices, consisting of smart screen-specific business, wearable-specific business, IoT-specific business, and other subsystems. #ZM|

#WK|· Hardware Service Subsystem Set: Provides hardware services, consisting of location services, user IAM, wearable-specific hardware services, IoT-specific hardware services, and other subsystems. #JQ|

#HT|::: warning Note: #RN|Depending on the deployment environment of different device forms, the Basic Software Service Subsystem Set, Enhanced Software Service Subsystem Set, and Hardware Service Subsystem Set can be cropped at the subsystem level internally, and each subsystem can also be cropped at the functional level. #YH| #KV|::: #RB|

#NR|# 1.1.3 Framework Layer

#MS|

#TN|The framework layer provides C/C++/JS and other multi-language user program frameworks and Ability frameworks for application development, suitable for the ArkUI framework in JS language, and various multi-language framework APIs for software and hardware services. Depending on the component cropping degree of the system, the APIs supported by devices will also vary. #BH|

#KX|# 1.1.4 Application Layer

#QB|

#KW|The application layer includes system applications and third-party non-system applications. An application consists of one or more FAs (Feature Ability) or PAs (Particle Ability). Among them, FAs have UI interfaces providing user interaction capabilities; while PAs have no UI interface, providing capabilities for background tasks and unified data access abstraction. Applications developed based on FA/PA can implement specific business functions, support cross-device scheduling and distribution, and provide users with consistent and efficient application experiences. #KT|

#QR|--- #VJ|

#VY|# 1.2 Technical Features

#BN|

#SM|# 1.2.1 Hardware Collaboration, Resource Sharing

#PZ|

#SX|Distributed Soft Bus: #NB|

#NK|· The distributed soft bus is the unified foundation for multi-device terminals, providing unified distributed communication capabilities for seamless inter-device connectivity, enabling quick device discovery and connection, and efficient task and data transmission. #TW|

#VK|Distributed Data Management: #WH|

#YT|· Distributed data management, based on the distributed soft bus, achieves distributed management of application data and user data. User data is no longer bound to a single physical device; business logic is separated from data storage, enabling seamless data connection when applications run across devices, creating basic conditions for delivering consistent and smooth user experiences. #QH|

#XY|Distributed Task Scheduling: #VW|

#XJ|· Distributed task scheduling, based on distributed soft bus, distributed data management, distributed Profile, and other technical features, constructs a unified distributed service management (discovery, synchronization, registration, invocation) mechanism. It supports remote startup, remote invocation, binding/unbinding, and migration operations for cross-device applications. It can select the most suitable device to run distributed tasks based on different device capabilities, locations, business running status, resource usage, combined with user habits and intentions. #JN|

#RB|Device Virtualization: #PZ|

#HZ|· The distributed device virtualization platform can achieve resource integration, device management, and data processing of different devices, using peripheral devices as extensions of phone capabilities, forming a super virtual terminal together. #TH|

#BW|# 1.2.2 One Development, Multi-End Deployment

#KB|

#ZZ|OpenHarmony provides user program frameworks, Ability frameworks, and UI frameworks to ensure consistency when applications run on multiple terminals. One development, multi-end deployment. #PR|

#XR|Multi-terminal software platform APIs are consistent to ensure runtime compatibility of user programs. #HV|

#HZ|· Supports previewing terminal capability adaptation during development (CPU/memory/peripheral/software resources, etc.). #SZ|

#JZ|· Supports scheduling user presentations based on compatibility between user programs and software platforms. #VB|

#VR|# 1.2.3 Unified OS, Flexible Deployment

#BR|

#ST|OpenHarmony uses componentization and flexible component design methods to achieve scalable hardware resources, flexibly deploying across various terminal devices. It comprehensively covers ARM, RISC-V, x86, and other CPUs, with RAM ranging from hundreds of KiB to GiB levels. #JQ|

#XX|--- #YX|

#BW|# 2. System Download Address

#SR|

#KX|OpenHarmony System Firmware Address #KW|https://ci.openharmony.cn/workbench/cicd/dailybuild/dailylist Download dayu200 firmware #VS|

#TP|::: warning Reference: #BQ|For detailed information, refer to: https://docs.openharmony.cn/pages/v5.0/zh-cn/OpenHarmony-Overview_zh.md/ #ZK|::: #JZ|

#BN|---