changed the folder name from figure to figures and updated links

Signed-off-by: wusongqing<wusongqing@huawei.com>

en/device-dev/get-code/gettools-acquire.md

@@ -114,7 +114,7 @@ hb set
 ```
 
 **Figure 1** Setting page<a name="fig7947145854013"></a>  
-![](figure/setting-page.png "setting-page")
+![](figures/setting-page.png "setting-page")
 
 > **NOTE**<br>
 > The mapping between the development board and the building GUI:

en/device-dev/get-code/sourcecode-acquire.md

@@ -138,7 +138,7 @@ You must install **Node.js** and HPM on your local PC. The installation procedur
     4.  Find your desired distribution and click it to view details.
 
         **Figure 1**  HPM page<a name="fig349416264520"></a> 
-        ![](figure/hpm-page.png "hpm-page")
+        ![](figures/hpm-page.png "hpm-page")
 
 2.  Learn more about the distribution.
 
@@ -147,7 +147,7 @@ You must install **Node.js** and HPM on your local PC. The installation procedur
     3.  Click **Custom** if you want to add or delete bundles of the distribution.
 
         **Figure 2**  Example distribution<a name="fig142484411121"></a> 
-        ![](figure/example-distribution.png "example-distribution")
+        ![](figures/example-distribution.png "example-distribution")
 
 3.  Customize bundles.
     1.  Access the **Custom solution** page, as shown in the following figure.
@@ -156,7 +156,7 @@ You must install **Node.js** and HPM on your local PC. The installation procedur
     4.  Click **Download**. The system generates the OpenHarmony code structure file \(for example, **my\_cust\_dist.zip**\) and saves it to your local PC.
 
         **Figure 3**  Customizing bundles<a name="fig1256020372197"></a>  
-        ![](figure/customizing-bundles.png "customizing-bundles")
+        ![](figures/customizing-bundles.png "customizing-bundles")
 
 4.  Install bundles.
     1.  Decompress the downloaded code structure file using CMD on Windows (or shell in Linux).

en/device-dev/security/security-guidelines-overall.md

@@ -9,7 +9,7 @@ This environment combines chip security and system security features with upper-
 
 **Figure 1** Security assurance
 
-![](figure/security-assurance-framework.png)
+![](figures/security-assurance-framework.png)
 
 
 ## Hardware Security
@@ -74,7 +74,7 @@ For device with 128 KB to 128 MB of memory, the OpenHarmony lite kernel is recom
 
 **Figure 2** How DAC works
 
-![](figure/how-dac-works.png)
+![](figures/how-dac-works.png)
 
 - Capability mechanism
 
@@ -103,7 +103,7 @@ OpenHarmony Universal KeyStore (HUKS) provides key and certificate management. F
 
 **Figure 3** HUKS functions
 
-![](figure/huks-functions.png)
+![](figures/huks-functions.png)
 
 The following algorithms are supported:
 
@@ -145,7 +145,7 @@ To ensure secure transmit of user data between devices, a trust relationship and
 
 **Figure 4** Process of establishing a trust relationship between devices
 
-![](figure/how-an-iot-controller-and-an-iot-device-establish-a-trust-relationship.png)
+![](figures/how-an-iot-controller-and-an-iot-device-establish-a-trust-relationship.png)
 
 
 - IoT device interconnection security

en/device-dev/security/security-privacy-protection.md

@@ -136,26 +136,26 @@ When collecting personal data, clearly and explicitly notify users of the data t
     **Figure  1**  Examples of a privacy notice and a privacy statement  
     
 
-    ![](figure/privacy-notice.png)![](figure/privacy-statement.png)
+    ![](figures/privacy-notice.png)![](figures/privacy-statement.png)
 
 -   Personal data shall be collected for specified, explicit, and legitimate purposes and not further processed in a manner that is incompatible with those purposes. If the purposes are changed or a user withdraws their consent, you shall obtain user consent again before using the data. The figures below are examples of a privacy statement update and content withdrawal, respectively.
 
     **Figure  2**  Example dialog showing a privacy statement update<a name="fig3591610523"></a>  
     
 
-    ![](figure/privacy-statement-update.png)
+    ![](figures/privacy-statement-update.png)
 
     **Figure  3**  Example dialog showing consent withdrawal<a name="fig12802152515583"></a>  
     
 
-    ![](figure/consent-withdrawal-1.png)![](figure/consent-withdrawal-2.png)
+    ![](figures/consent-withdrawal-1.png)![](figures/consent-withdrawal-2.png)
 
 -   You shall provide an entry for users to view the privacy statement. For example, you can provide an entry on the  **About**  page of your application to view the privacy statement, as shown in the following figure.
 
     **Figure  4**  Example of About page providing an entry to the privacy statement<a name="fig11392538162011"></a>  
     
 
-   ![](figure/privacy-statement-entry.png)
+   ![](figures/privacy-statement-entry.png)
 
 
 **Minimization in Data Collection and Use**
@@ -179,7 +179,7 @@ You shall obtain consent from users and comply with applicable laws and regulati
     **Figure  5**  Example dialog for requesting a sensitive permission<a name="fig20776134521514"></a>  
     
 
-    ![](figure/sensitive-permission-request.png)
+    ![](figures/sensitive-permission-request.png)
 
 -   Users shall have the right to modify or withdraw the permissions granted to your product. When a user does not agree to a permission or data collection, the user shall be allowed to use the functions irrelevant to the permission or data collection. For example, the user can refuse to grant the camera permission to social or communication apps on Smart TVs, when using product functions irrelevant to the camera, such as voice calls.
 -   In scenarios where personal data is recorded, users shall be provided with the functions of adding, deleting, modifying, and viewing personal data.

en/device-dev/subsystems/subsys-ai-aiframework-devguide.md

@@ -13,7 +13,7 @@ Under this framework, AI algorithm APIs will be standardized to facilitate distr
 The following figure shows the AI engine framework.
 
   **Figure 1** AI engine framework
-  ![en-us_image_0000001200128073](figure/en-us_image_0000001200128073.png)
+  ![en-us_image_0000001200128073](figures/en-us_image_0000001200128073.png)
 
 ### Setting Up the Environment
 
@@ -34,7 +34,7 @@ The following figure shows the code dependency between modules of the AI engine
 
   **Figure 2** Code dependency
 
-  ![en-us_image_0000001151931738](figure/en-us_image_0000001151931738.jpg)
+  ![en-us_image_0000001151931738](figures/en-us_image_0000001151931738.jpg)
 
 
 #### Recommendation: Develop plug-ins and SDKs in the directories specified by the AI engine.

en/device-dev/subsystems/subsys-application-framework-guide.md

@@ -683,15 +683,15 @@ The packing tool is generally integrated into the development tool or IDE, and y
 -   Example HAP File Structure
     -   Development view
 
-        ![](figure/en-us_image_0000001062942690.png)
+        ![](figures/en-us_image_0000001062942690.png)
 
     -   Compilation view
 
-        ![](figure/en-us_image_0000001062334618.png)
+        ![](figures/en-us_image_0000001062334618.png)
 
     -   Run the following commands to pack a HAP file using the packing tool.
 
-        ![](figure/en-us_image_0000001062476933.png)
+        ![](figures/en-us_image_0000001062476933.png)
 
         ```
         $ java -jar hmos_app_packing_tool.jar --mode hap --json-path ./config.json --assets-path ./assets/ --ability-so-path ./libentry.so --index-path ./resources.index --out-path out/entry.hap --force true

