1、前言
Android.mk用于向编译系统描述源文件和共享库，它实际上是编译系统解析一次或多次的微小GNU makefile片段。它的语法支持将源文件分组为模块，模块是静态库、共享库或独立的可执行文件。
2、简单示例
首先来看一个最简单的Android.mk的例子，如下所示：
# A simple Android.mk LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_SRC_FILES := hello.c LOCAL_MODULE := helloworld include $(BUILD_EXECUTABLE)
对该Android.mk文件进行解析，如下：
LOCAL_PATH := $(call my-dir)
每个Android.mk文件必须以定义LOCAL_PATH为开始，它用于在开发项目文件中查找源文件，而宏my-dir则由编译系统提供，返回包含Android.mk的目录路径。
include $(CLEAR_VARS)
CLEAR_VARS变量由编译系统提供，并指向一个特定的GNU Makefile，由它负责清理很多LOCAL_XXX的值，例如：LOCAL_MODULE、LOCAL_SRC_FILES等，但是不清理LOCAL_PATH，这个清理动作是必须的，因为所有的编译控制文件由同一个GNU Make解析和执行，其变量是全局的，清理后才能避免相互影响。
LOCAL_SRC_FILES := hello.c
LOCAL_SRC_FILES变量必须包含将要打包成模块的C/C++源文件，不必列出头文件，编译系统会自动找出依赖的文件，缺省的C++源码的拓展名为.cpp，也可以通过LOCAL_CPP_EXTENSION进行修改。
LOCAL_MODULE := helloworld
LOCAL_MODULE模块必须定义，以表示Android.mk中的每一个模块，名字必须唯一并且不包含空格，Build System会自动添加适当的前缀和后缀。
include $(BUILD_EXECUTABLE)
BUILD_EXECUTABLE是编译系统提供的一个变量，指向一个特定的GNU Makefile脚本，表示要编译成一个可执行的文件，如果想编译成动态库则可以用BUILD_SHARED_LIBRARY，如果想编译成静态库则可以用BUILD_STATIC_LIBRARY。
3、保留的变量
在编写Android.mk文件时应该使用或者定义的变量，可以视具体情况定义其他的变量，但是NDK编译环境保留以下变量名：
（1）LOCAL_开头的变量名（例如：LOCAL_MODULE）
（2）PRIVATE、NDK_以及APP_开头的变量名（内部使用）
（3）小写命名（内部使用，如my-dir）
如果要在Android.mk文件中定义自己的变量，建议使用前缀MY_开头，例如：
MY_SOURCES := foo.c ifneq ($(MY_CONFIG_BAR),) MY_SOURCES += bar.c LOCAL_SRC_FILES += $(MY_SOURCES)
4、NDK提供的变量
GNU Make在解析Android.mk文件之前由编译环境定义的一些变量，需要注意的是，在某些条件下，NDK可能会多次解析你的Android.mk文件，每一次都会为某些变量进行不同的定义。
（1）CLEAR_VARS
指向一个脚本，取消定义在模块变量下面几乎所有的LOCAL_XXX的定义，必须在一个新的模块下面包含这个脚本，如：
include $(CLEAR_VARS)
（2）BUILD_SHARED_LIBRARY
指向一个脚本，收集你提供的所有LOCAL_XXX变量的信息，决定如何根据你列出的源文件编译对应的共享库，注意，在包含这个脚本之前，你必须至少已经定义了LOCAL_MODULE和LOCAL_SRC_FILES，如：
include $(BUILD_SHARED_LIBRARY)
注意：这会生成一个名为lib$(LOCAL_MODULE).so文件。
（3）BUILD_STATIC_LIBRARY
该变量类似于BUILD_SHARED_LIBRARY，用来编译生成静态库，静态库不会拷贝到你的工程，但是可以用来生成共享库，如：
include $(BUILD_STATIC_LIBRARY)
注意：这会生成一个名为lib$(LOCLA_MODULE).a文件。
（4）PREBUILT_SHARED_LIBRARY
指定一个脚本，用来指定一个预置的共享库，和BUILD_SHARED_LIBRARY以及BUILD_SHARED_LIBRARY不同的是，LOCAL_SRC_FILES的值必须是一个预置共享库的路径，而不是一个源文件，如foo/libfoo.so文件，还可以在另一个模块中使用LOCAL_PREBUILTS变量来引用预置库。
（5）PREBUILT_STATIC_LIBRARY
和PREBUILT_SHARED_LIBRARY类似，但指定一个静态库。
（6）TARGET_ARCH
由AOSP指定的CPU架构名称，arm表示与ARM兼容。
（7）TARGET_PLATFORM
解析Android.mk时，目标Android平台的名称。
（8）TARGET_ARCH_ABI
解析Android.mk时，目标CPU+ABI的名称，如armeabi-v7a。
（9）TARGET_ABI
目标平台和abi的连接，由$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI)定义。
5、NDK提供的函数宏
下面是GNU Make的宏方法，必须使用$(call <function>)的形式使用，返回文本信息。
（1）my-dir
返回上一个包含Makefile文件的路径，通常是当前Android.mk的目录，在Android.mk文件起始位置定义LOCAL_PATH时很有用，如：
LOCAL_PATH := $(call my-dir)
注意：由于GNU Make的工作方式，该方法返回在解析编译脚本时最后一次包含Makefile文件的路径，在包含其他文件之后不要调用my-dir，例如下面的例子：
# Android.mk LOCAL_PATH := $(call my-dir) # Declare one module ... include $(LOCAL_PATH)/foo/Android.mk # Declare another module ...
这里的问题是，第二次调用my-dir会将LOCAL_PATH定义为$(LOCAL_PATH)/foo/而不是$(LOCAL_PATH)。
基于上面的这个原因，在一个Android.mk文件中，将额外的包含动作放在所有内容的后面，如下：
# Android.mk LOCAL_PATH := $(call my-dir) # Declare one module ... LOCAL_PATH := $(call my-dir) # Declare another module ... # Extra include at the end of Android.mk include $(LOCAL_PATH)/foo/Android.mk
还可以用一个变量保存第一次调用my-dir的值，如下：
# Android.mk MY_LOCAL_PATH := $(call my-dir) LOCAL_PATH := $(MY_LOCAL_PATH) # Declare one module ... includ $(LOCAL_PATH)/foo/Android.mk LOCAL_PATH := $(MY_LOCAL_PATH) # Declare another module ...
（2）all-subdir-makefiles
返回位于当前my-dir路径下的所有子目录中的Android.mk组成的列表，例如下面的结构：
sources/foo/Android.mk sources/foo/lib1/Android.mk sources/foo/lib2/Android.mk
如果source/foo/Android.mk文件中包含了这句：
include $(call all-subdir-makefiles)
那么，source/foo/lib1/Android.mk和source/foo/lib2/Android.mk会自动地被包含进来。
（3）this-makefile
返回当前Makefile文件的路径。
（4）parent-makefile
返回包含树中父Makefile文件的路径，如包含当前Makefile的Makefile的路径。
（5）grand-parent-makefile
与parent-makefile类似。
（6）import-module
该方法通过名字查找和包含另一个模块，通常的用法是：
$(call import-module,<name>)
该方法会在NDK_MODULE_PATH环境变量中查找标签为<name>的模块，然后自动地将它的Android.mk包含进来。
6、模块描述变量
下面的变量用来向编译环境描述模块，应该在include $(CLEAR_VARS)和include $(BUILD_XXX)之间定义这些变量，$(CLEAR_VARS)会取消定义或者清除所有这些变量。
（1）LOCAL_PATH
这个变量表示当前文件所在的路径，必须在Android.mk的开始处定义，可以由下面的命令来完成：
LOCAL_PATH := $(call my-dir)
$(CLEAR_VARS)不会清除该变量，因此，每个Android.mk只需定义一次即可。
（2）LOCAL_MODULE
模块的名字，每一个模块的名字必须唯一并且不含空格，必须在包含$(BUILD_XXX)脚本之前定义这个变量，默认的，这个名字决定了生成文件的名字，如名为<foo>的模块，共享库的名字为lib<foo>.so。
（3）LOCAL_MODULE_FILENAME
这个变量是可选的，帮助重新定义生成文件的名字，默认的情况下，<foo>模块会按照Unix的一般标准生成名为lib<foo>.a的静态库或者名为lib<foo>.so的共享库，可以通过LOCAL_MODULE_FILENAME重新定义生成文件的名字，如下：
# Android.mk LOCAL_MODULE := foo-version-1 LOCAL_MODULE_FILENAME := libfoo
注意：不要在LOCAL_MODULE_FILENAME中放路径或者拓展名，这些会被编译系统自动处理。
（4）LOCAL_SRC_FILES
用来编译的模块的源文件列表，只需要列出需要被传给编译器的文件，编译环境会自动计算依赖关系，所有的源文件名是相对LOCAL_PATH的，也可以使用路径分隔符，如：
LOCAL_SRC_FILES := foo.c
fun/bar.c
（5）LOCAL_CPP_EXTENSIONS
这是一个可选的变量，用来指示C++的源文件的文件拓展名，默认的是.cpp，但是可以改变它，如：
LOCAL_CPP_EXTENSION := .cxx
（6）LOCAL_C_INCLUDES
这是可选的变量，相对NDK根目录的相对路径列表，在编译所有的源文件时会被添加到搜索路径后面，如：
LOCAL_C_INCLUDES := sources/foo
or
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
它们需要放置在LOCAL_CFLAGS/LOCAL_CPPFLAGS之前，在使用ndk-gdb进行native调试时将自动使用LOCAL_C_INCLUDES路径。
（7）LOCAL_CFLAGS
这是一个可选的变量，编译C/C++源文件时的编译器flags，可以用来指定额外的宏定义和编译选项。
（8）LOCAL_CXXFLAGS
LOCAL_CPPFLAGS的别名。
（9）LOCAL_CPPFLAGS
可选的变量，编译C++文件时编译器flags，在编译器命令行中，他们出现在LOCAL_CFLAGS之后。
（10）LOCAL_STATIC_LIBRARIES
需要链接到这个模块的静态库module（使用BUILD_STATIC_LIBRARY编译的）列表，只在共享库中有用。
（11）LOCAL_SHARED_LIBRARIES
该模块在运行时需要依赖的共享库列表，在链接时需要，并在生成文件中嵌入相应的信息。
（12）LOCAL_LDLIBS
编译模块时需要的额外链接flags列表，传递指定的以-l为前缀的系统库，例如，下面的指令会告诉链接器生成一个在加载的时候链接到/system/lib/libz.so的模块：
LOCAL_LDLIBS := -lz
（13）LOCAL_ALLOW_UNDEFINED_SYMBOLS
默认情况下，在编译共享数据库时会遇到未定义的引用，导致未定义符号的错误，这对在源码中抓取log的作用很大，但是，如果考虑到某些原因需要关闭这个选项，将变量设置为true即可。
（14）LOCAL_ARM_MODE
默认情况下，以thumb模式生成ARM目标二进制，每一个指令都是16比特宽，如果想强制生成arm（32比特指令）模式下的模块，可以定义这个变量为arm，如下：
LOCAL_ARM_MODE := arm
也可以通过在源文件名称后面添加后缀.arm的方式编译系统以指定的arm模式编译源文件，如：
LOCAL_SRC_FILES := foo.c bar.c.arm
这会告诉编译系统以arm模式编译bar.c，但根据LOCAL_ARM_MODE的值编译foo.c。
（15）LOCAL_ARM_NENO
定义这个变量为true允许在C/C++文件中使用ARM Advanced SIMD GCC（也叫NEON）指令，就像在程序集文件中使用NEON指令一样。
（16）LOCAL_CFLAGS
定义这个变量来记录一组C/C++编译flags，这些会被添加到使用这个变量的模块的LOCAL_STATIC_LIBRARIES或者LOCAL_SHARED_LIBRARIES的LOCAL_CFLAGS中，例如：
# Define "foo" module include $(CLEAR_VARS) LOCAL_MODULE := foo LOCAL_SRC_FILES := foo/foo.c include $(BUILD_STATIC_LIBRARY) # Define "bar" module include $(CLEAR_VARS) LOCAL_MODULE := bar LOCAL_SRC_FILES := bar.c LOCAL_CFLAGS := -DBAR=2 LOCAL_STATIC_LIBRARYS := foo include $(BUILD_SHARED_LIBRARY)
在编译bar.c时会将-DFOO=1 –DBAR=2传给编译器，exported flags会被一层一层的传递，如果zoo依赖于bar，而bar依赖于foo，那么foo中的所有flags会被传给zoo，exported flags在当前module编译时不会被使用，在上面，编译foo/foo.c时不会传递-DFOO=1。
（17）LOCAL_EXPORT_CPPFLAGS
和LOCAL_EXPORT_CFLAGS一样，但是只对C++文件。
（18）LOCAL_EXPORT_C_INCLUDES
和LOCAL_EXPORT_CFLAGS一样，但记录的是C头文件路径。
（19）LOCAL_EXPORT_LDLIBS
和LOCAL_EXPORT_CFLAGS一样，记录链接器flags，导入的链接器flags会被添加到模块的LOCAL_LDLIBS中，这由Unix链接器的工作方式决定，当foo是一个静态库并且部分代码依赖系统库，该变量将会很有用，LOCAL_EXPORT_LDLIBS可以被用来导出依赖，如：
# Define "foo" module include $(CLEAR_VARS) LOCAL_MODULE := foo LOCAL_SRC_FILES := foo/foo.c LOCAL_EXPORT_LDLIBS := -llog include $(BUILD_STATIC_LIBRARY) # Define "bar" module include $(CLEAR_VARS) LOCAL_MODULE := bar LOCAL_SRC_FILES := bar.c LOCAL_STATIC_LIBRARY := foo include $(BUILD_SHARED_LIBRARY)
这里，libbar.so在链接时编译-llog，表示它依赖于系统日志库，因为它依赖于foo。
（20）LOCAL_FILTER_ASM
使用一个shell命令定义这个变量，用来过滤LOCAL_SRC_FILES中的或者由其生成的程序集文件。