AOSP build 系统简介
2014-01-24 14:11
866 查看
发现一个写得很简洁的 AOSP 的 build system 的介绍,很适合初学Android 的同学。 英文的 http://www.jayway.com/2012/10/24/a-practical-approach-to-the-aosp-build-system/
原文拷贝如下。
Tomas Nilsson -
Android,
Embedded
relevant parts of the build process. As you might already know, the Android source is built using
make, and this blog post assumes some knowledge in how to write makefiles.
If you want to follow this guide, start by setting up the development environment according to the AOSP web site:
http://source.android.com/source/index.html
After setting up the environment, finish a full build for the emulator (replacing
-j5 with a value suitable for your computer):
view raw
build_platform.sh hosted with ❤ by
GitHub
Now, lets have a look at the steps involved.
It also sources any vendorsetup.sh files found under vendor/*/vendorsetup.sh, vendor/*/*/vendorsetup.sh and device/*/*/vendorsetup.sh, which allows vendors to add their own products to the lunch menu using the
add_lunch_combo function. An example of the a vendorsetup.sh is the
Samsung Maguro product directory (device/samsung/maguro):
view raw
vendorsetup.sh hosted with ❤ by
GitHub
You can try calling one of the commands after sourcing envsetup.sh:
view raw
call_hmm.sh hosted with ❤ by GitHub
envsetup.sh. After making your selection, the chosen product and variant is verified and environment variables are set, including:
Check out some of the variables by typing:
view raw
check_env_variables.sh hosted with ❤ by
GitHub
view raw
build_platform.sh hosted with ❤ by
GitHub
Depending on the type of build you selected, the result can be varying. However, a typical build results in the following images:
These images is what makes up the Android system, with one exception. The Android kernel is not a part of the AOSP, and must be built separately. We will get back to this later…
packages/apps/Music and build it using mm:
view raw
build_module.sh hosted with ❤ by
GitHub
The main makefile for this module is called Android.mk and is located in $ANDROID_BUILD_TOP/packages/apps/Music:
view raw
music_app.mk hosted with ❤ by GitHub
The make file sets a few module specific build variables and includes the BUILD_PACKAGE variable to tell make how to build this particular module. The BUILD_PACKAGE variable is defined in a file called config.mk located at $ANDROID_BUILD_TOP/build/core/config.mk.
Lets have a look at the relevant parts of it:
view raw
config.mk hosted with ❤ by GitHub
As you can see, there are several build variables defined in this file. They basically references a separate make file which handles that particular type of build. For example, the BUILD_PACKAGE variable refers to the file $ANDROID_BUILD_TOP/build/core/package.mk.
Other build notable build variables are:
LOCAL_PATH) to ensure that any previously built modules does not affect the current module.
The result of the build can be found in the target output directory, e.g.
$ANDROID_BUILD_TOP/out/target/product/<product name>/APPS
get a feeling for how a build is triggered.
When invoking
envsetup.sh and calling lunch), make finds the default Makefile in the build root, which in turn includes the main makefile in build/core/main.mk. The main makefile includes lots of other makefiles based on what make target.
Assuming the default target, three of the more important ones are highlighted in the image below:
config.mk, definitions.mk and Makefile.
Short description of what the different makefiles actually do:
Verify correct java version
Setup build version (user, userdebug, eng)
Fnd all Android.mk files in the platform build
Filter out what Android.mk files (modules) to actually include in build
Setup the internal build system files as described earlier (CLEAR_VARS, etc.)
Find the board config file (BoardConfig.mk) based on lunch selection.
Sanity check the board config file
Setup tools, e.g. aapt, proguard, flex, etc.
Define LOTS of make macros, e.g. my-dir, all-subdir-makefiles,
add-prebuilt-file, etc.
Macros are later used in the other build files.
Define target variables for e.g. recovery image, system image, ramdisk image, ota package, etc.
As described earlier, each module defines its own Android.mk file, specifying the type of module by calling the correct build file for that module, e.g.
$(BUILD_PACKAGE) for building an APK.
the following post, I will show how to add an APK to the system image.
原文拷贝如下。
A practical approach to the AOSP build system
October 24th, 2012 byTomas Nilsson -
Android,
Embedded
Introduction
The Android open-source project (AOSP) is quite complex and it can be hard to find a good way to get more familiar with it. I’m going to try a practical approach, by adding an Android application to the system image, while at the same time describing therelevant parts of the build process. As you might already know, the Android source is built using
make, and this blog post assumes some knowledge in how to write makefiles.
If you want to follow this guide, start by setting up the development environment according to the AOSP web site:
http://source.android.com/source/index.html
After setting up the environment, finish a full build for the emulator (replacing
-j5 with a value suitable for your computer):
1 2 3 | source build/envsetup.shlunch 1make -j5 |
build_platform.sh hosted with ❤ by
GitHub
Now, lets have a look at the steps involved.
envsetup.sh
When building, you usually start with sourcing the file build/envsetup.sh to setup your build environment. It basically adds a lot of shell commands to your bash environment, e.g:hmm()– print short help menu
lunch()– prints lunch menu (available build targets)
add_lunch_combo()– adds a new entry to the lunch menu
mm()- Builds all of the modules in the current directory
It also sources any vendorsetup.sh files found under vendor/*/vendorsetup.sh, vendor/*/*/vendorsetup.sh and device/*/*/vendorsetup.sh, which allows vendors to add their own products to the lunch menu using the
add_lunch_combo function. An example of the a vendorsetup.sh is the
Samsung Maguro product directory (device/samsung/maguro):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | ## Copyright (C) 2011 The Android Open Source Project## Licensed under the Apache License, Version 2.0 (the "License");# you may not use this file except in compliance with the License.# You may obtain a copy of the License at## http://www.apache.org/licenses/LICENSE-2.0## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License.# add_lunch_combo full_maguro-userdebug |
vendorsetup.sh hosted with ❤ by
GitHub
You can try calling one of the commands after sourcing envsetup.sh:
1 | hmm |
call_hmm.sh hosted with ❤ by GitHub
lunch
Next thing is to select target using the lunch menu, which was added to your bash shell environment after sourcingenvsetup.sh. After making your selection, the chosen product and variant is verified and environment variables are set, including:
export TARGET_PRODUCT=$product– The chosen product
export TARGET_BUILD_VARIANT=$variant– The chosen variant
export TARGET_BUILD_TYPE=release– Only release type is available. Use choosecombo if you want to select type.
export ANDROID_BUILD_TOP=$(gettop)– The build root directory.
export ANDROID_TOOLCHAIN=...– The toolchain directory for the prebuilt cross-compiler matching the target architecture
export PATH=...– Among other stuff, the prebuilt toolchain is added to PATH.
export ANDROID_PRODUCT_OUT=...– Absolute path to the target product out directory
export ANDROID_HOST_OUT=...– Absolute path to the host out directory
Check out some of the variables by typing:
1 | echo $ANDROID_BUILD_TOP |
check_env_variables.sh hosted with ❤ by
GitHub
Building the platform
You previously finished a platform build by running the following commands:1 2 3 | source build/envsetup.shlunch 1make -j5 |
build_platform.sh hosted with ❤ by
GitHub
Depending on the type of build you selected, the result can be varying. However, a typical build results in the following images:
boot.img– Native system boot image.
ramdisk.img– Ramdisk
rootfs.
recovery.img– Recovery image.
ramdisk-recovery.img– Ramdisk
rootfsfor Recovery.
system.img– System data (
/systemdirectory)
userdata.img– User data (
/datadirectory)
These images is what makes up the Android system, with one exception. The Android kernel is not a part of the AOSP, and must be built separately. We will get back to this later…
Building a module
Now, in order to dig a little deeper into the build system, navigate to the Music application inpackages/apps/Music and build it using mm:
1 2 | cd $ANDROID_BUILD_TOP/packages/apps/Musicmm |
build_module.sh hosted with ❤ by
GitHub
The main makefile for this module is called Android.mk and is located in $ANDROID_BUILD_TOP/packages/apps/Music:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | LOCAL_PATH:= $(call my-dir)include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(call all-java-files-under, src) \src/com/android/music/IMediaPlaybackService.aidl LOCAL_PACKAGE_NAME := Music LOCAL_SDK_VERSION := current LOCAL_PROGUARD_FLAG_FILES := proguard.flags include $(BUILD_PACKAGE) # Use the folloing include to make our test apk.include $(call all-makefiles-under,$(LOCAL_PATH)) |
music_app.mk hosted with ❤ by GitHub
The make file sets a few module specific build variables and includes the BUILD_PACKAGE variable to tell make how to build this particular module. The BUILD_PACKAGE variable is defined in a file called config.mk located at $ANDROID_BUILD_TOP/build/core/config.mk.
Lets have a look at the relevant parts of it:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | ...# ################################################################ Build system internal files# ############################################################### BUILD_COMBOS:= $(BUILD_SYSTEM)/combo CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mkBUILD_HOST_STATIC_LIBRARY:= $(BUILD_SYSTEM)/host_static_library.mkBUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mkBUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mkBUILD_RAW_STATIC_LIBRARY := $(BUILD_SYSTEM)/raw_static_library.mkBUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mkBUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mkBUILD_RAW_EXECUTABLE:= $(BUILD_SYSTEM)/raw_executable.mkBUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mkBUILD_PACKAGE:= $(BUILD_SYSTEM)/package.mkBUILD_PHONY_PACKAGE:= $(BUILD_SYSTEM)/phony_package.mkBUILD_HOST_PREBUILT:= $(BUILD_SYSTEM)/host_prebuilt.mkBUILD_PREBUILT:= $(BUILD_SYSTEM)/prebuilt.mkBUILD_MULTI_PREBUILT:= $(BUILD_SYSTEM)/multi_prebuilt.mkBUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mkBUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mkBUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mkBUILD_DROIDDOC:= $(BUILD_SYSTEM)/droiddoc.mkBUILD_COPY_HEADERS := $(BUILD_SYSTEM)/copy_headers.mkBUILD_NATIVE_TEST := $(BUILD_SYSTEM)/native_test.mkBUILD_HOST_NATIVE_TEST := $(BUILD_SYSTEM)/host_native_test.mk... |
config.mk hosted with ❤ by GitHub
As you can see, there are several build variables defined in this file. They basically references a separate make file which handles that particular type of build. For example, the BUILD_PACKAGE variable refers to the file $ANDROID_BUILD_TOP/build/core/package.mk.
Other build notable build variables are:
CLEAR_VARS– Includes the file $ANDROID_BUILD_TOP/build/core/clear_vars.mk. Clears all LOCAL_* variables (with the exeption of
LOCAL_PATH) to ensure that any previously built modules does not affect the current module.
BUILD_PACKAGE- Includes the file $ANDROID_BUILD_TOP/build/core/package.mk. Defines how packages (*.apk) are built. The build is controlled by setting LOCAL_* variables as seen in the Music application example above.
BUILD_PREBUILT- Includes the file $ANDROID_BUILD_TOP/build/core/prebuilt.mk. Defines how pre-built modules should be handled, e.g. a pre-compiled jar file.
BUILD_JAVA_LIBRARY- Includes the file $ANDROID_BUILD_TOP/build/core/java_library.mk. Defines how shared java libraries should be built.
BUILD_STATIC_JAVA_LIBRARY- Includes the file $ANDROID_BUILD_TOP/build/core/static_java_library.mk. Defines how static java libraries should be built. Includes java_library.mk as well.
The result of the build can be found in the target output directory, e.g.
$ANDROID_BUILD_TOP/out/target/product/<product name>/APPS
A closer look at the core makefiles
How does the build system know what to build? The answer to this question is fairly complex and involves lots of build files, but a very simplistic view of the process can be seen in the image below. Most of the involved files have been abstracted away toget a feeling for how a build is triggered.
When invoking
makein the build root after setting up the environment (sourcing
envsetup.sh and calling lunch), make finds the default Makefile in the build root, which in turn includes the main makefile in build/core/main.mk. The main makefile includes lots of other makefiles based on what make target.
Assuming the default target, three of the more important ones are highlighted in the image below:
config.mk, definitions.mk and Makefile.
Short description of what the different makefiles actually do:
main.mk
Verify correct java version
Setup build version (user, userdebug, eng)
Fnd all Android.mk files in the platform build
Filter out what Android.mk files (modules) to actually include in build
config.mk
Setup the internal build system files as described earlier (CLEAR_VARS, etc.)
Find the board config file (BoardConfig.mk) based on lunch selection.
Sanity check the board config file
Setup tools, e.g. aapt, proguard, flex, etc.
definitions.mk
Define LOTS of make macros, e.g. my-dir, all-subdir-makefiles,
add-prebuilt-file, etc.
Macros are later used in the other build files.
Makefile
Define target variables for e.g. recovery image, system image, ramdisk image, ota package, etc.
As described earlier, each module defines its own Android.mk file, specifying the type of module by calling the correct build file for that module, e.g.
$(BUILD_PACKAGE) for building an APK.
Summary
This was a high level overview of the Android build system based on the Jellybean source code. To make the blog post relatively short, it barely touches many important parts such as board and product definitions, module makefiles and target output. Inthe following post, I will show how to add an APK to the system image.
相关文章推荐
- Qt的元对象(Meta-Object)系统简介
- 理解 Android Build 系统_概述_2
- Android输入系统简介
- Win10 Build 9901系统更新 预览版新版本下载
- 各种系统架构图及其简介(Spring+IBatis+Struts1+Struts2+Hibernate+Java EE+Oracle)
- Linux系统简介&分区&基础命令(ADMIN01-2)
- Lsf多集群系统简介
- 新一代 Linux 文件系统 btrfs 简介
- 计算机系统简介
- 单元测试、集成测试、系统测试简介
- btrfs文件系统简介及CentOS7下实例
- ebs系统架构简介8——Upgrade
- 邮件系统之amavisd-new的简介、安装及配置
- (转)Android Build类获取系统信息
- Dojo 的 build 工具简介
- ebs系统架构简介9——Patch
- Zephyr OS 基础篇: 系统简介
- Android系统简介(2)
- 中国移动业务支撑系统简介(BOSS、BASS、BOMC、4A及VGOP)
- uboot参数简介及启动根文件系统的几种方式