en/device-dev/subsystems/subsys-application-framework-overview.md

@@ -11,7 +11,7 @@ This section describes some basic concepts for you to better understand the Open
 The ability management framework manages running status of OpenHarmony applications.
 
 **Figure  1**  Architecture of the ability management framework<a name="fig9759195514371"></a>  
-![](figure/architecture-of-the-ability-management-framework.png "architecture-of-the-ability-management-framework")
+![](figures/architecture-of-the-ability-management-framework.png "architecture-of-the-ability-management-framework")
 
 -   **Ability**  is the minimum unit for the system to schedule applications. It is a component that can implement an independent functionality. An application can contain one or more  **Ability**  instances. There are two types of templates that you can use to create an  **Ability**  instance: Page and Service.
     -   An  **Ability using the Page template**  \(Page ability for short\) provides a UI for interacting with users.
@@ -23,14 +23,14 @@ The ability management framework manages running status of OpenHarmony applicati
 -   An  **AbilitySlice**  represents a single screen and its control logic. It is specific to Page abilities. A Page ability may contain one ability slice or multiple ability slices that provide highly relevant capabilities.
 
     **Figure  2**  Relationship between a Page ability and its ability slices<a name="fig1065819910347"></a>  
-    ![](figure/relationship-between-a-page-ability-and-its-ability-slices.png "relationship-between-a-page-ability-and-its-ability-slices")
+    ![](figures/relationship-between-a-page-ability-and-its-ability-slices.png "relationship-between-a-page-ability-and-its-ability-slices")
 
 -   **Lifecycle**  is a general term for all states of an ability, including  **INITIAL**,  **INACTIVE**,  **ACTIVE**, and  **BACKGROUND**.
 
     **Figure  3**  Lifecycle state transition of a Page ability<a name="fig56111543375"></a>  
     
 
-    ![](figure/fig1.png)
+    ![](figures/fig1.png)
 
     -   **OnStart\(\)**
 
@@ -88,7 +88,7 @@ The ability management framework manages running status of OpenHarmony applicati
 The bundle management framework is provided by OpenHarmony for you to manage application bundles.
 
 **Figure  4**  Architecture of the bundle management framework<a name="fig85883251434"></a>  
-![](figure/architecture-of-the-bundle-management-framework.png "architecture-of-the-bundle-management-framework")
+![](figures/architecture-of-the-bundle-management-framework.png "architecture-of-the-bundle-management-framework")
 
 -   **BundleKit**  includes external APIs provided by the Bundle Manager Service, including the APIs for application installation and uninstallation, bundle information query, and bundle state change listeners.
 -   The  **bundle scanning sub-module**  parses pre-installed or installed bundles on the local device and extracts information from them for the bundle management module to manage and make the information persistent for storage.
