Deleted docs/source/overview/figures/.gitkeep,...

Deleted docs/source/overview/figures/.gitkeep, docs/source/overview/figures/architecture.png, docs/source/overview/figures/data_management.png, docs/source/overview/figures/device_virtual.png, docs/source/overview/figures/muti-device.png, docs/source/overview/figures/system_security.jpg, docs/source/overview/figures/task_scheduling.png, docs/source/overview/figures/virtual_bus.png, docs/source/overview/.gitkeep, docs/source/overview/Readme-EN.rst, docs/source/overview/about-harmonyOS.rst, docs/source/overview/system-security.rst, docs/source/overview/technical-features.rst, docs/source/quickstart/images/architecture.png, docs/source/quickstart/.gitkeep, docs/source/quickstart/Readme-EN.rst, docs/source/quickstart/build-open-harmony.rst, docs/source/readme/Images/.gitkeep, docs/source/readme/Images/Font_style.PNG, docs/source/readme/Images/List-table.PNG, docs/source/readme/Images/List.PNG, docs/source/readme/Images/csv_table.PNG, docs/source/readme/Images/math.PNG, docs/source/readme/Images/multi-column_list.PNG, docs/source/readme/Images/multi_data.PNG, docs/source/readme/Images/tables.PNG, docs/source/readme/Images/tables22.png, docs/source/readme/Images/toctree.PNG, docs/source/readme/.gitkeep, docs/source/readme/C Coding Style Guide.rst files

docs/source/overview/Readme-EN.rst

-Overview
-========
-.. toctree::
-   :maxdepth: 2
-   
-   
-   about-harmonyOS
-   technical-features
-   system-security
-   

docs/source/overview/about-harmonyOS.rst

-About HarmonyOS
-===============
-
-System Positioning
-------------------
-
-HarmonyOS is a future-proof distributed operating system open to you as part of the initiatives for the all-scenario strategy, adaptable to mobile office, fitness and health, social communication, and media entertainment, to name a few. Unlike a legacy operating system that runs on a standalone device, HarmonyOS is built on a distributed architecture designed based on a set of system capabilities. It is able to run on a wide range of device forms.
-
-Play Video
-
-- If you are an end user, HarmonyOS integrates your various smart devices to implement fast connection, capability collaboration, and resource sharing 
-  between them. This way, your services can be seamlessly transferred to a suitable device that delivers smooth all-scenario experience.
-- If you are an application developer, HarmonyOS adopts distributed technologies to make your application development possible on different device 
-  forms. With HarmonyOS, you will have the choice to focus on upper-layer service logic and develop applications in a much easier and more efficient 
-  way.
-- If you are a device developer, HarmonyOS uses a component-based software design to tailor itself to your particular device forms based on their 
-  respective resource capabilities and service characteristics.
-
-HarmonyOS provides multi-programming-language APIs for you to develop applications. You can choose from Java, Extensible Markup Language (XML), C/C++, JavaScript (JS), Cascading Style Sheets (CSS), and HarmonyOS Markup Language (HML).
-
-Technical Architecture
-----------------------
-
-HarmonyOS 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 shows the technical architecture of HarmonyOS.
-
-.. figure:: figures/architecture.png
-   
-   :scale: 50
-   width: 100 px
-   :align: center
-   
-   Figure 1 Technical Architecture
-
-Kernel Layer
-------------
-
-- Kernel subsystem: HarmonyOS uses a multi-kernel design (Linux kernel, HarmonyOS microkernel, or LiteOS) so that appropriate OS kernels can be selected for devices with different resource limitations. The kernel abstraction layer (KAL) shields 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 HarmonyOS hardware ecosystem. It allows unified access from peripheral devices and provides foundation for driver development and management.
-
-System Service Layer
---------------------
-
-This layer provides a complete set of capabilities essential for HarmonyOS to offer services for applications through the framework layer. The system service layer consists of the following parts:
-
-- Basic system capability subsystem set: Implements distributed application running, scheduling, and migration across HarmonyOS devices. This 
-  subsystem set provides the following basic capabilities: distributed virtual bus, distributed data management, distributed scheduler, utils,  
-  multimode input, graphics, security, and AI.
-- Basic software service subsystem set: Provides HarmonyOS with common and universal software services, including common event and notification, 
-  telephony, multimedia, Design For X (DFX), as well as Mobile Sensing Development Platform (MSDP) & Device Virtualization (DV).
-- Enhanced software service subsystem set: Provides HarmonyOS with differentiated and enhanced software services, including those dedicated to smart 
-  TVs, wearables, IoT devices, and more.
-- Hardware service subsystem set: Provides HarmonyOS 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 tailored by subsystems, and each subsystem can be tailored by functions, depending on the deployment scenario for a particular device form.
-
-Framework Layer
----------------
-
-This layer provides what you need to develop HarmonyOS 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 HarmonyOS devices vary according to component-based tailoring.
-
-Application Layer
------------------
-
-This layer consists of system applications and third-party applications. Each HarmonyOS 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 implement specific business characteristics and achieve cross-device scheduling and distribution, delighting users with consistent and efficient experience.

