1. Android编译系统分析 ---系统变量解析
LOCAL_PATH - 编译时的目录
LOCAL_MODULE - 编译的目标对象
LOCAL_SRC_FILES - 编译的源文件
LOCAL_C_INCLUDES - 需要包含的头文件目录
LOCAL_SHARED_LIBRARIES - 链接时需要的外部库
LOCAL_PRELINK_MODULE - 是否需要prelink处理
BUILD_STATIC_LIBRARY - 指明要编译成静态库
BUILD_SHARED_LIBRARY - 指明要编译成动态库
(1). LOCAL_PATH - 编译时的目录
$(call 目录,目录….) 目录引入操作符: 如该目录下有个文件夹名称 src,则可以这样写 $(call src),那么就会得到 src 目录的完整路径
(2). include $(CLEAR_VARS) -清除之前的一些系统变量
CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk
在 build/core/config.mk 定义 CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk
通过include 包含自定义的.mk文件(即是自定义编译规则)或是引用系统其他的.mk文件(系统定义的编译规则)。
(3). LOCAL_SRC_FILES - 编译的源文件
可以是.c, .cpp, .java, .S(汇编文件)或是.aidl等格式, 不同的文件用空格隔开。
如果编译目录子目录,采用相对路径,如子目录/文件名。
也可以通过$(call 目录),指明编译某目录下所有.c/.cpp/.java/.S/ .aidl文件. 追加文件 LOCAL_SRC_FILES += 文件
(4). LOCAL_C_INCLUDES - 需要包含的头文件目录
可以是系统定义路径,也可以是相对路径. 如该编译目录下有个include目录,写法是include/*.h
(5). LOCAL_MODULE - 编译的目标对象
module 是指系统的 native code,通常针对c,c++代码
./system/core/sh/Android.mk:32:LOCAL_MODULE:= sh
./system/core/libcutils/Android.mk:71:LOCAL_MODULE := libcutils
./system/core/cpio/Android.mk:9:LOCAL_MODULE := mkbootfs
./system/core/mkbootimg/Android.mk:8:LOCAL_MODULE := mkbootimg
./system/core/toolbox/Android.mk:61:LOCAL_MODULE:= toolbox
./system/core/logcat/Android.mk:10:LOCAL_MODULE:= logcat
./system/core/adb/Android.mk:65:LOCAL_MODULE := adb
./system/core/adb/Android.mk:125:LOCAL_MODULE := adbd
./system/core/init/Android.mk:20:LOCAL_MODULE:= init
./system/core/vold/Android.mk:24:LOCAL_MODULE:= vold
./system/core/mountd/Android.mk:13:LOCAL_MODULE:= mountd
(6). LOCAL_PACKAGE_NAME
Java 应用程序的名字用该变量定义
./packages/apps/Music/Android.mk:9:LOCAL_PACKAGE_NAME := Music
./packages/apps/Browser/Android.mk:14:LOCAL_PACKAGE_NAME := Browser
./packages/apps/Settings/Android.mk:8:LOCAL_PACKAGE_NAME := Settings
./packages/apps/Stk/Android.mk:10:LOCAL_PACKAGE_NAME := Stk
./packages/apps/Contacts/Android.mk:10:LOCAL_PACKAGE_NAME := Contacts
./packages/apps/Mms/Android.mk:8:LOCAL_PACKAGE_NAME := Mms
./packages/apps/Camera/Android.mk:8:LOCAL_PACKAGE_NAME := Camera
./packages/apps/Phone/Android.mk:11:LOCAL_PACKAGE_NAME := Phone
./packages/apps/VoiceDialer/Android.mk:8:LOCAL_PACKAGE_NAME := VoiceDialer
(7). 依赖库
LOCAL_SHARED_LIBRARIES - 链接时需要的外部共享库
LOCAL_STATIC_LIBRARIES - 链接时需要的外部外部静态
LOCAL_JAVA_LIBRARIES 加入jar包
(8). BUILD_SHARED_LIBRARY - 指明要编译成动态库。编译的目标,用include 操作符
BUILD_STATIC_LIBRARY --- 来指明要编译成静态库。
如果是java文件的话,用 BUILD_PACKAGE 来指明。会用到系统的编译脚本host_java_library.mk,
-------------------
include $(BUILD_STATIC_LIBRARY)
BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk
-------------------
include $(BUILD_SHARED_LIBRARY)
./build/core/config.mk:50:BUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mk
-------------------
include $(BUILD_HOST_SHARED_LIBRARY)
BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk
-------------------
include $(BUILD_EXECUTABLE)
build/core/config.mk:51:BUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mk
-------------------
include $(BUILD_HOST_EXECUTABLE)
./build/core/config.mk:53:BUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mk
-------------------
BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
-------------------
BUILD_JAVA_LIBRARY
./build/core/config.mk:58:BUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mk
------------------
BUILD_STATIC_JAVA_LIBRARY 编译静态JAVA库
./build/core/config.mk:59:BUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mk
------------------
BUILD_HOST_JAVA_LIBRARY 编译本机用的JAVA库
./build/core/config.mk:60:BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
------------------
BUILD_HOST_STATIC_LIBRARY:= $(BUILD_SYSTEM)/host_static_library.mk
BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk
BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk
BUILD_RAW_STATIC_LIBRARY := $(BUILD_SYSTEM)/raw_static_library.mk
BUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mk
BUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mk
BUILD_RAW_EXECUTABLE:= $(BUILD_SYSTEM)/raw_executable.mk
BUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mk
BUILD_PACKAGE:= $(BUILD_SYSTEM)/package.mk
BUILD_HOST_PREBUILT:= $(BUILD_SYSTEM)/host_prebuilt.mk
BUILD_PREBUILT:= $(BUILD_SYSTEM)/prebuilt.mk
BUILD_MULTI_PREBUILT:= $(BUILD_SYSTEM)/multi_prebuilt.mk
BUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mk
BUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mk
BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
BUILD_DROIDDOC:= $(BUILD_SYSTEM)/droiddoc.mk
BUILD_COPY_HEADERS := $(BUILD_SYSTEM)/copy_headers.mk
BUILD_KEY_CHAR_MAP := $(BUILD_SYSTEM)/key_char_map.mk
2. NDK提供的宏功能 及 Anroid.mk 规范
以下是使用GNU make的宏功能,必须通过使用"$(call <function>)",返回一个文本信息。
my-dir
返回最后包含的makefile的路径,这通常是当前Android.mk所在目录的路径,在Android.mk开始之前定义
LOCAL——PATH是很有用的。
在Android.mk文件的开始位置定义
LOCAL_PATH :=$(call my-dir)
...声明一个模块
include $(LOCAL_PATH)/foo/Android.mk
LOCAL_PATH :=($call my-dir)
...声明另一个模块
这里的问题是第二次调用"my-dir"定义LOCAL_PATH替换$PATH为$PATH/foo,由于在此之前执行过。
对于这个原因,最好是将额外的其他所有东西都在Android.mk中包含进来
LOCAL_PATH :=$(call my-dir)
...声明一个模块
LOCAL_PATH :=$(call my-dir)
...声明另一个模块
#在Android.mk的最后额外包括进来
include $(LOCAL_PATH)/foo/Android.mk
如果这样不方便的话,保存第一个my-dir调用的值到另一个变量中,例如
MY_LOCAL_PATH :=$(call my-dir)
LOCAL_PATH :=$(MY_LOCAL_PATH)
...声明一个模块
include $(LOCAL_PATH)/foo/Android.mk
LOCAL_PATH :=$(MY_LOCAL_PATH)
...声明另一个模块
all-subdir-makefiles
返回一个Android.mk文件所在位置的列表,以及当前的my-dir的路径。比如
sources/foo/Android.mk
sources/foo/lib1/Android.mk
sources/foo/lib2/Android.mk
如果sources/foo/Android.mk包含了这行语句
include $(call all-subdir-makefiles)
那么,它将会自动将sources/foo/lib1/Android.mk和sources/foo/lib2/Android.mk包含进来。
此功能可以用于提供深层嵌套的源代码目录build system的层次结构。请注意,默认情况下,NDK只会寻找
sources/*Android.mk
this-makefile
返回当前makefile的路径(也就是那个功能被调用了)
parent-makefile
返回makefile的包含树,也就是包含Makefile当前的文件
grand-parent-makefile
你猜?
import-module
一个允许你通过名字找到并包含另一个模块的的Android.mk的功能,例如
$(call import-module,<name>)
这将会找到通过NDK_MODULE_PATH环境变量引用的模块<name>的目录列表,并且将其自动包含到
Android.mk中
详细信息请参阅:docs/IMPORT-MODULE.html
模块变量描述:
----------------------------------
下面的这些变量是用来描述怎样用你的模块来编译系统的。你可以定义它们中的一些比如
"include $(CLEAR_VARS)"和"include $(BUILD_XXX)",正如前面所写的,$(CLEAR_VARS)是一个可以取消定义/清楚所有变量的脚本。
LOCAL_PATH
这个变量是用来给出当前文件的路径。您比系再您的Android.mk开始位置定义:
LOCAL_PATH :=$(call my-dir)
注意,这个变量是不被$(CLEAR_VARS)清除的,其他的都要被清除(我们可以定义几个模块到一个文件中)
LOCAL_MODULE
这个是你模块的名称,它在你的所有模块中名称必须是唯一的,并且不能包含空格。你必须在包含任何
$(BUILD-XXX)脚本之前定义它。
默认情况下,模块的名称决定了生成的文件的名称,例如lib<foo>.so,它是foo模块的名字。
你可以用LOCAL_MODULE_FILENAME覆盖默认的那一个
LOCAL_MODULE_FILENAME
这个变量是可选的,并且允许你重新定义生成文件的名字。默认的,模块<foo>将始终生成lib<foo>.a或者lib<foo>.so文件,这是标准的UNIX公约
你可以通过LOCAL_MODULE_FILENAME覆盖它
LOCAL_MODULE :=foo-version-1
LOCAL_MODULE_FILENAME :=libfoo
注意:你不能将文件路径或者文件扩展名写到LOCAL_MODULE_FILENAME里,这些将有build system自动处理。
LOCAL_SRC_FILES
这是你模块中将要编译的源文件列表。只列出将被传递到编译器的文件,因为build system自动为您计算了它们的依赖。
注意:源文件的名称都是相对LOCAL_PATH的,您可以使用路径组件,例如
LOCAL_SRC_FILES :=foo.c\
toto/bar.c
注意:在build system时请务必使用UNIX风格的斜杠(/),windows风格的斜杠将不会得到处理
LOCAL_CPP_EXTENSION
这是个可选的变量,可以被定义为文件扩展名为c++的源文件,默认是".cpp",但是你可以改变它,比如
LOCAL_CPP_EXTENSION:=.cxx
LOCAL_C_INCLUDES
可选的路径列表,相对于NDK的根目录,当编译所有的源文件(C、C++、或者汇编)时将被追加到搜索路径中
例如:
LOCAL_C_INCLUDES:=sources/foo
或者
LOCAL_C_INCLUDES:=$(LOCAL_PATH)/../foo
这些都在任何相应列入标志之前被放置在
LOCAL_CFLAGS / LOCAL_CPPFLAGS
当用用ndk-gdb启动本机调试时,LOCAL_C_INCLUDES也会自动被使用到
LOCAL_CFLAGS
当编译C/C++源文件时传递一个可选的编译器标志。
这对于指定额外的宏定义或编译选项很有用
重要提示:尽量不要改变Android.mk中的优化/调试级别,这个可以通过在Application.mk中设置相应的信息来自动为你处理,并且会会让NDK生成在调试过程中使用的有用的数据文件。
注意:在Android-ndk-1.5_r1中,只使用于C源文件,而不适用于C++源文件。在匹配所有Android build system的行为已经得到了纠正。(现在你可以为C++源文件使用LOCAL_CPPFLAGS来指定标志)
它可以用LOCAL_CFLAGS += -I<path>来指定额外的包含路径,然而,如果使用LOCAL_C_INCLUDES会更好,因为用ndk-gdk进行本地调试的时候,那些路径依然是需要使用的
LOCAL_CXXFLAGS
LOCAL_CPPFLAGS的别名。请注意,这个标志在NDK的未来的版本中将会消失
LOCAL_CPPFLAGS
当只编译C++源代码的时候,将传递一个可选的编译器标志。它们将会出现再LOCAL_CFLAGS之后。
注意:在Android NDK-1.5_r1版本中,相应的标志可以应用于C或C++源文件上。在配合完整的Android build system的时候,这已经得到了纠正。(你可以使用LOCAL_CFLAGS去指定C或C++源文件)
LOCAL_STATIC_LIBRARIES
静态库模块的列表(通过BUILD_STATIC_LIBRARY创建)应与此模块链接。这仅仅是为了使动态库敏感。
LOCAL_SHARED_LIBRARY
共享库的列表“模块”,这个模块依赖于运行时.这在链接的时候和在生成的文件中嵌入相应的信息是非常必要的
LOCAL_WHOLE_STATIC_LIBRARIES
LOCAL_WHOLE_STATIC_LIBRARIES是一个用于表示相应的库模块被用作为“整个档案”到链接程序的变量。
当几个静态库之间有循环依赖关系的时候,通常是很有益的。注意,当用来编译一个动态库的时候,这将迫使你将所有的静态库中的对象文件添加到最终的二进制文件中。但生成可执行程序时,这是不确定的。
LOCAL_LDLIBS
当额外的链接标志列表被用于在编译你的模块时,通过用"-l"前缀的特定系统库传递名字是很有用的。例如,下面的旧爱哪个告诉你生成一个在加载时链接到/system/lib/libz.so的模块。
LOCAL_LDLIBS :=-lz
LOCAL_ALLOW_UNDEFINED_SYMBOLS
默认情况下,当试图编译一个共享库的时候遇到任何未定义的引用都可能导致"未定义符号"(undefined symbol)的错误。这在你的源代码中捕获bug会很有用。
然而,但是由于某些原因,你需要禁用此检查的话,设置变量为"true"即可。需要注意的是,相应的共享库在运行时可能加载失败。
LOCAL_ARM_MODE
默认情况下,在"thumb"模式下会生成ARM目标二进制,其中每个指令都是16位宽。你可以定义这个变量为"arm",如果你想在"arm"模式下(32位指令)强迫模块对象文件的生成。例如:
LOCAL_ARM_MODE := arm
注意,你需要执行编译系统为在ARM模式下通过文件的名字增加后缀的方式编译指定的源文件。比如:
LOCAL_SRC_FILES :=foo.c bar.c.arm
这会告诉编译系统一直以ARM模式编译"bar.c",并且通过LOCAL_ARM_MODE的值编译foo.c。
注意:在Application.mk文件中设置APP_OPTIM为"debug"也会强制ARM二进制文件的生成。这是因为工具链调试其中的bug不会处理thumb代码。
LOCAL_ARM_NEON
定义这个变量为"true"会允许在你的C或C++源文件的GCC的内部函数中使用ARM高级SIMD(又名NEON),以及在聚合文件中的NEON指令。
当针对"armeabi-v7a"ABI对应的ARMv7指令集时你应该定义它。注意,并不是所有的ARMv7都是基于NEON指令集扩展的CPU,你应该执行运行时来检测在运行时中这段代码的安全。
另外,你也可以指定特定的源文件,比如用支持NEON".neon"后缀的源文件也可以被编译。
LOCAL_SRC_FILES :=foo.c.neon bar.c zoo.c.arm.neon
在这个例子中,"foo.c"将会被编译在thumb+neon模式中,"bar.c"以thumb模式编译,zoo.c以arm+neon模式编译。
注意,如果你使用两个的话,".neon"后缀必须出现在".arm"后缀之后
(就是foo.c.arm.neon可以工作,但是foo.c.neon.arm不工作)
LOCAL_DISABLE_NO_EXECUTE
Android NDK r4开始添加了支持"NX位"安全功能特性。它是默认启用的,如果你需要的话,可以通过设置变量为“true”来禁用它。
注意:此功能不修改ABI,并且只在ARMv6及以上的CPU设备的内核上被启用。
更多信息,可以参见:
http://en.wikipedia.org/wiki/NX_bit
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
LOCAL_EXPORT_CFLAGS
定义这个变量用来记录C/C++编译器标志集合,并且会被添加到其他任何以LOCAL_STATIC_LIBRARIES和LOCAL_SHARED_LIBRARIES的模块的LOCAL_CFLAGS定义中。
例如:这样定义"foo"模块
include $(CLEAR_VARS)
LOCAL_MODULE :=foo
LOCAL_SRC_FILES :=foo/foo.c
LOCAL_EXPORT_CFLAGS :=-DFOO=1
include $(BUILD_STATIC_LIBRARY)
另一个模块,叫做"bar",并且依赖于上面的模块
include $(CLEAR_VARS)
LOCAL_MODULE :=bar
LOCAL_SRC_FILES :=bar.c
LOCAL_CFLAGS:=-DBAR=2
LOCAL_STATIC_LIBRARIES:=foo
include $(BUILD_SHARED_LIBRARY)
然后,当编译bar.c的时候,标志"-DFOO=1 -DBAR=2"将被传递到编译器。
输出的标志被添加到模块的LOCAL_CFLAGS上,所以你可以很容易复写它们。它们也有传递性:如果"zoo"依赖"bar",“bar”依赖"foo",那么"zoo"也将继承"foo"输出的所有标志。
最后,当编译模块输出标志的时候,这些标志并不会被使用。在上面的例子中,当编译foo/foo.c时,
-DFOO=1将不会被传递给编译器。
LOCAL_EXPORT_CPPFLAGS
类似LOCAL_EXPORT_CFLAGS,但适用于C++标志。
LOCAL_EXPORT_C_INCLUDES
类似LOCAL_EXPORT_C_CFLAGS,但是只有C能包含路径,如果"bar.c"想包含一些由"foo"模块提供的头文件的时候这会很有用。
LOCAL_EXPORT_LDLIBS
类似于LOCAL_EXPORT_CFLAGS,但是只用于链接标志。注意,引入的链接标志将会被追加到模块的LOCAL_LDLIBS,这是因为UNIX连接器的工作方式。
当模块foo是一个静态库的时候并且代码依赖于系统库时会很有用的。LOCAL_EXPORT_LDLIBS可以用于输出依赖,例如:
include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_LDLIBS := -llog
include $(BUILD_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)
这里,在连接器命令最后,libbar.so将以-llog参数进行编译来表明它依赖于系统日志库,因为它依赖于foo。
=================================================================================
一个Android.mk file用来向编译系统描述你的源代码。具体来说:该文件是GNU Makefile的一小部分,会被编译系统解析一次或多次。你可以在每一个Android.mk file中定义一个或多个模块,你也可以在几个模块中使用同一个源代码文件。选项参考以下文件:build/core/config.mk,默认的值在以下文件中定义:build/core/base_rules.mk。编译系统为你处理许多细节问题。例如,你不需要在你的Android.mk中列出头文件和依赖文件。NDK编译系统将会为你自动处理这些问题。
最后发现还是看ndk的文档最直接,也最全面,下面的总结主要是根据ndk提供的文档编写的。
1、单一的Android.mk文件:
Java代码
-
LOCAL_PATH := $(call my-dir)
-
include $(CLEAR_VARS)
-
-
LOCAL_MODULE := hello-jni
-
LOCAL_SRC_FILES := hello-jni.c
-
-
include $(BUILD_SHARED_LIBRARY)
LOCAL_PATH必须位于Android.mk文件的最开始。它是用来定位源文件的位置,$(call my-dir)的作用就是返回当前目录的路径。
include $(CLEAR_VARS)的作用是清除一些变量的值,但是LOCAL_PATH除外。
LOCAL_MODULE是用来指定当前待编译模块的名称,在示例中的模块名称为hello-jni
LOCAL_SRC_FILES是用来指定参与编译的源代码文件。这里只编译hell0-jin.c
include $(BUILD_SHARED_LIBRARY)是用来指示将当前模块编译为共享库,前缀为lib,后缀为.so。
还有另外一个BUILD_STATIC_LIBRARY,是用来指示将当前模块编译为静态库的,前缀为.a,后缀为.a。
这就是一个最简单的Android.mk的结构。可能还有另外一点需要介绍:
LOCAL_C_INCLUDES:=include 这个是用来指定在编译时即将使用的c头文件的位置,以当前目录为起点。
例如:
Java代码
-
SDL_PATH := ../SDL #定义一个变量
-
-
LOCAL_C_INCLUDES += #加载c头文件的目录
-
$(LOCAL_PATH)/$(SDL_PATH)/include
-
$(LOCAL_PATH)/../ffmpeg
2、定义多个Android.mk文件。
有的时候,需要编译的模块比较多,我们可能会将对应的模块放置在相应的目录中,这样,我们可以在每个目录中定义对应的Android.mk文件(类似于上面的写法),最后,在根目录放置一个Android.mk文件,内容如下:
Java代码
-
include $(call all-subdir-makefiles)
只需要这一行就可以了,它的作用就是包含所有子目录中的Android.mk文件
3、也可以在一个Android.mk文件里包含多个模块。
很直观的想法就是将第一个Android.mk文件的内容复制一份,然后修改。我最开始也是这样做的,但是后来出现问题了,在第二个模块中的源码找不到,最后还是看文档,发现里面已经有示例解释了:
Java代码
-
LOCAL_PATH := $(call my-dir)
基于GNU make的工作方式,$(call my-dir)会返回在解析build脚本时,遇到的最后一个 include中涉及的目录。
所以,很多时候,在这个Android.mk里面只需要调用一次$(call my-dir)就够了,如果所有的源文件都在一个目录中。
如果需要的话,可以在第一次调用call my-dir的时候,将值保存下来,比如:
Java代码
-
MY_LOCAL_PATH := $(call my-dir)
-
LOCAL_PATH := $(MY_LOCAL_PATH)
-
-
然后,在另外一个模块中,继续如下定义:
-
LOCAL_PATH := $(MY_LOCAL_PATH)
在编译一般的c源代码时,上面的基本可以满足了
关于LOCAL_CFLAGS
在某些时候,编译源码需要定义宏变量,这个时候,我们可以直接在对应的源码里面去修改,但也有一些情况,我们是没法在别人的源码里定义宏变量的,这个时候,就需要使用到LOCAL_CFLAGS 了 ,举例如下:
Java代码
-
LOCAL_CFLAGS += -D__FAVOR_BSD
-
这行代码的作用就是在原有的cflags基础上,再定义一个宏变量__FAVOR_BSD
类似于#define __FAVOR_BSD
二、自定义变量
以下是在 Android.mk中依赖或定义的变量列表, 可以定义其他变量为自己使用,但是NDK编译系统保留下列变量名:
Java代码
-
-以 LOCAL_开头的名字(例如 LOCAL_MODULE)
-
-以 PRIVATE_, NDK_ 或 APP_开头的名字(内部使用)
-
-小写名字(内部使用,例如‘my-dir’)
如果为了方便在 Android.mk 中定义自己的变量,建议使用 MY_前缀,一个小例子:
Java代码
-
MY_SOURCES := foo.c
-
ifneq ($(MY_CONFIG_BAR),)
-
MY_SOURCES += bar.c
-
endif
-
LOCAL_SRC_FILES += $(MY_SOURCES)
注意:‘:=’是赋值的意思;'+='是追加的意思;‘$’表示引用某变量的值。
三、GNU Make系统变量
这些 GNU Make变量在你的 Android.mk 文件解析之前,就由编译系统定义好了。注意在
某些情况下,NDK可能分析 Android.mk 几次,每一次某些变量的定义会有不同。
(1)CLEAR_VARS: 指向一个编译脚本,几乎所有未定义的 LOCAL_XXX 变量都在"Module-des cription"节中列出。必须在开始一个新模块之前包含这个脚本:include$(CLEAR_VARS),用于重置除LOCAL_PATH变量外的,所有LOCAL_XXX系列变量。
(2)BUILD_SHARED_LIBRARY: 指向编译脚本,根据所有的在 LOCAL_XXX 变量把列出的源代码文件编译成一个共享库。
注意,必须至少在包含这个文件之前定义 LOCAL_MODULE 和 LOCAL_SRC_FILES。
(3) BUILD_STATIC_LIBRARY: 一个 BUILD_SHARED_LIBRARY 变量用于编译一个静态库。静态库不会复制到的APK包中,但是能够用于编译共享库。
示例:include $(BUILD_STATIC_LIBRARY)
注意,这将会生成一个名为 lib$(LOCAL_MODULE).a 的文件
(4)TARGET_ARCH: 目标 CPU平台的名字, 和 android 开放源码中指定的那样。如果是
arm,表示要生成 ARM 兼容的指令,与 CPU架构的修订版无关。
(5)TARGET_PLATFORM: Android.mk 解析的时候,目标 Android 平台的名字.详情可参考/development/ndk/docs/stable- apis.txt.
Java代码
-
android-3 -> Official Android 1.5 system images
-
android-4 -> Official Android 1.6 system images
-
android-5 -> Official Android 2.0 system images
(6)TARGET_ARCH_ABI: 暂时只支持两个 value,armeabi 和 armeabi-v7a。在现在的版本中一般把这两个值简单的定义为 arm, 通过 android 平台内部对它重定义来获得更好的匹配。其他的 ABI 将在以后的 NDK 版本中介绍,它们会有不同的名字。注意虽然所有基于
ARM的ABI都会把 'TARGET_ARCH'定义成‘arm’, 但是会有不同的‘TARGET_ARCH_ABI’。
( 7 ) TARGET_ABI: 目标平台和 ABI 的组合,它事实上被定义成$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) ,在想要在真实的设备中针对一个特别的目标系统进行测试时,会有用。在默认的情况下,它会是'android-3-arm'。
五、模块描述变量
下面的变量用于向编译系统描述你的模块。你应该定义在'include $(CLEAR_VARS)'和'include $(BUILD_XXXXX)'之间。正如前面描写的那样,$(CLEAR_VARS)是一个脚本,清除所有这些变量。
(1) LOCAL_PATH: 这个变量用于给出当前文件的路径。必须在 Android.mk 的开头定义,可以这样使用:LOCAL_PATH := $(call my-dir) 这个变量不会被$(CLEAR_VARS)清除,因此每个 Android.mk 只需要定义一次(即使在一个文件中定义了几个模块的情况下)。
(2)LOCAL_MODULE: 这是模块的名字,它必须是唯一的,而且不能包含空格。必须在包含任一的$(BUILD_XXXX)脚本之前定义它。模块的名字决定了生成文件的名字。例如,如果一个一个共享库模块的名字是,那么生成文件的名字就是 lib.so。但是,在的 NDK 生成文
件中(或者 Android.mk 或者 Application.mk),应该只涉及(引用)有正常名字的其他模块。
(3)LOCAL_SRC_FILES: 这是要编译的源代码文件列表。只要列出要传递给编译器的文件,因为编译系统自动计算依赖。注意源代码文件名称都是相对于 LOCAL_PATH的,你可以使用路径部分,例如:
Java代码
-
LOCAL_SRC_FILES := foo.c toto/bar.c
-
Hello.c
文件之间可以用空格或Tab键进行分割,换行请用"".如果是追加源代码文件的话,请用LOCAL_SRC_FILES +=
注意:在生成文件中都要使用UNIX风格的斜杠(/).windows风格的反斜杠不会被正确的处理。
注意:可以LOCAL_SRC_FILES := $(call all-subdir-java-files)这种形式来包含local_path目录下的所有java文件。
(4) LOCAL_CPP_EXTENSION: 这是一个可选变量, 用来指定C++代码文件的扩展名,默认是'.cpp',但是可以改变它,比如:
LOCAL_CPP_EXTENSION := .cxx
(5) LOCAL_C_INCLUDES: 可选变量,表示头文件的搜索路径。默认的头文件的搜索路径是LOCAL_PATH目录。
示例:
Java代码
-
LOCAL_C_INCLUDES := sources/foo或LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
LOCAL_C_INCLUDES需要在任何包含LOCAL_CFLAGS/LOCAL_CPPFLAGS标志之前进行设置。
(6)LOCAL_CFLAGS: 可选的编译器选项,在编译 C 代码文件的时候使用。这可能是有
用的,指定一个附加的包含路径(相对于NDK的顶层目录),宏定义,或者编译选项。
注意:不要在 Android.mk 中改变 optimization/debugging 级别,只要在 Application.mk 中指定合适的信息,就会自动地为你处理这个问题,在调试期间,会让 NDK自动生成有用的数据文件。
(7)LOCAL_CXXFLAGS: 与 LOCAL_CFLAGS同理,针对 C++源文件。
(8)LOCAL_CPPFLAGS: 与 LOCAL_CFLAGS同理,但是对 C 和 C++ source files都适用。
(9)LOCAL_STATIC_LIBRARIES: 表示该模块需要使用哪些静态库,以便在编译时进行链接。
(10)LOCAL_SHARED_LIBRARIES: 表示模块在运行时要依赖的共享库(动态库),在链接时就需要,以便在生成文件时嵌入其相应的信息。注意:它不会附加列出的模块到编译图,也就是仍然需要在Application.mk 中把它们添加到程序要求的模块中。
(11)LOCAL_LDLIBS: 编译模块时要使用的附加的链接器选项。这对于使用‘-l’前缀传递指定库的名字是有用的。
例如,LOCAL_LDLIBS := -lz表示告诉链接器生成的模块要在加载时刻链接到/system/lib/libz.so
可查看 docs/STABLE-APIS.TXT 获取使用 NDK发行版能链接到的开放的系统库列表。
(12) LOCAL_ALLOW_UNDEFINED_SYMBOLS: 默认情况下, 在试图编译一个共享库时,任何未定义的引用将导致一个“未定义的符号”错误。这对于在源代码文件中捕捉错误会有很大的帮助。然而,如果因为某些原因,需要不启动这项检查,可把这个变量设为‘true’。
注意相应的共享库可能在运行时加载失败。(这个一般尽量不要去设为 true)。
(13) LOCAL_ARM_MODE: 默认情况下, arm目标二进制会以 thumb 的形式生成(16 位),你可以通过设置这个变量为 arm如果你希望你的 module 是以 32 位指令的形式。
'arm' (32-bit instructions) mode. E.g.:
LOCAL_ARM_MODE := arm
注意:可以在编译的时候告诉系统针对某个源码文件进行特定的类型的编译
比如,LOCAL_SRC_FILES := foo.c bar.c.arm 这样就告诉系统总是将 bar.c 以arm的模式编译。
(14)LOCAL_MODULE_PATH 和 LOCAL_UNSTRIPPED_PATH
在 Android.mk 文件中, 还可以用LOCAL_MODULE_PATH 和LOCAL_UNSTRIPPED_PATH指定最后的目标安装路径.
不同的文件系统路径用以下的宏进行选择:
Java代码
-
TARGET_ROOT_OUT:表示根文件系统。
-
TARGET_OUT:表示 system文件系统。
-
TARGET_OUT_DATA:表示 data文件系统。
用法如:LOCAL_MODULE_PATH :=$(TARGET_ROOT_OUT)
至于LOCAL_MODULE_PATH 和LOCAL_UNSTRIPPED_PATH的区别,暂时还不清楚。
七、GNU Make‘功能’宏
GNU Make‘功能’宏,必须通过使用'$(call )'来调用,调用他们将返回文本化的信息。
(1)my-dir:返回当前 Android.mk 所在的目录的路径,相对于 NDK 编译系统的顶层。这是有用的,在 Android.mk 文件的开头如此定义:
Java代码
-
LOCAL_PATH := $(call my-dir)
(2)all-subdir-makefiles: 返回一个位于当前'my-dir'路径的子目录中的所有Android.mk的列表。
例如,看下面的目录层次:
Java代码
-
sources/foo/Android.mk
-
sources/foo/lib1/Android.mk
-
sources/foo/lib2/Android.mk
如果 sources/foo/Android.mk 包含一行:
include $(call all-subdir-makefiles)
那么它就会自动包含 sources/foo/lib1/Android.mk 和 sources/foo/lib2/Android.mk。
这项功能用于向编译系统提供深层次嵌套的代码目录层次。
注意,在默认情况下,NDK 将会只搜索在 sources/*/Android.mk 中的文件。
(3)this-makefile: 返回当前Makefile 的路径(即这个函数调用的地方)
(4)parent-makefile: 返回调用树中父 Makefile 路径。即包含当前Makefile的Makefile 路径。
(5)grand-parent-makefile:返回调用树中父Makefile的父Makefile的路径
八、 Android.mk 使用模板
在一个 Android.mk 中可以生成多个APK应用程序,JAVA库,CC++可执行程序,CC++动态库和CC++静态库。
(1)编译APK应用程序模板。
关于编译APK应用程序的模板请参照《Android.mk编译APK范例》
(2)编译JAVA库模板
Java代码
-
LOCAL_PATH := $(call my-dir)
-
include $(CLEAR_VARS)
-
# Build all java files in the java subdirectory
-
LOCAL_SRC_FILES := $(call all-subdir-java-files)
-
# Any libraries that this library depends on
-
LOCAL_JAVA_LIBRARIES := android.test.runner
-
# The name of the jar file to create
-
LOCAL_MODULE := sample
-
# Build a static jar file.
-
include $(BUILD_STATIC_JAVA_LIBRARY)
注:LOCAL_JAVA_LIBRARIES := android.test.runner表示生成的JAVA库的jar文件名
(3)编译C/C++应用程序模板如下:
Java代码
-
LOCAL_PATH := $(call my-dir)
-
#include $(CLEAR_VARS)
-
LOCAL_SRC_FILES := main.c
-
LOCAL_MODULE := test_exe
-
#LOCAL_C_INCLUDES :=
-
#LOCAL_STATIC_LIBRARIES :=
-
#LOCAL_SHARED_LIBRARIES :=
-
include $(BUILD_EXECUTABLE)
注:‘:=’是赋值的意思,'+='是追加的意思,‘$’表示引用某变量的值
LOCAL_SRC_FILES中加入源文件路径,LOCAL_C_INCLUDES中加入需要的头文件搜索路径
LOCAL_STATIC_LIBRARIES 加入所需要链接的静态库(*.a)的名称,
LOCAL_SHARED_LIBRARIES 中加入所需要链接的动态库(*.so)的名称,
LOCAL_MODULE表示模块最终的名称,BUILD_EXECUTABLE 表示以一个可执行程序的方式进行编译。
(4)编译CC++静态库
Java代码
-
LOCAL_PATH := $(call my-dir)
-
include $(CLEAR_VARS)
-
LOCAL_SRC_FILES :=
-
helloworld.c
-
LOCAL_MODULE:= libtest_static
-
#LOCAL_C_INCLUDES :=
-
#LOCAL_STATIC_LIBRARIES :=
-
#LOCAL_SHARED_LIBRARIES :=
-
include $(BUILD_STATIC_LIBRARY)
和上面相似,BUILD_STATIC_LIBRARY 表示编译一个静态库。
(5)编译CC++动态库的模板
Java代码
-
LOCAL_PATH := $(call my-dir)
-
include $(CLEAR_VARS)
-
LOCAL_SRC_FILES := helloworld.c
-
LOCAL_MODULE := libtest_shared
-
TARGET_PRELINK_MODULES := false
-
#LOCAL_C_INCLUDES :=
-
#LOCAL_STATIC_LIBRARIES :=
-
#LOCAL_SHARED_LIBRARIES :=
-
include $(BUILD_SHARED_LIBRARY)
和上面相似,BUILD_SHARED_LIBRARY 表示编译一个共享库。
以上三者的生成结果分别在如下目录中,generic 依具体 target 会变:
Java代码
-
out/target/product/generic/obj/APPS
-
out/target/product/generic/obj/JAVA_LIBRARIES
-
out/target/product/generic/obj/EXECUTABLE
-
out/target/product/generic/obj/STATIC_LIBRARY
-
out/target/product/generic/obj/SHARED_LIBRARY
每个模块的目标文件夹分别为:
1)APK程序:XXX_intermediates
2)JAVA库程序:XXX_intermediates
这里的XXX
3)CC++可执行程序:XXX_intermediates
4)CC++静态库: XXX_static_intermediates
5)CC++动态库: XXX_shared_intermediates