makefile文件编写介绍

2024年2月8日发(作者：)

文档简要整理Android的make脚本的内容。以供备忘和参考。

1. Build Layers

Build Layers描述的是产品的硬件配置情况，据此make时选择不同的配置和模块。按照从上到下的顺序，Build Layer分成4层。

Layer sample Note

Arch arm, x86 处理器的种类

Board － 板子类型的代号

Device － device配置的类型代号

Product － 具体产品的代号

2. 添加应用

2.1 一个例子

以calculator为例，app代码可以放到packages/apps/目录下边，一个app对应一个目录，此例，pakcages/apps/Calculator/。创建，已去除多余的注释行。

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := optional

LOCAL_STATIC_JAVA_LIBRARIES := libarity

LOCAL_SRC_FILES := $(call all-java-files-under, src)

LOCAL_SDK_VERSION := current

LOCAL_PACKAGE_NAME := Calculator

include $(BUILD_PACKAGE)

include $(CLEAR_VARS)

LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES := libarity:

include $(BUILD_MULTI_PREBUILT)

# Use the folloing include to make our test apk.

include $(call all-makefiles-under,$(LOCAL_PATH))

至少有一个子目录，src下放源码。

中需要赋值的几个LOCAL_XXX变量，

LOCAL_PATH，调用my-dir（在中定义），得到当前路径，即，/

pakcages/apps/Calculator/。

LOCAL_MODULE_TAGS，，取值范围debug eng tests optional samples shell_ash shell_mksh。注意不能取值user，如果要预装，则应定义。

LOCAL_SRC_FILES，app的所有源码，可以调用all-java-files-under得到，如果是java源码的话。

LOCAL_PACKAGE_NAME，package的名字，这个名字在脚本中将标识这个app或package。

$(CLEAR_VARS)指的是clear_，脚本会清空所有LOCAL_xxx的变量，不影响后面这些变量的使用。

$(BUILD_PACKAGE)指的是

最后一句all-makefiles-under将会包含当前目录下所有的mk脚本文件。

2.2 LOCAL_XXX的列表

说明：

必须定义, 在app或package的中必须给定值。

可选定义，在app或package的中可以也可以不给定值。

不用定义，在app或package的中不要给定值，脚本自动指定值。

LOCAL_PATH， 当前路径，必须定义。

LOCAL_PACKAGE_NAME， 必须定义，package的名字，这个名字在脚本中将标识app或package。

LOCAL_MODULE_SUFFIX， 不用定义，module的后缀，=.apk。

LOCAL_MODULE， 不用定义，=$(LOCAL_PACKAGE_NAME)。

LOCAL_JAVA_RESOURCE_DIRS， 不用定义。

LOCAL_JAVA_RESOURCE_FILES， 不用定义。

LOCAL_MODULE_CLASS， 不用定义。

LOCAL_MODULE_TAGS， 可选定义。默认optional。取值范围user debug eng tests

optional samples shell_ash shell_mksh。

LOCAL_ASSET_DIR， 可选定义，推荐不定义。默认$(LOCAL_PATH)/assets

LOCAL_RESOURCE_DIR， 可选定义，推荐不定义。默认product package和device package相应的res路径和$(LOCAL_PATH)/res。

LOCAL_PROGUARD_ENABLED， 可选定义，默认为full，如果是user或userdebug。取值full, disabled, custom。

full_android_manifest， 不用定义，=$(LOCAL_PATH)/。

LOCAL_EXPORT_PACKAGE_RESOURCES， 可选定义，默认null。如果允许app的资源被其它模块使用，则设置true。

LOCAL_CERTIFICATE， 可选定义，默认为testkey。最终

private_key := $(LOCAL_CERTIFICATE).pk8

certificate := $(LOCAL_CERTIFICATE).

2.3 mm创建apk时的中变量分析

以Calculator为例，

由LOCAL_PATH，LOCAL_PACKAGE_NAME导出变量LOCAL_MODULE，all_assets，all_assets，all_resources。

设置LOCAL_MODULE_CLASS=APPS，此值local-intermediates-dir会用到。

设置中间生成目录路径，中间路径将放置文件。

package_expected_intermediates_COMMON := $(call local-intermediates-dir,COMMON)

这里COMMON是null，而LOCAL_MODULE_CLASS=APPS，所以

package_expected_intermediates_COMMON=out/target/common/obj/$(LOCAL_MODULE_CLASS)/$(LOCAL_MODULE)_intermediates

即

package_expected_intermediates_COMMON=out/target/common/obj/APPS/Calculator_inte

rmediates

设置

LOCAL_BUILT_MODULE_STEM :=

而

LOCAL_BUILT_MODULE := $(built_module_path)/$(LOCAL_BUILT_MODULE_STEM)

@base_

built_module_path := $(intermediates) @base_

intermediates := $(call local-intermediates-dir) @

最终

LOCAL_BUILT_MODULE=out/target/product//obj/$(LOCAL_MODULE_CLASS)/$(LOCAL_MODULE)_intermediates/$(LOCAL_BUILT_MODULE_STEM)

即

LOCAL_BUILT_MODULE=out/target/product/generic/obj/APPS/Calculator_intermediates/

由LOCAL_CERTIFICATE导出

private_key := $(SRC_TARGET_DIR)/product/security/$(LOCAL_CERTIFICATE).pk8

certificate := $(SRC_TARGET_DIR)/product/security/$(LOCAL_CERTIFICATE).

LOCAL_CERTIFICATE默认为testkey。

2.4 中定义的几个变量

PACKAGES.$(LOCAL_PACKAGE_NAME).PRIVATE_KEY := $(private_key)