docs/source/overview/system-security.rst

-System Security
-===============
-
-HarmonyOS-powered distributed devices ensure that the right person uses the right data through the right device.
-
-- Ensure the right person by performing distributed collaborative identity authentication.
-- Ensure the right device by building a trusted operating environment on the distributed device.
-- Ensure the right data by implementing classified and hierarchical management of data transmitted across devices.
-
-Right Person
-------------
-
-In the distributed scenario, the right person refers to an authenticated user who accesses the data or uses the service. The right person is the prerequisite for preventing illegal data access or user privacy breach. HarmonyOS implements distributed collaborative identity authentication in the following ways:
-
-- **Zero-trust model**: Implements user authentication and data access control. When a user attempts to access data across devices or perform a service operation with a high security level (for example, operating a security protection device), HarmonyOS authenticates the user to ensure that the user is authorized to perform the operation.
-
-- **Multi-factor authentication**: Associates authentication credentials that identify the same user on different devices to improve authentication accuracy.
-
-- **Collaborative authentication**: Decouples identity authentication from hardware so that identity authentication and data collection can be done on different devices to implement resource pooling as well as capability collaboration and sharing. This allows the right device to do the right thing and makes it possible for devices with a high security level to assist devices with a low security level in authenticating users.
-
-Right Device
-------------
-In the distributed scenario, the right person using the right device is the prerequisite to safeguard effective user data security on virtual devices and prevent user privacy breach.
-
-- **Secure boot** : HarmonyOS ensures from the source that the system firmware and applications running on each virtual device from the source are intact and untampered with. With secure boot, HarmonyOS protects image packages of device vendors from being replaced maliciously, thereby ensuring user data security and privacy.
-
-- **TEE** : HarmonyOS provides a hardware-based Trusted Execution Environment (TEE) to prevent data leakage of sensitive personal data when they are stored or processed. As the hardware of distributed devices varies in security capabilities, security issues may arise if sensitive personal data of users is stored and processed by devices with a low security level. To address this issue, HarmonyOS uses formal verification methods, which are an effective mathematical approach to validate system correctness, to secure the TEE microkernel. This helps the microkernel successfully achieve a CC EAL5+ certification for a commercial OS kernel.
-
-- **Device certificate authentication**: HarmonyOS preconfigures a public key infrastructure (PKI) device certificate in the TEE of a device so that the device can prove its security capabilities to other virtual devices. The device certificate ensures that the device is one that was manufactured legally. The certification is preconfigured during device production and proves that the device was manufactured legally. The private key of the certification is written and securely stored in the TEE and can only be used in the TEE. When sensitive user data (such as keys and encrypted biometrics) needs to be transmitted between devices, a secure channel is established between their TEEs only after the device security has been proven using the device certificate. The below figure shows how the device certificate is used.
-
-.. figure:: figures/system_security.jpg
-   :scale: 50
-   :align: center
-
-   Figure 1 Using the device certificate
-
-Right Data
-----------
-
-To ensure that the right data is used by the right person, HarmonyOS protects data security and privacy throughout the entire lifecycle, from data generation and storage to data use, transmission, and destruction. This ensures that personal data and privacy as well as confidential data (such as keys) are strictly protected against disclosure.
-
-- **Data generation**: Data is categorized and classified in compliance with local laws and regulations, and different protection levels are configured for the data based on the classification. For data granted with a specific protection level, security protection is implemented based on the corresponding security policy throughout the entire lifecycle. The access control system of the super virtual device supports tag-based access control policies, which ensure that data can be stored, used, and transmitted only on virtual devices that are able to provide effective security protection.
-
-- **Data storage**: Data with different security levels are stored in partitions with corresponding security protection capabilities to ensure data security. In addition, seamless cross-device key mobility and access control are supported throughout the lifecycle of keys for distributed, collaborative identity authentication and data sharing.
-
-- **Data usage**: Sensitive user data can only be used in a hardware-based TEE of distributed virtual devices, thereby ensuring data security and privacy.
-
-- **Data transmission**: To ensure secure data flow between virtual devices, each device must be reliable and trusted. Trust relationship is established among multiple virtual devices paired by using a HUAWEI ID. A secure channel will be established between virtual devices only after the trust relationship is verified, so that data can be transmitted securely. If two devices need to communicate with each other, they must be authenticated based on their identity credentials. After a successful authentication, an encrypted channel will be established for communication between the devices.
-
-- **Data destruction**: Data destruction is implemented by destroying keys. Data is stored on virtual devices based on keys. To destruct data completely, you only need to destroy the keys protecting the data.

