Android编译系统(下)

精彩图文

相关博文

倪萍侄女倪妮照鲜嫩多汁照烧鸡

娱乐圈极品渣男让人咂舌的片酬

马伊琍身形消瘦陈凯歌帅气长子

查看更多>>

中国第一位牺牲的女飞行员

揭秘小三女星姚笛整容上位史(图)

taoxinxu 释凡

图示张柏芝混娱乐圈尴尬惨痛经历

一池萍碎

肝癌发病5大因素

LOCAL_SHARED_LIBRARIES := /libutils /libui /libaudio /libexpat /libsgl ------分隔符，方便下次编辑修改------These are the libraries you directly link against. You don't need to pass transitively included libraries. Specify the name without the suffix:LOCAL_SHARED_LIBRARIES := \libutils \libui \libaudio \libexpat \libsgl LOCAL_SRC_FILES LOCAL_SRC_FILES 变量必须包含一系列将被构建和组合成模块的C/C++源文件。注意：不需要列出头文件或include 文件，因为生成系统会为你自动计算出源文件的依赖关系。默认的C++源文件的扩展名是.cpp ，但你可以通过定义LOCAL_DEFAUL T_EXTENSION 来指定一个扩展名。The build system looks at LOCAL_SRC_FILES to know what source files to compile -- .cpp .c .y .l .java. For lex and yacc files, it knows how to correctly do the intermediate .h and .c/.cpp files automatically. If the files are in a subdirectory of the one containing the Android.mk,prefix them with the directory name:LOCAL_SRC_FILES := \file1.cpp \dir/file2.cpp LOCAL_STATIC_LIBRARIES LOCAL_STATIC_LIBRARIES 变量和LOCAL_SHARED_LIBRARIES 类似，用来列出你的模块中所需的静态库的列表，你可以在你的module 中包含一些想使用的静态库，通常我们使用共享库，但是有些地方，像在sbin 下的可执行程序和主机上的可执行程序我们要使用静态库。例如：LOCAL_STATIC_LIBRARIES := /libutils /libtinyxml ------分隔符，方便下次编辑修改------These are the static libraries that you want to include in your module. Mostly, we use shared libraries, but there are a couple of places, like executables in sbin and host executables where we use static libraries instead.LOCAL_STATIC_LIBRARIES := \libutils \libtinyxml LOCAL_MODULE LOCAL_MODULE 变量必须定义，用来标识在Android.mk 文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。如果有其它moudle 中已经定义了该名称，那么你在编译时就会报类似这样的错误：libgl2jni already defined by frameworks/base/opengl/tests/gl2_jni/jni. Stop.下面就是该错误的截图：接下来就是修改你的module 的名字了，或者找到跟你重名的module 把它干掉，但不建议你那么做，因为有可能会带来未知的错误(你修改了别人的module 的名字，而别人不一定知道，当他再编译或者做其它时，就会出错)。LOCAL_MODULE is the name of what's supposed to be generated from your Android.mk. For exmample, for libkjs, the LOCAL_MODULE is "libkjs" (the build system adds the appropriate suffix -- .so .dylib .dll).注意：编译系统会自动产生合适的前缀和后缀，例如：LOCAL_MODULE := screenshot

LOCAL_EXPORT_C_INCLUDES

类似LOCAL_EXPORT_CFLAGS，但是只有C能包含路径，如果"bar.c"想包含一些由"foo"模块提供的头文件的时候这会很有用。

具体请参考LOCAL_EXPORT_CFLAGS条目。

LOCAL_EXPORT_LDLIBS

类似于LOCAL_EXPORT_CFLAGS，但是只用于链接标志。注意，引入的链接标志将会被追加到模块的LOCAL_LDLIBS，这是由UNIX连接器的工作方式决定的。

当模块foo是一个静态库的时候并且代码依赖于系统库时会很有用的。LOCAL_EXPORT_LDLIBS可以用于输出依赖，例如：

#Frist build the static library libfoo.a

include $(CLEAR_VARS)

LOCAL_MODULE := foo

LOCAL_SRC_FILES := foo/foo.c

LOCAL_EXPORT_LDLIBS := -llog

include $(BUILD_STATIC_LIBRARY)

#Then build the shared library libbar.so

include $(CLEAR_VARS)

LOCAL_MODULE := bar

LOCAL_SRC_FILES := bar.c

LOCAL_STATIC_LIBRARIES := foo

include $(BUILD_SHARED_LIBRARY)

这里，在连接器命令最后，libbar.so将以”-llog”参数进行编译来表明它依赖于系统日志库，因为它依赖于foo。

LOCAL_ALLOW_UNDEFINED_SYMBOLS

默认情况下，当试图编译一个共享库的时候遇到任何未定义的引用都可能导致"未定义符号"(unde?ned symbol)的错误。这在你的源代码中捕获bug会很有用。

然而，但是由于某些原因，你需要禁用此检查的话，设置变量为"true"即可。需要注意的是，相应的共享库在运行时可能加载失败。

