Android.mk文件语法规范及使用-白红宇

Android.mk文件语法规范及使用

阅读量：5784 次

发布时间：2019-06-18

本文共 12797 字，大约阅读时间需要 42 分钟。

from:

1.概述

Android.mk编译文件是用来向Android NDK描述你的C,C++源代码文件的。具体来说：

该文件是GNU Makefile的一小部分，会被编译系统解析一次或更多次的build系统。因此，您应尽量减少您声明的变量，不要认为某些变量在解析过程中不会被定义。

这个文件的语法允许把你的源代码组织成模块，一个模块属下列类型之一：

静态库

共享库

只有共享库将被安装/复制到您的应用软件包。虽然静态库能被用于生成共享库。你可以在每一个Android.mk file中定义一个或多个模块，你也可以在几个模块中使用同一个源代码文件。

2.样例简析

在描述语法细节之前，咱们来看一个简单的"hello world"的例子，比如，下面的文件：

sources/helloworld/helloworld.c

sources/helloworld/Android.mk

'helloworld.c'是一个JNI共享库，实现返回"hello world"字符串的原生方法。

相应的Android.mk文件会象下面这样：

---------- cut here ------------------

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE:= helloworld

LOCAL_SRC_FILES := helloworld.c

include $(BUILD_SHARED_LIBRARY)

---------- cut here ------------------

好，我们来解释一下这几行代码：

LOCAL_PATH:= $(call my-dir)

一个Android.mk file首先必须定义好LOCAL_PATH变量。它用于在开发树中查找源文件。在这个例子中，宏函数’my-dir’, 由编译系统提供，用于返回当前路径（即包含Android.mk file文件的目录）。

include $( CLEAR_VARS)

CLEAR_VARS由编译系统提供，指定让GNU MAKEFILE为你清除许多LOCAL_XXX变量（例如 LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, 等等...),

除LOCAL_PATH 。这是必要的，因为所有的编译控制文件都在同一个GNU MAKE执行环境中，所有的变量都是全局的。

LOCAL_MODULE := helloworld

LOCAL_MODULE变量必须定义，以标识你在Android.mk文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。注意编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为'foo'的共享库模块，将会生成'libfoo.so'文件。

重要注意事项

如果你把库命名为‘libhelloworld’，编译系统将不会添加任何的lib前缀，也会生成libhelloworld.so，这是为了支持来源于Android平台的源代码的Android.mk文件，如果你确实需要这么做的话。

LOCAL_SRC_FILES := helloworld.c

LOCAL_SRC_FILES变量必须包含将要编译打包进模块中的C或C++源代码文件。注意，你不用在这里列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。【注意，默认的C++源码文件的扩展名是’.cpp’. 指定一个不同的扩展名也是可能的，只要定义LOCAL_DEFAULT_CPP_EXTENSION变量，不要忘记开始的小圆点（也就是定义为‘.cxx’,而不是‘cxx’）（当然这一步我们一般不会去改它）】

include $(BUILD_SHARED_LIBRARY)

BUILD_SHARED_LIBRARY是编译系统提供的变量，指向一个GNU Makefile脚本（应该就是在build/core目录下的shared_library.mk），负责收集自从上次调用'include $(CLEAR_VARS)'以来，定义在LOCAL_XXX变量中的所有信息，并且决定编译什么，如何正确地去做。并根据其规则生成静态库。同理对于静态库。

3.深入分析

下面我们尝试从一个小模块逐步对android build system做一个深入剖析。选择的这个模块名字叫做acp ，源码位于build\tools\acp目录。

后续很多模块的编译都需要使用到acp，根据编译依赖一般会先编译本模块。当然它也需要依赖到其他文件，需要的时候我们再进行阐述。

acp的Android.mk比较简单，去掉的无用代码后，如下面所示：

Makefile代码

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_SRC_FILES := acp.c

LOCAL_STATIC_LIBRARIES := libhost

LOCAL_C_INCLUDES := build/libs/host/include

LOCAL_MODULE := acp

LOCAL_ACP_UNAVAILABLE := true