docs/source/overview/technical-features.rst

-Technical Features
-##################
-
-Hardware Collaboration and Resource Sharing
-===========================================
-
-Distributed Virtual Bus
------------------------
-
-Distributed virtual bus is a unified base for interconnection among devices. It powers devices with distributed communication capabilities. With such capabilities, devices can quickly discover and connect to each other, allowing efficient task distribution and data transmission. Figure 1 shows the diagram of distributed virtual bus.
-
-.. figure:: figures/virtual_bus.png
-
-   Figure 1 Distributed virtual bus
-
-Distributed Device Virtualization
----------------------------------
-
-The distributed device virtualization platform enables cross-device resource convergence, device management, and data processing so that multiple devices jointly function as a super virtual device. This platform virtualizes devices and fully utilizes their advantages by assigning the most appropriate hardware to execute particular user tasks. This ensures continuity of services while migrating between different devices. Figure 2 shows the diagram of distributed device virtualization.
-
-.. figure:: figures/device_virtual.png
-
-   Figure 2 Distributed device virtualization
-
-Distributed Data Management
----------------------------
-
-Distributed data management leverages distributed virtual bus to manage application data and user data distributed on different devices. Under such management, user data is no longer bound to a single physical device, and service logic is separated from data storage. As your applications are running across devices, their data is seamlessly transmitted from one device to another, therefore creating a foundation for consistent and smooth user experience. Figure 3 shows the diagram of distributed data management.
-
-.. figure:: figures/data_management.png
-
-   Figure 3 Distributed data management
-
-Distributed Task Scheduling
----------------------------
-
-Distributed task scheduling is designed based on technical features such as distributed virtual 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, remote connection, and migration of applications across devices. This way, your applications can select a 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.
-
-.. figure:: figures/task_scheduling.png
-
-   Figure 4 Distributed task scheduling
-
-
-One-Time Development for Multi-Device Deployment
-------------------------------------------------
-
-HarmonyOS provides the application, ability, and UI frameworks, which allow you to reuse service and UI logic during application development. This way, you can develop your applications once, and then deploy them across a broad range of devices, improving your development efficiency. Figure 5 shows the diagram of one-time development and multi-device deployment.
-
-.. figure:: figures/muti-device.png
-
-   Figure 5 One-time development and multi-device deployment
-
-Unified OS for Flexible Deployment
-----------------------------------
-
-HarmonyOS leverages component-based and miniaturized-oriented designs to allow on-demand deployment for diversified devices, adapting to different hardware resources and business characteristics. Specifically, component dependencies are automatically generated based on the cross-compilation toolchain to form a tree diagram illustrating component dependencies, facilitating convenient development and making development available for various devices, regardless of their hardware capabilities.
-
-- **On-demand component selection**: You can select required components based on hardware forms and requirements.
-
-- **Mutable function set configuration**: You can tailor function sets for each component based on hardware resources and function requirements. For example, you have an option of configuring only certain components for the UI framework.
-
-- **Associative inter-component dependencies**: You can have inter-component dependencies automatically generated based on the cross-compilation toolchain. For example, if you select components for the UI framework, their associative graphics engine-specific components will be automatically selected.

