2011-8-13 16:15:07

 

 
 
  2011-8-13 16:15:07
 
 

--build system可以为你处理许多细节，例如：你不许要在Android.mk文件中列出头文件或者其他的依赖关系，这些NDK的build system会自动为你计算并处理。

这也意味着，当更新到新版本的NDK的时候，你应该得益于新的toolchain/platform的支持，而无需修改你的Android.mk文件。

自动解决头文件和依赖关系

注意：这些语法非常接近于分布在完整的开源的Android源代码中的Android.mk文件，尽管是build system实现的，但是它们的用法是不同的。

这样故意设计的决定是为了让应用程序开发者重用“外部”库的源代码更容易。

用法不一

 

简单实例：
-------------
再详细讲解语法之前，让我们先看看一个简单的例子"hello JNI",它在apps/hello-jni/project下

--'src'目录下用于存放java源文件
--‘jni’目录下用于存放本地源文件，例如"jni/hello-jni.c"

现在这个例子是是NDK下的一个

这个源文件实现了一个简单的共享库(shared library)：实现了一个本地方法，为VM应用程序返回一个字符串。

--‘jni/Android.mk’文件描述了如何生成一个共享库，它的内容是：
-----------------Android.mk------------------------
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c

include $(BUILD_SHARED_LIBRARY)
---------------------------------------------------
现在，让我们分别解释这几行

LOCAL_PATH：=$(call my-dir)

Android.mk文件必须以LOCAL_PATH变量开始，它用于在树中定位文件。在这个例子中，宏功能'my-dir'是由build system提供的，用于返回当前目录路径（包括Android.mk文件本身）

以 LOCAL_PATH 开始

include $(CLEAR_VARS)

CLEAR_VARS变量是由build system提供的，并且指明了一个GNU makefile文件，这个功能会清理掉所有以LOCAL_开头的内容（例如LOCAL_MODULE,LOCAL_SRC_FILES,LOCAL_STATIC_LIBRARIES等），除了LOCAL_PATH，这句话是必须的，因为如果所有的变量都是全局变量的话，所有的可控的编译文件都需要在一个单独的GNU中被解析并执行

清除以local 开始的所有变量

LOCAL_MODULE :=hello-jni

LOCAL_MODULE变量必须被定义，用来区分Android.mk中的每一个模块。文件名必须是唯一的，不能有空格。

注意，这里编译器会为你自动加上一些前缀和后缀，来保证文件是一致的，比如：这里表明一个动态连接库模块被命名为"hello-jni"，

但是最后会生成为"libhello-jni.so"文件。但是在Java中装载这个库的时候还是使用"hello-jni"名称。

当然如果我们使用"IMPORTANT NOTE:",编译系统就不会为你加上前缀，但是为了支持Android平台源码中的Android.mk文件，也同样会生成libhello-jni.so这样的文件。

重要提示：如果你将你的模块命名为'libfoo'，编译系统将不会将前缀'lib'加上去，并且也会生成libfoo.so文件。

自动加上前缀和强制不加前缀