include $(BUILD_HOST_EXECUTABLE)

上面的语句大致的意思就是，使用当前路径下的acp.c源码，引用的include和链接的library都是host模块，最终编译生成一个可在当前主机运行的可执行文件，名字为acp(linux环境)。。

这里我们先不谈每一个变量的具体含义和使用，我们先大概看一下一个Android.mk的基本组成。

LOCAL_PATH 定义了当前模块的相对路径，必须出现在所有的编译模块之前

每个编译模块由include $(CLEAR_VARS) 开始，由include $(BUILD_XXX) 结束

include $(CLEAR_VARS) 是一个编译模块的开始，它会清空除LOCAL_PATH之外的所有LOCA_XXX变量

include $(BUILD_XXX) 描述了编译目标

LOCAL_SRC_FILES 定义了本模块编译使用的源文件，采用的是基于LOCAL_PATH的相对路径

LOCAL_MODULE 定义了本模块的模块名

编译acp还需要了几个可选的变量：

LOCAL_STATIC_LIBRARIES 表示编译本模块时需要链接的静态库

LOCAL_C_INCLUDES 表示了本模块需要引用的include文件

LOCAL_ACP_UNAVAILABLE 表示是否支持acp，如果支持acp，则使用acp进行拷贝，否则使用linux cp拷贝，本模块编译acp，当然是不支持acp了

编译目标

上面我们用到include $(CLEAR_VARS)和include $(BUILD_HOST_EXECUTABLE)，那么他们是在哪里定义的呢？除了BUILD_HOST_EXECUTABLE还有哪些BUILD_XXX目标呢？

它们的定义位于build/core/config.mk文件，当然config.mk文件定义的编译目标也很多，下面列举几个常用的目标：

编译目标	说明
BUILD_HOST_STATIC_LIBRARY	主机上的静态库
BUILD_HOST_SHARED_LIBRARY	主机上的动态库
BUILD_HOST_EXECUTABLE	主机上的可执行文件
BUILD_STATIC_LIBRARY	目标设备上的静态库
BUILD_SHARED_LIBRARY	目标设备上的动态库
BUILD_EXECUTABLE	目标设备上的可执行文件
BUILD_JAVA_LIBRARY	JAVA库
BUILD_STATIC_JAVA_LIBRARY	静态JAVA库
BUILD_HOST_JAVA_LIBRARY	主机上的JAVA库
BUILD_PACKAGE	APK程序

具体的每一个目标，等我们遇到的时候我们再详细进行讲解，先重点分析 LOCAL_PATH：

有人就问了，在本Android.mk中又没有使用到LOCAL_PATH，为什么先要定义这么一个变量呢？为什么规定必须放在所有的include $(CLEAR_VARS)之前呢？

在Android.mk中我们发现有LOCAL_SRC_FILES := acp.的定义，NDK文件中对LOCAL_SRC_FILES 的说明如下：

This is a list of source files that will be built for your module. Only list the files that will be passed to a compiler, since the build system automatically computes dependencies for you.

Note that source files names are all relative to LOCAL_PATH and you can use path components .

因此在定义LOCAL_SRC_FILES 时已经间接的使用到了LOCAL_PATH变量，即定义LOCAL_SRC_FILES是用的基于当前路径的相对路径。

我们接着看看为什么LOCAL_PATH的定义必须要放到所有的include $(CLEAR_VARS)之前。

LOCAL_PATH通过调用my-dir函数来获取当前的路径，my-dir函数的定义位于core/definitions.mk文件：

Makefile代码

<span style="font-size: small;"># Figure out where we are.

define my-dir

