Android compilation system

I. MAIN PROCESS OF makefile

The following main processes are arranged in build/CORE/Main. mk.

L initialization related parameter settings (buildspec. mk, envsetup. mk, config. mk)

L check the compilation environment and target environment

L determine the target product

L read product configuration information and target platform information

L clear the output directory

L check the version number

L read the configuration of the Board

L read the configurations of all modules

L generate necessary rules based on the configuration (build/CORE/makefile)

L generate an image

 

Main configuration file:

Build/CORE/config. mk Summary of config

Build/CORE/envsetup. mk generate dir config and so on

Build/target/product config

Build/target/board config

Build/CORE/Combo build flags config

Here we will explain the board and product here. Borad is mainly designed for hardware chip configurations, such as whether to provide certain hardware functions, such as GPU, or whether the chip supports floating point operations. Product is a pointer to the current chip configuration. It defines the personalized configuration of the product to be produced. It mainly refers to the APK configuration and the product to which the APK will be included, which APK is not provided in the current product.
Config. MK is a general concept that defines the host tools required for module compilation and how to compile various modules. For example, built_prebuilt defines how to compile the pre-compilation module. Envsetup. mk mainly reads some variables written by envsetup. Sh to the environment variables to configure the output directory during the compilation process. Combo mainly defines the compiler and compilation options that combine host and target.

The configuration section mainly completes the following tasks:

A) configuration based on Android products (product config): select to build the installed running program (User package)

B) set target and other related variables target_arch, target_ OS, target_build_type, target_prebuilt_tag

C) Set host and other variables such as host_ OS, host_arch, host_build_type, and host_prebuilt_tag according to the compiling environment.

D) Compile the toolchain required for running the program on the target and set the compilation parameters, such as the Linux-arm-CC, cflag, and include directories.

E) tool chain and compilation parameter settings required to compile the host to run the program.

This section briefly introduces the main components and relationships of the configuration part of the android build system.

 

 

Ii. initialization parameter settings

In Main. mk, after a few variables in the main compilation path are set, go to config. mk:

-------------- Config. mk --------------

It sets a series of paths for the source file, including the path of the header file, library file, service, and API compilation tool. (First 36 rows)

Starting from line 40, define the generation rules of some compilation modules:

Except that clear_vars is a clear local variable, all other variables correspond to a module generation rule. Each local module will include one of them to generate the target module.

 

 

 

Return to config. mk, and then try to read the settings of buildspec. mk:

 

As mentioned in the comment, we will try to find buildspec. mk. If the file does not exist, we will automatically use the environment variable settings. If it is still undefined, we will build it according to the default settings of arm.

Here, buildspec. mk can be created by yourself, or the buildspec. mk. default under the original build/can be directly named as buildspec. mk and moved to the root directory.

In fact, the buildspec. mk configuration is blocked. We can open and modify some variables as needed. Here we can add our target product information:

Ifndef target_product

Target_product: = generic_x86

Endif

And output directory settings:

Out_dir: = $ (topdir) generic_x86

 

3. Read product settings

Go back to config. mk and set global variables to envsetup. mk:

-------------- Envsetup. mk --------------

Most of the functions are defined in build/envsetup. Sh.

First, set the version information (line 11). In build/CORE/version_defaults.mk, define the platform version, SDK version, and product version. We can use build_number as the version information of our product generic_x86, of course, you can also customize a version variable.

Return to envsetup. mk and set the default target product (generic). Here, because target_product is set in buildspec. mk, the variable value is generic_x86.

Then read the settings of the product (41 rows). The specific implementation is in build/CORE/product_config.mk, and then enter the product. MK, from build/target/product/androidproducts. MK reads product_makefiles. These makefiles define the product independently, and generic_x86 should also add a MAKEFILE file generic_x86.mk. In generic_x86.mk, we can add the product_packages to be compiled.

Generic_x86.mk:

 

4. Read boardconfig