@@ -104,12 +104,12 @@ The bundle management framework is provided by OpenHarmony for you to manage app
 The Ability Manager Service and Bundle Manager Service are the core modules of the ability management framework and bundle management framework, respectively. The two system-level services are registered and discovered by using the system service framework SAMgr, and they are used by manage abilities and bundles for other processes. The Ability Manager Service and Bundle Manager Service are provided as open APIs in the AbilityKit and BundleKit.
 
 **Figure  5**  Startup of the Ability Manager Service and Bundle Manager Service<a name="fig13121104711910"></a>  
-![](figure/startup-of-the-ability-manager-service-and-bundle-manager-service.png "startup-of-the-ability-manager-service-and-bundle-manager-service")
+![](figures/startup-of-the-ability-manager-service-and-bundle-manager-service.png "startup-of-the-ability-manager-service-and-bundle-manager-service")
 
 OpenHarmony applications can be installed and started after the two services are started.
 
 **Figure  6**  Application startup process<a name="fig756104112311"></a>  
-![](figure/application-startup-process.png "application-startup-process")
+![](figures/application-startup-process.png "application-startup-process")
 
 The home screen is the first OpenHarmony application started by the Ability Manager Service. After the home screen is started, the user can touch any installed OpenHarmony application on the home screen to start the particular application. The figure above shows the interaction process of starting an installed application from the home screen.
 

en/device-dev/subsystems/subsys-boot-faqs.md

@@ -7,7 +7,7 @@
 During system startup, the error message "\[Init\] InitReadCfg, parse failed! please check file /etc/init.cfg format." is displayed, and the startup is interrupted, as shown in the following figure.
 
 **Figure  1**  Error information<a name="fig15217111545118"></a>  
-![](figure/error-information.png "error-information")
+![](figures/error-information.png "error-information")
 
 **Cause**
 

en/device-dev/subsystems/subsys-boot-init-sysparam.md

@@ -8,7 +8,7 @@ The parameter management module, namely, sysparam, provides an easy-to-use key-v
 
 Figure 1 System parameter operation primitives
 
-![System parameter operation primitives](figure/system-parameter-operation-primitives.png)
+![System parameter operation primitives](figures/system-parameter-operation-primitives.png)
 
 **Table 1** Description of system parameter operation primitives
 | Operation Primitive| Description|
@@ -96,7 +96,7 @@ Each subsystem defines the system parameters of its own modules, including the s
 
   **Figure 2** UGO rule structure
 
-  ![UGO rule](figure/dac-definition.png)
+  ![UGO rule](figures/dac-definition.png)
 
 - SELinux policy for system parameter configuration
 

en/device-dev/subsystems/subsys-boot-overview.md

@@ -7,7 +7,7 @@ The following figure shows the context structure of the Startup subsystem.
 
   **Figure 1** Context structure of the Startup subsystem
 
-  ![context-structure-of-the-Startup-subsystem](figure/context-structure-of-the-Startup-subsystem.png)
+  ![context-structure-of-the-Startup-subsystem](figures/context-structure-of-the-Startup-subsystem.png)
 
 When the system is powered on, the kernel loads and starts services and applications as follows:
 
@@ -426,7 +426,7 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
 
   1. Burn the original image, and view the device information of each partition.
 
-      ![Original partition](figure/ABStartup_1.png)
+      ![Original partition](figures/ABStartup_1.png)
 
       Use the original image to construct images of the partitions used for partition A/B booting, and test the partition A/B booting function.
       - Copy the **system** and **vendor** images, and add the suffix **\_b** to them.
@@ -441,16 +441,16 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
 
       1. Run the **cat /proc/cmdline** command. If the command output contains **bootslot=2**, the system supports partition A/B booting.
 
-          ![cmdline](figure/ABStartup_2.png)
+          ![cmdline](figures/ABStartup_2.png)
       2. Run the **param get ohos.boot.bootslot** command. If the command output contains **2**, the **bootslot** information is successfully written to the **parameter.txt**.
 
       3. Run the **ls -l /dev/block/by-name** command. If the command output contains **system_b** and **vendor_b**, device nodes are successfully created in partition B.
 
-          ![Device information](figure/ABStartup_3.png)
+          ![Device information](figures/ABStartup_3.png)
 
       4. Run the **df -h** command to check the partitions mounted to the system.
 
-          ![Partition information](figure/ABStartup_4.png)
+          ![Partition information](figures/ABStartup_4.png)
 
           As shown in the figure, partition **mmcblk0p6** is mounted to the root file system (represented by a slash), and partition **mmcblk0p7** is mounted to **/vendor**. Based on the command output in step 3, **mmcblk0p6** is the **system** partition, and **mmcblk0p7** is the **vendor** partition. That is, the mounted partitions are the default partitions, that is, **system** and **vendor** partitions without suffixes. In other words, partition A is the default partition.
 
@@ -458,21 +458,21 @@ Currently, OpenHarmony supports booting from partitions A and B (active and stan
 
           1) Run the **partitionslot setactive 2** command to set the slot of the active partition to **2**, that is, the slot of partition B.
 
-          ![Partition slot configuration](figure/ABStartup_5.png)
+          ![Partition slot configuration](figures/ABStartup_5.png)
 
           2) Run the **partitionslot getslot** command to check the configured slot.
 