PACKAGES.$(LOCAL_PACKAGE_NAME).CERTIFICATE := $(certificate)

PACKAGES.$(LOCAL_PACKAGE_NAME).OVERRIDES := $(strip $(LOCAL_OVERRIDES_PACKAGES))

PACKAGES.$(LOCAL_PACKAGE_NAME).RESOURCE_FILES := $(all_resources)

PACKAGES := $(PACKAGES) $(LOCAL_PACKAGE_NAME)

全编译时，PACKAGES变量将会记录遍历到的packages。

Android Make脚本的简记(2)

内容提要

文档简要整理Android的make脚本的内容。以供备忘和参考。

1. 分析

选取APPS场景，以Calculator为例说明。

LOCAL_JAVA_LIBRARIES=true时，中不能定义LOCAL_SDK_VERSION。

当LOCAL_SDK_VERSION=current时，LOCAL_JAVA_LIBRARIES=android_stubs_current。

中定义LOCAL_BUILT_MODULE_STEM=。

两个中间目录的路径，即对应的obj目录下APPS/_intermediates/。

intermediates=out/target/product/generic/obj/APPS/Calculator_intermediates

=out/target/common/obj/APPS/Calculator_intermediates

LOCAL_INTERMEDIATE_TARGETS先前中已经定义了，有增添了7个。

LOCAL_INTERMEDIATE_TARGETS += /

$(full_classes_jar) /

$(full_classes_compiled_jar) /

$(full_classes_emma_jar) /

$(full_classes_full_names_jar) /

$(full_classes_stubs_jar) /

$(full_classes_jarjar_jar) /

$(built_dex)

此例中，具体值是

LOCAL_INTERMEDIATE_TARGETS=

out/target/common/obj/APPS/Calculator_intermediates/src/

@defined in

out/target/common/obj/APPS/Calculator_intermediates/

@full_classes_jar

out/target/common/obj/APPS/Calculator_intermediates/

@full_classes_compiled_jar

out/target/common/obj/APPS/Calculator_intermediates/emma_out/lib/ @full_classes_emma_jar

out/target/common/obj/APPS/Calculator_intermediates/

@full_classes_full_names_jar

out/target/common/obj/APPS/Calculator_intermediates/

@full_classes_stubs_jar

out/target/common/obj/APPS/Calculator_intermediates/

@full_classes_jarjar_jar

out/target/common/obj/APPS/Calculator_intermediates/

@built_dex

随后include base_

后面处理了EMMA,PROGUARD在enable/disable情况下的动作

最后定义的target, $(LOCAL_MODULE)-findbugs因为prebuilt/common下还没有findbugs，目前不可用。

还定义了几个特别的变量，

ALL_MODULES.$(LOCAL_MODULE).PROGUARD_ENABLED:=$(LOCAL_PROGUARD_ENABLED)

ALL_MODULES.$(LOCAL_MODULE).CHECKED := $(full_classes_compiled_jar)

ALL_MODULES.$(LOCAL_MODULE).STUBS := $(full_classes_stubs_jar)

2. base_的分析

续1的场景。

提取变量my_prefix:=TARGET_

LOCAL_MODULE_TAGS在或中已经设定，默认是optional。

确认LOCAL_MODULE_PATH，默认$($(my_prefix)OUT$(use_data)_$(LOCAL_MODULE_CLASS))，此例中是out/target/product/generic/system/app

设定module_id := MODULE.$(TARGET).$(LOCAL_MODULE_CLASS).$(LOCAL_MODULE)，此例ator。

设定中间目录路径intermediates，，参见1.

设定LOCAL_MODULE_STEM=$(LOCAL_MODULE)，此例,Calculator。LOCAL_INSTALLED_MODULE_STEM＝。

LOCAL_INTERMEDIATE_TARGETS追加上，参见1.

处理aidl，转为java，放在下的目录中。

处理logtag，转为java，放在下的目录中。

确定java_sources，这包括中包含的，aidl和logtag生成的。

处理java_resource_files

处理了java lib相关

定义clean-$(LOCAL_MODULE) target, 可以删除app/package的生成文件，包括$(PRIVATE_CLEAN_FILES)，$(LOCAL_BUILT_MODULE)，$(LOCAL_INSTALLED_MODULE)，$(intermediates)，$()

还定义了$(LOCAL_MODULE) target, 几个变量的值

LOCAL_MODULE=Calculator

LOCAL_BUILT_MODULE=out/target/product/generic/obj/APPS/Calculator_intermediates/

LOCAL_INSTALLED_MODULE=out/target/product/generic/system/app/

最后定义了几个ALL_MODULES变量。

ALL_MODULES.$(LOCAL_MODULE).CLASS

ALL_MODULES.$(LOCAL_MODULE).PATH

ALL_MODULES.$(LOCAL_MODULE).TAGS

ALL_MODULES.$(LOCAL_MODULE).CHECKED

ALL_MODULES.$(LOCAL_MODULE).BUILT

ALL_MODULES.$(LOCAL_MODULE).INSTALLED

ALL_MODULES.$(LOCAL_MODULE).REQUIRED

ALL_MODULES.$(LOCAL_MODULE).EVENT_LOG_TAGS

3. multi_的分析

续1的场景。

mulit_顾名思义就是多次调用，对几种明确的prebuilt library完成需要的copy操作。

multi_定义了命令auto-prebuilt-boilerplate。入口有6个参数

# $(1): file list， ":"

# $(2): IS_HOST_MODULE

# $(3): MODULE_CLASS

# $(4): OVERRIDE_BUILT_MODULE_PATH

# $(5): UNINSTALLABLE_MODULE

# $(6): BUILT_MODULE_STEM

