Synchronous publishing platform

  • Blog garden: www.cnblogs.com/jiangxinnju…
  • CSDN: blog.csdn.net/jiangxinnju
  • The Denver nuggets: juejin. Cn/user / 166781…
  • Zhihu: www.zhihu.com/people/jian…

Reprint without permission is declined

Android build system is described in the following location: < https://source.android.com/setup/build >. You can use the build/envsetup sh set a convenient “environment” to deal with the Android source code. After executing source build/envsetup.sh in your current shell environment, you can enter the HMM as a list of defined functions that help you interact with the source.

An overview of the

The build system uses a few preset environment variables and a series of “make” files to build the Android system and prepare it for deployment to the platform.

The Android build files for the sub-project are called Android.bp and Android.mk.

There is only one official file named “Makefile” at the top of the source tree for the entire repository. You set up some environment variables and type “make” or just M to build the content. You can add options on the make command line (other targets) to turn on verbose output or perform other operations.

The build output is placed in out/host and out/ Target. The stuff under Out/Host is compiled for your host platform (desktop). The final content under out/target/product/ is placed on the target device (or emulator) in a specific way.

The directory out/target/product/ /obj is used to temporarily store “object” files, which are intermediate binary images used to build the final program. The content that actually falls on the target file system is stored in the root, system, and data directories under out/target/product/ . Typically, these files are bundled with image files named system.img, ramdisk.img, and userdata.img.

This matches the file system partitions used on most Android devices.

Some of the details

What tools to use

During build, you’ll use Soong, Ninja, and ‘make’ to control the build steps. Host toolchains (compilers, linkers, and other tools) and libraries will be used to build programs and tools that will run on the host. Use different toolchains to compile C and C++ code that will run on the target (embedded board, device, or emulator). This is typically a “cross” toolchain running on X86 platforms, but generates code for other platforms (most commonly ARM). The kernel is compiled as a separate binary (it does not use a program loader or link to any external libraries). Other projects, such as native programs (such as init or toolbox), daemons or libraries, will link to bionic libraries or other system libraries.

You’ll use the Java compiler and a number of Java-related tools to build most application frameworks, system services, and Android applications themselves. Finally, use tools to package application and resource files and create file system images that can be installed on the device or used with the emulator.

Tell the system where the Java toolchain is

Before building anything, you must tell the Android build system where the Java SDK is. (Installing the Java SDK is a prerequisite for the build). You do this by setting the JAVA_HOME environment variable.

Specify what to build

In order to decide what to build and how to build it, the build system requires setting some variables. You can build different products with different packages and options from the same source tree. The variable that controls this variable can be set through a file with a “make” variable declaration, or specified in the environment.

Equipment vendors can create definition files that describe what a particular board or product will contain. The definition file is called: buildSpec.mk and is located in the top-level source directory. You can manually edit this option to hardcode the selection.

If you have a buildSpec.mk file, it sets all the make variables needed for the build, and you don’t have to mess with the options.

Another way to specify options is to set environment variables. The build system has a rather fancy way of managing these options for you.

To setup your build environment, you need to load variables and functions in build/envsetup.sh. Do this by adding the file source to your shell environment, as follows:

. build/envsetup.sh
Copy the code

You can type “help” (or “HMM”) at this point to see some utility features that make it easier to work with the source code.

To select a set of things to build and the project to build, use the “Choosecombo” function or the “Lunch” function. Choosecombo will walk you step by step through the different projects you must choose, while Lunch allows you to choose a few preset combinations.

The projects that must be defined for the build are:

• Product (“generic” or some specific chip or platform name) • Build variant (“user”, “Userdebug” or “ENG”) • Whether it runs on emulator (“true” or “false”) • Build type (” release “or” debug”)

These different build variant that is located in source.android.com/porting/bui…

In this blog post, from the point of view of users well describe the build process: blog.codepainters.com/2009/12/18/…

Actual build system

Once set up, you can actually use the “make” command to build the system.

To build the whole thing, run “make” in the top-level directory. If you build everything (for example, for the first time), the build will take a long time.

Build skills

Look at the actual commands used to build the software

Use “showCommands” on the “make” line

make -j4 showcommands
Copy the code

You can use this in conjunction with another make target to see the commands for the build. That is, “showCommands” is not a target in itself, but just a modifier that specifies the build.