-          ![View Slot](figure/ABStartup_6.png)
+          ![View Slot](figures/ABStartup_6.png)
 
           If **current slot** is **2**, the slot of the active partition is successfully set to **2**.
 
           3) Upon restarting, run the **df -h** command to check the partitions mounted to the system.
           According to the command output, partition **mmcblk0p11** is mounted to the root file system, and partition **mmcblk0p12** is mounted to **/vendor**.
 
-          ![Mounting information](figure/ABStartup_7.png)
+          ![Mounting information](figures/ABStartup_7.png)
 
           4) Run the **ls -l /dev/block/by-name** command again.
 
-          ![New device information](figure/ABStartup_8.png)
+          ![New device information](figures/ABStartup_8.png)
 
           **mmcblk0p11** corresponds to **system_b**, and **mmcblk0p12** corresponds to **vendor_b**. That is, the system is successfully booted from partition B.

en/device-dev/subsystems/subsys-build-all.md

@@ -57,7 +57,7 @@ The Compilation and Build subsystem implements compilation and packaging through
 
 **Figure 1** Relationships between product, subsystem, component, and module
 
-![](figure/product_subsystem_component_module_relationships.png)
+![](figures/product_subsystem_component_module_relationships.png)
 
 The relationships between the product, subsystem, component, and module are as follows:
 
@@ -73,7 +73,7 @@ A product, component, and module can be built, but a subsystem cannot. The figur
 
 **Figure 2** Build process
 
-![Build process](figure/build_process.png)
+![Build process](figures/build_process.png)
 
 1. Run **hb set** to set the product to build.
 

en/device-dev/subsystems/subsys-build-gn-kconfig-visual-config-guide.md