根据这6个参数，命令确定

LOCAL_IS_HOST_MODULE

LOCAL_MODULE_CLASS

OVERRIDE_BUILT_MODULE_PATH

LOCAL_UNINSTALLABLE_MODULE

LOCAL_MODULE

LOCAL_SRC_FILES

LOCAL_BUILT_MODULE_STEM

LOCAL_MODULE_SUFFIX

并调用

multi_中分别对下面5中lib调用了auto-prebuilt-boilerplate。

prebuilt_static_libs := $(filter %.a,$(LOCAL_PREBUILT_LIBS))

prebuilt_shared_libs := $(filter-out %.a,$(LOCAL_PREBUILT_LIBS))

prebuilt_executables := $(LOCAL_PREBUILT_EXECUTABLES)

prebuilt_java_libraries := $(LOCAL_PREBUILT_JAVA_LIBRARIES)

prebuilt_static_java_libraries := $(LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES)

4. 的分析

续1的场景。

首先，include base_

定义

PACKAGES.$(LOCAL_MODULE).OVERRIDES

第二步，如果是APPS类型，则zipalign，并拷贝到中间路径$(intermediates)。不是APPS，则不做zipalign。

本例是JAVA_LIBRARY类型，目的路径out/target/common/obj/JAVA_LIBRARIES/libarity_intermediates/，注意其中的libarity和。

最后检查 signed情况。

Android101110: Android Make脚本的简记(3)

内容提要

文档简要整理Android的make脚本的内容。以供备忘和参考。

1. 的分析

中调用了，得到所有子目录下文件的路径。

subdir_makefiles := /

$(shell build/tools/ --prune=out --prune=.repo --prune=.git

$(subdirs) )

$(subdirs)一般编译中取值$(TOP)。

使用方法，

Usage: %(progName)s []

Options:

--mindepth=

Both behave in the same way as their find(1) equivalents.

--prune=

Avoids returning results from inside any directory called

(e.g., "*/out/*"). May be used multiple times.

程序首先依次选取dirlist中的目录，然后遍历所有子目录查找文件，如果有，则加入到返回列表中。

2. 的分析

中定义了一个列表pathmap_INCL，列表中每项是"短名:路径"对。命令

include-path-for使用这个pathmap_INCL列表，输入短名，得到路径。你可以在这个列表中添加自己的对。使用$(call include-path-for, <短名>)就可以得到路径。

另外，定义了FRAMEWORKS_BASE_JAVA_SRC_DIRS，含有frameworks/base目录下含java文件的所有目录。

3. 的分析

首先，包含， 其次，定义了一些变量，例如通用的编译参数，package的后缀名等。

随后包含。

接着包含。

然后包含$(board_config_mk)。$(board_config_mk)是位于build/target/board

/$(TARGET_DEVICE)/，device/*/$(TARGET_DEVICE)/，或vendor/*/$(TARGET_DEVICE) /目录下的文件。

-------TODO

4. 的分析

是用户应当配置的脚本文件，模板可以使用t，放到$(TOP)下。

在 中，用户应该配置好主要的参数，例如 TARGET_PRODUCT，

TARGET_BUILD_VARIANT， CUSTOM_MODULES， TARGET_SIMULATOR， TARGET_BUILD_TYPE，

CUSTOM_LOCALES， 和BUILD_ENV_SEQUENCE_NUMBER等。

如果不使用配置参数，也可以使用环境变量的形式。若不配置参数，那么android会使用默认的参数。

5. 的分析

首先包含进version_，定义好一些版本相关的变量。参见version_。

定义CORRECT_BUILD_ENV_SEQUENCE_NUMBER，这个数字用于更新时的提醒，应该同中的或环境变量中的BUILD_ENV_SEQUENCE_NUMBER相等。一般不用关注。

随后检查TARGET_PRODUCT，若为空，则置generic。TARGET_PRODUCT应当在或环境变量中已经定义好。

再检查TARGET_BUILD_VARIANT，若为空，则置eng。TARGET_BUILD_VARIANT应当在或环境变量中已经定义好。

然后包含进product_。

接着，检查$(TARGET_BUILD_VARIANT),取值范围是eng user userdebug tests。

随后判定HOST_OS(linux)，HOST_ARCH(x86)

接着，确定TARGET_ARCH和TARGET_OS，若没有定义，则取默认值。

TARGET_ARCH := arm

TARGET_OS := linux

接着，确定TARGET_BUILD_TYPE，若没有定义，则取默认值。

TARGET_BUILD_TYPE := release

接着，确定OUT_DIR。OUT_DIR是存放中间文件和最终结果的地方。若没有定义，则取默认值。

OUT_DIR := $(TOPDIR)out

随后，定义了一些列的路径变量

DEBUG_OUT_DIR，TARGET_OUT_ROOT_release，TARGET_OUT_ROOT_debug，TARGET_OUT_ROOT，BUILD_OUT，PRODUCT_OUT，TARGET_COMMON_OUT_ROOT，等等。

6. version_的分析

version_是检查一些跟版本相关的变量是否定义，如果未定义，则使用默认值。这些变量包括

PLATFORM_VERSION，默认AOSP

PLATFORM_SDK_VERSION，默认8

PLATFORM_VERSION_CODENAME，默认AOSP

DEFAULT_APP_TARGET_SDK，默认AOSP

BUILD_ID，默认UNKNOWN

BUILD_NUMBER，默认eng.$(USER).$(shell date +%Y%m%d.%H%M%S)的形式。

version_首先包含进build_。用户应当配置build_，而不应该改动version_文件。

然后检查上述变量，如未定义则赋值默认值。

7. build_的分析

用户可以在build_中定义这样几个参数，

