!207 上传英文Readme文件

Merge pull request !207 from Mark/noEmployeeNum_ChangeID_13278305_liudongmiao

en/readme/ai.md

+# AI<a name="EN-US_TOPIC_0000001087226912"></a>
+
+-   [Introduction](#section187321516154516)
+-   [Directory Structure](#section571610913453)
+-   [Constraints](#section5748426453)
+-   [Usage](#section6370123616447)
+-   [Repositories Involved](#section10492183517430)
+-   [Reference](#section6808423133718)
+
+## Introduction<a name="section187321516154516"></a>
+
+The AI subsystem is the part of OpenHarmony that provides native distributed AI capabilities. At the heart of the subsystem is a unified AI engine framework, which implements quick integration of AI algorithm plug-ins. The framework consists of the plug-in management, module management, and communication management modules, fulfilling lifecycle management and on-demand deployment of AI algorithms. Under this framework, AI algorithm APIs will be standardized to facilitate distributed calling of AI capabilities. In addition, unified inference APIs will be provided to adapt to different inference framework hierarchies.
+
+**Figure  1**  AI engine framework<a name="fig17296164711526"></a>  
+![](figures/ai-engine-framework.png "ai-engine-framework")
+
+## Directory Structure<a name="section571610913453"></a>
+
+```
+/foundation/ai/engine                        # Home directory of the AI subsystem
+├── interfaces
+│  └── kits                                  # External APIs of the AI subsystem
+└── services
+│  ├── client                                # Client module of the AI subsystem
+│  │  ├── client_executor                    # Executor of the client module
+│  │  └── communication_adapter              # Communication adaptation layer for the client module, with extension supported
+│  ├── common                                # Common tools and protocol modules of the AI subsystem
+│  │  ├── platform
+│  │  ├── protocol
+│  │  └── utils
+│  └── server                                # Server module of the AI subsystem
+│  │  ├── communication_adapter              # Communication adaptation layer for the server module, with extension supported
+│  │  ├── plugin
+│  │     ├── asr
+│  │        └── keyword_spotting             # ASR algorithm plug-in reference: keyword spotting
+│  │     └── cv
+│  │        └── image_classification         # CV algorithm plug-in reference: image classification
+│  │  ├── plugin_manager
+│  │  └── server_executor                    # Executor of the server module
+```
+
+## Constraints<a name="section5748426453"></a>
+
+**Programming language**: C/C++
+
+**Operating system**: OpenHarmony
+
+**Others**: The System Ability Manager \(Samgr\) has been started and is running properly.
+
+## Usage<a name="section6370123616447"></a>
+
+1.  Compile the AI subsystem.
+
+    The source code for lightweight AI framework is available at  **//foundation/ai/engine/services**.
+
+    The compilation procedure is as follows:
+
+    1. Set the compilation path.
+
+    ```
+    hb set -root dir (root dir is the root directory of the project code.)
+    ```
+
+    2. Specify the product for compilation. \(After the product list is displayed using the following command, move to the desired product with arrow keys and press  **Enter**.\)
+
+    ```
+    hb set -p
+    ```
+
+    3. Start compilation.
+
+    ```
+    hb build -f (Use this command if you want to compile the entire repository.)
+    hb build ai_engine (Use this command if you want to compile only the ai_engine module.)
+    ```
+
+    **Note**: For details about the hb configuration, see the readme of the build\_lite subsystem.
+
+2.  Develop the plug-in, with keyword spotting as an example.
+
+    Directory: //foundation/ai/engine/services/server/plugin/asr/keyword\_spotting
+
+    **Note**: The plug-in must implement the  **IPlugin**  and  **IPluginCallback**  APIs provided by the server.
+
+    ```
+    #include "plugin/i_plugin.h
+    class KWSPlugin : public IPlugin {       # Inherits the public base class of the IPlugin API for Keywords Spotting Plugin (KWSPlugin).
+        KWSPlugin();
+        ~KWSPlugin();
+    
+        const long long GetVersion() const override;
+        const char* GetName() const override;
+        const char* GetInferMode() const override;
+    
+        int32_t Prepare(long long transactionId, const DataInfo &amp;amp;inputInfo, DataInfo &amp;amp;outputInfo) override;
+        int32_t SetOption(int optionType, const DataInfo &amp;amp;inputInfo) override;
+        int32_t GetOption(int optionType, const DataInfo &amp;amp;inputInfo, DataInfo &amp;amp;outputInfo) override;
+        int32_t SyncProcess(IRequest *request, IResponse *&amp;amp;response) override;
+        int32_t AsyncProcess(IRequest *request, IPluginCallback*callback) override;
+        int32_t Release(bool isFullUnload, long long transactionId, const DataInfo &amp;amp;inputInfo) override;
+        .
+        .
+        .
+    };
+    ```
+
+    **Note**: Depending on the algorithm in use, you only need to implement the  **SyncProcess**  or  **AsyncProcess**  API. Use an empty function as a placeholder for the other API. In this example, the KWS plug-in uses the synchronous algorithm. Therefore, you need to implement  **SyncProcess**  API and use an empty function as a placeholder for the  **SyncProcess**  API.
+
+    ```
+    #include "aie_log.h"
+    #include "aie_retcode_inner.h"
+    .
+    .
+    .
+    
+    const long long KWSPlugin::GetVersion() const
+    {
+        return ALGOTYPE_VERSION_KWS;
+    }
+    
+    const char *KWSPlugin::GetName() const
+    {
+        return ALGORITHM_NAME_KWS.c_str();
+    }
+    
+    const char *KWSPlugin::GetInferMode() const
+    {
+        return DEFAULT_INFER_MODE.c_str();
+    }
+    .
+    .
+    .
+    int32_t KWSPlugin::AsyncProcess(IRequest *request, IPluginCallback *callback)
+    {
+        return RETCODE_SUCCESS;
+    }
+    ```
+
+3.  Develop the SDK, with keyword spotting as an example.
+
+    Directory: //foundation/ai/engine/services/client/algorithm\_sdk/asr/keyword\_spotting
+
+    Keyword spotting SDK:
+
+    ```
+    class KWSSdk {
+    public:
+        KWSSdk();
+        virtual ~KWSSdk();
+    
+        /**
+         * @brief Create a new session with KWS Plugin
+         *
+         * @return Returns KWS_RETCODE_SUCCESS(0) if the operation is successful,
+         *         returns a non-zero value otherwise.
+         */
+        int32_t Create();
+    
+        /**
+         * @brief Synchronously execute keyword spotting once
+         *
+         * @param audioInput pcm data.
+         * @return Returns KWS_RETCODE_SUCCESS(0) if the operation is successful,
+         *         returns a non-zero value otherwise.
+         */
+        int32_t SyncExecute(const Array<int16_t> &audioInput);
+    
+        /**
+         * @brief Asynchronously execute keyword spotting once
+         *
+         * @param audioInput pcm data.
+         * @return Returns KWS_RETCODE_SUCCESS(0) if the operation is successful,
+         *         returns a non-zero value otherwise.
+         */
+        int32_t AsyncExecute(const Array<int16_t> &audioInput);
+    
+        /**
+         * @brief Set callback
+         *
+         * @param callback Callback function that will be called during the process.
+         * @return Returns KWS_RETCODE_SUCCESS(0) if the operation is successful,
+         *         returns a non-zero value otherwise.
+         */
+        int32_t SetCallback(const std::shared_ptr<KWSCallback> &callback);
+    
+        /**
+         * @brief Destroy the created session with KWS Plugin
+         *
+         * @return Returns KWS_RETCODE_SUCCESS(0) if the operation is successful,
+         *         returns a non-zero value otherwise.
+         */
+        int32_t Destroy();
+    ```
+
+    **Note**: The sequence for the SDK to call client APIs of the AI engine is as follows: AieClientInit -\> AieClientPrepare -\> AieClientSyncProcess/AieClientAsyncProcess -\> AieClientRelease -\> AieClientDestroy. An exception will be thrown if the call sequence is violated. In addition, all these APIs must be called. Otherwise, a memory leakage may occur.
+
+    ```
+    int32_t KWSSdk::KWSSdkImpl::Create()
+    {
+        if (kwsHandle_ != INVALID_KWS_HANDLE) {
+            HILOGE("[KWSSdkImpl]The SDK has been created");
+            return KWS_RETCODE_FAILURE;
+        }
+        if (InitComponents() != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]Fail to init sdk components");
+            return KWS_RETCODE_FAILURE;
+        }
+        int32_t retCode = AieClientInit(configInfo_, clientInfo_, algorithmInfo_, nullptr);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]AieClientInit failed. Error code[%d]", retCode);
+            return KWS_RETCODE_FAILURE;
+        }
+        if (clientInfo_.clientId == INVALID_CLIENT_ID) {
+            HILOGE("[KWSSdkImpl]Fail to allocate client id");
+            return KWS_RETCODE_FAILURE;
+        }
+        DataInfo inputInfo = {
+            .data = nullptr,
+            .length = 0,
+        };
+        DataInfo outputInfo = {
+            .data = nullptr,
+            .length = 0,
+        };
+        retCode = AieClientPrepare(clientInfo_, algorithmInfo_, inputInfo, outputInfo, nullptr);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]AieclientPrepare failed. Error code[%d]", retCode);
+            return KWS_RETCODE_FAILURE;
+        }
+        if (outputInfo.data == nullptr || outputInfo.length <= 0) {
+            HILOGE("[KWSSdkImpl]The data or length of output info is invalid");
+            return KWS_RETCODE_FAILURE;
+        }
+        MallocPointerGuard<unsigned char> pointerGuard(outputInfo.data);
+        retCode = PluginHelper::UnSerializeHandle(outputInfo, kwsHandle_);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]Get handle from inputInfo failed");
+            return KWS_RETCODE_FAILURE;
+        }
+        return KWS_RETCODE_SUCCESS;
+    }
+    
+    int32_t KWSSdk::KWSSdkImpl::SyncExecute(const Array<uint16_t> &audioInput)
+    {
+        intptr_t newHandle = 0;
+        Array<int32_t> kwsResult = {
+            .data = nullptr,
+            .size = 0
+        };
+        DataInfo inputInfo = {
+            .data = nullptr,
+            .length = 0
+        };
+        DataInfo outputInfo = {
+            .data = nullptr,
+            .length = 0
+        };
+        int32_t retCode = PluginHelper::SerializeInputData(kwsHandle_, audioInput, inputInfo);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]Fail to serialize input data");
+            callback_->OnError(KWS_RETCODE_SERIALIZATION_ERROR);
+            return RETCODE_FAILURE;
+        }
+        retCode = AieClientSyncProcess(clientInfo_, algorithmInfo_, inputInfo, outputInfo);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]AieClientSyncProcess failed. Error code[%d]", retCode);
+            callback_->OnError(KWS_RETCODE_PLUGIN_EXECUTION_ERROR);
+            return RETCODE_FAILURE;
+        }
+        if (outputInfo.data == nullptr || outputInfo.length <= 0) {
+            HILOGE("[KWSSdkImpl] The data or length of outputInfo is invalid. Error code[%d]", retCode);
+            callback_->OnError(KWS_RETCODE_NULL_PARAM);
+            return RETCODE_FAILURE;
+        }
+        MallocPointerGuard<unsigned char> pointerGuard(outputInfo.data);
+        retCode = PluginHelper::UnSerializeOutputData(outputInfo, newHandle, kwsResult);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]UnSerializeOutputData failed. Error code[%d]", retCode);
+            callback_->OnError(KWS_RETCODE_UNSERIALIZATION_ERROR);
+            return retCode;
+        }
+        if (kwsHandle_ != newHandle) {
+            HILOGE("[KWSSdkImpl]The handle[%lld] of output data is not equal to the current handle[%lld]",
+                (long long)newHandle, (long long)kwsHandle_);
+            callback_->OnError(KWS_RETCODE_PLUGIN_SESSION_ERROR);
+            return RETCODE_FAILURE;
+        }
+        callback_->OnResult(kwsResult);
+        return RETCODE_SUCCESS;
+    }
+    
+    int32_t KWSSdk::KWSSdkImpl::Destroy()
+    {
+        if (kwsHandle_ == INVALID_KWS_HANDLE) {
+            return KWS_RETCODE_SUCCESS;
+        }
+        DataInfo inputInfo = {
+            .data = nullptr,
+            .length = 0
+        };
+        int32_t retCode = PluginHelper::SerializeHandle(kwsHandle_, inputInfo);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]SerializeHandle failed. Error code[%d]", retCode);
+            return KWS_RETCODE_FAILURE;
+        }
+        retCode = AieClientRelease(clientInfo_, algorithmInfo_, inputInfo);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]AieClientRelease failed. Error code[%d]", retCode);
+            return KWS_RETCODE_FAILURE;
+        }
+        retCode = AieClientDestroy(clientInfo_);
+        if (retCode != RETCODE_SUCCESS) {
+            HILOGE("[KWSSdkImpl]AieClientDestroy failed. Error code[%d]", retCode);
+            return KWS_RETCODE_FAILURE;
+        }
+        mfccProcessor_ = nullptr;
+        pcmIterator_ = nullptr;
+        callback_ = nullptr;
+        kwsHandle_ = INVALID_KWS_HANDLE;
+        return KWS_RETCODE_SUCCESS;
+    }
+    ```
+
+4.  **Sample development**  \(similar to keyword spotting\)
+
+    Directory: //applications/sample/camera/ai/asr/keyword\_spotting
+
+    Call the  **Create**  API.
+
+    ```
+    bool KwsManager::PreparedInference()
+    {
+        if (capturer_ == nullptr) {
+            printf("[KwsManager] only load plugin after AudioCapturer ready\n");
+            return false;
+        }
+        if (plugin_ != nullptr) {
+            printf("[KwsManager] stop created InferencePlugin at first\n");
+            StopInference();
+        }
+        plugin_ = std::make_shared<KWSSdk>();
+        if (plugin_ == nullptr) {
+            printf("[KwsManager] fail to create inferencePlugin\n");
+            return false;
+        }
+        if (plugin_->Create() != SUCCESS) {
+            printf("[KwsManager] KWSSdk fail to create.\n");
+            return false;
+        }
+        std::shared_ptr<KWSCallback> callback = std::make_shared<MyKwsCallback>();
+        if (callback == nullptr) {
+            printf("[KwsManager] new Callback failed.\n");
+            return false;
+        }
+        plugin_->SetCallback(callback);
+        return true;
+    }
+    ```
+
+    Call the  **SyncExecute**  API.
+
+    ```
+    void KwsManager::ConsumeSamples()
+    {
+        uintptr_t sampleAddr = 0;
+        size_t sampleSize = 0;
+        int32_t retCode = SUCCESS;
+        while (status_ == RUNNING) {
+            {
+                std::lock_guard<std::mutex> lock(mutex_);
+                if (cache_ == nullptr) {
+                    printf("[KwsManager] cache_ is nullptr.\n");
+                    break;
+                }
+                sampleSize = cache_->GetCapturedBuffer(sampleAddr);
+            }
+            if (sampleSize == 0 || sampleAddr == 0) {
+                continue;
+            }
+            Array<int16_t> input = {
+                .data = (int16_t *)(sampleAddr),
+                .size = sampleSize >> 1
+            };
+            {
+                std::lock_guard<std::mutex> lock(mutex_);
+                if (plugin_ == nullptr) {
+                    printf("[KwsManager] cache_ is nullptr.\n");
+                    break;
+                }
+                if ((retCode = plugin_->SyncExecute(input)) != SUCCESS) {
+                    printf("[KwsManager] SyncExecute KWS failed with retCode = [%d]\n", retCode);
+                    continue;
+                }
+            }
+        }
+    }
+    ```
+
+    Call the  **Destroy**  API.
+
+    ```
+    void KwsManager::StopInference()
+    {
+        printf("[KwsManager] StopInference\n");
+        if (plugin_ != nullptr) {
+            int ret = plugin_->Destroy();
+            if (ret != SUCCESS) {
+                printf("[KwsManager] plugin_ destroy failed.\n");
+            }
+            plugin_ = nullptr;
+        }
+    }
+    ```
+
+
+## Repositories Involved<a name="section10492183517430"></a>
+
+AI subsystem:
+
+**ai\_engine**
+
+Dependency repositories:
+
+build\_lite
+
+distributedschedule\_services\_samgr\_lite
+
+startup\_init\_lite
+
+## Reference<a name="section6808423133718"></a>
+
+-   AI Engine Framework Development Guide
+

en/readme/compilation-and-building-subsystem.md

 # Compilation and Building Subsystem<a name="EN-US_TOPIC_0000001052340730"></a>
 
+-   [Overview](#section11660541593)
+-   [Directory Structure](#section1464106163817)
+-   [Constraints](#section1718733212019)
+-   [Usage](#section641210360552)
+-   [Repositories Involved](#section6299103515474)
+
 ## Overview<a name="section11660541593"></a>
 
 The compilation and building subsystem provides a compilation and building framework based on GN and Ninja. Using this subsystem, you can perform the following operations:

en/readme/distributed-communication-subsystem.md

-# Distributed Communication Subsystem<a name="EN-US_TOPIC_0000001051344287"></a>
-
-## Overview<a name="section11660541593"></a>
-
-The use of different communication modes \(such as USB, WLAN, and Bluetooth\) varies greatly and is complex. In addition, the convergence, sharing, and conflicts between communication links cannot be resolved, and communication security is difficult to guarantee. The distributed communication subsystem manages unified distributed communication between near-field devices and provides device discovery and data transmission APIs that apply to all links. Currently, the following features are available:
-
--   Service publishing: After a service is published, peripheral devices can discover and use it.
--   Data transmission: A session is established based on the service name and device ID to transmit data between services.
--   Security: Communication data is encrypted.
-
-You can use APIs of the distributed communication subsystem to implement fast and secure communication between devices without caring about management of communication details, thereby achieving cross-platform development.
-
-## Directory Structure<a name="section1464106163817"></a>
-
-The following figure shows the softbus\_lite source code directory structure.
-
-**Table 1**  softbus\_lite source code directory structure
-
-<a name="table1843451445317"></a>
-<table><thead align="left"><tr id="row16552191445314"><th class="cellrowborder" valign="top" width="50%" id="mcps1.1.3.1.1"><p id="p75521114125314"><a name="p75521114125314"></a><a name="p75521114125314"></a>Name</p>
-</th>
-<th class="cellrowborder" valign="top" width="50%" id="mcps1.1.3.1.2"><p id="p2055231419539"><a name="p2055231419539"></a><a name="p2055231419539"></a>Description</p>
-</th>
-</tr>
-</thead>
-<tbody><tr id="row15552151465314"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.1 "><p id="p255221425316"><a name="p255221425316"></a><a name="p255221425316"></a>authmanager</p>
-</td>
-<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="p11552114135313"><a name="p11552114135313"></a><a name="p11552114135313"></a>Provides the device authentication mechanism and manages device knowledge libraries.</p>
-</td>
-</tr>
-<tr id="row1755251416537"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.1 "><p id="p455231495317"><a name="p455231495317"></a><a name="p455231495317"></a>discovery</p>
-</td>
-<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="p15531214115319"><a name="p15531214115319"></a><a name="p15531214115319"></a>Provides a device discovery mechanism that is based on the Constrained Application Protocol (CoAP).</p>
-</td>
-</tr>
-<tr id="row155534148533"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.1 "><p id="p1252015524711"><a name="p1252015524711"></a><a name="p1252015524711"></a>trans_service</p>
-</td>
-<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="p1752055220713"><a name="p1752055220713"></a><a name="p1752055220713"></a>Provides authentication and transmission channels.</p>
-</td>
-</tr>
-</tbody>
-</table>
-
-## Constraints<a name="section1718733212019"></a>
-
--   Language: C
--   Networking: Devices must be in the same LAN.
-
-## Usage<a name="section167037358130"></a>
-
-1.  Discover devices.
-
-When using device discovery, ensure that the device to perform a discovery and the discovered device are in the same LAN and the devices can receive packets from each other.
-
-a. After a device sends a discovery request, it uses CoAP to send a broadcast packet in the LAN. The following figure shows the request packet.
-
-![](figures/1.png)
-
-b. The discovered device uses the  **PublishService**  API to publish services. After receiving the broadcast packet, the device sends a CoAP unicast packet to the device that performs the discovery. The following figure shows the packet example.
-
-![](figures/2.png)
-
-c. After receiving the packet, the device that performs the discovery updates device information.
-
-The following is an example of how to use device discovery:
-
-```
-// Declare the callback function.
-void onSuccess(int publishId)
-{
-    printf("public success,publishId = %d\r\n", publishId);
-}
-void onFail(int publishId, PublishFailReason reason)
-{
-    printf("publish failed, publishId = %d, reason = %d\r\n", publishId, reason);
-}
-// Publish services.
-PublishInfo info = {0};
-IPublishCallback cb = {0};
-cb.onPublishSuccess = onSuccess;
-cb.onPublishFail = onFail;
-char a[] = "456";
-info.capabilityData = a;
-info.capability = "ddmpCapability";
-info.dataLen = strlen("456");
-info.medium = 2;
-info.publishId = 1;
-PublishService("cxx", &info, &cb);
-```
-
-2. Transmit data.
-
-The soft bus provides unified session-based transmission. Services can receive and send data or obtain basic attributes through  **sessionId**. Currently, services can determine whether to accept a received session based on the service requirements and session attributes. Currently, sessions cannot be enabled.
-
-The sample code for data transmission is as follows:
-
-```
-// Define the service name, session name, and related callback.
-const char *g_moduleName  = "BUSINESS_NAME";
-const char *g_sessionName = "SESSION_NAME";
-struct ISessionListener * g_sessionCallback= NULL;
-
-// Implement the callback: After receiving data sent by the peer end using SendBytes, return a fixed message.
-void OnBytesReceivedTest(int sessionId, const void* data, unsigned int dataLen)
-{
-    printf("OnBytesReceivedTest\n");
-    printf("Recv Data: %s\n", (char *)data);
-    printf("Recv Data dataLen: %d\n", dataLen);
-    char *testSendData = "Hello World, Hello!";
-    SendBytes(sessionId, testSendData, strlen(testSendData));
-    return;
-}
-
-// Implement the callback: Perform relevant operations after the session is closed, for example, releasing service resources related to the current session. The session does not need to be released by the service.
-void OnSessionClosedEventTest(int sessionId)
-{
-    printf("Close session successfully, sessionId=%d\n", sessionId);
-}
-
-// Implement the callback: Perform relevant operations after a session is opened. The return value 0 means to accept the session, and other values mean to reject the session. In the following example, only sessions with the same name from other devices are accepted.
-int OnSessionOpenedEventTest(int sessionId)
-{
-    if (strcmp(GetPeerSessionName(sessionId), SESSION_NAME) != 0) {
-        printf("Reject the session which name is different from mine, sessionId=%d\n", sessionId);
-        return -1;
-    }
-    printf("Open session successfully, sessionId=%d\n", sessionId);
-    return 0;
-}
-
-// Register the service session service and its callbacks with the soft bus.
-int StartSessionServer()
-{
-    if (g_sessionCallback == NULL) {
-        g_sessionCallback = (struct ISessionListener*)malloc(sizeof(struct ISessionListener));
-    }
-    if (g_sessionCallback == NULL) {
-        printf("Failed to malloc g_sessionCallback!\n");
-        return -1;
-    }
-    g_sessionCallback->onBytesReceived = OnBytesReceivedTest;
-    g_sessionCallback->onSessionOpened = OnSessionOpenedEventTest;
-    g_sessionCallback->onSessionClosed = OnSessionClosedEventTest;
-    int ret = CreateSessionServer(g_moduleName , g_sessionName, g_sessionCallback);
-    if (ret < 0) {
-        printf("Failed to create session server!\n");
-        free(g_sessionCallback);
-        g_sessionCallback = NULL;
-    }
-    return ret;
-}
-
-// Delete the service session service and its callbacks from the soft bus.
-void StopSessionServer()
-{
-    int ret = RemoveSessionServer(g_moduleName , g_sessionName);
-    if (ret < 0) {
-        printf("Failed to remove session server!\n");
-        return;
-    }
-    if (g_sessionCallback != NULL) {
-        free(g_sessionCallback);
-        g_sessionCallback = NULL;
-    }
-}
-```
-
-## Repositories Involved<a name="section4499619123117"></a>
-
-communication\_frameworks\_wifi\_lite
-
-communication\_frameworks\_ipc\_lite
-
-communication\_hals\_wifi\_lite
-
-communication\_interfaces\_kits\_ipc\_lite
-
-communication\_interfaces\_kits\_softbuskit\_lite
-
-communication\_interfaces\_kits\_wifi\_lite
-
-communication\_services\_softbus\_lite
-

en/readme/distributed-scheduler.md

 # Distributed Scheduler<a name="EN-US_TOPIC_0000001051983009"></a>
 
-## Overview<a name="section11660541593"></a>
+-   [Introduction](#section11660541593)
+-   [Directory Structure](#section1464106163817)
+-   [Constraints](#section1718733212019)
+-   [Usage](#section10729231131110)
+-   [Repositories Involved](#section176111311166)
+
+## Introduction<a name="section11660541593"></a>
 
 The Distributed Scheduler is used for cross-device component management. It allows the local device to access or control remote components, and enables application collaboration in distributed scenarios. The following figure shows the modules in the Distributed Scheduler.
 
@@ -19,7 +25,7 @@ The following table describes the directory structure of the Distributed Schedul
 </th>
 </tr>
 </thead>
-<tbody><tr id="row64161056151718"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.1 "><p id="p9416656181720"><a name="p9416656181720"></a><a name="p9416656181720"></a>dtbschedmgr_lite</p>
+<tbody><tr id="row64161056151718"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.1 "><p id="p9416656181720"><a name="p9416656181720"></a><a name="p9416656181720"></a>dmsfwk_lite</p>
 </td>
 <td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="p541645611177"><a name="p541645611177"></a><a name="p541645611177"></a>Implementation of the Distributed Scheduler</p>
 </td>
@@ -29,35 +35,14 @@ The following table describes the directory structure of the Distributed Schedul
 <td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="p04163569170"><a name="p04163569170"></a><a name="p04163569170"></a>Implementation of the foundation process</p>
 </td>
 </tr>
+<tr id="row65582011104710"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.1 "><p id="p1655851194713"><a name="p1655851194713"></a><a name="p1655851194713"></a>samgr_lite</p>
+</td>
+<td class="cellrowborder" valign="top" width="50%" headers="mcps1.1.3.1.2 "><p id="p145595112471"><a name="p145595112471"></a><a name="p145595112471"></a>Implementation of system ability framework</p>
+</td>
+</tr>
 </tbody>
 </table>
 
-The source code directory structure of the Distributed Scheduler is as follows:
-
-```
-├── BUILD.gn
-├── include
-│  ├── distributed_schedule_service.h        # Header file for the open APIs provided by the Distributed Scheduler
-│  ├── dmslite_check_remote_permission.h     # Header file for the permission management module of the Distributed Scheduler
-│  ├── dmslite_famgr.h                       # Header file for the FA management module of the Distributed Scheduler
-│  ├── dmslite_inner_common.h                # Internal common file for the Distributed Scheduler
-│  ├── dmslite.h                             # Header file for the implementation of the Distributed Scheduler Service
-│  ├── dmslite_log.h                         # Header file for the log module
-│  ├── dmslite_msg_parser.h                  # Header file for the distributed message parsing module
-│  ├── dmslite_tlv_common.h                  # Header file for the TLV data parsing module
-│  └── dmslite_session.h                     # Header file for the inter-device communication module
-├── readme.md
-├── LICENSE
-├── source
-    ├── distributed_schedule_service.c
-    ├── dmslite.c
-    ├── dmslite_check_remote_permission.c
-    ├── dmslite_famgr.c
-    ├── dmslite_msg_parser.c
-    ├── dmslite_tlv_common.c
-    └── dmslite_session.c
-```
-
 ## Constraints<a name="section1718733212019"></a>
 
 **Language**: C or C++
@@ -68,12 +53,12 @@ The source code directory structure of the Distributed Scheduler is as follows:
 
 **Limitations and constraints on remote startup**:
 
--   Only FAs can be started remotely. Remote startup is unavailable to abilities using the Service template.
+-   Only Feature Abilities \(FAs\) can be started remotely. Remote startup is unavailable to abilities using the Service template.
 -   Before the remote startup, ensure that the distributed networking between the primary and secondary devices is successful. Otherwise, the remote startup fails.
 
 ## Usage<a name="section10729231131110"></a>
 
--   **Compiling the Distributed Scheduler**
+-   **Compiling and Building the Distributed Scheduler**
 
 The code of the Distributed Scheduler is stored in the following directory:
 
@@ -81,7 +66,7 @@ The code of the Distributed Scheduler is stored in the following directory:
 foundation/distributedschedule/services/dtbschedmgr_lite
 ```
 
-When compiling the code for a specific platform, you need to specify the target platform. The following code snippet uses code compilation for the Hi3516DV300 platform as an example:
+When compiling and building the code for a specific platform, you need to specify the target platform. The following code snippet uses code compilation and building for the Hi3516 DV300 platform as an example:
 
 ```
 python build.py ipcamera -p hi3516dv300_liteos_a
@@ -116,9 +101,7 @@ Call the  **startAbility**  method on the primary device to start the target FA
 
 ## Repositories Involved<a name="section176111311166"></a>
 
-distributedschedule\_interfaces\_kits\_samgr\_lite
-
-distributedschedule\_services\_dtbschedmgr\_lite
+[Distributed scheduler](https://gitee.com/openharmony/docs/blob/master/readme/distributedschedule/dmslite.md)
 
-distributedschedule\_services\_safwk\_lite
+[System ability framework](https://gitee.com/openharmony/docs/blob/master/readme/distributedschedule/samgrlite.md)
 

en/readme/driver-subsystem.md

 # Driver Subsystem<a name="EN-US_TOPIC_0000001052619216"></a>
 
+-   [Overview](#section11660541593)
+-   [Architecture](#section101721227145613)
+-   [Directory Structure](#section1464106163817)
+-   [Use](#section8496817141616)
+-   [Installation](#section14778154275818)
+-   [Repositories Involved](#section134812226297)
+
 ## Overview<a name="section11660541593"></a>
 
 The OpenHarmony driver subsystem is constructed using the C object-oriented programming \(OOP\). It provides a unified driver platform through platform decoupling, kernel decoupling, and compatible kernels. This unified driver architecture platform is designed to provide a more precise and efficient development environment, where you develop a driver that can be deployed on different systems supporting HDF.
@@ -34,155 +41,52 @@ You can use DevEco to manage driver projects, generate driver templates, and man
 
 The OpenHarmony driver framework adopts the primary/secondary mode and is developed based on the framework, model, competence library, and tool.
 
-**Figure  1**  Interaction between the driver and framework<a name="fig2213154653916"></a>  
-
+**Figure  1**  Driver subsystem architecture<a name="fig1077923710115"></a>  
+![](figures/driver-subsystem-architecture.png "driver-subsystem-architecture")
 
-![](figures/en-us_image_0000001053805078.png)
-
--   Driver framework stored in the  **frameworks/core**  directory
+-   Driver framework stored in the  **framework/core**  directory
     -   Loads and starts drivers.
     -   Deploys and expands the driver framework flexibly through the object manager.
 
--   Driver models stored in the  **frameworks/model**  directory
+-   Driver model stored in the  **framework/model**  directory
     -   Provides model-based driving capabilities, such as network device models.
 
--   Driver capability library stored in the  **frameworks/ability**  directory
+-   Driver capability library stored in the  **framework/ability**  directory
     -   Provides basic driver models, such as the I/O communication model.
 
--   Driver tools stored in the  **frameworks\\tools**  directory
+-   Driver tools stored in the  **framework/tools**  directory
     -   Provides tools for HDI API conversion, and driver configuration and driver compilation.
 
--   Driver APIs stored in the  **lite\\hdi**  directory
-    -   Provides normalized driver APIs.
+-   Driver APIs stored in the  **lite/hdi**  directory
+    -   Provides standardized driver APIs.
 
--   Support stored in the  **frameworks/support**  directory
+-   Support stored in the  **framework/support**  directory
     -   Provides platform driver APIs and system APIs with normalized abstraction capabilities.
 
 
-## Directory Structures<a name="section1464106163817"></a>
-
-**Table  1**  Directory structure of the OpenHarmony driver framework
-
-<a name="table2977131081412"></a>
-<table><thead align="left"><tr id="row7977610131417"><th class="cellrowborder" valign="top" width="30.34%" id="mcps1.2.3.1.1"><p id="p18792459121314"><a name="p18792459121314"></a><a name="p18792459121314"></a>Directory</p>
-</th>
-<th class="cellrowborder" valign="top" width="69.66%" id="mcps1.2.3.1.2"><p id="p77921459191317"><a name="p77921459191317"></a><a name="p77921459191317"></a>Description</p>
-</th>
-</tr>
-</thead>
-<tbody><tr id="row17666001869"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p4667601064"><a name="p4667601064"></a><a name="p4667601064"></a>hdf</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p154741318610"><a name="p154741318610"></a><a name="p154741318610"></a>Indicates the OpenHarmony driver framework.</p>
-</td>
-</tr>
-<tr id="row17977171010144"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p2793159171311"><a name="p2793159171311"></a><a name="p2793159171311"></a>hdf/frameworks</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p879375920132"><a name="p879375920132"></a><a name="p879375920132"></a>Provides the source code to develop the driver frameworks, driver models, and capability model libraries.</p>
-</td>
-</tr>
-<tr id="row258624313915"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p858718432912"><a name="p858718432912"></a><a name="p858718432912"></a>hdf/frameworks/ability</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p1866016071012"><a name="p1866016071012"></a><a name="p1866016071012"></a>Provides functional capabilities for the driver development, such as the message model libraries.</p>
-</td>
-</tr>
-<tr id="row6978161091412"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p37931659101311"><a name="p37931659101311"></a><a name="p37931659101311"></a>hdf/frameworks/core</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p6793059171318"><a name="p6793059171318"></a><a name="p6793059171318"></a>Provides the core code to implement the OpenHarmony driver framework.</p>
-</td>
-</tr>
-<tr id="row6978201031415"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p117935599130"><a name="p117935599130"></a><a name="p117935599130"></a>hdf/frameworks/core/host</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p53051522133"><a name="p53051522133"></a><a name="p53051522133"></a>Provides functions of the driver host environment framework, including:</p>
-<p id="p168291956191214"><a name="p168291956191214"></a><a name="p168291956191214"></a>1. Loading and starting a driver, and dispatching device nodes.</p>
-<p id="p945834131310"><a name="p945834131310"></a><a name="p945834131310"></a>2. Dispatching events.</p>
-<p id="p1365513245138"><a name="p1365513245138"></a><a name="p1365513245138"></a>3. Managing the internal power status.</p>
-<p id="p113814121414"><a name="p113814121414"></a><a name="p113814121414"></a>4. Managing the common driver resource configurations.</p>
-</td>
-</tr>
-<tr id="row138241821218"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p1138321861211"><a name="p1138321861211"></a><a name="p1138321861211"></a>hdf/frameworks/core/manager</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p103831518181211"><a name="p103831518181211"></a><a name="p103831518181211"></a>Provides the management modules of the driver framework, including:</p>
-<p id="p1125114971315"><a name="p1125114971315"></a><a name="p1125114971315"></a>1. Driver API management module.</p>
-<p id="p419655510136"><a name="p419655510136"></a><a name="p419655510136"></a>2. Driver configuration management module.</p>
-<p id="p95776361144"><a name="p95776361144"></a><a name="p95776361144"></a>3. Device node management module.</p>
-<p id="p75789456140"><a name="p75789456140"></a><a name="p75789456140"></a>4. Security management module.</p>
-<p id="p183476761517"><a name="p183476761517"></a><a name="p183476761517"></a>5. Fault management module.</p>
-</td>
-</tr>
-<tr id="row116251627171512"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p76251275152"><a name="p76251275152"></a><a name="p76251275152"></a>hdf/frameworks/core/shared</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p56256278150"><a name="p56256278150"></a><a name="p56256278150"></a>Provides shared code for the host and manager.</p>
-</td>
-</tr>
-<tr id="row2306123015162"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p10306143019164"><a name="p10306143019164"></a><a name="p10306143019164"></a>hdf/frameworks/model</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p1030713021612"><a name="p1030713021612"></a><a name="p1030713021612"></a>Provides a universal framework model for drivers.</p>
-</td>
-</tr>
-<tr id="row2021312310176"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p421315312177"><a name="p421315312177"></a><a name="p421315312177"></a>hdf/frameworks/model/network</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p421313113179"><a name="p421313113179"></a><a name="p421313113179"></a>Provides network device models for drivers.</p>
-</td>
-</tr>
-<tr id="row2167642189"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p21683416181"><a name="p21683416181"></a><a name="p21683416181"></a>hdf/frameworks/support</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p71681548183"><a name="p71681548183"></a><a name="p71681548183"></a>Provides drivers with system APIs and hardware, such as GPIO, I2C, and SPI capabilities.</p>
-<p id="p19848191416195"><a name="p19848191416195"></a><a name="p19848191416195"></a>Some interfaces can be migrated across platforms.</p>
-</td>
-</tr>
-<tr id="row116634294203"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p1866392919204"><a name="p1866392919204"></a><a name="p1866392919204"></a>hdf/frameworks/support/platform</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p5663329202017"><a name="p5663329202017"></a><a name="p5663329202017"></a>Provides APIs that support the common hardware of platforms, such as GPIO, I2C, and SPI capabilities.</p>
-</td>
-</tr>
-<tr id="row193157275210"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p1331513279211"><a name="p1331513279211"></a><a name="p1331513279211"></a>hdf/frameworks/tools</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p131542762113"><a name="p131542762113"></a><a name="p131542762113"></a>Provides the driver capability libraries, such as the tool that configures and compiles the HCS (HDF Configuration Source).</p>
-</td>
-</tr>
-<tr id="row66349163223"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p2634161611224"><a name="p2634161611224"></a><a name="p2634161611224"></a>hdf/frameworks/utils</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p26341516202215"><a name="p26341516202215"></a><a name="p26341516202215"></a>Provides basic data structures and algorithms.</p>
-</td>
-</tr>
-<tr id="row1897841071415"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p16793185961315"><a name="p16793185961315"></a><a name="p16793185961315"></a>hdf/lite/adapter</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p14793959161317"><a name="p14793959161317"></a><a name="p14793959161317"></a>Adapts to kernel operation APIs and provides abstract APIs.</p>
-</td>
-</tr>
-<tr id="row16448173512518"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p644893514514"><a name="p644893514514"></a><a name="p644893514514"></a>hdf/lite/include</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p1744933517511"><a name="p1744933517511"></a><a name="p1744933517511"></a>Provides driver APIs for lightweight devices.</p>
-</td>
-</tr>
-<tr id="row192731625216"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p10281116185217"><a name="p10281116185217"></a><a name="p10281116185217"></a>hdf/lite/hdi</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p7286165524"><a name="p7286165524"></a><a name="p7286165524"></a>Provides APIs of the OpenHarmony driver.</p>
-</td>
-</tr>
-</tbody>
-</table>
-
-## Constraints<a name="section1718733212019"></a>
-
-None
-
-## Use<a name="section8496817141616"></a>
+## Directory Structure<a name="section1464106163817"></a>
 
-**Figure  2**  Interaction between the driver and framework<a name="fig1254113325118"></a>  
+```
+drivers
+├── adapter               # Adaptation code for differentiated platforms
+├── framework             # Core code of the HDF
+└── peripheral            # Peripheral driver code 
+```
 
+## Use<a name="section8496817141616"></a>
 
-![](figures/en-us_image_0000001052764349.png)
+**Figure  2**  Interaction between the driver and framework<a name="fig1356181413429"></a>  
+![](figures/interaction-between-the-driver-and-framework.png "interaction-between-the-driver-and-framework")
 
 Driver loading is mostly done by the driver framework, and you only need to register and configure required APIs. The driver framework will load and initialize the driver based on the parsing content.
 
 Driver development based on the HDF consists of the following three parts:
 
-1. Driver: develop the functions.
+1. Driver: Develop the functions.
 
-2. Information configuration: present the loading information of the driver.
+2. Information configuration: Present the loading information of the driver.
 
-3. Resource configuration: configure the hardware information of the driver.
+3. Resource configuration: Configure the hardware information of the driver.
 
 The driver mainly aims to develop the functions.
 
@@ -211,7 +115,7 @@ int32_t SampleDriverBind(struct HdfDeviceObject *deviceObject)
 }
 ```
 
-Description of Init: When devices are successfully bound, the framework calls Init to initialize the driver. After initialization is complete, the driver framework will determine whether to create external service interfaces based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device interface.
+**Init**: When devices are successfully bound, the framework calls  **Init**  to initialize the driver. After initialization is complete, the driver framework will determine whether to create external service interfaces based on the configuration file. If the driver fails to be initialized, the driver framework will automatically release the created device interface.
 
 ```
 int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
@@ -221,7 +125,7 @@ int32_t SampleDriverInit(struct HdfDeviceObject *deviceObject)
 }
 ```
 
-**Release**: When you need to uninstall a driver, the drive framework calls this function to release the driver resources. Then, other internal resources will be released.
+**Release**: When you need to uninstall a driver, the driver framework calls this function to release the driver resources. Then, other internal resources will be released.
 
 ```
 void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
@@ -235,14 +139,28 @@ void SampleDriverRelease(struct HdfDeviceObject *deviceObject)
 
 The OpenHarmony driver is mainly deployed in the kernel space using the static link mode. It is compiled and packed with the kernel subsystem and system image.
 
-**Figure  3**  OpenHarmony driver installation<a name="fig675692712"></a>  
+**Figure  3**  Driver installation<a name="fig20119729154211"></a>  
+![](figures/driver-installation.png "driver-installation")
 
+## Repositories Involved<a name="section134812226297"></a>
 
-![](figures/en-us_image_0000001053044331.png)
+**Driver subsystem**
 
-## Repositories Involved<a name="section134812226297"></a>
+hmf/drivers/framework
+
+hmf/drivers/adapter\_uhdf
+
+hmf/drivers/adapter\_khdf\_linux
+
+hmf/drivers/adapter\_khdf\_liteos
+
+hmf/drivers/peripheral\_display
+
+hmf/drivers/peripheral\_input
+
+hmf/drivers/peripheral\_wlan
 
-[drivers\_hdf\_frameworks](https://openharmony.gitee.com/openharmony/drivers_hdf_frameworks)
+hmf/drivers/peripheral\_audio
 
-[drivers\_hdf\_lite](https://openharmony.gitee.com/openharmony/drivers_hdf_lite)
+hmf/drivers/peripheral\_sensor
 

en/readme/globalization-subsystem.md

-# Globalization Subsystem<a name="EN-US_TOPIC_0000001054438981"></a>
-
-## Overview<a name="section11516137123416"></a>
-
-Users can set the locale regarding about 68 languages and regions on OpenHarmony devices. As the locale settings are synchronized from one OpenHarmony device to another during interconnection, multi-language resource backtracking and multi-language preference support should be taken into account.
-
-The global resource manager mainly provides the following capabilities:
-
--   Multi-language resource backtracking: Users in different regions have their own cultural background and use their respective native languages. During resource loading, it is critical to support multi-language locale settings, specifically, to use as few languages as possible to match users' particular cultural background.
-
--   Multi-language preference support: One of users' multiple preferred languages is selected and displayed for users \(for example, the Swiss\) who have multiple native languages.
-
-## Repositories Involved<a name="section5889165803317"></a>
-
-global\_frameworks\_resmgr\_lite
-
-global\_interfaces\_innerkits\_resmgr\_lite
-

en/readme/globalization.md

+# Globalization<a name="EN-US_TOPIC_0000001054438981"></a>
+
+-   [Introduction](#section11516137123416)
+-   [Architecture](#section8958681672)
+-   [Directory Structure](#section1121775732114)
+-   [Constraints](#section43112258019)
+-   [Repositories Involved](#section5889165803317)
+
+## Introduction<a name="section11516137123416"></a>
+
+If OpenHarmony devices and applications need to be used globally, they must meet the requirements of users in different regions on languages and cultures. The globalization subsystem provides the multi-language and multi-cultural capabilities for global use, including:
+
+-   Resource management
+
+    The subsystem loads, parses, and initializes system and application resources based on device types and system configurations, and provides APIs for obtaining resources such as character strings and images.
+
+
+-   Internationalization \(i18n\)
+
+    The subsystem provides the bottom-layer resource backtracking capabilities, with a wide array of i18n APIs for implementing functions such as date/time formatting, number formatting, and singular-plural formatting.
+
+
+## Architecture<a name="section8958681672"></a>
+
+**Figure  1**  Architecture of the globalization subsystem<a name="fig1416834516101"></a>  
+
+
+![](figures/轻鸿蒙-全球化子系统-系统架构3.png)
+
+-   The resource kit provides the capability of loading built-in resource files for applications and other subsystems. Currently, this capability is not yet open to applications and is used only for other subsystems to obtain framework resources of applications. 
+-   The i18n kit provides i18n APIs for applications and other subsystems to meet the requirements of users in different countries or regions on languages and cultures. Only the date/time, number, and singular-plural formatting capabilities are supported currently.
+-   The  **i18n.dat**  file provides cultural data specific to different languages, which ranges from date/time to number, for the i18n framework.
+
+## Directory Structure<a name="section1121775732114"></a>
+
+```
+/base/global/
+├── i18n_lite                # Code repository for the i18n framework
+│   ├──  frameworks         # Core code of the i18n framework
+│   │   ├── i18n           # i18n module
+│   │   │   ├── include   # Header files
+│   │   │   ├── src       # Implementation code
+│   │   │   └── test      # Test cases
+│   ├──  interfaces         # APIs of the i18n framework 
+│   │   ├── kits           # Application APIs
+│   │   │   ├── i18n      # C/C++ i18n APIs
+│   │   │   └── js        # C/C++ support for JavaScript APIs
+├── resmgr_lite              # Code repository for the resource management framework
+│   ├──  frameworks         # Core code of the resource management framework
+│   │   ├── resmgr         # Core code for resource parsing
+│   │   │   ├── include   # Header files
+│   │   │   └── src       # Implementation code
+│   ├──  interfaces         # APIs of the resource management framework 
+│   │   └── innerkits      # APIs of the resource management framework for other subsystems
+├── cust_lite                # Code repository for the customization framework
+│   ├── frameworks          # Core code of the customization framework
+│   │   ├── cust_lite      # Customization framework
+│   │   │   ├── src       # Implementation code
+│   │   │   └── test      # Test code
+│   ├── interfaces          # APIs of the customization framework
+│   │   └── innerkits      # APIs of the customization framework for other subsystems
+```
+
+## Constraints<a name="section43112258019"></a>
+
+None
+
+## Repositories Involved<a name="section5889165803317"></a>
+
+Globalization subsystem
+
+hmf/global/i18n\_lite
+
+hmf/global/resmgr\_lite
+
+hmf/global/cust\_lite
+

en/readme/graphics-subsystem.md

 # Graphics Subsystem<a name="EN-US_TOPIC_0000001051979319"></a>
 
+-   [Overview](#section5243712115918)
+-   [Directory Structure](#section99241319175914)
+-   [Constraints](#section37625514114)
+-   [Adding a UI Component](#section266451716115)
+-   [Repositories Involved](#section78781240113620)
+
 ## Overview<a name="section5243712115918"></a>
 
 The graphics subsystem mainly includes user interface \(UI\) components, layout, animator, font, input event, window management, rendering and drawing modules. It builds an application framework based on the LiteOS to develop  applications on Internet of Things \(IoT\) devices with small hardware resources.
@@ -15,14 +21,14 @@ Module description:
 -   Input: processes input events.
 -   Display: processes display events.
 -   Render: renders and draws components.
--   Draw2d: draws lines, rectangles, circles, arcs, images, and texts, and interconnects with software rendering and hardware acceleration.
+-   Draw2d: draws lines, rectangles, circles, arcs, images, and texts, and connects to platforms and devices with software rendering and hardware acceleration capabilities.
 -   Surface: applies for and releases shared memory.
 -   Window: manages windows, including creating, showing, hiding a window, and combining windows.
--   Adapter: interconnects with underlying interfaces of the adaptation layer.
+-   Adapter: connects to underlying interfaces of the adaptation layer.
 
 ## Directory Structure<a name="section99241319175914"></a>
 
-**Table  1**  Directory structure of source code for the graphics subsystem
+**Table  1**  Source code directory structure of the graphics subsystem
 
 <a name="table2977131081412"></a>
 <table><thead align="left"><tr id="row7977610131417"><th class="cellrowborder" valign="top" width="17.7%" id="mcps1.2.3.1.1"><p id="p18792459121314"><a name="p18792459121314"></a><a name="p18792459121314"></a>Directory</p>
@@ -43,7 +49,7 @@ Module description:
 </tr>
 <tr id="row6978201031415"><td class="cellrowborder" valign="top" width="17.7%" headers="mcps1.2.3.1.1 "><p id="p117935599130"><a name="p117935599130"></a><a name="p117935599130"></a>frameworks/ui</p>
 </td>
-<td class="cellrowborder" valign="top" width="82.3%" headers="mcps1.2.3.1.2 "><p id="p0793185971316"><a name="p0793185971316"></a><a name="p0793185971316"></a>UI module, which defines functions related to UI components, animators and fonts.</p>
+<td class="cellrowborder" valign="top" width="82.3%" headers="mcps1.2.3.1.2 "><p id="p0793185971316"><a name="p0793185971316"></a><a name="p0793185971316"></a>UI module, which defines functions related to UI components, animators and fonts</p>
 </td>
 </tr>
 <tr id="row1897841071415"><td class="cellrowborder" valign="top" width="17.7%" headers="mcps1.2.3.1.1 "><p id="p16793185961315"><a name="p16793185961315"></a><a name="p16793185961315"></a>hals</p>
@@ -63,12 +69,12 @@ Module description:
 </tr>
 <tr id="row1534591617478"><td class="cellrowborder" valign="top" width="17.7%" headers="mcps1.2.3.1.1 "><p id="p43456161472"><a name="p43456161472"></a><a name="p43456161472"></a>services/ims</p>
 </td>
-<td class="cellrowborder" valign="top" width="82.3%" headers="mcps1.2.3.1.2 "><p id="p23451616124717"><a name="p23451616124717"></a><a name="p23451616124717"></a>Input event management, including processing and distributing input events such as click and press.</p>
+<td class="cellrowborder" valign="top" width="82.3%" headers="mcps1.2.3.1.2 "><p id="p23451616124717"><a name="p23451616124717"></a><a name="p23451616124717"></a>Input event management, including processing and distributing input events such as click and press</p>
 </td>
 </tr>
 <tr id="row1044522874716"><td class="cellrowborder" valign="top" width="17.7%" headers="mcps1.2.3.1.1 "><p id="p644516283476"><a name="p644516283476"></a><a name="p644516283476"></a>services/wms</p>
 </td>
-<td class="cellrowborder" valign="top" width="82.3%" headers="mcps1.2.3.1.2 "><p id="p194451528144716"><a name="p194451528144716"></a><a name="p194451528144716"></a>Window management, including creating, managing, and combining windows.</p>
+<td class="cellrowborder" valign="top" width="82.3%" headers="mcps1.2.3.1.2 "><p id="p194451528144716"><a name="p194451528144716"></a><a name="p194451528144716"></a>Window management, including creating, managing, and combining windows</p>
 </td>
 </tr>
 <tr id="row48471930154713"><td class="cellrowborder" valign="top" width="17.7%" headers="mcps1.2.3.1.1 "><p id="p4847830134713"><a name="p4847830134713"></a><a name="p4847830134713"></a>utils</p>

en/readme/intelligent-soft-bus.md

+# Intelligent Soft Bus<a name="EN-US_TOPIC_0000001051344287"></a>
+
+-   [Overview](#section11660541593)
+-   [Directory Structure](#section1464106163817)
+-   [Constraints](#section1718733212019)
+-   [Usage](#section167037358130)
+-   [Repositories Involved](#section4499619123117)
+
+## Overview<a name="section11660541593"></a>
+
+The use of different communication modes \(such as USB, WLAN, and Bluetooth\) varies greatly and is complex. In addition, the convergence, sharing, and conflicts between communication links cannot be resolved, and communication security is difficult to guarantee. The distributed communication subsystem manages unified distributed communication between near-field devices and provides device discovery and data transmission APIs that apply to all links. Currently, the following features are available:
+
+-   Service publishing: After a service is published, peripheral devices can discover and use it.
+-   Data transmission: A session is established based on the service name and device ID to transmit data between services.
+-   Security: Communication data is encrypted.
+
+You can use APIs of the distributed communication subsystem to implement fast and secure communication between devices without caring about management of communication details, thereby achieving cross-platform development.
+
+## Directory Structure<a name="section1464106163817"></a>
+
+```
+/foundation/communication/softbus_lite/
+├── authmanager         # Device authentication mechanism and device knowledge library management
+├── discovery           # Device discovery based on CoAP
+├── os_adapter          # OS adaption code
+└── trans_service       # Authentication and transmission channels
+```
+
+## Constraints<a name="section1718733212019"></a>
+
+**Language**: C
+
+**Networking**: Devices must be in the same LAN.
+
+**Operating system**: OpenHarmony
+
+## Usage<a name="section167037358130"></a>
+
+1.  **Device discovery**
+
+When using device discovery, ensure that the device to perform a discovery and the device to discover are in the same LAN and the devices can receive packets from each other.
+
+a. After a device sends a discovery request, it uses Constrained Application Protocol \(CoAP\) to send a broadcast packet in the LAN.
+
+b. The discovered device uses the  **PublishService**  API to publish services. After receiving the broadcast packet, the device sends a CoAP unicast packet to the device that performs the discovery.
+
+c. After receiving the packet, the device that performs the discovery updates device information.
+
+**2. Transmission**
+
+The soft bus provides unified session-based transmission. Services can receive and send data or obtain basic attributes through  **sessionId**. Currently, services can determine whether to accept a received session based on the service requirements and session attributes. Currently, sessions cannot be enabled.
+
+## Repositories Involved<a name="section4499619123117"></a>
+
+communication\_softbus\_lite
+
+communication\_ipc\_lite
+
+communication\_wifi\_aware
+

en/readme/js-application-framework.md

-# JS Application Framework<a name="EN-US_TOPIC_0000001052342972"></a>
+# JS Application Framework<a name="EN-US_TOPIC_0000001078402300"></a>
+
+-   [Introduction](#section11660541593)
+-   [Directory Structure](#section1464106163817)
+-   [Constraints](#section1718733212019)
+-   [Using targets](#section1460013282612)
+-   [Using Runtime-core](#section1460223932718)
+-   [Repositories Involved](#section11703194974217)
 
 ## Introduction<a name="section11660541593"></a>
 
@@ -6,25 +13,26 @@ The JS application framework allows you to develop web-like applications across
 
 The following figure shows the framework modules.
 
-![](figures/js-framework.png)
+**Figure  1**  Framework architecture<a name="fig1771713591545"></a>  
+![](figures/framework-architecture.png "framework-architecture")
 
 ## Directory Structure<a name="section1464106163817"></a>
 
-The source code of the framework is stored in  **/foundation/ace**. The following shows the directory structure.
+The source code of the framework is stored in  **/foundation/ace/ace\_engine\_lite**. The directory structure is as follows.
 
 ```
-/foundation/ace
-├── frameworks # Framework code
-│   └── lite
-│       ├── examples # Sample code
-│       ├── include # Exposed header files
-│       ├── packages # JavaScript implementation
-│       ├── src # Source code
-│       ├── targets # Configuration file of each target device
-│       └── tools # Tool code
-├── interfaces # APIs exposed externally
-│   └── innerkits # Header files of internal subsystems
+/foundation/ace/ace_engine_lite
+├── frameworks       # Framework code
+│   ├── examples    # Sample code
+│   ├── include     # Header files
+│   ├── packages    # JavaScript implementation
+│   ├── src        # Source code
+│   ├── targets     # Configuration files of target devices
+│   └── tools       # Tool code
+├── interfaces       # APIs exposed externally
+│   └── innerkits   # Header files for internal subsystems
 │       └── builtin # JavaScript third-party module APIs exposed by the JS application framework
+└── test             # Test cases
 ```
 
 ## Constraints<a name="section1718733212019"></a>
@@ -58,54 +66,55 @@ The implementation of the JS application framework consists of the following two
 -   Native part: The native part is developed in C++ and is the main body of the framework.
 -   JavaScript part: The JavaScript part supports the runtime environment of JavaScript files, and supports the interaction between the JavaScript runtime and native framework through some global functions or objects exposed to the JavaScript engine.
 
-The framework uses feature macros to customize function code to be compiled on different platforms. The feature macros are stored in header files in  **foundation/ace/frameworks/lite/targets**. The directory structure is as follows:
+The framework uses feature macros to customize function code to be compiled on different platforms. The feature macros are stored in header files in  **foundation/ace/ace\_engine\_lite/frameworks/targets**. The directory structure is as follows:
 
 ```
-/foundation/ace/frameworks/lite/targets
+/foundation/ace/ace_engine_lite/frameworks/targets
 ├── default/
 │   └── acelite_config.h
-├── linux/ # Linux environment configuration files
+├── linux/                # Linux environment configuration files
 │   └── acelite_config.h
-├── liteos_a/ # Environment configuration files for LiteOS Cortex-A
+ ├── liteos_a/            # Environment configuration files for LiteOS Cortex-A
 │   └── acelite_config.h
-├── liteos_m/ # Environment configuration files for LiteOS Cortex-M
+├── liteos_m/             # Environment configuration files for LiteOS Cortex-M
 │   └── acelite_config.h
 ├── platform_adapter.cpp
 ├── platform_adapter.h
-└── simulator/ # Simulator environment configuration files
-    └── win/
-        └── acelite_config.h*
+└── simulator/            # Simulator environment configuration files
+    ├── acelite_config.h
+    └── BUILD.gn
 ```
 
-Note: Currently only the target compilation for LiteOS Cortex-A is open-source, which is built using Ninja \(BUILD.g\). Other targets such as simulat \(CMake+MingW\), Linux\(Ninja\), and LiteOS Cortex-M \(IAR\) are not completely open and will be gradually released after the adaptation is complete. The following examples describe the role of the **targets** directory in building different targets.
+Note: Currently only the target compilation for LiteOS Cortex-A is open-source, which is built using Ninja \(BUILD.gn\). Other targets such as simulator \(CMake+MingW\) and LiteOS Cortex-M \(IAR\) are not completely open and will be gradually released after the adaptation is complete. The following examples describe the role of the  **targets**  directory in building different targets.
 
-When compiling for different platform targets, use the  **acelite\_config.h**  file in the corresponding platform directory. You can configure the header file searching path for compilation to locate the file to use. The following takes  **ninja**  and  **cmake**  build tools as examples:
+When compiling for different platform targets, use the  **acelite\_config.h**  file in the corresponding platform directory. You can configure the header file searching path for compilation to locate the file to use. The following takes Ninja and CMake build tools as examples:
 
--   **ninja**:
+-   Ninja
 
     ```
       if (ohos_kernel_type == "liteos_a" || ohos_kernel_type== "liteos_m" ||
-          ohos_kernel_type == "liteos_riscv") { // Select different header file searching paths based on the target kernel platform.
-        include_dirs += [ "targets/liteos-a" ]
+          ohos_kernel_type == "liteos_riscv") { # Select different header file searching paths based on the target kernel platform.
+        include_dirs += [ "targets/liteos_a" ]
       } else if (ohos_kernel_type == "linux") {
         include_dirs += [ "targets/linux" ]
       }
     ```
 
 
--   **cmake**:
+-   CMake
 
     ```
     ......
-    set(ACE_LITE_CONFIG_PATH "${CMAKE_CURRENT_SOURCE_DIR}/targets/simulator/win") # Set the simulator search path to targets/simulator/win.
+    set(ACE_LITE_CONFIG_PATH "${CMAKE_CURRENT_SOURCE_DIR}/targets/simulator") # Set the simulator search path to targets/simulator.
+    set(ACE_LITE_INNERKITS_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../interfaces/innerkits/builtin")
     set(JSFWK_INCLUDE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/include")
+    set(JSFWK_INNERKITS_BUILTIN_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../../foundation/ace/ace_engine_lite/interfaces/innerkits/builtin")
     set(JSFWK_SOURCE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/src/core")
-    set(UIKIT_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../ui")
-    set(THIRTY_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../third_party")
-    set(JSFWK_SIMULATOR_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../tools/simulator")
-    set(JS_API_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../api/emui_band/MoltenCore/application/framework/ace/api")
-    set(JSFWK_SIMULATOR_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../tools/simulator")
+    set(UIKIT_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../../foundation/graphic/lite")
+    set(THIRTY_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../../third_party")
+    set(JSFWK_SIMULATOR_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../../tools/developer_tools_lite/graphic_tool/simulator")
     set(AAFWK_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../aafwk")
+    set(UTILS_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../../../../utils/native/lite")
     
     # header files
     include_directories(
@@ -121,14 +130,14 @@ When compiling for different platform targets, use the  **acelite\_config.h**  f
 
 The  **acelite\_config.h**  file is used to enable or disable the feature macros of different platforms. It can also be used to define constants for shielding platform differences. For example, platform file systems are different, and the names of some fixed directories might be different. These constants can be defined as follows:
 
--   **liteos-a/acelite\_config.h**
+-   liteos\_a/acelite\_config.h
 
     ```
     #define JS_FRAMEWORK_PATH "//system/ace/bin/"
     ```
 
 
--   **simulator/win/acelite\_config.h**
+-   simulator/acelite\_config.h
 
     ```
     #define JS_FRAMEWORK_PATH "..\\..\\..\\jsfwk\\packages\\runtime-core\\build"
@@ -140,32 +149,33 @@ The  **acelite\_config.h**  file is used to enable or disable the feature macros
 Runtime-core is a JavaScript-based simple data hijacking framework provided by the JS application framework to implement unidirectional data binding. The directory structure is as follows:
 
 ```
-/foundation/ace/frameworks/lite/packages
+/foundation/ace/ace_engine_lite/frameworks/packages
 └── runtime-core
-    ├── .babelrc # Babel configuration file
-    ├── .editorconfig # IDE configuration file
-    ├── .eslintignore # Configuration file of the ESLint tool. You can set a directory or files that will not be scanned by the ESLint tool.
-    ├── .eslintrc.js # ESLint configuration file for scanning rules
+    ├── .babelrc          # Babel configuration file
+    ├── contribution.md
+    ├── .editorconfig     # IDE configuration file
+    ├── .eslintignore     # Configuration file of the ESLint tool. You can set a directory or files that will not be scanned by the ESLint tool.
+    ├── .eslintrc.js      # ESLint configuration file for scanning rules
     ├── .gitignore
-    ├── package.json # NPM file
+    ├── package.json      # NPM file
     ├── package-lock.json # NPM dependency lock file
-    ├── .prettierrc # Configuration file for code formatting rules
-    ├── scripts # Directory for compilation scripts
-    │   ├── build.js # Compilation script
-    │   └── configs.js # Rollup configuration file
+    ├── .prettierrc       # Configuration file for code formatting rules
+     ├── scripts          # Directory for compilation scripts
+    │   ├── build.js     # Compilation script
+    │   └── configs.js   # Rollup configuration file
     ├── .size-snapshot.json
-    └── src # Source code
-        ├── core # ViewModel core implementation code
+    └── src               # Source code
+        ├── core          # ViewModel core implementation code
         │   └── index.js
         ├── index.js
-        ├── observer # Data hijacking implementation code
+        ├── observer      # Data hijacking implementation code
         │   ├── index.js
         │   ├── observer.js
         │   ├── subject.js
         │   └── utils.js
-        ├── profiler # profiler directory
+        ├── profiler      # profiler directory
         │   └── index.js
-        └── __test__ # Test cases
+        └── __test__      # Test cases
             └── index.test.js
 ```
 
@@ -177,10 +187,10 @@ The following NPM commands are supported:
 
     ```
     build/
-    ├── framework-dev.js // Framework code used in the development environment (uncompressed and obfuscated)
+    ├── framework-dev.js     // Framework code used in the development environment (uncompressed and obfuscated)
     ├── framework-dev.min.js // Framework code used in the development environment (compressed and obfuscated)
-    ├── framework-dev.js // Framework code used in the production environment (uncompressed and obfuscated)
-    ├── framework-dev.min.js // Framework code used in the production environment (compressed and obfuscated)
+    ├── framework.js         // Framework code used in the production environment (uncompressed and obfuscated)
+    └── framework.min.js     // Framework code used in the production environment (compressed and obfuscated)
     ```
 
 -   **npm run test**
@@ -190,6 +200,5 @@ The following NPM commands are supported:
 
 ## Repositories Involved<a name="section11703194974217"></a>
 
-ace\_lite\_jsfwk
+ace\_engine\_lite
 
-ace\_interfaces\_innerkits\_builtin

en/readme/kernel-subsystem.md

-# Kernel Subsystem<a name="EN-US_TOPIC_0000001051340509"></a>
-
-## Overview<a name="section12995104752113"></a>
-
-The OpenHarmony kernel is a real-time OS kernel developed by Huawei for IoT devices. It is as lightweight as RTOS and as easy-to-use as Linux.
-
-The OpenHarmony kernel includes basic kernel functions such as process and thread scheduling, memory management, IPC mechanism, and timer management.
-
-The source code of the OpenHarmony kernel consists of two repositories: the [`kernel_liteos_a`](https://gitee.com/openharmony/kernel_liteos_a) repository for Cortex-A processors and the [`kernel_liteos_m`](https://gitee.com/openharmony/kernel_liteos_m) repository for Cortex-M processors. The directory structures of the two repositories are similar. The following describes the directory structure of kernel_liteos_a.
-
-## Directory Structure<a name="section1121775732114"></a>
-
-**Table  1**  Directory structure of the OpenHarmony kernel source code
-
-<a name="table2977131081412"></a>
-<table><thead align="left"><tr id="row7977610131417"><th class="cellrowborder" valign="top" width="30.34%" id="mcps1.2.3.1.1"><p id="p18792459121314"><a name="p18792459121314"></a><a name="p18792459121314"></a>Directory</p>
-</th>
-<th class="cellrowborder" valign="top" width="69.66%" id="mcps1.2.3.1.2"><p id="p77921459191317"><a name="p77921459191317"></a><a name="p77921459191317"></a>Description</p>
-</th>
-</tr>
-</thead>
-<tbody><tr id="row17977171010144"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p2793159171311"><a name="p2793159171311"></a><a name="p2793159171311"></a>apps</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p879375920132"><a name="p879375920132"></a><a name="p879375920132"></a>User-space init and shell application program</p>
-</td>
-</tr>
-<tr id="row6978161091412"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p37931659101311"><a name="p37931659101311"></a><a name="p37931659101311"></a>arch</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p6793059171318"><a name="p6793059171318"></a><a name="p6793059171318"></a>System architecture, such as ARM</p>
-</td>
-</tr>
-<tr id="row6978201031415"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p117935599130"><a name="p117935599130"></a><a name="p117935599130"></a>bsd</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p0793185971316"><a name="p0793185971316"></a><a name="p0793185971316"></a>Code of the driver and adaptation layer module related to the FreeBSD, such as the USB module</p>
-</td>
-</tr>
-<tr id="row113263612392"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p2133163611390"><a name="p2133163611390"></a><a name="p2133163611390"></a>compat</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p1913313364399"><a name="p1913313364399"></a><a name="p1913313364399"></a>Compatibility with the kernel POSIX interfaces</p>
-</td>
-</tr>
-<tr id="row15700172218399"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p10701622113920"><a name="p10701622113920"></a><a name="p10701622113920"></a>fs</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p270110222398"><a name="p270110222398"></a><a name="p270110222398"></a>File system module, which mainly derives from the NuttX open-source project</p>
-</td>
-</tr>
-<tr id="row1897841071415"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p16793185961315"><a name="p16793185961315"></a><a name="p16793185961315"></a>kernel</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p14793959161317"><a name="p14793959161317"></a><a name="p14793959161317"></a>Kernel modules including the process, memory, and IPC modules</p>
-</td>
-</tr>
-<tr id="row172848480398"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p728414485392"><a name="p728414485392"></a><a name="p728414485392"></a>lib</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p12284154818399"><a name="p12284154818399"></a><a name="p12284154818399"></a>Kernel library</p>
-</td>
-</tr>
-<tr id="row5827141194012"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p48272110403"><a name="p48272110403"></a><a name="p48272110403"></a>net</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p28272119406"><a name="p28272119406"></a><a name="p28272119406"></a>Network module, which mainly derives from the lwip open-source project</p>
-</td>
-</tr>
-<tr id="row980916239407"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p080910232403"><a name="p080910232403"></a><a name="p080910232403"></a>platform</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p11809202324018"><a name="p11809202324018"></a><a name="p11809202324018"></a>Code for supporting different systems on a chip (SOCs), such as Hi3516DV300</p>
-</td>
-</tr>
-<tr id="row194244440402"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p0424124412401"><a name="p0424124412401"></a><a name="p0424124412401"></a>security</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p442410448409"><a name="p442410448409"></a><a name="p442410448409"></a>Code related to security features, including process permission management and virtual ID mapping management</p>
-</td>
-</tr>
-<tr id="row674312515406"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p1274395114012"><a name="p1274395114012"></a><a name="p1274395114012"></a>syscall</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p1374365134011"><a name="p1374365134011"></a><a name="p1374365134011"></a>System calls</p>
-</td>
-</tr>
-<tr id="row343553564120"><td class="cellrowborder" valign="top" width="30.34%" headers="mcps1.2.3.1.1 "><p id="p54351735114113"><a name="p54351735114113"></a><a name="p54351735114113"></a>tools</p>
-</td>
-<td class="cellrowborder" valign="top" width="69.66%" headers="mcps1.2.3.1.2 "><p id="p17435635114116"><a name="p17435635114116"></a><a name="p17435635114116"></a>Building tool as well as related configuration and code</p>
-</td>
-</tr>
-</tbody>
-</table>
-
-## Constraints<a name="section1967115154223"></a>
-
-Hi3518EV300 uses the JFFS2 file system by default, and Hi3516DV300 uses the VFAT file system by default. If other file systems need to be used, the configurations of the file systems must be added accordingly.
-
-## Usage<a name="section1821123352217"></a>
-
-For details, see  [Kernel Usage Guidelines](../kernel/Readme-EN.md).
-
-## Repositories Involved<a name="section2392425183215"></a>
-
-[drivers_liteos](https://gitee.com/openharmony/drivers_liteos)
-
-[kernel_liteos_a](https://gitee.com/openharmony/kernel_liteos_a)
-
-[kernel_liteos_a_huawei_proprietary_fs_proc](https://gitee.com/openharmony/kernel_liteos_a_huawei_proprietary_fs_proc)
-
-[kernel_liteos_m](https://gitee.com/openharmony/kernel_liteos_m)
-

en/readme/kernel.md

+# Kernel<a name="EN-US_TOPIC_0000001051340509"></a>
+
+-   [Overview](#section12995104752113)
+-   [Directory Structure](#section1121775732114)
+-   [Constraints](#section1967115154223)
+-   [Usage](#section1821123352217)
+-   [Repositories Involved](#section2392425183215)
+
+## Overview<a name="section12995104752113"></a>
+
+The OpenHarmony kernel is a real-time OS kernel developed for IoT devices. It is as lightweight as the real-time operating system \(RTOS\) and as easy-to-use as Linux.
+
+The OpenHarmony kernel provides basic kernel functions such as process and thread scheduling, memory management, inter-process communication \(IPC\) mechanism, and timer management.
+
+The source code of the OpenHarmony kernel consists of two repositories: the  **kernel\_liteos\_a**  repository for standard devices and the  **kernel\_liteos\_m**  repository for tiny and mini devices. The following describes the  **kernel\_liteos\_a**  repository.  [Figure1](#fig115631528152315)  shows the architecture of the  LiteOS Cortex-A kernel.
+
+**Figure  1**  Architecture of the OpenHarmony LiteOS Cortex-A kernel<a name="fig115631528152315"></a>  
+![](figures/architecture-of-the-openharmony-liteos-cortex-a-kernel.png "architecture-of-the-openharmony-liteos-cortex-a-kernel")
+
+## Directory Structure<a name="section1121775732114"></a>
+
+```
+/kernel/liteos_a
+├── apps                   # User-space init and shell application programs
+├── arch                   # System architecture, such as ARM
+│   └── arm                # Code for ARM architecture
+├── bsd                    # Code of the driver and adaptation layer module related to the FreeBSD, such as the USB module
+├── compat                 # Kernel API compatibility
+│   └── posix              # POSIX APIs
+├── drivers                # Kernel drivers
+│   └── char               # Character device
+│       ├── mem            # Driver for accessing physical input/output (I/O) devices
+│       ├── quickstart     # APIs for quick start of the system
+│       ├── random         # Driver for random number generators
+│       └── video          # Framework of the framebuffer driver
+├── fs                     # File system module, which mainly derives from the NuttX open-source project
+│   ├── fat                # FAT file system
+│   ├── jffs2              # JFFS2 file system
+│   ├── include            # Header files exposed externally
+│   ├── nfs                # NFS file system
+│   ├── proc               # proc file system
+│   ├── ramfs              # RAMFS file system
+│   └── vfs                # VFS layer
+├── kernel                 # Kernel modules including the process, memory, and IPC modules
+│   ├── base               # Basic kernel modules including the scheduling and memory modules
+│   ├── common             # Common components used by the kernel
+│   ├── extended           # Extended kernel modules including the dynamic loading, vDSO, and LiteIPC modules
+│   ├── include            # Header files exposed externally
+│   └── user               # Init process loading
+├── lib                    # Kernel library
+├── net                    # Network module, which mainly derives from the lwIP open-source project
+├── platform               # Code for supporting different systems on a chip (SOCs), such as Hi3516D V300
+│   ├── hw                 # Logic code related to clocks and interrupts
+│   ├── include            # Header files exposed externally
+│   └── uart               # Logic code related to the serial port
+├── platform               # Code for supporting different systems on a chip (SOCs), such as Hi3516D V300
+├── security               # Code related to security features, including process permission management and virtual ID mapping management
+├── syscall                # System calling
+└── tools                  # Building tools as well as related configuration and code
+```
+
+## Constraints<a name="section1967115154223"></a>
+
+Hi3518E V300 uses the JFFS2 file system by default, and Hi3516D V300 uses the VFAT file system by default. If other file systems need to be used, the configurations of the file systems must be added accordingly.
+
+## Usage<a name="section1821123352217"></a>
+
+For details, see the  **Usage**  section of  _LiteOS Cortex-A_  and  _LiteOS Cortex-M_
+
+## Repositories Involved<a name="section2392425183215"></a>
+
+Kernel subsystem
+
+drivers\_liteos
+
+kernel\_liteos\_a
+
+kernel\_liteos\_m
+

en/readme/lite-power-management.md

+# Lite Power Management<a name="EN-US_TOPIC_0000001083440980"></a>
+
+-   [Introduction](#section11660541593)
+-   [Directory Structure](#section19472752217)
+-   [Repositories Involved](#section63151229062)
+
+## Introduction<a name="section11660541593"></a>
+
+The lite power management subsystem provides the following capabilities:
+
+1.  Querying the battery level
+2.  Keeping the device screen always on using a lock
+
+**Figure  1**  Lite power management subsystem architecture<a name="fig106301571239"></a>  
+
+
+![](figures/en-us_image_0000001130297625.png)
+
+## Directory Structure<a name="section19472752217"></a>
+
+```
+base/powermgr/powermgr_lite
+├── interfaces		# APIs
+│   └── kits
+│       └── battery		# API for querying the battery level
+└── services		        # Services
+    ├── include
+    └── source
+```
+
+## Repositories Involved<a name="section63151229062"></a>
+
+**hmf/powermgr/powermgr\_lite**
+

en/readme/liteipc_driver.md

-# LiteIPC driver
-
-## Overview
-LiteIPC is a HarmonyOS extension to the LiteOS(a) kernel which provides a means for processes on the same device to communicate with each other.  It is a somewhat higher level mechanism than POSIX IPC methods such as message queues or shared memory, providing automatic management of resources used for IPC and control of access rights to send messages to other processes.  IPC messages are exchanged between tasks.  An IPC service is a task which has been set up to receive request type messages.  Access rights are granted to processes, if a process has access to a service then all tasks in the process are able to send requests to the service.
-
-## API
-*Application-layer Interface*  
-//foundation/communication/frameworks/ipc_lite/liteipc/include/liteipc.h  
-//foundation/communication/interfaces/kits/ipc_lite/liteipc_adapter.h  
-
-*Implementation*  
-//kernel/liteos_a/kernel/extended/liteipc/hm_liteipc.h  
-//kernel/liteos_a/kernel/extended/liteipc/hm_liteipc.c  
-
-`LITEIPC_DRIVER` specifies the name of the character device used to communicate with the LiteIPC driver (currently /dev/lite_ipc).
-
-Memory mapping allocates a memory area for storing messages received by the process' tasks.  ioctl calls to the driver before it has been memory mapped return with error **ENOMEM**.
-
-The IpcMsg structure is the basic unit of transaction for LiteIPC.
-| Member    | Type        | Description |
-| --------- | ----------- | ----------- |
-| type      | MsgType     | The message's type.  It can be one of the following values **MT_REQUEST**, **MT_REPLY**, **MT_FAILED_REPLY**, **MT_DEATH_NOTIFY**. |
-| target    | SvcIdentity | Specifies the message's recipient. |
-| flag      | IpcFlag     | Indicates whether the message can be replied to or is one-way.  It can be one of the following values **LITEIPC_FLAG_DEFAULT**, **LITEIPC_FLAG_ONEWAY**. |
-| dataSz    | UINT32      | The size of the message data in bytes pointed to by data (cannot exceed IPC_MSG_DATA_SZ_MAX, currently 1024 bytes). |
-| data      | void*       | Pointer to the message data. |
-| spObjNum  | UINT32      | The number of special objects contained in the message data (cannot exceed IPC_MSG_OBJECT_NUM_MAX). |
-| offsets   | void*       | An array of offsets relative to data pointing to SpecialObj special objects in data. |
-| code      | UINT32      | Service function code. |
-| timestamp | UINT64      | Timestamp for when the message was sent.  Automatically set by the IPC system for requests and death notifications. |
-| taskID    | UINT32      | Specifies the message's sender.  Automatically set by the IPC system. |
-| processID | UINT32      | Additional information on the message's sender.  Automatically set by the IPC system. |
-
-SpecialObj
-| Member  | Type       | Description |
-| ------- | ---------- | ----------- |
-| type    | ObjType    | The type of special object.  It can be one of the following values **OBJ_FD**, **OBJ_PTR**, **OBJ_SVC**. |
-| content | ObjContent | The special object. |
-
-ObjContent
-| SpecialObj type | Member | Type        | Description |
-| --------------- | ------ | ----------- | ----------- |
-| OBJ_FD          | fd     | UINT32      | Currently does nothing. |
-| OBJ_PTR         | ptr    | BuffPtr     | Auxiliary data to be sent (not limited by IPC_MSG_DATA_SZ_MAX). |
-| OBJ_SVC         | svc    | SvcIdentity | A service to give the recipient permission to send requests to. |
-
-`IPC_SEND_RECV_MSG` is the primary request which provides the ability to send and receive IpcMsg messages as well as free memory used by unneeded messages.  Its argument is a pointer to an IpcContent structure.
-
-IpcContent
-| Member     | Type        | Description |
-| ---------- | ----------- | ----------- |
-| flag       | UINT32      | Specifies the operation(s) to be performed.  It is the bitwise-or of one or more of the following flags **SEND**, **RECV**, **BUFF_FREE**. |
-| outMsg     | IpcMsg*     | Points to a message to be sent. |
-| inMsg      | IpcMsg*     | Points to a message that has been received. |
-| buffToFree | void*       | Points to IPC memory to be freed (a previously received message which is no longer needed). |
-
-- The **SEND** flag indicates a request to send outMsg.  Returns with error **EINVAL** if any member of the message has been given an invalid value.
-  - Sending a message with type **MT_REQUEST** returns with error **EACCES** if the task doesn't have access rights to the recipient, and **EINVAL** for an invalid recipient.  All tasks have access rights to the CMS (see IPC_SET_CMS), and to their own process' IPC services.
-  - Sending a message with type **MT_REPLY** or **MT_FAILED_REPLY** returns with error **EINVAL** if any of the following are not satisifed:
-    - buffToFree must point at the message being replied to and the **BUFF_FREE** flag must be set.
-    - The outMsg recipient (target.handle) must match the buffToFree sender (taskID).
-    - The outMsg and buffToFree timestamps must match.
-    - buffToFree must be a **MT_REQUEST** type message and cannot be marked as **LITEIPC_FLAG_ONEWAY**.
-    - buffToFree must be addressed to a service of the current process.
-
-    Trying to reply to a message sent more than LITEIPC_TIMEOUT_NS nanoseconds ago (currently 5 seconds) returns with error **ETIME**.
-
-  The message is copied into memory allocated from the IPC memory area of the process for the recipient task specified by target.handle.  Returns with error **ENOMEM** if the memory cannot be allocated.   Special objects in offsets are then processed.  **OBJ_PTR** objects' data is copied into memory allocated from the recipient's IPC memory area, discards the message and returns with error **EINVAL** if unable to allocate enough memory.  **OBJ_SVC** objects grant the recipient access rights to the service specified by the object if the sender already has access and the service is set as an IPC task (see IPC_SET_IPC_THREAD), discards the message and returns with error **EACCES** if the sender doesn't have access or **EINVAL** if the service isn't running.  Access rights are not revokable, on error any access rights granted before the special object which caused the error will remain.  The message is then added to the tail end of the recipient's list of received messages, the recipient is woken and the scheduler is called.
-- The **BUFF_FREE** flag indicates a request to free the memory used by the buffToFree message so it can be used again later for receiving messages.  Returns with error **EFAULT** if buffToFree doesn't point to a received message.  Returns with error **EINVAL** if an invalid address.
-- The **RECV** flag indicates a request to receive a message.
-  - If the **SEND** flag is set the task will wait for a message for up to LITEIPC_TIMEOUT_MS milliseconds (currently 5 seconds).  Returns with error **ETIME** on timeout.  Messages with a type of **MT_REQUEST** and **MT_REPLY** or **MT_FAILED_REPLY** type messages which don't match outMsg (matching timestamp or matching code and target.token depending on kernel configuration) are discarded (resets timer).  Sets inMsg to point at the received message and removes it from the list of received messages for **MT_REPLY** or **MT_DEATH_NOTIFY** type messages.  Note that receiving  a **MT_DEATH_NOTIFY** makes it impossible to receive the reply so send/receive requests shouldn't be used by services which might receive death notifications.  Discards the message and returns with error **ENOENT** without changing inMsg if the received message has type **MT_FAILED_REPLY**.
-  - If the **SEND** flag is not set, the task will sleep until a message with type **MT_REQUEST** or **MT_DEATH_NOTIFY** is received.  Sets inMsg to point at the received message, and removes the message from its list of received messages.  Discards **MT_REPLY** or **MT_FAILED_REPLY** type messages received while waiting.
-
-For a single request the operations are processed in the order **SEND**->**BUFF_FREE**->**RECV** with **BUFF_FREE** being processed even if there was an error in **SEND**.  Error checking on buffToFree occurs before **SEND**, an error in buffToFree will abort the request without doing anything.
-
-The `IPC_SET_IPC_THREAD` request designates the current task as the IPC task for the current process.  It can only be performed once per process.  Returns the ID of the task set as IPC task on success, subsequent calls return with error **EINVAL**.  The IPC task receives the death notifications from IPC services the process has access rights to when those services terminate.  A service which has been set as IPC task can have access rights to itself distributed through special objects without using the CMS.
-
-IPC_SEND_RECV_MSG and IPC_SET_IPC_THREAD both return with error **EINVAL** if the CMS has not been set.
-
-### Internal functions
-The first task to use the `IPC_SET_CMS` request sets itself as the system's CMS.  HarmonyOS assigns this role to the distributed scheduler's samgr.  Once set it cannot be changed.  Returns with error **EEXIST** if the CMS has already been set.  Messages are sent to the CMS by setting a recipient handle of 0.  The argument to the request specifies the maximum size of a message sent to the CMS.  Sending a message whose total size including IpcMsg data structure, data size, size of special object offsets, and data in any BuffPtr special objects exceeds the maximum size (currently 256 bytes) returns with error **EINVAL**.
-
-The `IPC_CMS_CMD` request provides various service related utility functions to the CMS.  It can only be used by the CMS, any other task making this request will get an **EACCES** error.  The argument to the request is a pointer to a CmsCmdContent structure.  The cmd member indicates the function to be performed.
-- **CMS_GEN_HANDLE** creates a service handle for the task specified by taskID member and stores the handle in the serviceHandle member.  The CMS always has access rights to any created IPC services.
-- **CMS_REMOVE_HANDLE** unregisters the service handle specified by the serviceHandle member.
-- **CMS_ADD_ACCESS** gives the task specified by the taskID member access rights to the service specified by the serviceHandle member.
-
-LiteIPC includes utility functions for the kernel to manage the IPC system.  
-`LiteIpcInit` initializes the IPC system and must be called before it can be used.  
-`LiteIpcPoolInit` performs basic initialization of a ProcIpcInfo.  Called by the kernel on task creation to initialize the IPC variables in the task's control block.  
-`LiteIpcPoolReInit` initializes the IPC variables of a child task from it's parent's task.  Called by the kernel on the creation of child tasks for basic initialization.  
-`LiteIpcPoolDelete` removes a process' IPC memory pool allocated by memory mapping and all the process' access rights.  Called by the kernel on process deletion for automatic memory and IPC resource management.  
-`LiteIpcRemoveServiceHandle` deregisters a service, clearing out the service task's message list and the list of processes with access rights to the service and sending death notification messages to any services with a set IPC task which had access.  Death notification messages are only sent once, if there is an error in the send (**ENOMEM**) the recipient will not get the death notification.  Death notification messages set target.token to the sevice handle of the service which terminated.  Called by the kernel on task deletion for automatic IPC resource management.  
-
-### Sample code
-1.  Initialization before we can use LiteIPC.
-    ```
-    #include "liteipc_adapter.h"
-    #include "liteipc.h"
-
-    int fd = open(LITEIPC_DRIVER, O_RDONLY);
-    mmap(NULL, 10000, PROT_READ, MAP_PRIVATE, fd, 0);
-    ```
-
-2.  Send a message to the CMS.  For simplicity let's say we have a primitive CMS which simply gives us access to and returns the handle of the service named in the request we send to it.
-    ```
-    #define SVCNAME "wakeup service"
-    IpcMsg msg = {
-        .type = MT_REQUEST,
-        .target = { 0, 0, 0 },
-        .flag = LITEIPC_FLAG_DEFAULT,
-        .dataSz = sizeof(SVCNAME),
-        .data = SVCNAME,
-        .spObjNum = 0,
-        .offsets = NULL
-    };
-    IpcContent content = {
-        .flag = SEND | RECV,
-        .outMsg = &msg
-    };
-
-    // Send a message to the CMS
-    if (ioctl(fd, IPC_SEND_RECV_MSG, &content) < 0) {
-        goto ERROR;
-    }
-    ```
-
-3.  Set our IPC task and send a message to the wakeup service.
-    ```
-    // Set ourselves as IPC task so we can distribute access on our own
-    int myId = ioctl(fd, IPC_SET_IPC_THREAD, 0);
-
-    struct {
-        char summary[20];
-        SpecialObj command;
-        SpecialObj svc;
-    } wakeupData = {
-        .summary = "one wakeup"
-    };
-    char commandStr[100] = "Wake me up at 9:00 in the morning.";
-    void* wakeupOffsets[2] = {
-        (void*)((uintptr_t)&wakeupData.command - (uintptr_t)&wakeupData),
-        (void*)((uintptr_t)&wakeupData.svc - (uintptr_t)&wakeupData)
-    };
-
-    // Send a request to the wakeup service and free the CMS's reply
-    content.flag = SEND | BUFF_FREE;
-    content.buffToFree = content.inMsg;
-    msg.type = MT_REQUEST;
-    // Set the recipient from the CMS' reply
-    msg.target.handle = *(uint32_t*)content.inMsg->data;
-    // Add the auxiliary data.
-    wakeupData.command.type = OBJ_PTR;
-    wakeupData.command.content.ptr.buffSz = sizeof(commandStr);
-    wakeupData.command.content.ptr.buff = commandStr;
-    // Give the wakeup service access to send us requests.
-    wakeupData.svc.type = OBJ_SVC;
-    wakeupData.svc.content.svc.handle = myId;
-    // Complete the message and send it.
-    msg.data = &wakeupData;
-    msg.dataSz = sizeof(wakeupData);
-    msg.offsets = wakeupOffsets;
-    msg.spObjNum = 2;
-    if (ioctl(fd, IPC_SEND_RECV_MSG, &content) < 0) {
-        goto ERROR;
-    }
-    ```
-
-4.  Wait for wakeup and process the wakeup message.
-    ```
-    // Enter "server" mode, wait for the service to wake us up.
-    content.flag = RECV;
-    ioctl(fd, IPC_SEND_RECV_MSG, &content);
-
-    // Free the received message
-    content.flag = BUFF_FREE;
-    content.buffToFree = content.inMsg;
-    ioctl(fd, IPC_SEND_RECV_MSG, &content);
-    ```
-
-5.  LiteIPC automatically cleans up our IPC resources when we exit, but closing the file descriptor when we're done using it is a good habit.
-    ```
-    ERROR:
-    close(fd);
-    ```

en/readme/overview.md

-# Overview<a name="EN-US_TOPIC_0000001054438981"></a>
-
-## Globalization Subsystem<a name="section11516137123416"></a>
-
-Users can set the locale regarding about 68 languages and regions on OpenHarmony devices. As the locale settings are synchronized from one OpenHarmony device to another during interconnection, multi-language resource backtracking and multi-language preference support should be taken into account.
-
-The global resource manager mainly provides the following capabilities:
-
--   Multi-language resource backtracking: Users in different regions have their own cultural background and use their respective native languages. During resource loading, it is critical to support multi-language locale settings, specifically, to use as few languages as possible to match users' particular cultural background.
-
--   Multi-language preference support: One of users' multiple preferred languages is selected and displayed for users \(for example, the Swiss\) who have multiple native languages.
-
-## Repositories Involved<a name="section5889165803317"></a>
-
-global\_frameworks\_resmgr\_lite
-
-global\_interfaces\_innerkits\_resmgr\_lite
-

en/readme/pan-sensor.md

+# Pan-Sensor<a name="EN-US_TOPIC_0000001078062432"></a>
+
+-   [Introduction](#section11660541593)
+-   [Directory Structure](#section161941989596)
+-   [Usage](#section1312121216216)
+-   [Repositories Involved](#section1371113476307)
+
+## Introduction<a name="section11660541593"></a>
+
+The pan-sensor service subsystem provides a lightweight sensor service framework, through which you can perform the following operations:
+
+-   Query the sensor list.
+-   Enable or disable a sensor.
+-   Subscribe to or unsubscribe from sensor data.
+-   Set the data reporting mode of a sensor.
+
+The following figure shows the architecture of the pan-sensor service framework.
+
+**Figure1**  Pan-sensor service architecture
+
+![](figures/en-us_image_0000001106694563.png)
+
+## Directory Structure<a name="section161941989596"></a>
+
+```
+/base/sensors
+├── sensor_lite          # Sensor directory
+│   ├── frameworks      # Framework code
+│   ├── interfaces      # Native APIs
+│   └── services        # Code of services
+└── miscdevice_lite      # Misc device directory
+```
+
+## Usage<a name="section1312121216216"></a>
+
+The following modules work cooperatively to implement pan-sensor capabilities: Sensor API, Sensor Framework, and Sensor Service.
+
+-   Sensor API: provides APIs for performing basic operations on sensors, including querying the sensor list, enabling or disabling sensors, and subscribing to or unsubscribing from sensor data.
+-   Sensor Framework: manages sensor data subscription, creates and destroys data channels, subscribes to or unsubscribes from sensor data, and implements communication with the Sensor Service module.
+-   Sensor Service: interacts with the HDF module to receive, parse, and distribute data, manages sensor services and sensor data reporting, and controls sensor permissions.
+
+## Repositories Involved<a name="section1371113476307"></a>
+
+**Pan-sensor subsystem**
+
+hmf/sensors/sensor\_lite
+
+hmf/sensors/miscdevice\_lite
+

en/readme/security-subsystem.md

 # Security Subsystem<a name="EN-US_TOPIC_0000001051982984"></a>
 
+-   [Overview](#section6309125817418)
+-   [Directory Structure](#section5614117756)
+-   [Constraints](#section14134111467)
+-   [Secure Boot](#section10750510104718)
+-   [Application Permission Management](#section20822104317111)
+-   [IPC Authentication](#section156859591110)
+-   [HUKS](#section9819115764715)
+-   [HiChain](#section19390142934814)
+-   [Application Integrity Verification](#section15468226154919)
+-   [Repositories Involved](#section1665013282177)
+
 ## Overview<a name="section6309125817418"></a>
 
-This section provides samples about how to use existing security mechanisms to improve system security features, including secure boot, application permission management, inter-process communication \(IPC\) authentication, Huawei Universal Keystore Service \(HUKS\), HiChain, and application signature verification.
+This document provides samples about how to use existing security mechanisms to improve system security features, including secure boot, application permission management, inter-process communication \(IPC\) authentication, Huawei Universal Keystore Service \(HUKS\), HiChain, and application signature verification.
 
 ## Directory Structure<a name="section5614117756"></a>
 
 ```
-security
-├── framework
-│     ├── appverify    Application signature verification
-│     ├── crypto_lite    Encryption and decryption
-│     ├── hichainsdk_lite    Device authentication
-│     ├── huks_lite    Key and certificate management
-│     ├── secure_os    Secure OS
-├── interface    Interface directory
-│     ├── innerkits    Internal kit directory
-│     │     ├── appverify    Application signature verification
-│     │     ├── crypto_lite    Encryption and decryption
-│     │     ├── hichainsdk_lite    Device authentication
-│     │     ├── huks_lite    Key and certificate management
-│     │     ├── iam_lite    Application permission management
-│     │     ├── secure_os    Secure OS
-│     ├── kits    External kit directory
-│     │     ├── iam_lite    Application permission management
-├── services    Implementation
-│     ├── iam_lite    Application permission management
-│     ├── secure_os    Secure OS
+base/security
+├── appverify
+│   └── interfaces
+│       └── innerkits
+│           └── appverify_lite  # Application signature verification APIs
+├── deviceauth
+│   ├── frameworks
+│   │   └── deviceauth_lite  # Device authentication implementation
+│   └── interfaces
+│       └── innerkits
+│           └── deviceauth_lite # Device authentication APIs
+├── huks
+│   ├── frameworks
+│   │   ├── crypto_lite  # Encryption and decryption implementation
+│   │   └── huks_lite  # Key management implementation
+│   └── interfaces
+│       └── innerkits
+│           └── huks_lite  # Key management APIs
+└── permission
+    ├── interfaces
+    │   ├── innerkits
+    │   │   └── permission_lite  # Internal APIs for permission management
+    │   └── kits
+    │       └── permission_lite  # External APIs for permission management
+    └── services
+        └── permission_lite  # Permission management service
 ```
 
 ## Constraints<a name="section14134111467"></a>
@@ -43,38 +60,40 @@ Application permissions are used to control access to system resources and featu
 
 The following table describes fields in a permission.
 
+**Table  1**  Descriptions of fields in a permission
+
 <a name="table1073153511418"></a>
-<table><thead align="left"><tr id="row11107193541417"><th class="cellrowborder" valign="top" width="22.220000000000002%" id="mcps1.1.4.1.1"><p id="p6107535141420"><a name="p6107535141420"></a><a name="p6107535141420"></a>Field</p>
+<table><thead align="left"><tr id="row11107193541417"><th class="cellrowborder" valign="top" width="22.220000000000002%" id="mcps1.2.4.1.1"><p id="p6107535141420"><a name="p6107535141420"></a><a name="p6107535141420"></a>Field</p>
 </th>
-<th class="cellrowborder" valign="top" width="35.099999999999994%" id="mcps1.1.4.1.2"><p id="p111080352143"><a name="p111080352143"></a><a name="p111080352143"></a>Value</p>
+<th class="cellrowborder" valign="top" width="35.099999999999994%" id="mcps1.2.4.1.2"><p id="p111080352143"><a name="p111080352143"></a><a name="p111080352143"></a>Value</p>
 </th>
-<th class="cellrowborder" valign="top" width="42.68%" id="mcps1.1.4.1.3"><p id="p161080358141"><a name="p161080358141"></a><a name="p161080358141"></a>Description</p>
+<th class="cellrowborder" valign="top" width="42.68%" id="mcps1.2.4.1.3"><p id="p161080358141"><a name="p161080358141"></a><a name="p161080358141"></a>Description</p>
 </th>
 </tr>
 </thead>
-<tbody><tr id="row151081735111418"><td class="cellrowborder" valign="top" width="22.220000000000002%" headers="mcps1.1.4.1.1 "><p id="p1108193521417"><a name="p1108193521417"></a><a name="p1108193521417"></a>name</p>
+<tbody><tr id="row151081735111418"><td class="cellrowborder" valign="top" width="22.220000000000002%" headers="mcps1.2.4.1.1 "><p id="p1108193521417"><a name="p1108193521417"></a><a name="p1108193521417"></a>name</p>
 </td>
-<td class="cellrowborder" valign="top" width="35.099999999999994%" headers="mcps1.1.4.1.2 "><p id="p131081435151413"><a name="p131081435151413"></a><a name="p131081435151413"></a>String</p>
+<td class="cellrowborder" valign="top" width="35.099999999999994%" headers="mcps1.2.4.1.2 "><p id="p131081435151413"><a name="p131081435151413"></a><a name="p131081435151413"></a>String</p>
 </td>
-<td class="cellrowborder" valign="top" width="42.68%" headers="mcps1.1.4.1.3 "><p id="p0108235141411"><a name="p0108235141411"></a><a name="p0108235141411"></a>Permission name</p>
+<td class="cellrowborder" valign="top" width="42.68%" headers="mcps1.2.4.1.3 "><p id="p0108235141411"><a name="p0108235141411"></a><a name="p0108235141411"></a>Permission name</p>
 </td>
 </tr>
-<tr id="row19108143516148"><td class="cellrowborder" valign="top" width="22.220000000000002%" headers="mcps1.1.4.1.1 "><p id="p51081355145"><a name="p51081355145"></a><a name="p51081355145"></a>reason</p>
+<tr id="row19108143516148"><td class="cellrowborder" valign="top" width="22.220000000000002%" headers="mcps1.2.4.1.1 "><p id="p51081355145"><a name="p51081355145"></a><a name="p51081355145"></a>reason</p>
 </td>
-<td class="cellrowborder" valign="top" width="35.099999999999994%" headers="mcps1.1.4.1.2 "><p id="p01082358147"><a name="p01082358147"></a><a name="p01082358147"></a>Multi-language string ID</p>
+<td class="cellrowborder" valign="top" width="35.099999999999994%" headers="mcps1.2.4.1.2 "><p id="p01082358147"><a name="p01082358147"></a><a name="p01082358147"></a>Multi-language string ID</p>
 </td>
-<td class="cellrowborder" valign="top" width="42.68%" headers="mcps1.1.4.1.3 "><p id="p191081235171414"><a name="p191081235171414"></a><a name="p191081235171414"></a>Purpose of requesting the permission.</p>
+<td class="cellrowborder" valign="top" width="42.68%" headers="mcps1.2.4.1.3 "><p id="p191081235171414"><a name="p191081235171414"></a><a name="p191081235171414"></a>Purpose of requesting the permission.</p>
 </td>
 </tr>
-<tr id="row13108123516145"><td class="cellrowborder" valign="top" width="22.220000000000002%" headers="mcps1.1.4.1.1 "><p id="p18109835101415"><a name="p18109835101415"></a><a name="p18109835101415"></a>used-scene{</p>
+<tr id="row13108123516145"><td class="cellrowborder" valign="top" width="22.220000000000002%" headers="mcps1.2.4.1.1 "><p id="p18109835101415"><a name="p18109835101415"></a><a name="p18109835101415"></a>used-scene{</p>
 <p id="p910913358146"><a name="p910913358146"></a><a name="p910913358146"></a>ability,</p>
 <p id="p11109235181420"><a name="p11109235181420"></a><a name="p11109235181420"></a>when</p>
 <p id="p16109193531417"><a name="p16109193531417"></a><a name="p16109193531417"></a>}</p>
 </td>
-<td class="cellrowborder" valign="top" width="35.099999999999994%" headers="mcps1.1.4.1.2 "><p id="p4109123511420"><a name="p4109123511420"></a><a name="p4109123511420"></a><strong id="b1164855864917"><a name="b1164855864917"></a><a name="b1164855864917"></a>ability</strong>: string of the component class name</p>
+<td class="cellrowborder" valign="top" width="35.099999999999994%" headers="mcps1.2.4.1.2 "><p id="p4109123511420"><a name="p4109123511420"></a><a name="p4109123511420"></a><strong id="b1164855864917"><a name="b1164855864917"></a><a name="b1164855864917"></a>ability</strong>: string of the component class name</p>
 <p id="p19109133531410"><a name="p19109133531410"></a><a name="p19109133531410"></a><strong id="b12827212500"><a name="b12827212500"></a><a name="b12827212500"></a>when</strong>: <strong id="b4362946506"><a name="b4362946506"></a><a name="b4362946506"></a>inuse</strong> and <strong id="b182868713508"><a name="b182868713508"></a><a name="b182868713508"></a>always</strong></p>
 </td>
-<td class="cellrowborder" valign="top" width="42.68%" headers="mcps1.1.4.1.3 "><p id="p31091835151413"><a name="p31091835151413"></a><a name="p31091835151413"></a>Scene where the APIs controlled by this permission are called.</p>
+<td class="cellrowborder" valign="top" width="42.68%" headers="mcps1.2.4.1.3 "><p id="p31091835151413"><a name="p31091835151413"></a><a name="p31091835151413"></a>Scene where the APIs controlled by this permission are called.</p>
 <p id="p93361156407"><a name="p93361156407"></a><a name="p93361156407"></a>This field declares what components can call the APIs controlled by this permission in the specified scene (foreground/background).</p>
 </td>
 </tr>
@@ -142,7 +161,7 @@ HUKS consists of native APIs, the hardware abstraction layer \(HAL\), and Core M
 
 1.  Native APIs are implemented using the C language to ensure consistency among all devices, and include the APIs for key generation, encryption, and decryption.
 2.  Core Module depends on the HAL and provides core functions such as encryption and decryption, signature verification, and key storage.
-3.  HAL shields differences between hardware and OSs and defines the unified APIs for HUKS. It contains platform algoIOrithm libraries, file systems, and logs.
+3.  HAL shields differences between hardware and OSs and defines the unified APIs for HUKS. It contains platform algorithm libraries, file systems, and logs.
 
 ## HiChain<a name="section19390142934814"></a>
 
@@ -180,89 +199,21 @@ During this process, the user needs to enter or scan the PIN provided by the IoT
 
 When an IoT controller and an IoT device communicate with each other after establishing a trust relationship, they authenticate each other by using the locally stored identity public key of the peer. Bidirectional identity authentication and session key exchange are performed using the Station-to-Station \(STS\) protocol during each communication. The session key is used to encrypt the data transmission channel between the devices.
 
-## Application Signature Verification<a name="section15468226154919"></a>
-
-To ensure the integrity of application content, OpenHarmony uses application signatures and profiles to manage application sources. Only pre-installed applications and applications from HUAWEI AppGallery can be installed on devices.
-
-**Basic Concepts**
-
--   **Developer certificate**
-
-
-Identity digital certificate of a developer, which is used to sign local debugging software
-
--   **Application debugging profile**
-
-
-Application debugging authorization file that allows you to install and debug an application on a specified device
-
--   **Application publishing certificate**
-
-
-Identity digital certificate of an application publisher, which is used to sign an application to be published or preset
-
--   **Application publishing profile**
-
-
-Description file of an application, which is used for reviewing an application to be published or preset
-
--   **APPID**
-
-
-Unique identifier of an application, which consists of the application bundle name and the public key of the application publishing certificate
+## Application Integrity Verification<a name="section15468226154919"></a>
 
-**How Application Signature Verification Works**
+To ensure the integrity and trustworthiness of the applications to be installed in OpenHarmony, the applications must be signed and their signatures must be verified.
 
-1.  Apply for becoming an authorized application developer on HUAWEI AppGallery.
-2.  Install and debug an application on a specified device.
-3.  Publish the application.
-
-## **Signature of an Application Published on HUAWEI AppGallery**<a name="section1273895216490"></a>
-
--   **Application debugging scenario**
-
-To develop and debug applications for OpenHarmony devices, you need to apply for becoming an authorized application developer on HUAWEI AppGallery. You need to generate a public/private key pair and upload the public key to HUAWEI AppGallery. HUAWEI AppGallery creates a developer certificate based on your identity information and the uploaded public key, and issues the certificate through the developer certificate CA. You also need to upload the application information and debugging device ID for creating an application debugging profile, which contains the HUAWEI AppGallery signature and cannot be tampered with. Upon obtaining the developer certificate and application debugging profile, you can install and debug applications signed with the private key on a specified OpenHarmony device.
-
-The application installation service of OpenHarmony verifies the application signature to ensure application integrity. In addition, the service verifies the developer certificate, application debugging profile, and the mapping between them to ensure the validity of your identity and the application.
-
-![](figures/en-us_image_0000001051282241.png)
-
--   **Application publishing**
-
-To publish applications in HUAWEI AppGallery, you need to use the application publishing certificate and profile issued by HUAWEI AppGallery to sign the applications. As shown in the following figure, the procedure of applying for the application publishing certificate and profile is similar to that of applying for the developer certificate and application debugging profile \(you can use the same public/private key pair\). Applications signed by the application publishing certificate cannot be directly installed on devices. Instead, the applications must be published in HUAWEI AppGallery for review. After the applications are reviewed and approved, HUAWEI AppGallery uses the publishing certificate to re-sign the applications. The re-signed applications can be downloaded and installed by users.
-
-The application installation service of OpenHarmony verifies the application signature to ensure application integrity. In addition, the service checks whether the signature certificate is from HUAWEI AppGallery to ensure that the application is trusted.
-
-![](figures/en-us_image_0000001051562162.png)
+In application development: After developing an application, you need to sign its installation package to ensure that the installation package is not tampered with when it is released on devices. To sign the application package, you can use the signature tools and the public key certificates and follow the signing certificate generation specifications provided by the application integrity verification module. For your convenience, a public key certificate and a corresponding private key are preset in OpenHarmony. You need to replace the public key certificate and private key in your commercial version of OpenHarmony.
 
+In application installation: The application framework subsystem of OpenHarmony installs applications. Upon receiving an application installation package, the Application Framework subsystem parses the signature of the installation package, and verifies the signature using the application integrity verification APIs. The application can be installed only after the verification succeeds. During the verification, the application integrity verification module uses the preset public key certificate to verify the signature.
 
 ## Repositories Involved<a name="section1665013282177"></a>
 
-security\_services\_app\_verify
-
-security\_frameworks\_crypto\_lite
-
-security\_services\_hichainsdk\_lite
-
-security\_services\_huks\_lite
-
-security\_frameworks\_secure\_os
-
-security\_interfaces\_innerkits\_hichainsdk\_lite
-
-security\_interfaces\_innerkits\_iam\_lite
-
-security\_interfaces\_innerkits\_huks\_lite
-
-security\_interfaces\_innerkits\_app\_verify
-
-security\_interfaces\_innerkits\_crypto\_lite
-
-security\_interfaces\_innerkits\_secure\_os
+security\_permission
 
-security\_interfaces\_kits\_iam\_lite
+security\_appverify
 
-security\_services\_iam\_lite
+security\_deviceauth
 
-security\_services\_secure\_os
+security\_huks
 

en/readme/update.md

+# Update<a name="EN-US_TOPIC_0000001051224339"></a>
+
+-   [Introduction](#section11660541593)
+-   [Directory Structure](#section1464106163817)
+-   [Constraints](#section1718733212019)
+-   [Usage](#section18867101215181)
+-   [Repositories Involved](#section68521336131912)
+
+## Introduction<a name="section11660541593"></a>
+
+Over the Air \(OTA\) provides the remote device update capability. Your devices will be able to support OTA update through secondary development on the provided APIs.
+
+By providing unified update APIs externally, the update subsystem shields the differences of underlying chips.
+
+## Directory Structure<a name="section1464106163817"></a>
+
+```
+/base/update/ota_lite
+├── frameworks         # OTA update implementation, including update package parsing, verification, writing, and updating
+├── interfaces/kits    # External APIs for OTA update
+├── hals               # Chip adaptation code, for example, Hisilicon chip adaptation code is located at device\hisilicon\hardware\update
+```
+
+## Constraints<a name="section1718733212019"></a>
+
+The update subsystem is compiled using the C language. Currently, only the Hi3518E V300, Hi3516D V300, and Hi3861 development boards are supported. If you want to support devices that use other chips, you can implement the OpenHarmony integration APIs in the  **vendor**  directory. Currently, only the full-package update is supported.
+
+## Usage<a name="section18867101215181"></a>
+
+Add the dependency on the update subsystem. The following uses the Hi3516D V300 development board as an example.
+
+-   Add  **update**  to the  **subsystem\_list field in the vendor\\hisilicon\\ipcamera\_hi3516dv300\_liteos\\config.json**  file, and add the following code under  **subsystem\_list**:
+
+    ```
+    {
+            "subsystem": "update",
+            "components": [
+              { "component": "hota", "features": [] }
+            ]
+     },
+    ```
+
+
+-   Add the  **update.json**  file to the  **build\\lite\\components**  directory.
+
+    ```
+    "components": [
+        {
+          "component": "hota",
+          "description": "",
+          "optional": "false",
+          "dirs": [
+            "base/update/ota_lite/frameworks",
+            "base/update/ota_lite/interfaces/kits"
+          ],
+          "targets": [
+            "//base/update/ota_lite/frameworks:ota_lite"
+          ],
+    ...
+    ```
+
+
+-   Add test code. For example, add  **subsystem\_test**  to the  **base\\update\\ota\_lite\\frameworks\\BUILD.gn**  file.
+
+-   Run the following commands to compile the system. You can experience the OTA update function after flashing the system to the Hi3516 chip.
+
+    ```
+    hb set
+    hb build
+    ```
+
+
+## Repositories Involved<a name="section68521336131912"></a>
+
+Update subsystem
+
+update\_ota\_lite
+
+hmf/device/hisilicon/hardware
+

en/readme/utils-library.md

-# Utils Library<a name="EN-US_TOPIC_0000001052623010"></a>
-
-## Overview<a name="section11660541593"></a>
-
-The Utils library stores basic components of OpenHarmony. These basic components are used by OpenHarmony service subsystems and upper-layer applications.
-
-The Utils library provides the following capabilities on different platforms:
-
--   LiteOS Cortex-M \(Hi3861 platform\): KV stores, file operations, timers, and IoT peripheral control
--   LiteOS Cortex-A \(Hi3516 and Hi3518 platforms\): KV stores, timers, and ACE JavaScript APIs
-
-## Directory Structure<a name="section1464106163817"></a>
-
-```
-utils/native/lite/                 # Root directory of the Utils library
-├── file                        # Implementation of the file interface
-├── hals                        # HAL directory
-│   └── file                   # Header files of the hardware abstraction layer for file operations
-├── include                     # Files of external interfaces provided by the Utils library
-├── js                          # ACE JavaScript API directory                 
-│   └── builtin					
-│       ├── common
-│       ├── deviceinfokit       # Device information kit
-│       ├── filekit             # File kit
-│       └── kvstorekit          # KV store kit
-├── kal                          # KAL directory
-│   └── timer                   # KAL implementation of the timer
-├── kv_store	                    # KV store implementation
-│   ├── innerkits               # Internal KV store interfaces
-│   └── src	                    # KV store source file
-└── timer_task                   # Timer implementation
-
-base/iot_hardware                   # IoT peripheral control
-├── frameworks          
-│   └── wifiiot_lite            # Implementation of the IoT peripheral control module
-├── hals
-│   └── wifiiot_lite            # HAL interfaces
-└── interfaces
-    └── kits                     # Interfaces of the IoT peripheral control module
-
-vendor/hisi/hi3861/hi3861_adapter/hals/iot_hardware  # HAL for IoT peripheral control
-└── wifiiot_lite                 # Implementation of the interfaces at the HAL
-```
-
-## Constraints<a name="section1718733212019"></a>
-
-The Utils library is developed using the C language.
-
-**Table  1**  Capabilities and constraints of the Utils library
-
-<a name="table1361018216112"></a>
-<table><thead align="left"><tr id="row1661115214112"><th class="cellrowborder" valign="top" width="12.659999999999998%" id="mcps1.2.5.1.1"><p id="p1261115231118"><a name="p1261115231118"></a><a name="p1261115231118"></a>Component</p>
-</th>
-<th class="cellrowborder" valign="top" width="14.78%" id="mcps1.2.5.1.2"><p id="p11611825118"><a name="p11611825118"></a><a name="p11611825118"></a>Platform</p>
-</th>
-<th class="cellrowborder" valign="top" width="32.22%" id="mcps1.2.5.1.3"><p id="p1336312010465"><a name="p1336312010465"></a><a name="p1336312010465"></a>Description</p>
-</th>
-<th class="cellrowborder" valign="top" width="40.339999999999996%" id="mcps1.2.5.1.4"><p id="p1833742934815"><a name="p1833742934815"></a><a name="p1833742934815"></a>Constraint</p>
-</th>
-</tr>
-</thead>
-<tbody><tr id="row10455841151112"><td class="cellrowborder" valign="top" width="12.659999999999998%" headers="mcps1.2.5.1.1 "><p id="p1945511415113"><a name="p1945511415113"></a><a name="p1945511415113"></a>KV store</p>
-</td>
-<td class="cellrowborder" valign="top" width="14.78%" headers="mcps1.2.5.1.2 "><p id="p668274310317"><a name="p668274310317"></a><a name="p668274310317"></a>LiteOS Cortex-M and LiteOS Cortex-A</p>
-</td>
-<td class="cellrowborder" valign="top" width="32.22%" headers="mcps1.2.5.1.3 "><p id="p193638017460"><a name="p193638017460"></a><a name="p193638017460"></a>Provides KV storage for applications.</p>
-</td>
-<td class="cellrowborder" valign="top" width="40.339999999999996%" headers="mcps1.2.5.1.4 "><p id="p1733717294484"><a name="p1733717294484"></a><a name="p1733717294484"></a>N/A</p>
-</td>
-</tr>
-<tr id="row540314384111"><td class="cellrowborder" valign="top" width="12.659999999999998%" headers="mcps1.2.5.1.1 "><p id="p134041038141112"><a name="p134041038141112"></a><a name="p134041038141112"></a>File operation</p>
-</td>
-<td class="cellrowborder" valign="top" width="14.78%" headers="mcps1.2.5.1.2 "><p id="p1766172113197"><a name="p1766172113197"></a><a name="p1766172113197"></a>LiteOS Cortex-M</p>
-</td>
-<td class="cellrowborder" valign="top" width="32.22%" headers="mcps1.2.5.1.3 "><p id="p113646084618"><a name="p113646084618"></a><a name="p113646084618"></a>Provides unified file operation interfaces that can be used on different underlying chip components.</p>
-</td>
-<td class="cellrowborder" valign="top" width="40.339999999999996%" headers="mcps1.2.5.1.4 "><p id="p83372029154819"><a name="p83372029154819"></a><a name="p83372029154819"></a>N/A</p>
-</td>
-</tr>
-<tr id="row175322121218"><td class="cellrowborder" valign="top" width="12.659999999999998%" headers="mcps1.2.5.1.1 "><p id="p1053219131219"><a name="p1053219131219"></a><a name="p1053219131219"></a>Timer</p>
-</td>
-<td class="cellrowborder" valign="top" width="14.78%" headers="mcps1.2.5.1.2 "><p id="p5406226171912"><a name="p5406226171912"></a><a name="p5406226171912"></a>LiteOS Cortex-M and LiteOS Cortex-A</p>
-</td>
-<td class="cellrowborder" valign="top" width="32.22%" headers="mcps1.2.5.1.3 "><p id="p15364170194610"><a name="p15364170194610"></a><a name="p15364170194610"></a>Provides unified timer operation interfaces that can be used on different underlying chip components.</p>
-</td>
-<td class="cellrowborder" valign="top" width="40.339999999999996%" headers="mcps1.2.5.1.4 "><p id="p633742915481"><a name="p633742915481"></a><a name="p633742915481"></a>N/A</p>
-</td>
-</tr>
-<tr id="row1821629675"><td class="cellrowborder" valign="top" width="12.659999999999998%" headers="mcps1.2.5.1.1 "><p id="p198212291879"><a name="p198212291879"></a><a name="p198212291879"></a>IoT peripheral control</p>
-</td>
-<td class="cellrowborder" valign="top" width="14.78%" headers="mcps1.2.5.1.2 "><p id="p4214123191912"><a name="p4214123191912"></a><a name="p4214123191912"></a>LiteOS Cortex-M</p>
-</td>
-<td class="cellrowborder" valign="top" width="32.22%" headers="mcps1.2.5.1.3 "><p id="p4822295710"><a name="p4822295710"></a><a name="p4822295710"></a>Provides the capability of performing operations for peripherals.</p>
-</td>
-<td class="cellrowborder" valign="top" width="40.339999999999996%" headers="mcps1.2.5.1.4 ">&nbsp;&nbsp;</td>
-</tr>
-</tbody>
-</table>
-
-## Usage<a name="section83091355151312"></a>
-
--   **KV store**
-
-    ```
-    Obtaining an interface
-    char key1[] = "rw.sys.version";
-    char value1[32] = {0};
-    int ret = UtilsGetValue(key1, value1, 32);
-    
-    Setting the interface
-    char key14[] = "key_14";
-    ret = UtilsSetValue(key14, defValue);
-    ```
-
--   **File operation**
-
-    ```
-    // open && write
-    char fileName[] = "testfile";
-    int fd = UtilsFileOpen(fileName, O_RDWR_FS | O_CREAT_FS | O_TRUNC_FS, 0);
-    printf("file handle = %d\n", fd);
-    int ret = UtilsFileWrite(fd, def, strlen(def));
-    printf("write ret = %d\n", ret);
-    
-    // stat
-    int fileLen = 0;
-    ret = UtilsFileStat(fileName, &fileLen);
-    printf("file size = %d\n", fileLen);
-    
-    // seek
-    int fd1 = UtilsFileOpen(fileName, O_RDWR_FS, 0);
-    ret = UtilsFileSeek(fd1, 5, SEEK_SET_FS);
-    printf("lseek ret = %d\n", ret);
-    char buf[32] = {0};
-    int readLen = UtilsFileRead(fd1, buf, 32);
-    ret = UtilsFileClose(fd1);
-    printf("read len = %d : buf = %s\n", readLen, buf);
-    
-    // delete
-    ret = UtilsFileDelete(fileName);
-    printf("delete ret = %d\n", ret);
-    ```
-
-
-## Repositories Involved<a name="section6250105871917"></a>
-
-iothardware\_frameworks\_wifiiot\_lite
-
-iothardware\_hals\_wifiiot\_lite
-
-iothardware\_interfaces\_kits\_wifiiot\_lite
-
-utils\_native\_lite
-