@@ -40,13 +40,13 @@ Kconfig visual configuration has the following advantages:
    menuconfig kconfig
    ```
 
-   ![Kconfig example](./figure/kconfig_interface.png)
+   ![Kconfig example](./figures/kconfig_interface.png)
 
 4. Set parameters.
 
    For details about the parameters, see productdefine/common/base/base_product.json.
 
-   ![Setting parameters](./figure/kconfig_set_parameters.gif)
+   ![Setting parameters](./figures/kconfig_set_parameters.gif)
 
 5. Select and configure the component.
 
@@ -56,13 +56,13 @@ Kconfig visual configuration has the following advantages:
 
    3. When setting `feature`, use commas (,) to separate multiple values.
 
-      ![Selecting a component](./figure/kconfig_select_component.gif)
+      ![Selecting a component](./figures/kconfig_select_component.gif)
 
 6. Save the settings.
 
    Press **S** to save the settings. You can set the name of the file to generate. By default, a file named `.config` file is generated in the current directory.
 
-   ![Save settings](./figure/kconfig_save.png)
+   ![Save settings](./figures/kconfig_save.png)
 
 7. Generate the OpenHarmony style configuration file.
 

en/device-dev/subsystems/subsys-build-module.md

@@ -369,7 +369,7 @@ The following figure shows the logic for adding a module. Generally, you need to
 
 - Add a module to a new subsystem.
 
-  ![](figure/module_addition_process.png)
+  ![](figures/module_addition_process.png)
 
 **Adding a Module to an Existing Component**
 

en/device-dev/subsystems/subsys-build-reference.md

@@ -6,7 +6,7 @@ When adding a module, you must declare its dependencies in **BUILD.gn**. **deps*
 
 **Dependency Types**
 
-![Dependency Types](figure/dependency_types.png)
+![Dependency Types](figures/dependency_types.png)
 
 The dependency between modules can be classified into **deps** (left in the figure above) and **external_deps** (right in the figure above).
 
@@ -187,7 +187,7 @@ The **out/rk3568/.ninja_log** file records the build start time and end time (ms
 
 The four columns are start time, end time, modified timestamp (mtime), and command hash from left to right.
 
-![Ninja_Trace](figure/Ninja_Trace.png)
+![Ninja_Trace](figures/Ninja_Trace.png)
 
 You can graphically display the build time as follows:
 

en/device-dev/subsystems/subsys-data-relational-database-overview.md

@@ -25,7 +25,7 @@ The OpenHarmony RDB provides a common operation interface (**RdbStore**) for ext
 
 **Figure 1** How RDB works
 
-![](figure/en-us_image_0000001115980740.png)
+![](figures/en-us_image_0000001115980740.png)
 
 ## Default Settings
 - The default database logging mode is write-ahead logging (WAL).

en/device-dev/subsystems/subsys-data-storage-overview.md

@@ -22,7 +22,7 @@ When obtaining a **Preferences** instance, the application can read data from or
 **Figure 1** How lightweight data store works<a name="fig1657785713509"></a>
 
 
-![](figure/en-us_image_0000001192123772.png)
+![](figures/en-us_image_0000001192123772.png)
 
 ## Constraints
 

en/device-dev/subsystems/subsys-dfx-faultlogger.md

@@ -18,7 +18,7 @@ The following figure shows the process of handling a process crash based on the
 
   **Figure 1** Process crash handling flowchart
 
-![process_crash_handling](figure/process_crash_handling.png)
+![process_crash_handling](figures/process_crash_handling.png)
 
 1. After the signal processor is installed, the **DFX_SignalHandler** function detects and responds to the process crash exception signal.
 

en/device-dev/subsystems/subsys-dfx-hitracechain.md

@@ -16,24 +16,24 @@ HiTraceChain can be used for the following purposes:
 
     **Figure  1**  Use cases of HiTraceChain
     
-    ![](figure/use-cases-of-hitrace.png "use-cases-of-hitrace")
+    ![](figures/use-cases-of-hitrace.png "use-cases-of-hitrace")
 
 
 ### Usage Example
 
 **Figure  2**  Service calling process \(inter-device and inter-process synchronous call\) 
 
-![](figure/service-calling-process-(inter-device-and-inter-process-synchronous-call).png "service-calling-process-(inter-device-and-inter-process-synchronous-call)")
+![](figures/service-calling-process-(inter-device-and-inter-process-synchronous-call).png "service-calling-process-(inter-device-and-inter-process-synchronous-call)")
 
 1. Display the call relationship in the service process, analyze key paths and function dependency, and determine the time consumption and call frequency at each call point to detect performance bottlenecks.
 
    **Figure  3**  Service calling process
 
-   ![](figure/service-calling-process.png "service-calling-process")
+   ![](figures/service-calling-process.png "service-calling-process")
 
    **Figure  4**  Time delay in the service calling process
 
-   ![](figure/time-delay-in-the-service-calling-process.png "time-delay-in-the-service-calling-process")
+   ![](figures/time-delay-in-the-service-calling-process.png "time-delay-in-the-service-calling-process")
 
 2.  Add  **traceid**  to logs and events automatically to facilitate comprehensive analysis and quick fault location.
 
@@ -444,7 +444,7 @@ Extended communication mechanisms can also follow this implementation.
 
 **Figure  5**  Call chain tracing in synchronous communication
 
-![](figure/call-chain-tracing-in-synchronous-communication.png "call-chain-tracing-in-synchronous-communication")
+![](figures/call-chain-tracing-in-synchronous-communication.png "call-chain-tracing-in-synchronous-communication")
 
 The process is as follows:
 

en/device-dev/subsystems/subsys-dfx-hitracemeter.md

@@ -79,7 +79,7 @@ HiTraceMeter provides the hitrace CLI tool for capturing trace data in user mode
 
 
 
-![HiTraceMeter architecture](figure/HiTraceMeter.png)
+![HiTraceMeter architecture](figures/HiTraceMeter.png)
 
 
 

en/device-dev/subsystems/subsys-dfx-hiview.md

@@ -10,7 +10,7 @@ Hiview is a module that provides toolkits for device maintenance across differen
 
 **Figure 1** Data interaction between Hiview modules
 
-![Hiview_module_data_interaction](figure/Hiview_module_data_interaction.png)
+![Hiview_module_data_interaction](figures/Hiview_module_data_interaction.png)
 
 1. The service process calls the event logging API to report logged event information and writes the information to the node file.
 2. SysEventSource of the Hiview process asynchronously reads event information from the node file and distributes the event to SysEventPipeline for processing.

en/device-dev/subsystems/subsys-graphics-animation-guide.md

@@ -181,6 +181,6 @@ A UI animator is implemented by calling the callback function you set for each t
 4.  Click the buttons in the lower part of the following figure to verify that the animation effects are as expected.
 
     **Figure  1**  Animator effect<a name="fig17833181682317"></a>  
-    ![](figure/animator-effect.gif "animator-effect")
+    ![](figures/animator-effect.gif "animator-effect")
 
 

en/device-dev/subsystems/subsys-graphics-common-guide.md

@@ -3,7 +3,7 @@
 Common components inherit from the base class  **UIView**. Child components cannot be added to common components, such as buttons, images, and labels.
 
 **Figure  1**  Tree structure of common components<a name="fig3386518305"></a>  
-![](figure/tree-structure-of-common-components.png "tree-structure-of-common-components")
+![](figures/tree-structure-of-common-components.png "tree-structure-of-common-components")
 
 **UIView**  is a base class of the following components:  **UIAbstractProgress**,  **UIArcLabel**,  **UIButton**,  **UICanvas**,  **UILabel**, and  **UIImageView**.  **UIBoxProgress**  and  **UICircleProgress**  inherit from  **UIAbstractProgress**.  **UILabelButton**  and  **UIRepeatButton**  inherit from  **UIButton**.  **UIImageAnimatorView**  and  **UITextureMapper**  inherit from  **UIImageView**.
 
@@ -107,7 +107,7 @@ Common components inherit from the base class  **UIView**. Child components cann
 4.  Verify that the button is clicked and its size increases gradually, as shown in the following figure.
 
     **Figure  2**  Effect of clicking a  **UIButton**<a name="fig1921134162020"></a>  
-    ![](figure/effect-of-clicking-a-uibutton.gif "effect-of-clicking-a-uibutton")
+    ![](figures/effect-of-clicking-a-uibutton.gif "effect-of-clicking-a-uibutton")
 
 
 ## UIImageView<a name="section19523161611259"></a>
@@ -193,7 +193,7 @@ Common components inherit from the base class  **UIView**. Child components cann
 3.  Verify that the  **UIImageView**  component is adaptive to the image.
 
     **Figure  3**  Image auto-adaption effect<a name="fig64751933144118"></a>  
-    ![](figure/image-auto-adaption-effect.png "image-auto-adaption-effect")
+    ![](figures/image-auto-adaption-effect.png "image-auto-adaption-effect")
 
 
 ## How to Develop \(Tile Mode\)<a name="section97178160421"></a>
@@ -221,7 +221,7 @@ Common components inherit from the base class  **UIView**. Child components cann
 4.  Verify that the tile mode has been enabled for the  **UIImageView**.
 
     **Figure  4**  Image tile effect<a name="fig1075461619424"></a>  
-    ![](figure/image-tile-effect.png "image-tile-effect")
+    ![](figures/image-tile-effect.png "image-tile-effect")
 
 
 ## UILabel<a name="section16588132012911"></a>
@@ -379,7 +379,7 @@ Common components inherit from the base class  **UIView**. Child components cann
 
 4.  Verify the label size and display effect, as shown in the following figure.
 
-    ![](figure/en-us_image_0000001051782526.png)
+    ![](figures/en-us_image_0000001051782526.png)
 
 
 ## How to Develop \(Background Color and Opacity\)<a name="section933360204510"></a>
@@ -408,7 +408,7 @@ Common components inherit from the base class  **UIView**. Child components cann
 
 4.  Verify that the background color of the label is  **Gray**, as shown in the following figure.
 
-    ![](figure/en-us_image_0000001052582522.png)
+    ![](figures/en-us_image_0000001052582522.png)
 
 
 ## How to Develop \(Letter Spacing\)<a name="section19447826124518"></a>
@@ -437,7 +437,7 @@ Common components inherit from the base class  **UIView**. Child components cann
 
 4.  Verify that the letter spacing is  **5**  pixels on the label, as shown in the following figure.
 
-    ![](figure/en-us_image_0000001052942531.png)
+    ![](figures/en-us_image_0000001052942531.png)
 
 
 ## How to Develop \(Size-Adaptive Mode\)<a name="section101711842154617"></a>
@@ -468,7 +468,7 @@ Regarding too long text, the size of a label can be automatically adjusted based
 
 4.  Verify that the label size adapts to the text, as shown in the following figure.
 
-    ![](figure/en-us_image_0000001052782555.png)
+    ![](figures/en-us_image_0000001052782555.png)
 
 
 ## How to Develop \(Ellipsis Mode\)<a name="section1249519410471"></a>
@@ -499,7 +499,7 @@ In  ellipsis  mode, an ellipsis \(...\) is displayed at the end of the label if
 
 4.  Verify that the ellipsis mode has taken effect on the label, as shown in the following figure.
 
-    ![](figure/en-us_image_0000001052662559.png)
+    ![](figures/en-us_image_0000001052662559.png)
 
 
 ## How to Develop \(Scrolling Mode\)<a name="section15643122618478"></a>
@@ -531,6 +531,6 @@ In scrolling mode, long text is kept scrolling on a screen to bring the entire t
 
 4.  Verify that the text is scrolling on the label, as shown in the following figure.
 
-    ![](figure/20200721-223604(espace).gif)
+    ![](figures/20200721-223604(espace).gif)
 
 

en/device-dev/subsystems/subsys-graphics-container-guide.md

@@ -3,7 +3,7 @@
 Container components are capable of containing UI components and inherit from  **UIViewGroup**. Components that are commonly used and need to contain child components are placed in the container class inheritance structure. For example, you need to call the  **Add**  function to add information such as time statistics and icons to  **UIAnalogClock**.
 
 **Figure  1**  Structure of common container components<a name="fig1931013319293"></a>  
-![](figure/structure-of-common-container-components.png "structure-of-common-container-components")
+![](figures/structure-of-common-container-components.png "structure-of-common-container-components")
 
 The  **RootView**,  **UIAbstractScroll**, and  **UIPicker**  components inherit from  **UIViewGroup**, and the  **UIList**,  **UIScrollView**, and  **UISwipeView**  components inherit from  **UIAbstractScroll**.
 
@@ -14,7 +14,7 @@ The  **RootView**,  **UIAbstractScroll**, and  **UIPicker**  components inherit
 **UIViewGroup**  is a base class for container components. For example, you can call the functions in this class to add, remove, and insert container components. Also, you can call the  **Add**  function to add child components for a container component. You need to set the position information for child components in a common container component. The position information is the coordinates relative to those of their parent component. The following figure shows the tree structure of components.
 
 **Figure  2**  Component tree structure<a name="fig279970183012"></a>  
-![](figure/component-tree-structure.png "component-tree-structure")
+![](figures/component-tree-structure.png "component-tree-structure")
 
 As shown in the figure, the container component  **ViewGroup1**  and the component  **View1**  are added to  **RootView**, the component  **View2**  and the container component  **ViewGroup2**  are added to  **ViewGroup1**, and then the component  **View3**  \(as a sibling of  **View1**\) is also added to  **ViewGroup1**.
 
@@ -117,7 +117,7 @@ As shown in the figure, the container component  **ViewGroup1**  and the compone
 4.  The following figure shows the effect of adding view instances to a  **ViewGroup**.
 
     **Figure  3**  Effect of adding view instances to a ViewGroup<a name="fig33041856184219"></a>  
-    ![](figure/effect-of-adding-view-instances-to-a-viewgroup.png "effect-of-adding-view-instances-to-a-viewgroup")
+    ![](figures/effect-of-adding-view-instances-to-a-viewgroup.png "effect-of-adding-view-instances-to-a-viewgroup")
 
 
 ## UIScrollView<a name="section174961523161315"></a>
@@ -231,5 +231,5 @@ scroll->Add(button2);
 ```
 
 **Figure  4**  Scrolling effect in both horizontal and vertical directions<a name="fig99017432114"></a>  