PLATFORM_VERSION

PLATFORM_SDK_VERSION

PLATFORM_VERSION_CODENAME

DEFAULT_APP_TARGET_SDK

BUILD_ID

BUILD_NUMBER

这些参数最终将出现中。

Froyo的build_中定义了2个变量，

BUILD_ID，通常用于说明分支branch的，默认的是OPENMASTER，用户应该配置这个参数。

DISPLAY_BUILD_NUMBER，在TARGET_BUILD_VARIANT=user的版本中，中是

是显示成$(BUILD_ID).$(BUILD_NUMBER)，还是显示成$(BUILD_ID)形式。设成true，则显示前者。

8. product_的分析

make PRODUCT--

如果使用上述形式的make命令，那么将等同于

TARGET_PRODUCT:=

TARGET_BUILD_VARIANT:=

goal_name:=PRODUCT--

MAKECMDGOALS:=droid

.PHONY: $(goal_name)

$(goal_name): $(MAKECMDGOALS)

endif

注意,goal的取值范围是user userdebug eng tests，如果不属于上述范围，则将算入MAKECMDGOALS中，此时, TARGET_BUILD_VARIANT := eng。例如

make PRODUCT-dream-installclean

等同于

TARGET_PRODUCT=dream make installclean

使用make PRODUCT--这种形式，可以方便的指定TARGET_PRODUCT，和TARGET_BUILD_VARIANT。

make APP-

如果使用上述形式的make命令，那么将等同于

TARGET_BUILD_APPS:=

unbundled_goals:=APP-

MAKECMDGOALS:=droid

.PHONY: $(unbundled_goals)

$(unbundled_goals): $(MAKECMDGOALS)

使用make APP-这种形式，可以方便的指定TARGET_BUILD_APPS。

注意，PRODUCT--和APP-可以一块使用。

处理完PRODUCT--和APP-，product_会包含下面3个文件

node_

上面的3个mk文件定义了一些命令，用于搜寻product, device对应的目录，生成相应的,和变量。

接着，使用$(call import-products, $(get-all-product-makefiles))遍历Prodcut相关的文件，读入变量。可以去掉文件中下面两句话的注释符，查看。

#$(dump-products)

#$(error done)

随后，使用和TARGET_PRODUCT，得到INTERNAL_PRODUCT信息，即指定product的路径。

再由INTERNAL_PRODUCT得到TARGET_DEVICE， PRODUCT_LOCALES， PRODUCT_BRAND，

PRODUCT_MODEL， PRODUCT_MANUFACTURER， PRODUCT_DEFAULT_WIFI_CHANNELS，

PRODUCT_POLICY， PRODUCT_COPY_FILES， PRODUCT_PROPERTY_OVERRIDES，

PRODUCT_PACKAGE_OVERLAYS， DEVICE_PACKAGE_OVERLAYS， PRODUCT_TAGS，

PRODUCT_OTA_PUBLIC_KEYS。

由PRODUCT_LOCALES导出PRODUCT_AAPT_CONFIG。

ADDITIONAL_BUILD_PROPERTIES中追加PRODUCT_PROPERTY_OVERRIDES中的值。

上面所说的这些值，实际上都是在product的mk文件中定义。

9. node_的分析

定义了一些命令。这些命令在，，和product_中会使用。这里重点说明import-nodes。

import-nodes需要3个入口参数：

$(1)是一个字串，是输出变量的主干名。例如”PRODUCTS"和”DEVICES“。

$(2)是一个makefile文件列表，这些文件中应该含有对$(3)中变量的定义。

$(3)是一个变量列表。

import- nodes会创建这样形式的变量，以$(1)="PRODUCTS", $(2)中含有"build/target/product/", $(3)中含有"PRODUCT_NAME", 而且中定义了PRODUCT_NAME:=core为例，

/target/product/T_NAME:=core

import- nodes中还考虑了inherit的问题，如果某个变量的值中有‘@inherit:’标识后面跟着 mk文件名的字串，则会把那个mk文件中相应的变量的属性添加到中。'@inherit:'是 inherit-product命令添加的。参见。

在product_中会说明$(2)中的mk文件列表是中的PRODUCT_MAKEFILES定义的。

node_的代码真的很杀伤脑细胞...

10. 的分析

构造了一些命令，供product_中使用。

_find-android-products-files这个命令会得到device/和vendor/, 包括子目录，以及build/target/product/下的文件列表。

get-all-product-makefiles这个命令会得到所有$(_find-android-products-files)的文件中PRODUCT_MAKEFILES变量定义的mk文件。

_product_var_list对应的是import-nodes命令的$(3), 定义了会生成那些PRODUCT属性名的变量。这些变量实际也是在product的mk文件中要考虑定义的。

_product_var_list := /

PRODUCT_NAME /

PRODUCT_MODEL /

PRODUCT_LOCALES /

PRODUCT_PACKAGES /

PRODUCT_DEVICE /

PRODUCT_MANUFACTURER /

PRODUCT_BRAND /

PRODUCT_PROPERTY_OVERRIDES /

PRODUCT_COPY_FILES /

PRODUCT_OTA_PUBLIC_KEYS /

PRODUCT_POLICY /

PRODUCT_PACKAGE_OVERLAYS /

DEVICE_PACKAGE_OVERLAYS /

PRODUCT_CONTRIBUTORS_FILE /

PRODUCT_TAGS /

PRODUCT_SDK_ADDON_NAME /

PRODUCT_SDK_ADDON_COPY_FILES /

PRODUCT_SDK_ADDON_COPY_MODULES /

PRODUCT_SDK_ADDON_DOC_MODULE /