Go back to config. mk, (row 114) and search for all boardconfig. mk, mainly including the following:

 

The target_device here is generic_x86, which means to define our own product generic_x86, we need to add our own directory generic_x86 under build/target/board to load our board configuration.

In boardconfig. mk, determine whether to compile information such as Bootloader and kernel.

 

5. Read all modules

After the global variable configuration is completed, return to main. mk and check the compilation tool and version immediately. If the error occurs, the compilation will be interrupted.

Row 3 contains the definitions. mk file, which defines many variables and functions for Main. mk. Line 3 of Main. mk reads all android. mk files:

 

Include $ (one_shot_makefile)

This one_shot_makefile is assigned in the mm (envsetup. mk) function mentioned above:

One_shot_makefile = $ M make-C $ t files $ @

 

Return to main. mk and save the path of Android. mk in all the subdirectories retrieved by traversal to the subdir_makefiles variable (row 470 in Main. mk ):

We can see android in the root directory of each module in package/apps. MK, which defines the tag of the current local module: local_module_tags. Android uses this tag to determine which local modules will be compiled into the system, use Product and local_module_tags to determine which application packages will be compiled into the system. (As mentioned earlier, you can also use buildspec. mk to compile modules into the system)

This process starts in row 445 of Mian. mk. Finally, the module path to be compiled is packaged into all_default_installed_modules (row 602 ):

 

6. Generate the corresponding rules and generate the image

All the preparations to be configured have been completed. Next we will decide how to generate the image output file. This process is actually processed in build/CORE/makefile.

In this section, the generation of imgis is defined, including ramdisk.img?userdata.img=system.img=update.zip and recover. IMG. For details about the corresponding rules, refer:

Http://img154.ph.126.net/5ekAHoRqfPf17ALmDJGDYA==/2269251262242871911.png

When make include all files are parsed to all make files, the system will look for rules to generate corresponding targets and generate their dependencies in sequence until all satisfied modules are compiled, then use the corresponding tool to package it into the corresponding IMG.

 

Specific make operations:

Complete Compilation

Enter the make command in the root directory to start full compilation. The default target of this command is droid.

That is to say, you can input the make droid actually executed by make. Next, let's take a look at the last part of the main. mk file, which has many pseudo targets, such as SDK, clean, and clobber. These will not be executed under the default make droid command. We can add these labels after make to implement some operations separately. For example, if you enter make SDK, the corresponding SDK of this version will be generated. If you enter make clean, the output of the last compilation will be cleared.

Module Compilation

Sometimes we only modify a certain module and hope to compile this module separately Instead of re-compiling it completely. At this time, we need to use several bash helper functions provided in build/envsetup. Sh.

Run the following command in the source code root directory:

. Build/envsetup. Sh (. There is a space behind it)

In this way, there are several more available commands.

You can use the help command to view the help information:

The commands for module compilation are tapas, M, mm, and mmm.

1. Tapas -- sets the Build Environment Variables interactively.

Input: tapas

Step 1: select the target device:

Step 2: select the code format:

Step 3: select the product platform:

 

Note: In Google source code, the default value is generic, and we need to modify it to generic_x86 for our own products.

Modify the corresponding code in the chooseproduct () function in build/envsetup. Sh.

2. M, mm, and mmm use the make command of independent modules.

Use the HELP command to view the functions of several commands.

For example, we modified the code of the camera module. Now we need to re-compile this module separately. In this case, we can use the mmm command, follow the path of the specified module (note the module root directory ).

The details are as follows:

Mmm packages/apps/camera/

In order to directly test the changes, the system. IMG needs to be regenerated after compilation.

Run make Snod.

Compile an image file separately

Generally, after compilation, three important image files are generated: ramdisk. IMG, system. IMG, and userdata. IMG. Of course, we can compile these three goals separately:

Make ramdisk -- ramdisk. img

Make userdataimage -- userdata. img

Make systemimage -- system. img