In the example above, -j4 is independent of the ShowCommands option and is used to execute four make sessions running in parallel.

Set goals

Here is a list of different make targets that can be used to build different parts of the system:

• Make SDK – Build SDK tools (ADB, Fastboot, etc.) • make snod – Build system images from current software binaries • make services • make Runtime • make droid – Make droid is a normal build. • Make all – Build everything, whether or not it is included in the product definition • Make clean – Remove all built files (ready for new builds). Same as rm -rf out/

/ • make modules – Displays a list of submodules that can be built (all LOCAL_MODULE defined lists) • make < LOCAL_MODULE > – Build a specific module (note that this is different from the directory name. It is the LOCAL_MODULE definition in the Android.mk file) • make clean < LOCAL_MODULE > – Clean up specific modules • make bootimage TARGET_PREBUILT_KERNEL=/path/to/bzImage – Creates a new boot image using the custom bzImage

Auxiliary macros and functions

When you get envsetup.sh, some helper macros and functions are installed. They are recorded at the top of envesetup.sh, but here’s some of the information:

• HMM – Lists help content • Lunch –

– loads product and builds variant configurations (driver files, device specific configurations, etc.) • Tapas [


…] [arm | x86 | MIPS | armv5 | arm64 | x86_64 | mips64] [eng | userdebug | user] – this command is used to build not bundled applications. If you do not provide a build, the default is ENG. • Provision – Burn equipment with all required partitions. Options will be passed to FastBoot.

Build macros and functions

• croot – Change directory to top of tree • M – Perform “make” from top of tree (even if current directory is located elsewhere) • MM – build all modules in current directory • MMM

… – Builds all modules in the supplied directory, but does not build their dependencies. To limit the module being built, use the following syntax: MMM dir / : target1,target2. • MMA – Builds all modules and their dependencies in the current directory. • mmma < dir1-name >… – Builds all modules and their dependencies in the supplied directory.

Grep macros and functions