PRODUCT_DEFAULT_WIFI_CHANNELS

import-products会调用import-nodes。product_中用到。

define import-products

$(call import-nodes,PRODUCTS,$(1),$(_product_var_list))

endef

inherit-product命令则将在所有的变量值中后缀上'@inherit:'，当import-nodes处理时，会替换成继承的属性。

check-all-products命令借助$(PRODUCTS)诸变量，会对product进行唯一性检查和PRODUCT_NAME,PRODUCT_BRAND,PRODCUT_COPY_FILES的简单检查。

resolve-short-product-name命令，给定Product的短名，返回对应mk的路径。

11. 的分析

同类似，构造了一些命令。有resolve-short-device-name，和import-devices。

Android Make脚本的简记(4)

内容提要

文档简要整理Android的make脚本的内容。以供备忘和参考。

1. 的分析

首先，包含， 其次，定义了一些变量，例如通用的编译参数，package的后缀名等。

随后包含。

接着包含。中会遍历所有product相关的路径，载入所有支持的product的信息到变量集 PRODUCT..中，一个product对应一个。最后根据TARGET_PRODUCT的值，定义各种跟product相关的变量，包括 TARGET_DEVICE变量。

然后包含$(board_config_mk)。$(board_config_mk)是位于

build/target/board/$(TARGET_DEVICE)/，device/*/$(TARGET_DEVICE)/，或vendor

/*/$(TARGET_DEVICE)/目录下的文件。 $(TARGET_DEVICE)已经在product_中定义了。在包含$(board_config_mk)之前，会做检查，多个$(board_config_mk)存在则报错。

定义TARGET_DEVICE_DIR，TARGET_BOOTLOADER_BOARD_NAME，TARGET_CPU_ABI等跟board相关的变量。

接着，依次以HOST_和TARGET_条件包含。这里说明TARGET_的。先定义combo_os_arch，通常是linux-arm，然后定义各种跟编译链接相关的一些变量，最后再包含进build/core/combo/TARGET_linux- 。

再包含，定义javac的命令和通用参数。

随后，定义一些变量，指向通用工具，其中一些是os提供的，例如YACC；一些是froyo编译生成，放在out/host/linux-x86/bin/下，一些是预定义的脚本和工具，例如MKTARBALL。

最后定义了一些编译链接变量，这里专门列出，

HOST_GLOBAL_CFLAGS += $(COMMON_GLOBAL_CFLAGS)

HOST_RELEASE_CFLAGS += $(COMMON_RELEASE_CFLAGS)

HOST_GLOBAL_CPPFLAGS += $(COMMON_GLOBAL_CPPFLAGS)

HOST_RELEASE_CPPFLAGS += $(COMMON_RELEASE_CPPFLAGS)

TARGET_GLOBAL_CFLAGS += $(COMMON_GLOBAL_CFLAGS)

TARGET_RELEASE_CFLAGS += $(COMMON_RELEASE_CFLAGS)

TARGET_GLOBAL_CPPFLAGS += $(COMMON_GLOBAL_CPPFLAGS)

TARGET_RELEASE_CPPFLAGS += $(COMMON_RELEASE_CPPFLAGS)

HOST_GLOBAL_LD_DIRS += -L$(HOST_OUT_INTERMEDIATE_LIBRARIES)

TARGET_GLOBAL_LD_DIRS += -L$(TARGET_OUT_INTERMEDIATE_LIBRARIES)

HOST_PROJECT_INCLUDES:= $(SRC_HEADERS) $(SRC_HOST_HEADERS) $(HOST_OUT_HEADERS)

TARGET_PROJECT_INCLUDES:= $(SRC_HEADERS) $(TARGET_OUT_HEADERS)

ifneq ($(TARGET_SIMULATOR),true)

TARGET_GLOBAL_CFLAGS += $(TARGET_ERROR_FLAGS)

TARGET_GLOBAL_CPPFLAGS += $(TARGET_ERROR_FLAGS)

endif

HOST_GLOBAL_CFLAGS += $(HOST_RELEASE_CFLAGS)

HOST_GLOBAL_CPPFLAGS += $(HOST_RELEASE_CPPFLAGS)

TARGET_GLOBAL_CFLAGS += $(TARGET_RELEASE_CFLAGS)

TARGET_GLOBAL_CPPFLAGS += $(TARGET_RELEASE_CPPFLAGS)

其中的TARGET_PROJECT_INCLUDES包含了SRC_HEADERS，添加头文件路径的话，可以改动SRC_HEADERS。

最后包含进

2. 的分析

中会定义javac的编译命令和通用参数。

CUSTOM_JAVA_COMPILER做为的入口参数，可以考虑openjdk，eclipse。不定义时则使用默认的javac。另外定义为openjdk时，因为prebuilt/对应目录下没有相应的工具，所以还不可用。

依次一般忽略定义CUSTOM_JAVA_COMPILER，只要直接配置自己编译环境的path，指向使用的javac就可以了。

javac在linux平台的定义是

javac -J-Xmx512M -target 1.5 -Xmaxerrs 9999999

-J-Xmx512M，传递给vm launcher参数-Xmx512M，告知起始空间设定为512M。

-target 1.5，编译的结果适用1.5版本。

-Xmaxerrs 9999999，最大输出的错误数是9999999。

3. 的分析

支持两种target: dumpvar-，和dumpvar-abs-。中的 get_build_var和get_abs_build_var就使用了这些target。

使用方法：假设位于$(TOPDIR)路径，

CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core make -f build/core/

dumpvar-

或

CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core make -f build/core/

dumpvar-abs-

