Understanding of Android Build system

Hello Guys !!! Hope you all doing well. Today I am going to discuss AOSP build system.

Android Build system is a part of the AOSP source code. How to download and build AOSP you can follow my previous blog link.

• Android Build system used to compile the Android system, Android SDK and related package and documents.
• Android Build system is mainly contain Make files, Shell scripts and Python scripts. The most important one is Make files.
• From Android 6 (M, API 23) AOSP master platform builds with ninja instead ofGNU make and in Android 7 (N, API 24, 25) , ninja and kati become default build system.
• The build/core makefiles and Android.mk files are read by kati which will interpret them and write out a$OUT_DIR/build_$(TARGET_file, and then the execution of the build rules will be handled by ninja.

Building with kati and ninja provides some immediate benefits:

1. Faster start-up time for new builds. Running kati and then ninja results in builds starting about 25% faster than GNU make.
2. Much faster incremental builds. kati caches the mtimes of files and directories it read, what environment variables it used, etc., and only re-reads all the makefiles if something has changed. This includes globs like $(call all-files-under). Incremental builds with a warm disk cache will start within 5 seconds.
3. Better build command output. Ninja buffers the output of each command and prints it without mixing output from multiple commands, meaning error messages will be printed as a group after a build failure, and not mixed with other concurrent build output. Ninja also prints a configurable status line that defaults to printing the percentage of build commands that have been run, the number that have been run, and the number that need to run, giving a reasonable approximation of the progress through the build.
4. Incremental builds should be more reliable. Ninja considers outputs whose command line has changed to be dirty, which will catch changes to global cflags, etc. and rebuild anything that has changed.
5. The use of ninja should be transparent, it is wrapped by the top level Makefile, so all make-based commands should continue to work.

For more detail you can follow following link

https://android.googlesource.

https://github.com/google/

https://android.googlesource.

https://ninja-build.org/

https://android-review.

https://groups.google.com/

https://www.xda-developers.

The build system uses some pre-set environment variables and a series of 'make' files in order to build an Android system and prepare it for deployment to a platform.

Step by step detail of AOSP build System

1. Types of tools used by AOSP build system

• During the build we use 'make' to control the build steps themselves.
• A host toolchain (compiler, linker and other tools) and libraries will be used to build programs and tools that will run on the host.
• A different toolchain is used to compile the C and C++ code that will wind up on the target (which is an embedded board, device or the emulator).
• The kernel is compiled as a standalone binary (it does not use a program loader or link to any outside libraries).
• Native programs (e.g. init or toolbox), daemons or libraries will link against bionic or other system libraries.
• A Java compiler and a bunch of java-related tools to build most of the application framework, system services and Android applications themselves.
• Finally, tools are used to package the applications and resource files, and to create the filesystem images that can be installed on a device or used with the Emulator.

2. Setup "what to build"

• In order to decide what to build, and how to build it, the build system requires that some variables be set.
• Different products, with different packages and options can be built from the same source tree.
• The variables to control this can be set via a file with declarations of 'make' variables, or can be specified in the environment.
• A device vendor can create definition files that describe what is to be included on a particular board or for a particular product. The definition file is called: buildspec.mk, and it is located in the top-level source directory.
• Another method of specifying options is to set environment variables. To set up your build environment, you need to load the variables and function in build/envsetup.sh. your can set shell environment, like this

$ . build/envsetup.sh

or

$ source build/envsetup.sh

You can type 'help' (or 'hmm') at this point to see some utility functions that are available to make it easier to work with the source.

3. Building the system

Once We have things set up, you actually build the system with the 'make' command. Before issuing the make command we have to put lunch command in our terminal.

• lunch command provide a list of available build types.
• It will show both non-official or non-standard builds for your device
• It includes special debug versions and also allows you to build for Android Emulator

After lunch command, We have to use 'make' command for final AOSP building.

• $ make -j4 // Based on your CPU core and RAM you can give -j8, -j16 etc
• $ make -j4 showcommands // It will show build process used by AOSP

4. Make targets

List of different make targets we can use to build different parts of the system

• make sdk- build the tools that are part of an SDK (adb, fastboot, etc.)
• make snod- build the system image from the current software binaries
• make services
• make runtime
• make all- make everything, whether it is included in the product definition or not
• make clean- remove all built files (prepare for a new build). Same as rm -rf out/<configuration>/
• make modules- shows a list of submodules that can be built (List of all LOCAL_MODULE definitions)
• make update-api- To update the framework and native libs during AOSP build

5. Helper macros and functions

There are some helper macros and functions that are installed when we set envsetup.sh. Following are most used one :-

• m- execute 'make' from the top of the tree (even if your current directory is somewhere else)
• mm- Builds all of the modules in the current directory, but not their dependencies
• mmm <dir1>- Builds all of the modules in the supplied directories, but not their dependencies
• mma- Builds all of the modules in the current directory, and their dependencies.
• mmma <dir>- Builds all of the modules in the supplied directories, and their dependencies
• mm -B : Rebuild the module even it hasn’t any changes.
• cgrep <pattern>- grep on all local C/C++ files
• jgrep <pattern>- grep on all local Java files
• resgrep <pattern>- grep on all local res/*.xml files
• godir <filename>- go to the directory containing a file

6. Syncing the changes directly

If you make changes in some file and you want to update this changes in your connected device or emulator you can do it easily. Example:-

we can do our change on the PhoneStatusBar.java file and run the following commands to update the device:

• $ mmm frameworks/base/packages/
• $ adb sync // Sync the updated module to the device
• $ adb shell stop // Stopping the shell
• $ adb shell start // Starting the shell again

And all that will take less than 30 seconds!

Hope Guys!!! You enjoyed this articles.

Happy Coding!!!

Thanks

Saurabh