Understanding Android Build System

After configuring the above file, we can compile the system image of our newly added device.

First, the output from the command called "source build/envsetup.sh" will see that the build system has introduced the vendorsetup.sh file that was just added.

Then call the "Lunch" function, and the list of the functions output will contain the entries added in the newly added vendorsetup.sh. You can then select by number or name.

Finally, call "Make-j8" to perform the compilation.

Add a new module

The description of "module" has been mentioned above and is not discussed here.

In the source tree, all files for a module are usually in the same folder. In order to add the current module to the entire Build system, each module requires a dedicated make file with the name "Android.mk". The build system scans the file named "Android.mk" and compiles the corresponding product based on the contents of the file.

It is important to note that in Android build system, the compilation is in the module (not the file) as the unit, each module has a unique name, a module of the dependent object can only be another module, but not other types of objects. For a compiled binary library, if you want to be used as a dependent object, you should use these compiled libraries as separate modules. Use Build_prebuilt or build_multi_prebuilt for these already compiled libraries. For example, when compiling a Java library that relies on some jar packages and does not directly specify the path of the jar package as a dependency, the jar packages must first be defined as a module, and then the Java library is compiled with the name of the module to rely on the jar packages.

Below, we will explain the writing of the Android.mk file:

The android.mk file usually begins with the following two lines of code:

Local_path: = $ (call My-dir)
Include $ (clear_vars)

The purpose of these two lines of code is to:

Sets the compilation path for the current module to the current folder path.
Clean up variables used in the compilation environment (possibly set by other modules).

To facilitate the compilation of the module, the build system sets a lot of compiler environment variables. To compile a module, set the variables as needed before compiling and then perform the compilation. They include:

Local_src_files: All source code files contained in the current module.
Local_module: The name of the current module, the name should be unique, the dependencies between the modules are referenced by this name.
The path to the header file required by the LOCAL_C_INCLUDES:C or C + + language.
Local_static_libraries: The name of the library that the current module requires when it is statically linked.
Local_shared_libraries: The name of the dynamic library that the current module relies on at run time.
Local_cflags: Additional compilation parameters provided to the C + + compiler.
Local_java_libraries: The JAVA shared library that the current module relies on.
Local_static_java_libraries: The JAVA Static library that the current module relies on.
Local_package_name: The name of the current APK app.
Local_certificate: Sign the name of the certificate that is currently applied.
Local_module_tags: The tag contained in the current module, a module can contain multiple labels. The value of the tag may be debug, eng, user,development, or optional. Where optional is the default label. Tags are provided for use by compilation types. Different compilation types install modules with different tags, and descriptions of compilation types are shown in table 7:

The files in table 3 already define how the various types of modules are compiled. So to do the compilation, just introduce the corresponding make file in table 3 (in the way of constants). For example, to compile an APK file, simply add "include $" (build_package) to the Android.mk file.

In addition, the Build system also defines some handy functions for use in android.mk, including:

$ (call My-dir): Gets the current folder path.

$ (call All-java-files-under, <src>): Gets all Java files under the specified directory.

$ (call All-c-files-under, <src>): Gets all the C language files in the specified directory.

$ (call All-iaidl-files-under, <src>): Gets all aidl files in the specified directory.

$ (call All-makefiles-under, <folder>): Gets all the make files in the specified directory.

$ (call intermediates-dir-for, <class>, <app_name>,

Listing 2 and Listing 3 are examples of make files that compile the APK file and compile the Java static library, respectively:

Listing 2. Compiling an APK file

Double-click code Select All

12345678910

LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) # 获取所有子目录中的 Java 文件LOCAL_SRC_FILES := $(call all-subdir-java-files)          # 当前模块依赖的静态 Java 库，如果有多个以空格分隔LOCAL_STATIC_JAVA_LIBRARIES := static-library # 当前模块的名称LOCAL_PACKAGE_NAME := LocalPackage # 编译 APK 文件include $(BUILD_PACKAGE)

Listing 3. Compiling a static library of Java

Double-click code Select All

1234567891011121314

LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS)      # 获取所有子目录中的 Java 文件LOCAL_SRC_FILES := $(call all-subdir-java-files)       # 当前模块依赖的动态 Java 库名称LOCAL_JAVA_LIBRARIES := android.test.runner       # 当前模块的名称LOCAL_MODULE := sample      # 将当前模块编译成一个静态的 Java 库include $(BUILD_STATIC_JAVA_LIBRARY)

Conclusion

The whole Build system contains a lot of content, because of the limitations of space, this article can only introduce the most important content.

Since the build system itself is also evolving along with the Android platform, the content and definitions of the different versions may vary. The information on this part of the network is fragmented, and some of the content of the material is obsolete and no longer applicable, coupled with the lack of official documentation, it is difficult to learn in this part.

This requires us to have a strong code reading ability, after all, the code will not lie. You know, for us developers, the source code is our most loyal friend. Use the source,luke!

Understanding Android Build System