第一种形式，返回varName的值。第二种形式，返回varName的值，前缀上路径。考虑到android脚本中广泛使用':=’的变量定义方法，因此，基本上只能显示之前定义的变量值。LOCAL_xxxx的变量也不适用。

4. 的分析

在包含了后，会包含进。

定义了add-clean-step命令。有一个入口参数

$(1)，执行删除操作的具体shell命令。

一般add-clean-step应当在%/脚本中使用，命令会为$(1)定义一个变量保存，变量的名字是 INTERNAL_STEP.$(_acs_id)，所有的$(_acs_id)保存在INTERNAL_STEPS中。$(_acs_id)的值分成3 个部分构造

第一部分是有的路径转化而来，用'_'替代'/'，'-'替代'.'，后缀_acs。第二部分是$(INTERNAL_CLEAN_BUILD_VERSION)，默认是4，第三部分是有'@'组成，中的第几个add- clean-step就用几个@。

例如，packages/apps/Camera/中定义了两个删除动作

$(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/APPS/Camera*)

$(call add-clean-step, rm -rf $(OUT_DIR)/target/common/obj/APPS/Camera*)

那么，对应的有

INTERNAL_es_apps_Camera_CleanSpec-mk_acs4@ := rm -rf

$(PRODUCT_OUT)/obj/APPS/Camera*

INTERNAL_es_apps_Camera_CleanSpec-mk_acs4@@ := rm -rf

$(OUT_DIR)/target/common/obj/APPS/Camera*

接着，包扩进

包含进$(PRODUCT_OUT)/clean_，

接下来，检查CURRENT_CLEAN_BUILD_VERSION是否与INTERNAL_CLEAN_BUILD_VERSION相同，默认是4

如果相同，

执行所有在INTERNAL_STEPS中登记的删除操作。

否则，

删除 $(OUT_DIR)

然后，重新生成$(PRODUCT_OUT)/clean_，写入"CURRENT_CLEAN_BUILD_VERSION :=

$(INTERNAL_CLEAN_BUILD_VERSION)"和"CURRENT_CLEAN_STEPS :=

$(INTERNAL_CLEAN_STEPS)"。

随后，读入$(PRODUCT_OUT)/previous_build_，看是否与当前的编译选项一致，不一致则标明上次的中间文件不可用，则删除相应的中间目录，或提示用户。接着重新将当前的信息写入$(PRODUCT_OUT)/previous_build_，格式是，

current_build_config := /

$(TARGET_PRODUCT)-$(TARGET_BUILD_VARIANT)$(building_sdk)-{$(locale_list)}

echo "PREVIOUS_BUILD_CONFIG := $(current_build_config)" > /

$(previous_build_config_file)

最后，定义了两个target， installclean和dataclean。

