[Excerpt] Android Building System Analysis

ArticleDirectory

• Goals
• Initialization and zookeeper
• Token set by product
• Module-based fetch
• Board level settings
• Rules

To learn about a system, I often start with makefile or building system to understand the system composition elements? What is the final structure of the project? For Android, I am no exception. Through understanding the building system, we can know how to add, modify, and delete programs, and maintain integrity.

Set hosts

Android building system includes important configuration items,

• Android. mk
• Androidproducts. mk
• Target _ <OS>-<arch>. mk, host _ <OS>-<arch>. mk and <OS>-<arch>. mk
• Boardconfig. mk
• Buildspec. mk

Android. mk is the specification of the module and package. Each module/package has an android. mk. The defined module refers to the native code of the system, which is equivalent to the Android Application written in Java as a package.

Configure the product according to androidproducts. mk. Product is the version of a specific system. Different products are installed in different versions, and different applications are installed in different versions. A product can be used to generate a specific rule system for a specific case.

Boardconfig. mk is used to set the product motherboard, such as Driver selection and configuration. * <OS>-<arch>. mk is the role system and CPU architecture of the Scheduler for the selected instance.

Buildspec. mk is located in the source root directory and is set for the attacker. For example, you can select the product, platform, and module/package outside the region to be produced here.

Metric data

Build/envsetup. Sh is used as a mm command, which allows you to write a single module without setting up the entire source tree. One_shot_makefile this makefile variable/parameter is used to implement this function. The usage is to specify the Android. mk of the module as the variable number when making the statement.

• Make one_shot_makefile = <path to androiod. mk>

Through the definition of create_module_info_file, the building system will list all module information in the $ (product_out)/module-info.txt case.

• Make create_module_info_file = true

Set build_tiny_android = true. The building system generates a simple image to improve the availability of the hardware. This function is used to transplant early segments for fast bring up.

Host_build_type and target_build_type specify the building system to generate the binary program for debug or release. The binry that includes debug information can be generated by setting these two variables.

• Debug
• Release

These records can also be set in buildspec. mk to avoid re-specifying the issue.

Goals

Generally, the entire android system uses the droid goal. Droid produces a complete system, including bootloader, kernel, system program, model, and application program.

The showcommands and droid functions are the same, but the droid shows the commands used during the upload process. Through the showcommands goal, the building system diagram shows the detailed commands for each step in the process.

Makefile Process

• Initialize correlation data
• Both Environment and target environments
• Determine the target product
• Configure the product
• Configure the platform architecture based on the project specified by the product
  • Optional toolchain
  • Specify the maximum number of bytes (* <OS>-<arch>. mk)
• Clear a category
• Set/check version of zookeeper
• Retrieve all boardconfig. mk Samples
• Set all modules.
• Root setting, produce required Rule
• Produce Image

The above processes are arranged by build/CORE/Main. mk.

Initialization and zookeeper

Run build/CORE/config. mk. Build/CORE/envsetup. mk check the developer's settings (buildspec. mk) and check the development environment to determine whether the project is displayed or not.

Build/CORE/config. mk also depends on the relational data to determine the relational data during the release. Such as the number of compiler routers, flags, Lex, and YACC.

The product-related settings are handled by build/CORE/product_config.mk, and macro injection provided by build/CORE/product. mk is used. The content of the Root parameter androidproduct. mk is determined by product_config.mk.

• Product_tags
• Ota_public_keys
• Product_policy
• ......

Token set by product

Android product is set to androidproduct. mk under build/target/product/androidproduct. mk and vendor. Building system goes through the find command to find all possible androidproduct. mk. Define the product_makefiles variable in androidproduct. mk, and list all makefiles that define the product. These makefiles are custom products. Product-related parameters are saved as changes in the form of products. <path of makefile>. <variable>. And there is a products change in the makefile path. Therefore, you can obtain all the product path records/NAME records through products, and obtain the content through changes in the form of products. <path of makefile>. <variable>.

Module-based fetch

Module refers to native code components, while Java application is called as package. Build/CORE/definitions. mk define the macro relation between the module/package, and retrieve and query the module/package definition cases. The Android. mk examples of various source tree scenarios are scattered. Build/CORE/Main. mk use the find command to find all android. mk in these sub-projects and store the path in subdir_makefiles changes. Finally, include these cases.

These Android. mk include definitions to build makefiles that match the build_shared_library and build_package values. These makefiles change the content defined by Android. mk and are saved as all_modules. <path of Android. mk>. <variable>. For example, Android. mk defines local_module_suffix and becomes all_modules. <path of Android. mk>. local_module_suffix. The android. mk path is stored in the all_modules variable.

The path of search Android. mk is basically the entire source tree. However, depending on the specific goal, the selection is only for specific targets. For example, the SDK only needs Android. mk under a specific category.

Board level settings

The settings related to the main board of the target platform, such as the usage of license, driver, and other functions, or whether the Bootloader and kernel need to be installed are all in the boardconfig. set in MK. In the same way, the motherboard can have different settings for each region. There are boardconfig. mk in different regions, and find the following example in find region:

• Build/target/board/$ (target_device)/boardconfig. mk
• Vendor/*/$ (target_device)/boardconfig. mk

Target_device is defined by product, so the same boardconfig. mk can be used by multiple products. One target_device, usually only one boardconfig. mk. Boardconfig. mk will be directly included in the name space of the building system. Therefore, enable/disable of some modules can be mapped to different motherboard in boardconfig. mk.

Rules

In the module definition Definition Android. mk, you can define the module tag and local_module_tags to classify these modules. Each product can specify the required tag (product_tags) so that the building system can only mark the modules of these tags. In build/CORE/Main. mk, all modules that indicate specific tags are collected as all_default_installed_modules and include the build/CORE/makefile processing.

Build/CORE/makefile generates rule for these modules, and generates goal depend on these rule for the image, so that these modules are wrongly formed.

Conclusion

In fact, the building system of Android is not so dynamic. After learning about it, it is not so easy to modify. However, some usage methods of GNU make, the building system uses some usage that is not so direct, so that the building system has knowledge. However, you can overcome it with a little thought.