From http://blog.csdn.net/yili_xie/archive/2009/11/30/4906865.aspx
Compile scripts and System Variables
Build/envsetup. Sh script analysis
Before compiling the source code, you usually need to execute ../build/envsetup. Sh in the top-level directory of the android source code to use
The script envsetup. Sh defines some functions:
Function help ()
Function get_abs_build_var ()
Function get_build_var ()
Function check_product ()
Function check_variant ()
Function setpaths ()
Function printconfig ()
Function set_stuff_for_environment ()
Function set_sequence_number ()
Function settitle ()
Function choosetype ()
Function chooseproduct ()
Function choosevariant ()
Function tapas ()
Function choosecombo ()
Function print_lunch_menu ()
Function lunch ()
Function gettop
Function M ()
Function findmakefile ()
Function mm ()
Function Mmm ()
Function Croot ()
Function PID ()
Function gdbclient ()
Function jgrep ()
Function cgrep ()
Function resgrep ()
Function getprebuilt
Function tracedmdump ()
Function runhat ()
Function getbugreports ()
Function startviewserver ()
Function stopviewserver ()
Function isviewserverstarted ()
Function smoketest ()
Function runtest ()
Function runtest_py ()
Function godir ()
Choosecombo command analysis:
Function choosecombo ()
{
Choosesim $1
Echo
Echo
Choosetype $2
Echo
Echo
Chooseproduct $3
Echo
Echo
Choosevariant $4
Echo
Set_stuff_for_environment
Printconfig
}
The following options are selected in sequence:
Build for the simulator or the device?
1. Device
2. Simulator
Which wocould you like? [1]
Build Type choices are:
1. Release
2. Debug
Which wocould you like? [1]
Product choices are:
1. emulator
2. Generic
3. Sim
4. Littleton
You can also type the name of a product if you know it.
Which wocould you like? [Littleton]
Variant choices are:
1. User
2. userdebug
3. Eng
Which wocould you like? [ENG] user
After the default option is selected, the following will appear:
Target_product = Littleton
Target_build_variant = user
Target_simulator = false
Target_build_type = release
Target_arch = arm
Host_arch = x86
Host_ OS = Linux
Host_build_type = release
Build_id =
============
Function chooseproduct () function analysis:
Choices = ('/bin/ls build/target/board/*/boardconfig. mk vendor/*/boardconfig. mk 2>/dev/null ')
Read the board configuration file boardconfig. mk In the build/target/board/* directory.
Read the board configuration file boardconfig. mk in the directory of Vendor /*/.
Choices value:
Build/target/board/emulator/boardconfig. mk
Build/target/board/generic/boardconfig. mk
Build/target/board/SIM/boardconfig. mk
Vendor/Marvell/Littleton/boardconfig. mk
After:
For choice in $ {choices [@]}
Do
# The product name is the name of the directory containing
# The makefile we found, above.
Prodlist = ($ {prodlist [@]} 'dirname $ {choice} | xargs basename ')
Done
The prodlist value is:
Emulator generic SIM Littleton
Select the following menu:
Product choices are:
1. emulator
2. Generic
3. Sim
4. Littleton
If you select 4, The target_product value is Littleton.
Board_config_mk: =/
$ (Strip $ (wildcard/
$ (Src_target_dir)/board/$ (target_device)/boardconfig. mk/
Vendor/*/$ (target_device)/boardconfig. mk/
))
How to add a module
Local_path: = $ (call my-DIR)
# Compile a static library
Include $ (clear_vars)
Local_module = libhellos
Local_cflags = $ (l_cflags)
Local_src_files = hellos. c
Local_c_includes = $ (includes)
Local_shared_libraries: = libcutils
Local_copy_headers_to: = libhellos
Local_copy_headers: = hellos. h
Include $ (build_static_library)
# Compile a dynamic library
Include $ (clear_vars)
Local_module = libhellevels
Local_cflags = $ (l_cflags)
Local_src_files = hellevels. c
Local_c_includes = $ (includes)
Local_shared_libraries: = libcutils
Local_copy_headers_to: = libhellevels
Local_copy_headers: = hellevels. h
Include $ (build_shared_library)
Build_test = true
Ifeq ($ (build_test), true)
# Using static libraries
Include $ (clear_vars)
Local_module: = hellos
Local_static_libraries: = libhellos
Local_shared_libraries: =
Local_ldlibs + =-LDL
Local_cflags: = $ (l_cflags)
Local_src_files: = mains. c
Local_c_includes: = $ (includes)
Include $ (build_executable)
# Use a dynamic library
Include $ (clear_vars)
Local_module: = hellevels
Local_module_tags: = debug
Local_shared_libraries: = libc libcutils libhelfine
Local_ldlibs + =-LDL
Local_cflags: = $ (l_cflags)
Local_src_files: = maind. c
Local_c_includes: = $ (includes)
Include $ (build_executable)
Endif # ifeq ($ (wpa_build_supplicant), true)
########################
# Local_target_dir: = $ (target_out)/etc/WiFi
# Include $ (clear_vars)
# Local_module: = wpa_supplicant.conf
# Local_module_tags: = user
# Local_module_class: = etc
# Local_module_path: = $ (local_target_dir)
# Local_src_files: = $ (local_module)
# Include $ (build_prebuilt)
########################
System variable Parsing
Local_module-compiled target object
Local_src_files-compiled source file
Local_c_includes-directory of the header files to be included
Local_shared_libraries-External library required for Link
Local_prelink_module-whether prelink processing is required
Build_shared_library-specifies the library to be compiled into a dynamic library
Local_path-directory during compilation
$ (Call directory, directory ....) Directory import operator
If the directory has a folder named SRC, you can write $ (call SRC) in this way, then the complete path of the src directory will be obtained.
Include $ (clear_vars)-clear previous system variables
Clear_vars: = $ (build_system)/clear_vars.mk
Define clear_vars :=$ (build_system)/clear_vars.mk in build/CORE/config. mk
Include custom. mk files (that is, custom compilation rules) or reference other. mk files (system-defined compilation rules) in the system ).
Local_src_files-compiled source file
It can be in. C,. cpp,. Java,. S (Assembly file),. aidl, and other formats.
Different files are separated by spaces. If you compile a directory subdirectory, use a relative path, such as subdirectory/file name. You can also use $ (call Directory) to specify a directory to compile.
All. c/. CPP/. Java/. S/. aidl files. append files local_src_files + = files
Local_c_includes-directory of the header files to be included
It can be a system-defined path or a relative path. For example, the compilation directory contains an include directory, which is written as include/*. h.
Local_shared_libraries-External shared library required for Link
Local_static_libra Ries-External external static required for Link
Add local_java_libraries to the jar package
Local_module-compiled target object
Module refers to the native code of the system, usually for C, C ++ code
./System/CORE/SH/Android. mk: 32: local_module: = sh
./System/CORE/libcutils/Android. mk: 71: local_module: = libcutils
./System/CORE/cpio/Android. mk: 9: local_module: = mkbootfs
./System/CORE/mkbootimg/Android. mk: 8: local_module: = mkbootimg
./System/CORE/toolbox/Android. mk: 61: local_module: = toolbox
./System/CORE/logcat/Android. mk: 10: local_module: = logcat
./System/CORE/ADB/Android. mk: 65: local_module: = aDb
./System/CORE/ADB/Android. mk: 125: local_module: = adbd
./System/CORE/init/Android. mk: 20: local_module: = init
./System/CORE/vold/Android. mk: 24: local_module: = vold
./System/CORE/mountd/Android. mk: 13: local_module: = mountd
Local_package_name
The Java application name is defined using this variable.
./Packages/apps/music/Android. mk: 9: local_package_name: = Music
./Packages/apps/Browser/Android. mk: 14: local_package_name: = Browser
./Packages/apps/settings/Android. mk: 8: local_package_name: = settings
./Packages/apps/STK/Android. mk: 10: local_package_name: = STK
./Packages/apps/contacts/Android. mk: 10: local_package_name: = contacts
./Packages/apps/MMS/Android. mk: 8: local_package_name: = MMS
./Packages/apps/camera/Android. mk: 8: local_package_name: = camera
./Packages/apps/phone/Android. mk: 11: local_package_name: = phone
./Packages/apps/voicedialer/Android. mk: 8: local_package_name: = voicedialer
Build_shared_library-specifies the library to be compiled into a dynamic library.
The purpose of compilation. Use the include operator.
Uild_static_library to specify the static library to be compiled.
If it is a Java file, the system's compiling script host_java_library.mk will be used to specify it with build_package. Three compilations
-------------------
Include $ (build_static_library)
Build_static_library: = $ (build_system)/static_library.mk
-------------------
Include $ (build_shared_library)
./Build/CORE/config. mk: 50: build_shared_library :=$ (build_system)/shared_library.mk
-------------------
Include $ (build_host_shared_library)
Build_host_shared_library: = $ (build_system)/host_shared_library.mk
-------------------
Include $ (build_executable)
Build/CORE/config. mk: 51: build_executable: = $ (build_system)/executable. mk
-------------------
Include $ (build_host_executable)
./Build/CORE/config. mk: 53: build_host_executable: = $ (build_system)/host_executable.mk
-------------------
Build_host_java_library: = $ (build_system)/host_java_library.mk
-------------------
Build_java_library
./Build/CORE/config. mk: 58: build_java_library :=$ (build_system)/java_library.mk
------------------
Build_static_java_library
./Build/CORE/config. mk: 59: build_static_java_library :=$ (build_system)/static_java_library.mk
------------------
Build_host_java_library
./Build/CORE/config. mk: 60: build_host_java_library :=$ (build_system)/host_java_library.mk
------------------
Build_host_static_library: = $ (build_system)/host_static_library.mk
Build_host_shared_library: = $ (build_system)/host_shared_library.mk
Build_static_library: = $ (build_system)/static_library.mk
Build_raw_static_library: = $ (build_system)/raw_static_library.mk
Build_shared_library: = $ (build_system)/shared_library.mk
Build_executable: = $ (build_system)/executable. mk
Build_raw_executable: = $ (build_system)/raw_executable.mk
Build_host_executable: = $ (build_system)/host_executable.mk
Build_package: = $ (build_system)/package. mk
Build_host_prebuilt: = $ (build_system)/host_prebuilt.mk
Build_prebuilt: = $ (build_system)/prebuilt. mk
Build_multi_prebuilt: = $ (build_system)/multi_prebuilt.mk
Build_java_library: = $ (build_system)/java_library.mk
Build_static_java_library: = $ (build_system)/static_java_library.mk
Build_host_java_library: = $ (build_system)/host_java_library.mk
Build_droiddoc: = $ (build_system)/droiddoc. mk
Build_copy_headers: = $ (build_system)/copy_headers.mk
Build_key_char_map: = $ (build_system)/key_char_map.mk
================
Local_prelink_module
Prelink uses the advance link instead of the runtime link to accelerate the loading of shared libraries. It not only speeds up startup, but also reduces some memory overhead,
It is a popular tool in various Linux architectures for reducing program loading time, shortening system startup time, and accelerating application startup. When the program is running
The overhead of dynamic links, especially relocation, is huge for large systems.
The process of dynamic linking and loading is costly. In most systems, function libraries are not often changed.
Actions are identical, especially for embedded systems. Therefore, this process can be pre-processed before it is run, that is, it takes some time
The prelink tool is used to process dynamic shared libraries and executable files, modify these binary files, and add the corresponding relocation information, saving
It is time-consuming to query the function address at startup, which can reduce the startup time of the program and reduce the memory consumption.
This kind of prelink method also has a price: each time a dynamic shared library is updated, the relevant executable files must be re-executed once to ensure
The token is valid because the symbol information and address in the new Shared library may be different from the original one. This is why the android framework code is changed,
At this time, related applications will be re-compiled.
This price may bring a little complexity to developers of embedded systems, but it is almost negligible for users.
--------------------
If the variable is set to false, the prelink operation is not performed.
Local_prelink_module: = false
Prlink is required by default and must be added to build/CORE/prelink-linux-arm.map
Libhellevels. So 0x96000000
This map file seems to be used to specify the address of the dynamic library. Some address range information is shown in the preceding comment. Pay attention to the number of intervals between the library and the library,
If this parameter is not specified, an address space conflict is prompted during compilation. In addition, pay attention to sorting. here we need to put the big data in front,
Sort by size in descending order.
Resolve the local_prelink_module variable
Build/CORE/dynamic_binary.mk: 94: ifeq ($ (local_prelink_module), true)
Ifeq ($ (local_prelink_module), true)
$ (Prelink_output): $ (prelink_input) $ (target_prelinker_map) $ (Apriori)
$ (Transform-to-prelinked)
Transform-to-prelinked definition:
./Build/CORE/definitions. mk: 1002: Define transform-to-prelinked
Define transform-to-prelinked
@ Mkdir-p $ (DIR $ @)
@ Echo "target prelink: $ (private_module) ($ @)"
$ (Hide) $ (Apriori )/
-- Prelinkmap $ (target_prelinker_map )/
-- Locals-only/
-- Quiet/
$ </
-- Output $ @
Endef
./Build/CORE/config. mk: 183: Apriori: = $ (host_out_executables)/Apriori $ (host_executable_suffix)
Prelink is not a commonly used prelink, but a prelink. Its source code is located in "<your_android>/build/tools/Apriori"
Reference:
Dynamic library Optimization-prelink Technology
Http://www.eefocus.com/article/09-04/71629s.html
====================
Local_arm_mode: = arm
Currently, most Android devices are based on ARM processors. Arm commands use two modes: thumb (two bytes per command) and arm command (four bytes per command)
Local_cflags + =-O3-fstrict-aliasing-fprefetch-loop-Arrays
By setting the compiler operation, the optimization level.-O0 indicates no optimization,-O1 indicates the default value, and-O3 indicates the highest optimization level.
Local_cflags + =-w-wall
Local_cflags + =-FPIC-dpic
Local_cflags + =-O2-g-dadb_host = 1-wall-wno-unused-Parameter
Local_cflags + =-d_xopen_source-d_gnu_source-dsh_history
Local_cflags + =-duseoverlay2
Select the appropriate compilation parameters according to the conditions.
Ifeq ($ (target_arch), arm)
Local_cflags + =-dandroid_gadget = 1
Local_cflags: = $ (pv_cflags)
Endif
Ifeq ($ (target_build_type), release)
Local_cflags + =-O2
Endif
Local_ldlibs: =-lpthread
Local_ldlibs + =-LDL
Ifdef use_marvell_mved
Local_whole_static_libraries + = lib_il_mpeg4aspdecmved_wmmx2lnx lib_il_h1_decmved_wmmx2lnx
Local_shared_libraries + = libmrvlmved
Else
Local_whole_static_libraries + = lib_il_h1_dec_wmmx2lnx lib_il_mpeg4aspdec_wmmx2lnx
Endif
The following content is transferred from: http://www.360doc.com/content/11/0609/14/474846_122680003.shtml
I. MAIN PROCESS OF makefile
The following main processes are arranged in build/CORE/Main. mk.
Initialize related parameter settings (buildspec. mk, envsetup. mk, config. mk)
Check compilation environment and target environment
Read product configuration information and target platform information
Clear output directory
Check version number
Read the configuration of the Board
Read configurations of all modules
Generate necessary rules based on configuration (build/CORE/makefile)
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 used to design hardware chip configurations, such
Whether to provide certain hardware functions, such as GPU, or the chip supports floating point operations. Product
Is a pointer to the current chip configuration definition you will produce personalized configuration of the product, mainly refers to the APK Configuration
Which APK will be included in which product and which APK will not be provided in the current product.
Config. mk is a general concept that defines the use of various modules for compilation.
Host tool and how to compile various modules. For example, built_prebuilt defines how to compile
Translate the pre-compilation module. Envsetup. mk mainly reads some variables written by envsetup. Sh into the environment variables.
To configure the output directory during the compilation process. Combo mainly defines the compilation of various host and target combinations.
Interpreter and compilation options.
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_ OS, host_arch, host_build_type according to the compiling environment,
Host_prebuilt_tag
D) Compile the toolchain required for running the program on the target and set the compilation parameters, such as Linux-arm-
CC, cflag, include directory, etc.
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 source files, including header files, library files, services, and APIs that have been compiled
Path. (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 the generation rules of a module.
Then, each local module will finally 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, the system will try to find buildspec. mk. If the file does not exist, the environment variable will be automatically used.
If it is still undefined, it will be built according to the default settings of arm.
Buildspec. mk can be created by yourself or
Buildspec. mk. Default is 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
Variable. 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, which is defined in build/CORE/version_defaults.mk (row 11 ).
Platform version, SDK version, and product version. We can use build_number as our product
Generic_x86 version information. Of course, you can also customize a version variable.
Return to envsetup. mk and set the default target product (generic ).
Target_product has been set in buildspec. mk. In fact, the value of this variable 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 product. mk, read from build/target/product/androidproducts. mk
Product_makefiles: These makefiles define product independently, and our products
Generic_x86 should also add a MAKEFILE file generic_x86.mk. In generic_x86.mk, I
You 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:
Several places:
The target_device here is generic_x86, that is, to define our own product
Generic_x86. We need to add a directory named generic_x86 under build/target/board.
Load your own 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.
The compilation is interrupted.
Row 3 contains the definitions. mk file, which defines many variables and functions for Main. mk.
. Line 446th of Main. mk,All Android. mk files will be read here:
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 under all the subdirectories retrieved by traversal
In the subdir_makefiles variable (line 470 in Main. mk ):
We can see Android. mk in the root directory of each module in package/apps, which will define
Tag of the current local module: local_module_tags. Android uses this tag to determine which local
The module is compiled into the system. The product and local_module_tags are used to determine which application packages will be compiled
System. (As mentioned earlier, you can also use buildspec. mk to compile modules into the system)
This process starts at line 1 of Mian. mk, and the module path to be compiled is packaged
All_default_installed_modules (row 602 ):
6. Generate the corresponding rules and generate the image
All preparations to be configured have been completed. Next, we will determine how to generate an image output file.
This process is actually processed in build/CORE/makefile.
Various IMG generation methods are defined here, including ramdisk. IMG, userdata. IMG,
System.img1_update.zip and recover. IMG.
When make include all files, all make files will be searched for and generated after being parsed.
Rules corresponding to the target are generated in turn until all satisfied modules are compiled and then
The tool should be packaged into the corresponding IMG.
Specific make operations:
Complete Compilation
Enter the make command in the root directory to start full compilation. This command is actually compiled and generated
The default target is droid.
That is to say, you can input the make droid actually executed by make. Next, let's take a look.
The last part of the main. mk file contains many pseudo targets, such as SDK, clean, and clobber.
The default make droid command will not be executed. We can add these labels to make
Only some operations are implemented. For example, if you enter make SDK, the corresponding SDK of this version will be generated, and enter make clean
The output of the last compilation is cleared.
Module Compilation
Sometimes we only modify a certain module and hope to compile this module separately Instead of re-completing it.
Compile it once. At this time, we need to use the bash help letter provided in build/envsetup. Sh.
Number.
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's source code, the default value is generic, and we need to fix it for our own products.
Change to generic_x86
In the chooseproduct () function in build/envsetup. Sh, fix the corresponding code.
Change.
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, you can use the mmm command, followed by the path of the specified module (note that it is the root directory of the module ).
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
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