dataclean删除的主要是./$(PRODUCT_OUT)/data/*，

installclean的删除包括dataclean。installclean的本意是用于不同build_type编译时删除前次的中间文件。

总结的内容，就3件事，一是载入所有的，二是检查更新clean_和 previous_build_，避免不同编译间的互相干扰。最后是，定义installclean和dataclean。

5. 的分析

首先定义

INTERNAL_CLEAN_BUILD_VERSION := 4

接着使用遍历所有子目录，找到，并包含进。用户可以在中定义自己需要的删除操作。实际上还可以包含不仅仅是删除的操作。

至此，INTERNAL_包含了所有定义的clean动作。

6. version_的分析

在后，会借助$(OUT_DIR)/version_检查版本，如果版本不一致，则重新检查系统文件系统大小写敏感问题，路径上是否含有空格，java和javac的版本，没有问题，则更新version_。

version_中就定义了

VERSIONS_CHECKED := $(VERSION_CHECK_SEQUENCE_NUMBER)

7. showcommands和checkbuild的说明

checkbuild貌似并未使用。

showcommands必须同其它target一同使用，showcommands会详细打印出执行的具体命令内容。

8. 的说明

中定义了大量的命令，其它的mk文件将使用。这其中包括执行编译链接的命令，通常是transform-XXX-to-XXX的形式，例如，transform-cpp-to-o。

其中的inherit-package命令有待研究...

Android101112: Android Make脚本的简记(5)

内容提要

文档简要整理Android的make脚本的内容。以供备忘和参考。

声明

仅限学习交流，禁止商业用途。转载需注明出处。

1. Makefile的分析

首先定义target， 用于生成$(OUT_DOCS)/

再定义target， 用于生成$(TARGET_ROOT_OUT)/

再定义target， 用于生成$(TARGET_OUT)/。文件记录了一系列属性值。它的内容分成两部分，第一部分是一些关于 product,device,build的一般性属性值，第二部分的属性值源自ADDITIONAL_BUILD_PROPERTIES。 product配置mk文件中定义的PRODUCT_PROPERTY_OVERRIDES会加入到 ADDITIONAL_BUILD_PROPERTIES，建议增加property时，直接修改 PRODUCT_PROPERTY_OVERRIDES。

再定义target， 用于生成$(PRODUCT_OUT)/sdk/

再定义target，package-stats，用于生成$(PRODUCT_OUT)/，这个文件包含了.jar,.apk后缀文件的信息。

再定义target，apkcerts-list，用于生成$(name)-apkcerts-$(FILE_NAME_TAG)，描述各module的certificate和private_key文件信息。

接着，如果定义了CREATE_MODULE_INFO_FILE，则生成$(PRODUCT_OUT)/，其中包含了描述所有module的信息。

再定义target，event-log-tags。

接着，处理

再处理，如果TARGET_NO_KERNEL不是true，则将kernel和组装成。

接着，定影命令combine-notice-files，用于生成target，notice_files。notice_files

会抽取生成相应的声明文件。

随后，建立target，otacert，用于将.后缀的认证文件打包存放到$(TARGET_OUT_ETC)/security/。

接着，建立target，recoveryimage，处理recovery img

还有下面的target,

systemimage-nodeps， snod

systemtarball-nodeps，stnod

boottarball-nodeps，btnod

userdataimage-nodeps

userdatatarball-nodeps

otatools

target-files-package

otapackage

installed-file-list

tests-zip-package

dalvikfiles

updatepackage

最后包含进 build/core/task/下的mk文件。

Android Make脚本的简记(3)

2011-07-19 19:59

Email: zcatt@

Blog

内容提要

文档简要整理Android的make脚本的内容。以供备忘和参考。

声明

仅限学习交流，禁止商业用途。转载需注明出处。

版本记录

Date Ver Note

2010-11-10 0.1 Draft. zcatt@Beijing

2010-11-11 0.2 add inherit-product

1. 的分析

中调用了，得到所有子目录下文件的路径。

subdir_makefiles :=

$(shell build/tools/ --prune=out --prune=.repo --prune=.git

$(subdirs) )

$(subdirs)一般编译中取值$(TOP)。

使用方法，

Usage: %(progName)s []

Options:

--mindepth=

Both behave in the same way as their find(1) equivalents.

--prune=

Avoids returning results from inside any directory called

(e.g., "*/out/*"). May be used multiple times.

程序首先依次选取dirlist中的目录，然后遍历所有子目录查找文件，如果有，则加入到返回列表中。

2. 的分析

中定义了一个列表pathmap_INCL，列表中每项是"短名:路径"对。命令include-path-for使用这个 pathmap_INCL列表，输入短名，得到路径。你可以在这个列表中添加自己的对。使用$(call include-path-for, <短名>)就可以得到路径。

另外，定义了FRAMEWORKS_BASE_JAVA_SRC_DIRS，含有frameworks/base目录下含java文件的所有目录。

3. 的分析

首先，包含， 其次，定义了一些变量，例如通用的编译参数，package的后缀名等。

随后包含。

接着包含。

然后包含$(board_config_mk)。$(board_config_mk)是位于build/target/board

/$(TARGET_DEVICE)/，device/*/$(TARGET_DEVICE)/，或vendor/*/$(TARGET_DEVICE) /目录下的文件。

-------TODO

4. 的分析

是用户应当配置的脚本文件，模板可以使用t，放到$(TOP)下。

在中，用户应该配置好主要的参数，例如 TARGET_PRODUCT，

TARGET_BUILD_VARIANT， CUSTOM_MODULES， TARGET_SIMULATOR， TARGET_BUILD_TYPE，

CUSTOM_LOCALES， 和BUILD_ENV_SEQUENCE_NUMBER等。

如果不使用配置参数，也可以使用环境变量的形式。若不配置参数，那么android会使用默认的参数。

5. 的分析

首先包含进version_，定义好一些版本相关的变量。参见version_。

定义CORRECT_BUILD_ENV_SEQUENCE_NUMBER，这个数字用于更新时的提醒，应该同中的或环境变量中的BUILD_ENV_SEQUENCE_NUMBER相等。一般不用关注。

随后检查TARGET_PRODUCT，若为空，则置generic。TARGET_PRODUCT应当在或环境变量中已经定义好。

再检查TARGET_BUILD_VARIANT，若为空，则置eng。TARGET_BUILD_VARIANT应当在或环境变量中已经定义好。

然后包含进product_。

接着，检查$(TARGET_BUILD_VARIANT),取值范围是eng user userdebug tests。

随后判定HOST_OS(linux)，HOST_ARCH(x86)

接着，确定TARGET_ARCH和TARGET_OS，若没有定义，则取默认值。

TARGET_ARCH := arm

TARGET_OS := linux

接着，确定TARGET_BUILD_TYPE，若没有定义，则取默认值。

TARGET_BUILD_TYPE := release

接着，确定OUT_DIR。OUT_DIR是存放中间文件和最终结果的地方。若没有定义，则取默认值。

OUT_DIR := $(TOPDIR)out

随后，定义了一些列的路径变量

DEBUG_OUT_DIR，TARGET_OUT_ROOT_release，TARGET_OUT_ROOT_debug，TARGET_OUT_ROOT，BUILD_OUT，PRODUCT_OUT，TARGET_COMMON_OUT_ROOT，等等。

6. version_的分析

version_是检查一些跟版本相关的变量是否定义，如果未定义，则使用默认值。这些变量包括

PLATFORM_VERSION，默认AOSP

PLATFORM_SDK_VERSION，默认8

PLATFORM_VERSION_CODENAME，默认AOSP

DEFAULT_APP_TARGET_SDK，默认AOSP

BUILD_ID，默认UNKNOWN

BUILD_NUMBER，默认eng.$(USER).$(shell date +%Y%m%d.%H%M%S)的形式。

version_首先包含进build_。用户应当配置build_，而不应该改动version_文件。

然后检查上述变量，如未定义则赋值默认值。

7. build_的分析

用户可以在build_中定义这样几个参数，

PLATFORM_VERSION

PLATFORM_SDK_VERSION

PLATFORM_VERSION_CODENAME

DEFAULT_APP_TARGET_SDK

BUILD_ID

BUILD_NUMBER

这些参数最终将出现中。

Froyo的build_中定义了2个变量，

BUILD_ID，通常用于说明分支branch的，默认的是OPENMASTER，用户应该配置这个参数。

DISPLAY_BUILD_NUMBER，在TARGET_BUILD_VARIANT=user的版本中，中是

是显示成$(BUILD_ID).$(BUILD_NUMBER)，还是显示成$(BUILD_ID)形式。设成true，则显示前者。

8. product_的分析

make PRODUCT--

如果使用上述形式的make命令，那么将等同于

TARGET_PRODUCT:=

TARGET_BUILD_VARIANT:=

goal_name:=PRODUCT--

MAKECMDGOALS:=droid

.PHONY: $(goal_name)

$(goal_name): $(MAKECMDGOALS)

endif

注意,goal的取值范围是user userdebug eng tests，如果不属于上述范围，则将算入MAKECMDGOALS中，此时, TARGET_BUILD_VARIANT := eng。例如

make PRODUCT-dream-installclean

等同于

TARGET_PRODUCT=dream make installclean

使用make PRODUCT--这种形式，可以方便的指定TARGET_PRODUCT，和TARGET_BUILD_VARIANT。

make APP-

如果使用上述形式的make命令，那么将等同于

TARGET_BUILD_APPS:=

unbundled_goals:=APP-

MAKECMDGOALS:=droid

.PHONY: $(unbundled_goals)

$(unbundled_goals): $(MAKECMDGOALS)

使用make APP-这种形式，可以方便的指定TARGET_BUILD_APPS。

注意，PRODUCT--和APP-可以一块使用。

处理完PRODUCT--和APP-，product_会包含下面3个文件

node_

上面的3个mk文件定义了一些命令，用于搜寻product, device对应的目录，生成相应的,和变量。

接着，使用$(call import-products, $(get-all-product-makefiles))遍历Prodcut相关的文件，读入变量。可以去掉文件中下面两句话的注释符，查看。

#$(dump-products)

#$(error done)

随后，使用和TARGET_PRODUCT，得到INTERNAL_PRODUCT信息，即指定product的路径。

再由INTERNAL_PRODUCT得到TARGET_DEVICE， PRODUCT_LOCALES， PRODUCT_BRAND，

PRODUCT_MODEL， PRODUCT_MANUFACTURER， PRODUCT_DEFAULT_WIFI_CHANNELS，

PRODUCT_POLICY， PRODUCT_COPY_FILES， PRODUCT_PROPERTY_OVERRIDES，

PRODUCT_PACKAGE_OVERLAYS， DEVICE_PACKAGE_OVERLAYS， PRODUCT_TAGS，

PRODUCT_OTA_PUBLIC_KEYS。

由PRODUCT_LOCALES导出PRODUCT_AAPT_CONFIG。

ADDITIONAL_BUILD_PROPERTIES中追加PRODUCT_PROPERTY_OVERRIDES中的值。

上面所说的这些值，实际上都是在product的mk文件中定义。

9. node_的分析

定义了一些命令。这些命令在，，和product_中会使用。这里重点说明import-nodes。

import-nodes需要3个入口参数：

$(1)是一个字串，是输出变量的主干名。例如”PRODUCTS"和”DEVICES“。

$(2)是一个makefile文件列表，这些文件中应该含有对$(3)中变量的定义。

$(3)是一个变量列表。

import-nodes会创建这样形式的变量，以$(1)="PRODUCTS", $(2)中含有"build/target/product/", $(3)中含有"PRODUCT_NAME", 而且中定义了PRODUCT_NAME:=core为例，

/target/product/T_NAME:=core

import-nodes中还考虑了inherit的问题，如果某个变量的值中有‘@inherit:’标识后面跟着mk文件名的字串，则会把那个mk文件中相应的变量的属性添加到中。'@inherit:'是inherit-product命令添加的。参见。

在product_中会说明$(2)中的mk文件列表是中的PRODUCT_MAKEFILES定义的。

node_的代码真的很杀伤脑细胞...

10. 的分析

构造了一些命令，供product_中使用。

_find-android-products-files这个命令会得到device/和vendor/, 包括子目录，以及build/target/product/下的文件列表。

get-all-product-makefiles这个命令会得到所有$(_find-android-products-files)的文件中PRODUCT_MAKEFILES变量定义的mk文件。

_product_var_list对应的是import-nodes命令的$(3), 定义了会生成那些PRODUCT属性名的变量。这些变量实际也是在product的mk文件中要考虑定义的。

_product_var_list :=

PRODUCT_NAME

PRODUCT_MODEL

PRODUCT_LOCALES

PRODUCT_PACKAGES

PRODUCT_DEVICE

PRODUCT_MANUFACTURER

PRODUCT_BRAND

PRODUCT_PROPERTY_OVERRIDES

PRODUCT_COPY_FILES

PRODUCT_OTA_PUBLIC_KEYS

PRODUCT_POLICY

PRODUCT_PACKAGE_OVERLAYS

DEVICE_PACKAGE_OVERLAYS

PRODUCT_CONTRIBUTORS_FILE

PRODUCT_TAGS

PRODUCT_SDK_ADDON_NAME

PRODUCT_SDK_ADDON_COPY_FILES

PRODUCT_SDK_ADDON_COPY_MODULES

PRODUCT_SDK_ADDON_DOC_MODULE

PRODUCT_DEFAULT_WIFI_CHANNELS

import-products会调用import-nodes。product_中用到。

define import-products

$(call import-nodes,PRODUCTS,$(1),$(_product_var_list))

endef

inherit-product命令则将在所有的变量值中后缀上'@inherit:'，当import-nodes处理时，会替换成继承的属性。

check-all-products命令借助$(PRODUCTS)诸变量，会对product进行唯一性检查和PRODUCT_NAME,PRODUCT_BRAND,PRODCUT_COPY_FILES的简单检查。

resolve-short-product-name命令，给定Product的短名，返回对应mk的路径。

11. 的分析

同类似，构造了一些命令。有resolve-short-device-name，和import-devices。