docs/source/quickstart/Readme-EN.rst

-Quick-Start
-===========
-.. toctree::
-   :maxdepth: 2
-   
-   
-   build-open-harmony
-   
-   

docs/source/quickstart/build-open-harmony.rst

-.. BuildOpenharmony:
-
-Building OpenHarmony Image
-##########################
-
-OpenHarmony is a distributed OS that is designed to run on top of variety of OS kernels. Currently the supported kernels are  Zephyr, Yocto, and FreeRTOS. To build OpenHarmony image, you need to add multiple layers called meta-ohos. The meta-ohos is an umbrella meta layer containing all layers required to build OpenHarmony Image based on existing kernel meta-layers. This section describes how to build, add layers, and run the OpenHarmony image. 
-
-* `Build and Run Using Zephyr <using zypher>`_
-* `Build and Run Using Linux <using linux>`_ 
-* `Build and Run Using FreeRTOS <using freertos>`_
-
-
-Currently OpenHarmony Supports building image using the following boards: 
-
-* `Nitrogen <https://www.96boards.org/documentation/iot/nitrogen/>`_
-* `Avenger96 <https://www.96boards.org/documentation/consumer/avenger96/>`_
-
-**Figure 1 meta-ohos overview**
-
-.. figure:: images/architecture.png
-     :align: center
-     :alt: meta-ohos overview
-
-Prerequisites
--------------------
-
-To start working with meta-ohos first install git repo:
-
-.. code-block:: console
-
-   $ sudo add-apt-repository ppa:zyga/oh-tools
-   $ sudo apt-get update
-   $ sudo apt-get install git-repo
-
-.. _using zypher:
-
-Build and Run Using Zypher
------------------------------------------
-
-1. Once git repo has been installed, clone the necessary repositories.
-
- .. code-block:: console
-
-      $ mkdir ohos; cd ohos
-      $ repo init -u https://git.ostc-eu.org/incubate/meta-ohos/manifest.git
-      $ repo sync
-      $ cd poky
-      poky$ . oe-init-build-env
-
-2. Add layers for other kernels. Working directory will automatically change to ./poky/build. 
-
- .. code-block:: console
-
-      build$ bitbake-layers add-layer ../meta-openembedded/meta-oe
-      build$ bitbake-layers add-layer ../meta-openembedded/meta-python
-      build$ bitbake-layers add-layer ../meta-zephyr
-      build$ bitbake-layers add-layer ../meta-freertos
-
- .. note::
-   Layers for poky were added automatically by sourcing oe-init-build-env.
-
-3. Build distro by selecting the prefered board:
-
- * For Nitrogen
-
-     .. code-block:: console
- 
-         build$ DISTRO=zephyr MACHINE=96b-nitrogen bitbake zephyr-philosophers
-	 
- * For Avenger96
-	 
-     .. code-block:: console
- 
-         build$ DISTRO=zephyr MACHINE=96b-avenger96 bitbake zephyr-philosophers
-	 
-
- .. note::
-    For Zephyr, zephyr-philosophers is the one of sample applications available in meta-zephyr layer by Yocto project. It's easy to build other samples using recipes available in meta-zephyr/recipes-kernel/zephyr-kernel/ directory.
-	
-4. After the build is successful, run the image by executing the following command:
-
-
- * For Nitrogen
-
-     .. code-block:: console
- 
-         build$ DEPLOY_DIR_IMAGE=tmp-newlib/deploy/images/96b-nitrogen runqemu 96b-nitrogen
-	 	 
-	 	 
- * For Avenger96
-	 
-     .. code-block:: console
- 
-         build$ DEPLOY_DIR_IMAGE=tmp-newlib/deploy/images/96b-avenger96 runqemu 96b-avenger96
-         
-After successful bootup, the following message should be displayed:
-
-.. code-block:: console
-
-   Booting from ROM..*** Booting Zephyr OS build zephyr-v2.4.0  ***
-   Philosopher 0 [P: 3]  THINKING [  300 ms ]
-   Philosopher 1 [P: 2]   EATING  [  575 ms ]
-   Philosopher 2 [P: 1]        STARVING
-   Philosopher 3 [P: 0]   EATING  [  525 ms ]
-   Philosopher 4 [C: -1]  THINKING [  475 ms ]
-
-.. _using linux:
-
-
-Build and Run Using Linux
-----------------------------------------
-
-1. Once git repo has been installed, clone the necessary repositories.
-
- .. code-block:: console
-
-      $ mkdir ohos; cd ohos
-      $ repo init -u https://git.ostc-eu.org/incubate/meta-ohos/manifest.git
-      $ repo sync
-      $ cd poky
-      poky$ . oe-init-build-env
-
-2. Add layers for other kernels. Working directory will automatically change to ./poky/build. 
-
- .. code-block:: console
-
-      build$ bitbake-layers add-layer ../meta-openembedded/meta-oe
-      build$ bitbake-layers add-layer ../meta-openembedded/meta-python
-      build$ bitbake-layers add-layer ../meta-zephyr
-      build$ bitbake-layers add-layer ../meta-freertos
-
- .. note::
-   Layers for poky were added automatically by sourcing oe-init-build-env.
-
-3. Build distro by selecting the prefered board:
-
- * For Nitrogen
-
-     .. code-block:: console
- 
-         build$ DISTRO=poky-tiny MACHINE=96b-nitrogen bitbake core-image-minimal
-	 
- * For Avenger96
-	 
-     .. code-block:: console
- 
-         build$ DISTRO=poky-tiny MACHINE=96b-avenger96 bitbake core-image-minimal
-	
-4. After the build is successful, run the image by executing the following command:
-
- * For Nitrogen
-
-     .. code-block:: console
- 
-         build$ runqemu 96b-nitrogen ramfs qemuparams="-nographic"
-	 	 
-	 	 
- * For Avenger96
-	 
-     .. code-block:: console
- 
-         build$ runqemu 96b-avenger96 ramfs qemuparams="-nographic"
-         
-After successful bootup, the following message should be displayed:
-
- * For Nitrogen
-
-     .. code-block:: console
- 
-            # For poky
-            96b-nitrogen login:
-            # Default login is _root_ without a password.
-            # After login you should see prompt:
-            root@96b-nitrogen:~#
-	 	 
- * For Avenger96
-	 
-     .. code-block:: console
- 
-            # For poky
-            96b-avenger96 login:
-            # Default login is _root_ without a password.
-            # After login you should see prompt:
-            root@96b-avenger96:~#
- 
-.. _using freertos:
- 
-Build and Run Using FreeRTOS
------------------------------------------------
-
-1. Once git repo has been installed, clone the necessary repositories.
-
- .. code-block:: console
-
-      $ mkdir ohos; cd ohos
-      $ repo init -u https://git.ostc-eu.org/incubate/meta-ohos/manifest.git
-      $ repo sync
-      $ cd poky
-      poky$ . oe-init-build-env
-
-2. Add layers for other kernels. Working directory will automatically change to ./poky/build. 
-
- .. code-block:: console
-
-      build$ bitbake-layers add-layer ../meta-openembedded/meta-oe
-      build$ bitbake-layers add-layer ../meta-openembedded/meta-python
-      build$ bitbake-layers add-layer ../meta-zephyr
-      build$ bitbake-layers add-layer ../meta-freertos
-
-3. Build distro by selecting the prefered board.
-
-   .. Note::
-      Currently FreeRTOS supports *qemu* boards only.
-
-     .. code-block:: console
-        
-         build$ DISTRO=freertos MACHINE=qemuarmv5 bitbake freertos-demo
-
-4. After the build is successful, run the image by executing the following command:
-
-     .. code-block:: console
- 
-         build$ runqemu 96b-nitrogen
-         
-After successful bootup, the following message should be displayed:
-
-.. code-block:: console
-
-   ###### - FreeRTOS sample application -######
-
-   A text may be entered using a keyboard.
-   It will be displayed when 'Enter' is pressed.
-   
-   Periodic task 10 secs
-   Waiting For Notification - Blocked...
-   Task1
-   Task1
-   You entered: "HelloFreeRTOS"
-   Unblocked
-   Notification Received
-   Waiting For Notification - Blocked...
-
-
- 
- 
-     
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-