-![](figure/scrolling-effect-in-both-horizontal-and-vertical-directions.gif "scrolling-effect-in-both-horizontal-and-vertical-directions")
+![](figures/scrolling-effect-in-both-horizontal-and-vertical-directions.gif "scrolling-effect-in-both-horizontal-and-vertical-directions")
 

en/device-dev/subsystems/subsys-graphics-layout-guide.md

@@ -87,7 +87,7 @@ Layout container components consist of basic view classes. You can set the view
     **Figure  1**  Horizontal swiping effect of  **UISwipeView**<a name="fig933862020262"></a>  
     
 
-    ![](figure/en-us_image_0000001053247975.gif)
+    ![](figures/en-us_image_0000001053247975.gif)
 
 
 ##   Development Procedure \(Cyclic Horizontal Swiping\)<a name="section1976914915282"></a>
@@ -121,7 +121,7 @@ Layout container components consist of basic view classes. You can set the view
     **Figure  2**  Cyclic horizontal swiping effect of  **UISwipeView**<a name="fig1533902042618"></a>  
     
 
-    ![](figure/en-us_image_0000001053207924.gif)
+    ![](figures/en-us_image_0000001053207924.gif)
 
 
 ## GridLayout<a name="section46819199173"></a>
@@ -201,6 +201,6 @@ Layout container components consist of basic view classes. You can set the view
 4.  Verify the layout of buttons, as shown in the following figure.
 
     **Figure  3**  Setting a 2x2 grid and adding four buttons in a layout<a name="fig898719135314"></a>  
