# OpenHarmony - [Introduction](#section1270210396435) - [Technical Architecture](#section2502124574318) - [Technical Features](#section12212842173518) - [Device Types](#section145241459142416) - [Subsystems](#section25831825174419) - [Getting Started](#section44681652104210) - [Code Organization Address](#sectionCodeOrganizationAddress) - [OpenHarmony Documentation](#section21031470109) - [Source Code Downloading](#section39011923144212) - [How to Participate](#section19611528174215) - [License Agreement](#section1245517472115) - [Contact Info](#section61728335424) ## Introduction OpenHarmony is an open-source project launched by the OpenAtom Foundation, and serves as an open-source, distributed operating system \(OS\) that is intended to address all conceivable usage scenarios. Unlike traditional OSs, which are limited to a specific type of device, OpenHarmony provides distributed features that are compatible with a wide range of different devices. The first version supports devices with 128 KB to 128 MB of memory. Join us as we keep updating OpenHarmony versions. For device developers, OpenHarmony uses a component-based design to tailor its features to better suit specific devices, based on each device's capabilities and service characteristics. OpenHarmony can run on devices with limited resources and wearables with just a few hundred KBs of memory, as well as more powerful devices, such as smart home cameras and dashcams with hundreds of MB of memory. ## Technical Architecture OpenHarmony is designed with a layered architecture, which from bottom to top, consists of the kernel layer, system service layer, framework layer, and application layer. System functions are expanded by levels, from system to subsystem, and further to function/module. In multi-device deployment scenario, unnecessary subsystems, functions, or modules can be excluded from the system as required. The following figure shows the technical architecture of OpenHarmony. ![](https://gitee.com/openharmony/docs/raw/master/en/readme/figures/1-en.png) **Kernel Layer** - Kernel subsystem: OpenHarmony uses a multi-kernel design \(Linux or LiteOS\) so that different kernels can be selected for devices with different resource limitations. The kernel abstraction layer \(KAL\) hides differences in kernel implementations and provides the upper layer with basic kernel capabilities, including process and thread management, memory management, file system, network management, and peripheral management. - Driver subsystem: Hardware Driver Foundation \(HDF\) lays the foundation for an open OpenHarmony hardware ecosystem. It allows for unified access from peripheral devices and provides foundation for driver development and management. **System Service Layer** The system service layer provides a complete set of capabilities essential for OpenHarmony to offer services for applications through the framework layer. This layer consists of the following parts: - Basic system capability subsystem set: Implements distributed application running, scheduling, and migration across OpenHarmony devices. This subsystem set provides the following basic capabilities: Intelligent Soft Bus, distributed data management, Distributed Scheduler, Utils, multimodal input, graphics, security, and AI. - Basic software service subsystem set: Provides OpenHarmony with common universal software services, including common event and notification, telephony, multimedia, and Design For X \(DFX\). - Enhanced software service subsystem set: Provides OpenHarmony with differentiated enhanced software services, including those dedicated to smart TVs, wearables, IoT devices, and more. - Hardware service subsystem set: Provides OpenHarmony with hardware services, including location, biometric recognition, as well as those dedicated to wearables and IoT devices. The basic software service, enhanced software service, and hardware service subsystem sets can be modified by the subsystems, and each subsystem can be modified by various functions, depending on the deployment scenario for a particular device form. **Framework layer** This layer provides with what you need to develop OpenHarmony applications: application framework and ability framework, specific to multiple languages \(like Java, C, C++, and JS\), Java and JS UI frameworks, as well as multi-language APIs for hardware and software services. The APIs designed for different OpenHarmony devices can be modified based on various system components. **Application layer** This layer consists of system applications and third-party applications. Each OpenHarmony application is powered by one or more Feature Abilities \(FAs\) or Particle Abilities \(PAs\). An FA provides a UI for user interaction. A PA has no UI and provides background task processing as well as data access. Applications developed based on FAs and PAs provide specific service characteristics and enable cross-device scheduling and distribution, delighting users with consistent and efficient experience. ## Technical Features 1. **Hardware collaboration and resource sharing** This feature is implemented through the following modules: - Intelligent Soft Bus Intelligent Soft Bus is a unified base for seamless interconnection among devices. It powers OpenHarmony with distributed communication capabilities to quickly discover and connect devices, and efficiently transmit data. - Distributed data management Intelligent Soft Bus manages applications and user data distributed across different devices. Under such management, user data is no longer bound to a single physical device, and service logic is decoupled from storage. As your applications are running across devices, their data is seamlessly transmitted from one device to another, creating a foundation for a user experience that is smooth and consistent. - Distributed Scheduler The Distributed Scheduler is designed based on technical features such as Intelligent Soft Bus, distributed data management, and distributed profile. It builds a unified distributed service management mechanism \(including service discovery, synchronization, registration, and invocation\), and supports remote startup, remote invocation, binding/unbinding, and migration of applications across devices. This way, your applications can select the most suitable device to perform distributed tasks based on the capabilities, locations, running status, and resource usage of different devices, as well as user habits and intentions. - Device virtualization A distributed device virtualization platform enables cross-device resource convergence, device management, and data processing so that virtual peripherals can function as capability extensions of smartphones to form a super virtual terminal. 2. **One-time development for multi-device deployment** OpenHarmony provides you with the user application, ability, and UI frameworks. With these frameworks, you can develop your applications once, and then flexibly deploy them across a broad range of different devices. Consistent APIs ensure the operational compatibility of applications across devices. - Adaptation of device capabilities \(including CPU, memory, peripheral, and software resources\) can be previewed. - Resources can be scheduled based on the compatibility between user applications and the software platform. 3. **A unified OS for flexible deployment** OpenHarmony enables hardware resources to be scaled with its component-based and small-scale designs. It can be deployed on demand for a diverse range of devices, including ARM, RISC-V, and x86 architectures, and providing RAM volumes ranging from hundreds of KB to GB. ## Device Types OpenHarmony supports the following device types: - **Mini-System Devices \(reference memory ≥ 128 KB\)** Such devices are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. They provide robust short-distance connection and peripheral bus access capabilities. Typical products include LinkIoT module devices and smart home sensors. The LinkIoT module is usually used as a hardware module that provides connectivity for smart Internet of Things \(IoT\) devices. In the smart home field, the LinkIoT module is integrated into devices by vendors. For example, a LinkIoT module provides WLAN/Bluetooth access and data connection, and it usually communicates with the chip of smart home devices via a universal asynchronous receiver-transmitter \(UART\) or general-purpose input/output \(GPIO\) interface. - **Small-System Devices \(reference memory ≥ 1 MB\)** Such devices are equipped with application processors such as ARM Cortex-A. They provide improved security, a standard graphics framework, and multimedia capabilities for video encoding and decoding. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel. - **Standard-System Devices \(reference memory ≥ 128 MB\)** Such devices are equipped with application processors such as ARM Cortex-A. They provide a complete application framework supporting enhanced interaction, 3D GPU, hardware composer, a diverse range of components and visual displays, for example the type included on a high-end refrigerator. - **Large-System Devices \(reference memory ≥ 1 GB\)** Such devices are equipped with application processors such as ARM Cortex-A and provide a complete compatible application framework. Typical products include smart TVs and smart watches. ## Subsystems For details about the subsystems in the following table, see [https://gitee.com/openharmony/docs/tree/master/zh-cn/readme](https://gitee.com/openharmony/docs/tree/master/zh-cn/readme). \* The open-source OS, OpenHarmony, is available for devices running on just a few hundred KB to those with megabytes of RAM. The following table describes some of the subsystems.