LOCAL_ARM_MODE

LOCAL_ARM_MODE变量主要是应用与嵌入式产品的编译系统中，可以指定为arm模式。例如：LOCAL_ARM_MODE := arm

注意：你需要执行编译系统为在ARM模式下通过文件的名字增加后缀的方式编译指定的源文件。例如：LOCAL_SRC_FILES :=foo.c bar.c.arm

这会告诉编译系统一直以ARM模式编译"bar.c"，并且通过LOCAL_ARM_MODE的值编译foo.c。

2.2.2.BUILD_XXX变量

2.2.2.1.BUILD_SHARED_LIBRARY

BUILD_SHARED_LIBRARY：指明要编译生成动态共享库。指向一个生成脚本，这个脚本通过LOCAL_XXX变量收集关于组件的信息，并决定如何根据你列出来的源文件生成目标共享库。

注意：在include这个脚本文件之前你必须至少已经定义了LOCAL_MODULE和LOCAL_SRC_FILES。例如：include $(BUILD_SHARED_LIBRARY)

注意：这会生成一个名为lib$(LOCAL_MODULE).so的动态库。

2.2.2.2.BUILD_STATIC_LIBRARY

BUILD_STATIC_LIBRARY与BUILD_SHARED_LIBRARY类似，但用来生成目标静态库。静态库不会被拷贝至你的project/packages文件夹下，但可用来生成共享库。

例如：

include $(BUILD_STATIC_LIBRARY)

注意：这会生成一个静态库，名叫lib$(LOCAL_MODULE).a的静态库。

2.2.2.

3.BUILD_PACKAGE

BUILD_PACKAGE变量用于在最好编译时生成*.apk，例如：

include $(BUILD_STATIC_LIBRARY)

注意：这会生成一个apk安装包，名字就叫$(LOCAL_MODULE).apk的安装包。

2.2.

3.其它变量

2.2.

3.1.CLEAR_VARS

CLEAR_VARS变量是生成系统提供的，它指向一个特殊的GNU Make?le，它将会为你自动清除许多名为

LOCAL_XXX的变量(比如：LOCAL_MODULE、LOCAL_SRC_FILES、LOCAL_STATIC_LIBRARIES等)，但LOCAL_PATH是例外，它不会被清除。

注意：这些变量的清除是必须的，因为所有的控制文件是在单一的Make?le，执行环境中解析的，在这里所有的变量都是全局的。

2.2.

3.2.TARGET_PLATFORM

TARGET_PLATFORM：当解析该Android.mk文件时用它来指定Andoid目标平台的名称。例

如：android-3与Android 1.5相对应。

2.2.4.NDK提供的宏函数

下面是GNU Make的宏函数，必须通过这样的形式调用：

$(call )

2.2.4.1.my-dir

my-dir：返回放置当前Android.mk的文件夹相对于NDK生成系统根目录的路径。可用来在Android.mk的开始处定义LOCAL_PATH的值：

LOCAL_PATH := $(call my-dir)

2.2.4.2.all-subdir-make?les

all-subdir-make?les：返回my-dir子目录下的所有Android.mk。例如：

代码的结构如下：

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仅在source/*/Android.mk里寻找文件。

2.2.4.

3.this-make?le

this-make?le：返回当前Make?le所在目录的路径。

2.2.4.4.parent-make?le

parent-make?le：返回父Make?le所在目录make?le的路径。

2.2.4.5.import-module

一个允许你通过名字找到并包含另一个模块的的Android.mk的功能，例如：

$(call import-module,)

这将会找到通过NDK_MODULE_PATH环境变量引用的模块的目录列表，并且将其自动包含到Android.mk中。

3.Application.mk

3.1.作用

Application.mk目的是描述在你的应用程序中所需要的模块(即静态库或动态库)。

Application.mk文件通常被放置在$PROJECT/jni/Application.mk下，$PROJECT指的是您的项目。另一种方法是将其放在顶层的子目录下，既$NDK/apps目录下，例如：

$NDK/apps//Application.mk

是一个简称，用于描述你的NDK编译系统的应用程序（这个名字不会生成共享库或者最终的包），这个方法是Android NDK r4以前的，现在仍然兼容。但是我们强烈建议你使用第一种方法，因为它更简单并且不用修改NDK安装树的目录。

3.2.详细说明

下面是Application.mk中定义的几个变量：

3.2.1.APP_MODULES

APP_MODULES变量是强制性的，并且会列出所有你所需要的模块。它不允许用一个空格来分隔其模块列表，这个模块名字被定义在Android.mk文件中的LOCAL_MODULE中。

3.2.2.APP_PROJECT_PATH

APP_PROJECT_PATH变量也是强制性的，并且会给出应用程序工程的根目录一个绝对路径。这是用来复制或者安装一个没有任何版本限制的JNI库，从而给APK生成工具一个详细的路径。例如：

登录名：密码：找回密码注册记住登录状态

评论并转载此博文

验证码：请点击后输入验证码