-    ![](figure/setting-a-2x2-grid-and-adding-four-buttons-in-a-layout.png "setting-a-2x2-grid-and-adding-four-buttons-in-a-layout")
+    ![](figures/setting-a-2x2-grid-and-adding-four-buttons-in-a-layout.png "setting-a-2x2-grid-and-adding-four-buttons-in-a-layout")
 
 

en/device-dev/subsystems/subsys-multimedia-camera-overview.md

@@ -97,7 +97,7 @@ It is considered good practice that you understand the following concepts before
         **Figure  1**  Sequence diagram for creating a camera<a name="fig9882125184416"></a>  
         
 
-        ![](figure/en-us_image_0000001054101094.png)
+        ![](figures/en-us_image_0000001054101094.png)
 
     1.  Taking a video/Previewing
 
@@ -106,7 +106,7 @@ It is considered good practice that you understand the following concepts before
         **Figure  2**  Sequence diagram for recording/previewing<a name="fig642695404512"></a>  
         
 
-        ![](figure/en-us_image_0000001054421113.png)
+        ![](figures/en-us_image_0000001054421113.png)
 
 
 

en/device-dev/subsystems/subsys-security-devicesecuritylevel.md

@@ -16,11 +16,11 @@ The Device Security Level Management (DSLM) module is introduced to manage the s
 
   The following figure shows the OpenHarmony security architecture.
 
-  ![OpenHarmony system security architecture](figure/ohos_system_security_architecture.png)
+  ![OpenHarmony system security architecture](figures/ohos_system_security_architecture.png)
 
   The above figure shows the typical security architecture for a single device. The architecture may vary depending on the risk level as well as the software and hardware resources of the device. The security capabilities of OpenHarmony devices are classified into five levels from SL1 to SL5, based on the industry standard security classification model and actual OpenHarmony service scenarios and device types. In the OpenHarmony ecosystem, higher security levels include all the capabilities of lower security levels by default. The figure below shows the security levels of OpenHarmony devices.
 
-  ![OpenHarmony device security levels](figure/ohos_device_security_level.png)
+  ![OpenHarmony device security levels](figures/ohos_device_security_level.png)
 
   - SL1: SL1 is the lowest security level of OpenHarmony devices. Usually equipped with a lightweight operating system and low-end microprocessors, such devices implement simple services and do not need to process sensitive data. SL1 devices are required to support software integrity protection and eliminate common errors. Devices that cannot meet the requirements of SL1 can only be controlled by OpenHarmony devices. They cannot control OpenHarmony devices for more complex service collaboration.
 

en/device-dev/subsystems/subsys-security-huks-guide.md

@@ -43,7 +43,7 @@ HUKS supports key lifecycle management, which covers the following:
 The following uses the key generation process as an example to describe communication between the HUKS Service and HUKS Core. Other key operations are similar.
 The upper-layer application invokes the HUKS Service through the key management SDK. The HUKS Service invokes the HUKS Core, which invokes the key management module to generate a key. The HUKS Core uses a work key derived from the root key to encrypt the generated key and sends the encrypted key to the HUKS Service. The HUKS Service stores the encrypted key in a file.
 
