Android Building System Analysis

Android Building System Analysis

By thinker
2 columns
Keywords:

Android


Coding

To learn about a system, I often start with makefile or building system,
What are the elements of system composition? What is the final structure of the project? For android
And 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 for the module and package. Each module/package
There will be an android
. Mk.
The defined module refers to the native code of the system.
The application is named package.

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

Boardconfig. mk is designed for the product motherboard, such as Driver selection,
Set. * <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 updating the entire source.
Tree. One_shot_makefile this makefile variable/parameter is used to implement this function. Use
The method is to specify the change data as the module's android
. Mk.

• Make one_shot_makefile = <path to androiod. mk>

 

If create_module_info_file is specified, the building system configures all module information
Listed in $ (product_out)/module-info.txt cases.

• Make create_module_info_file = true

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

Host_build_type and target_build_type specify building system to generate binary
For debug or release. By setting these two variables, debugging information can be generated.
Binry.

• Debug
• Release

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

 

Goals

Generally, the entire android
The system uses the droid goal. Droid produces
Complete system, including bootloader, kernel, system program, module, 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 progress of each step in the process.
Command.

 

 

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 plugin check developer settings (buildspec. mk ),
And check the actual conditions to determine the specific and specific targets.

Build/CORE/config. mk also depends on the relational data to determine the relational data during the release. Like Compiler
The number of router operators, flags, Lex, and YACC.

The product-related settings are handled by build/CORE/product_config.mk,
Use the macro plugin provided by build/CORE/product. mk. Root volume androidproduct. mk content,
Product_config.mk decided

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

 

Token set by product

Android
Product settings are based on build/target/product/androidproduct. mk and
Androidproduct. mk under the vendor sub-project. Building system goes through the find command,
Find all possible androidproduct. mk. Definition in androidproduct. mk
The number of product_makefiles, listing all makefiles that define the product.
These makefiles are custom products. Product-related records are saved
Changes in the form of products. <path of makefile>. <variable>. And change the makefile path
There are products changes. Therefore, through products, you can obtain all product links/name links,
And obtain the content through the 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: the module/package is related to macro. Retrieve and query metrics.
Module/package definition, which disperses the android
. Mk statement case.
Build/CORE/Main. mk use the find command to find all android
. Mk,
And there will be subdir_makefiles changes in the path. Finally, include these cases.

These android
. Mk will include variable build_shared_library, build_package, etc,
The makefile that matches the target. These makefiles will change android
. Mk content of definition, saved
All_modules. <path of Android
. Mk>. <variable> format. For example,
Android
. Mk defines local_module_suffix and changes
All_modules. <path of Android
. Mk>. local_module_suffix. Android
. Mk Road,
It is stored in the all_modules variable.

Search android
The path of. mk is basically the entire source tree. But the goal,
Select a specific category only. For example, the SDK only needs android
. Mk.

 

Board level settings

Settings related to the main board of the target platform, such as the license settings and driver used, or whether the license is required
Bootloader and kernel are all set in boardconfig. mk. In the same way, each worker Motherboard
There can be different settings, there are boardconfig. mk under different targets, and find the following example using find targets:

• 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 divided into multiple
Product. One target_device, usually only one boardconfig. mk.
Boardconfig. mk will be directly included in the name space of the building system.
Therefore, the enable/disable of some modules can be mapped in boardconfig. mk to different
Motherboard.

 

Rules

Define android in Module
In. mk, you can define the tag of the module, local_module_tags,
To classify these modules.
Each product can specify the required tag (product_tags) so that the building system
Only the modules that mark these tags are displayed. In build/CORE/Main. mk, all tags
Modules of are collected as all_default_installed_modules and include
Build/CORE/makefile processing.

Build/CORE/makefile generates rule for these modules and generates the goal depend on
These rule causes these modules to be overwritten.

 

Conclusion

Android
In fact, the building system is not so complex. After learning about it, it is not so easy to modify.
However, some methods of GNU make use less intuitive usage in the building system,
Make the building system development environment understand. However, you can overcome it with a little thought.

 

From: http://www.codemud.net /~ Thinker/gingin_cgi.py/show_id_doc/393