1# Component-based Startup 2## Overview 3### Function Introduction 4Builds four basic component images and provides component-based directories, including: 5- System component: **system** 6- Common product configuration component: **sys_prod** 7- Chipset component: **chipset** 8- Hardware configuration component: **chip_prod** 9 10The subsystem mainly provides two functions: ensure that system parameters and startup scripts can be scanned and initialized by component priority, and complete the independent compilation and building of system and chipset components. 11### Basic Concepts 12- Basic Components 13 14 **system**: serves as the file system mount point, and functions as a platform service irrelevant to the chipset and hardware. 15 **sys_prod**: extends and customizes capabilities of the **system** component, bears product-level differentiated capabilities, and stores product-related configuration files. 16 **chipset**: serves as the file system mount point, and offers unified hardware abstraction services for the **system** component. Same chipset platforms can use the same **chipset** component. 17 **chip_prod**: offers specific hardware capabilities of a peripheral board and product-level differentiated hardware configurations, as well as chipset-related configuration files. 18 19- Component-based compilation and building 20 21 Use **target_cpu** to specify the instruction set of the **system** component. Use **inherit** to inherit the common component set such as **base**, **headless**, and **rich**. Use **subsystems** to define more components for a specific product type. 22 23- System parameters and startup scripts scanned and initialized by component priority 24 25 System parameters and startup scripts include the CFG configuration file, PARAM file, sandbox JSON configuration file, and module plugin library file of a service. The following are related files that are in ascending order in terms of priority: **/system**, **/chipset**, **/sys_prod**, and **/chip_prod**. A file with a higher priority replaces and updates the configuration file with a lower priority. 26 27 28### Constraints 29Standard and small systems support component-based compilation and building. System parameters and startup scripts are scanned and initialized by component priority. 30 31## Vibrator Development 32### When to Use 33Component-based startup enables vendors and hardware platforms to quickly develop products through modular combination. The following uses RK3568 as an example to illustrate component-based startup in detail. 34 35### Building and Compiling RK3568 Based on Components 36The **//vendor/hihope/rk3568/config.json** configuration file implements components required for building the product: 37 38 { 39 "product_name": "rk3568", 40 "device_company": "rockchip", 41 ... 42 "target_cpu": "arm", 43 ... 44 "inherit": [ "productdefine/common/inherit/rich.json", "productdefine/common/inherit/chipset_common.json" ], 45 "subsystems": [ 46 { 47 "subsystem": "security", 48 "components": [ 49 { 50 "component": "selinux", 51 "features": [] 52 } 53 ] 54 } 55 ... 56 } 57 58The example above indicates the product name, chipset vendor, supported instruction set, and more. **inherit** indicates the dependent common components, and **subsystems** indicates other components. 59The following illustrates the configuration of the **system** component in the **//productdefine/common/inherit/rich.json** file. The **system** component can also include **base.json** (list of minimal components that all products must contain) and **headless.json** (list of minimal components with which products having no UI allow for application installation and management). 60 61 { 62 "version": "3.0", 63 "subsystems": [ 64 { 65 "subsystem": "arkui", 66 "components": [ 67 { 68 "component": "ace_engine", 69 "features": [] 70 }, 71 { 72 "component": "napi", 73 "features": [] 74 } 75 ] 76 }, 77 { 78 "subsystem": "account", 79 "components": [ 80 { 81 "component": "os_account", 82 "features": [] 83 } 84 ] 85 }, 86 ... 87 } 88 89### Scanning and Initializing System Parameters by Priority 90The following are CFG files of a service, which are in ascending order in terms of priority: **/system/etc**, **/system/etc/init**, and **/chipset/etc**. A file with a higher priority replaces and updates the configuration file with a lower priority. The following uses **/system/etc/init/camera_service.cfg** as an example: 91 92 { 93 "services" : [{ 94 "name" : "camera_service", 95 "path" : ["/system/bin/sa_main", "/system/profile/camera_service.xml"], 96 "uid" : "cameraserver", 97 "gid" : ["system", "shell"], 98 "secon" : "u:r:camera_service:s0", 99 "permission" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"], 100 "permission_acls" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"] 101 }] 102 } 103 104**/chipset/etc/camera_B_service.cfg** exists at the same time. 105 106 { 107 "services" : [{ 108 "name" : "camera_service", 109 "path" : ["/system/bin/sa_main", "/system/profile/camera_B_service.xml"], 110 "uid" : "cameraserver", 111 "gid" : ["system", "shell"], 112 "secon" : "u:r:camera_service:s0", 113 "permission" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"], 114 "permission_acls" : ["ohos.permission.GET_SENSITIVE_PERMISSIONS"], 115 "disabled" : 1 116 }] 117 } 118 119Based on the priority requirement, the **path** attribute of the **camera_service** service will be replaced by **["/system/bin/sa_main", "/system/profile/camera_B_service.xml"]** that has a higher priority, and the **disabled** attribute is added. 120