-![](figure/HUKS-GenerateKey1.png)
+![](figures/HUKS-GenerateKey1.png)
 
 ### Constraints
 
@@ -51,13 +51,13 @@ The upper-layer application invokes the HUKS Service through the key management
 
 * The certificate chain returned by **HuksHdiAttestKey** must be in the sequence of the application certificate, device certificate, CA certificate, and root certificate, with the certificate length added before each certificate. The certificate chain and its length are assembled in the binary large object (BLOB) format. If you want to define the certificate format, the format must be the same as that parsed by the server.
 
-![CertChain format](figure/HUKS-CertChain.png)
+![CertChain format](figures/HUKS-CertChain.png)
 
 * The key returned by the API must be assembled into a **KeyBlob** based on the key storage status. For details about the APIs that must comply with this constraint, see [Available APIs](#available-apis).
 
    The **KeyBlob** stores both the key and its attributes. The figure below shows the **KeyBlob** structure. For details about how to construct a **KeyBlob**, see [hks_keyblob.c/HksBuildKeyBlob](https://gitee.com/openharmony/security_huks/blob/master/services/huks_standard/huks_engine/main/core/src/hks_keyblob.c).
 
-![KeyBlob format](figure/HUKS-KeyBlob.png)
+![KeyBlob format](figures/HUKS-KeyBlob.png)
 
 ## Development Guidelines
 

en/device-dev/subsystems/subsys-security-sigverify.md

@@ -14,7 +14,7 @@ An unsigned HAP is in  **.zip**  format and consists of a file block, central di
 After the HAP is signed, a signature block is added between the file block and the central directory. The integrated signature block consists of a profile signature block, HAP signature block, and signature header. The following figure shows the structure of a signed HAP.
 
 **Figure  1**  Structure of a signed HAP<a name="fig157962397486"></a>  
-![](figure/structure-of-a-signed-hap.png "structure-of-a-signed-hap")
+![](figures/structure-of-a-signed-hap.png "structure-of-a-signed-hap")
 
 The signature verification process consists of three steps: HAP signature verification, profile signature verification, and profile content verification.
 

en/device-dev/subsystems/subsys-sensor-overview.md

@@ -7,7 +7,7 @@ The pan-sensor service subsystem provides a lightweight sensor service framework
 
   **Figure 1** Sensor service framework
 
-  ![](figure/en-us_image_0000001077724150.png)
+  ![](figures/en-us_image_0000001077724150.png)
 
 - Sensor API: provides APIs for performing basic operations on sensors, including querying the sensor list, subscribing to or unsubscribing from sensor data, and executing control commands. This module makes application development simpler.
 

en/device-dev/subsystems/subsys-tel-guide.md

@@ -379,7 +379,7 @@ The following table describes the API for reporting modem events.
    **Figure  1** Time sequence of API calling for an outgoing call<a name="fig494mcpsimp"></a>  
    
 
-    ![](figure/en-us_image_0000001171507146.png)
+    ![](figures/en-us_image_0000001171507146.png)
 
    When an application initiates an outgoing call, RIL Adapter receives a call request, and the **hril** layer invokes the **ReqDial\(\)** function. In **ReqDial\(\)**, the data passed by the Telephony Service is encapsulated as an AT command and sent to the modem. After executing the dial command, the modem reports the execution result to RIL Adapter through **OnCallReport\(\)**.
 
@@ -458,7 +458,7 @@ The following table describes the API for reporting modem events.
    **Figure  2** Time sequence of API calling for an incoming call<a name="fig556mcpsimp"></a>  
    
 
-    ![](figure/en-us_image_0000001214727595.png)
+    ![](figures/en-us_image_0000001214727595.png)
 
    The **g\_reader** thread cyclically reads the messages reported by the modem. When the modem receives an incoming call event, it actively reports the information about the incoming call.
 

en/device-dev/subsystems/subsys-tel-overview.md

@@ -20,7 +20,7 @@ This document provides development guidelines related to the telephony subsystem
 **Figure  1**  RIL Adapter architecture<a name="fig196mcpsimp"></a>  
 
 
-![](figure/en-us_image_0000001210683929.png)
+![](figures/en-us_image_0000001210683929.png)
 
 As shown in the preceding figure, RIL Adapter is logically divided into three layers:  **hril\_hdf**,  **hril**, and  **vendorlib**.
 

en/device-dev/subsystems/subsys-usbservice-overview.md

@@ -29,7 +29,7 @@ USB devices are classified into two types: USB host and USB device. On OpenHarmo
 The USB subsystem logically consists of three parts: USB API, USB Service, and USB HAL. The following figure shows how the USB service is implemented.
 
   **Figure 1** USB service architecture
-  ![USB service architecture](figure/en-us_image_0000001267088285.png)
+  ![USB service architecture](figures/en-us_image_0000001267088285.png)
 
 - USB API: provides USB APIs that implement various basic functions, for example, query of the USB device list, bulk data transfer, control transfer, and right management.