• Cgrep is displayed on all local C/C++ files. • Ggrep is displayed on all local Gradle files. • Jgrep used on all local Java files. • resgrep in all local res/*. Lock on XML files. • Mangrep scans all local Androidmanifest.xml files. • mgrep captures on all local makefiles. • Sepgrep Locks all local Sepolicy files. • sgrep captures on all local source files. • godir < filename > go to the directory containing the file

To speed up the building

You can use the ‘-j’ option in make to start multiple make threads at the same time.

In my experience, you should specify 2 more threads than the processor on the computer. If you have two processors, use ‘make-j4’; If they are hyperthreaded (meaning you have 4 virtual processors), try ‘make-j6.

You can also specify the use of a “ccache” compiler cache, which will speed up processing after you first build your content. To do this, specify “export USE_CCACHE = 1” on your shell command line. (Note that ccache is included in the pre-built part of the repository and does not have to be installed separately on the host.)

For the latest versions of Android, there is no pre-built ccache, and you need to set the path to a local binary using CCACHE_EXEC according to this COMMIT.

Build only a single program or module

If you use build/envsetup.sh, you can use some defined functions to build only a portion of the tree. Use the “mm” or “MMM” command to do this.

The “mm” command populates the current directory (and subdirectories, I believe). Using the “MMM” command, you can specify a directory or list of directories and then build it. To install your changes, “make snod” from the top of the tree. Make snod” builds a new system image from the current binary.

Sets module-specific build parameters

Some code in the Android system can be customized according to how it is built (separate from build variants and distribution and debugging options). You can set variables to control the various build options by setting them in the environment or passing them directly to “make” (or “m…” as “make” is called). Function).

For example, you can build an ‘init’ program that supports bootchart logging by setting the INIT_BOOTCHART variable. (See Using Bootchart on Android for why you might want to do this.)

You can do this in any of the following ways:

touch system/init/init.c
export INIT_BOOTCHART=true
make
Copy the code

or

touch system/init/init.c
m INIT_BOOTCHART=true
Copy the code

The Makefile skills

These are a few hints of what you can use in your own Android.mk files.

Set up the helper function

In the file build/core/definitions. Mk defines many build helper function

Try to make an exhaustive list. grep define build/core/definitions.mk

$(call

, < param-1 >, < param-2 >)$(call

)

Here are some features that might be interesting:

• print-vars – Prints all Makefile variables for debugging (not their values). • emma-line – Output line to file during build • dump-words-to-file – Output word list to file • copy-one-file – Copy file from one place to another (is the destination at the destination?) • all-subdir-makefiles – recursively calls all files from the current directory (usage :). Android.mkinclude $(call all-subdir-makefiles)

Build a variable

• $(ANDROID_BUILD_TOP) – AOSP file system root folder • $(LOCAL_PATH)- Usually the current directory. Set by the developer/user in each Android.mk file. It will be overwritten in other files under the file tree (for example, when used). Android.mk include $(call all-subdir-makefiles)

Solutions:

 SAVED_LOCAL_PATH := $(call my-dir)
 include $(call all-subdir-makefiles)
 LOCAL_PATH:= $(SAVED_LOCAL_PATH)
Copy the code

Add files directly to the output area

You can use the add-prebuilt-in function to copy files directly to the output area without building anything.

Copy the following list of rows of files extracted from prebuilt/ Android-arm/gdbServer /Android.mk to the EXECUTABLES directory of the output region:

$(call add-prebuilt-files, EXECUTABLES, $(prebuilt_files))

Add new programs to build

Steps to add a new program to the Android source tree

, in the “external” directory, such as ANDROID/external/myprogram, create your C/CPP file. • Create Android.mk as a clone of external/ping/ android. mk • Change the names ping.c and ping to match your C/ CPP file and program name • After external/zlib ANDROID/build/core/main. The directory name from a mk added as external/myprogram (at least since ANDROID 7.1 is no longer needed), starting from the root of the source tree, Your files will be displayed in the build output area and in the system image. • If you want to copy files individually to the target (instead of performing the entire installation), you can use out/target/product/… Copy the file.

For more details, see www.aton.com/android-nat… .

Build a kernel

The kernel is “external” to the normal Android build system (in fact, it is not included in the Android Open Source Project by default). However, AOSP has several tools for building kernels. If you want to build a kernel, from this page, please start: HTTP: / / source.android.com/source/building-kernels.html

If you’re building a kernel for an emulator, you might also want to look at: HTTP: //stackoverflow.com/questions/1809774/android-kernel-compile-and-test-with-android-emulator

Moreover, Ron M. wrote (on the Android-kernel mailing list of May 21, 2012) :

This article is quite old – but as far as AOSP is concerned, nothing has changed, so if anyone is interested in QEMU and runs into this problem, please do the following: Actually, building a kernel for the QEMU target provided by AOSP is a nice, shorter way to do it:

  1. CD to your kernel source directory (only goldfish 2.6.29 is available in the emulator)
  2. ANDROIDBUILDTOP/external/qemu/distrib/build – kernel. Sh – j = 64 – – the arch = x86 – – out = {ANDROID_BUILD_TOP} /external/qemu/distrib/build-kernel.sh -j = 64 –arch = x86 –out = ANDROIDBUILDTOP/external/qemu/distrib/build – kernel. Sh – j = 64 – – the arch = x86 – – out = YourOutDir
  3. emulator -kernel ${YourOutDir}/kernel-qemu # run emulator:

Step # 2 calls the toolbox.sh wrapper script, which works with SSE disabling GCC warnings – occurring when GCC <4.5 (as in AOSP’s pre-built X86 toolchain).

If it were X86, the script would add “-mfpMath = 387-fno-pic”, eliminating the compilation error seen above.

For better control over the build process, you can use the “toolbox.sh” wrapper and set up a few other things without modifying the script file.

Here is an example of building the same emulator:

# Set arch
export ARCH=x86
# Have make refer to the QEMU wrapper script for building android over x86 
(eliminates the errors listed above)
export 
CROSS_COMPILE=${ANDROID_BUILD_TOP}/external/qemu/distrib/kernel-toolchain/android-kernel-toolchain-
# Put your cross compiler here. I am using the AOSP prebuilt one in this exampleexport REAL_CROSS_COMPILE = ${ANDROID_BUILD_TOP} / prebuilt/Linux x86 / toolchain/i686 - android - Linux - 4.4.3 / bin/i686 - android - Linux -# Configure your kernel - here I am taking the default goldfish_defconfig
make goldfish_defconfig
# build
make -j64
# Run emulator:
emulator -kernel arch/x86/boot/bzImage -show-kernel
Copy the code

This applies to the 2.6.29 metanere branch.

translationElinux.org/Android_Bui…