$(strip \

$(eval md_file_ := $$(lastword $$(MAKEFILE_LIST))) \

$(if $(filter $(CLEAR_VARS),$(md_file_)), \

$(error LOCAL_PATH must be set before including $$(CLEAR_VARS)) \

$(patsubst %/,%,$(dir $(md_file_))) \

)

endef

请注意，这里明确的说明了LOCAL_PATH的定义必须要放在任何include $(CLEAR_VARS)语句之前，如果不这么做的话，编译就直接报错，停止不干了。

可是它是怎么判断LOCAL_PATH的定义是在任何include $(CLEAR_VARS)语句之前呢，我们看到有这么一句话：

Makefile代码

$(if $(filter $(CLEAR_VARS),$(md_file_))

这个判断语句是个关键，我们先看看CLEAR_VARS变量的定义

CLEAR_VARS

在build/core/config.mk中有如下明确的定义：

Makefile代码

CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk

而BUILD_SYSTEM的定义在build/core/main.mk文件中：

BUILD_SYSTEM := $(TOPDIR)build/core

Makefile代码

BUILD_SYSTEM := $(TOPDIR)build/core

紧接着：

Makefile代码

TOPDIR :=

即TOPDIR为android源码的根目录， BUILD_SYSTEM= build/core，所以CLEAR_VARS变量的值就为build/core/clear_vars.mk，当然这个也是相对于Android源码根路径。

得到了CLEAR_VARS变量的值，我们再回到my-dir函数中。

my-dir

根据gnu make定义，gnu make 会自动将所有读取的makefile路径都会加入到MAKEFILE_LIST变量中，而且是按照读取的先后顺序添加。

那么，在运行本makefile文件时，$(MAKEFILE_LIST)字符串中最后一个makefile肯定是最后读取的makefile，即$(lastword $(MAKEFILE_LIST))则会返回build/tools/acp/Android.mk，此字符串经过$(eval md_file_ := $$(lastword $$(MAKEFILE_LIST))运算，赋值给了临时变量md_file_。

判断md_file_中是否包含CLEAR_VARS变量的值$(if $(filter $(CLEAR_VARS),$(md_file_))，肯定也就会返回失败，再通过$(patsubst %/,%,$(dir $(md_file_)))函数，则会得到当前路径，即build/tools/acp

如果我们在include $(CLEAR_VARS)之后，再调用my-dir函数，那么$$(lastword $$(MAKEFILE_LIST))肯定就会返回$(BUILD_SYSTEM)/clear_vars.mk，同时，$(patsubst %/,%,$(dir $(md_file_))) 也就会返回$(BUILD_SYSTEM)的值build/core，而不是当前的路径build/tools/acp。

这么一来得到的LOCAL_PATH的值就是错误的值，依赖LOCAL_PATH的其他变量也就更加不可能是正确的了！所以说，LOCAL_PATH必须要在任何including $(CLEAR_VARS))之前定义。

讨论完LOCAL_PATH，我们紧接着来看看LOCAL_SRC_FILES。

LOCAL_SRC_FILES：

Makefile代码

LOCAL_SRC_FILES := acp.c

LOCAL_SRC_FILES变量的意思见名知意，很明显是用来记录当前模块的源文件列表的一个变量。

这里是他的赋值，我们下面来看看他的使用的地方。在build/core/binary.mk中有如下的部分：

Makefile代码

###########################################################

## C: Compile .c files to .o.

###########################################################

c_arm_sources := $(patsubst %.c.arm,%.c,$(filter %.c.arm,$(LOCAL_SRC_FILES)))

c_arm_objects := $(addprefix $(intermediates)/,$(c_arm_sources:.c=.o))

c_normal_sources := $(filter %.c,$(LOCAL_SRC_FILES))

c_normal_objects := $(addprefix $(intermediates)/,$(c_normal_sources:.c=.o))

$(c_arm_objects): PRIVATE_ARM_MODE := $(arm_objects_mode)

$(c_arm_objects): PRIVATE_ARM_CFLAGS := $(arm_objects_cflags)

$(c_normal_objects): PRIVATE_ARM_MODE := $(normal_objects_mode)

$(c_normal_objects): PRIVATE_ARM_CFLAGS := $(normal_objects_cflags)

c_objects := $(c_arm_objects) $(c_normal_objects)

ifneq ($(strip $(c_objects)),)

$(c_objects): $(intermediates)/%.o: $(TOPDIR)$(LOCAL_PATH)/%.c $(yacc_cpps) $(proto_generated_headers) $(LOCAL_ADDITIONAL_DEPENDENCIES)

$(transform-$(PRIVATE_HOST)c-to-o)

-include $(c_objects:%.o=%.P)

endif

分析上面的代码，

1. 我们首先从LOCAL_SRC_FILES中得到所有的C文件

c_normal_sources value acp.c

2. 定义一个变量，c_normal_objects，用来表示生成的.o文件的路径

c_normal_objects value out/host/linux-x86/obj/EXECUTABLES/acp_intermediates/acp.o

其中，$(c_normal_sources:.c=.o)会返回acp.o，那么c_normal_objects的关键就是$(intermediates)变量

intermediates

通过查找，我们可以发现在以下地方有intermediates的赋值：

Makefile代码

build/core/host_java_library.mk:intermediates := $(call local-intermediates-dir)

build/core/base_rules.mk:intermediates := $(call local-intermediates-dir)

build/core/dynamic_binary.mk:guessed_intermediates := $(call local-intermediates-dir)

build/core/java.mk:intermediates := $(call local-intermediates-dir)

即，他们的都是调用local-intermediates-dir函数获取当前的intermediates的值

在build/core/definitions.mk中有local-intermediates-dir函数的定义：

Makefile代码

# Uses LOCAL_MODULE_CLASS, LOCAL_MODULE, and LOCAL_IS_HOST_MODULE

# to determine the intermediates directory.

# $(1): if non-empty, force the intermediates to be COMMON

define local-intermediates-dir

$(strip \

$(if $(strip $(LOCAL_MODULE_CLASS)),, \

$(error $(LOCAL_PATH): LOCAL_MODULE_CLASS not defined before call to local-intermediates-dir)) \

$(if $(strip $(LOCAL_MODULE)),, \

$(error $(LOCAL_PATH): LOCAL_MODULE not defined before call to local-intermediates-dir)) \

$(call intermediates-dir-for,$(LOCAL_MODULE_CLASS),$(LOCAL_MODULE),$(LOCAL_IS_HOST_MODULE),$(1)) \

)

endef

根据注释，我们知道 local-intermediates-dir的定义会依赖于LOCAL_MODULE_CLASS, LOCAL_MODULE, 和 LOCAL_IS_HOST_MODULE这三个变量的值。

我们先通过添加打印的方式，得到如下三个变量的值：

LOCAL_MODULE_CLASS value EXECUTABLES

LOCAL_MODULE value acp

LOCAL_IS_HOST_MODULE value true

其中，LOCAL_MODULE 的值是acp，这个肯定的是没问题的，因为在acp模块的Android.mk文件中有明确的定义：LOCAL_MODULE := acp

那LOCAL_MODULE_CLASS 为什么是EXECUTABLES呢？我们这里先猜一下，估计是和最后一句include $(BUILD_HOST_EXECUTABLE )有关，

同样，LOCAL_IS_HOST_MODULE 为true，估计也是和include $(BUILD_HOST _EXECUTABLE)有关了。

我们还是先回到 local-intermediates-dir函数中，其中前两个判断是判断是否定义LOCAL_MODULE_CLASS和LOCAL_MODULE，如果未空，则直接报错，这里也就说明了在每一个编译模块中（即include $(CLEAR_VARS)和include $(BUILD_XXX)之间）必须定义LOCAL_MODULE的值。

因此，如果LOCAL_MODULE_CLASS和LOCAL_MODULE都不为空时，则执行intermediates-dir-for这个函数，$(LOCAL_MODULE_CLASS),$(LOCAL_MODULE),$(LOCAL_IS_HOST_MODULE)还有 local-intermediates-dir函数的第一个参数 $(1)会作为参数传给intermediates-dir-for函数。根据上面intermediates的赋值部分的代码，我们知道调用local-intermediates-dir函数时没有传递任何参数，因此此时的$(1)即为空，传给intermediates-dir-for函数的也就只有上述的3个参数。

intermediates-dir-for

下面我们来看intermediates-dir-for

Makefile代码