Android NDK开发

1. 简介

NDK实际是一个交叉编译工具链，也就是在一个平台上编译生成可在另一个平台上运行的代码，比如在X86上编译生成在arm平台上可运行的代码。

2.开发工具

使用eclipse可以安装CDT插件，使用Android Studio时， 本身已支持Native开发。

3. 什么是JNI

JNI 全称java native interface, JNI是一个协议，这个协议用来沟通java代码和外部的本地代码(C/C++)通过这个协议java代码可以调用外部的C/C++代码，外部的C/C++代码也可以调用java代码。

下图展示了JNI层位置关系图

下图展示了Android软件栈中代码层级关系图
当java代码无法满足需求时，会通过JNI调用C/C++代码。

4. 为什么使用JNI

1. JNI扩展了java虚拟机的能力，驱动开发（wifi-hotspot）2.3以后。
   Java代码不能写驱动，具有一次编译，到处运行的特点，java虚拟机屏蔽了底层实现，无法直接操作硬件。
   Wifi-hotspot实现是通过操作网卡将其置为混杂模式，涉及硬件操作。
   Java代码运行原理图如下：
   

2. Native code 效率高，数学运算块，实现渲染的游戏上，音频视频
   例如：（1）Android下极品飞车对重力的感应，碰撞效果的模拟，java代码不能满足性能需要C/C++代码实现，再比如，（2）调用一些开源的C代码库，如opencv,由intel开发，功能为图形和视频实时处理的方法库，（3）再比如音频视频的编解码代码库（引擎），再比如 opengl c代码库（4）车载电脑项目，在线调试系统，获取汽车胎压，转速，发动机温度等信息，这些信息通过芯片obd获取，该芯片获取的为电信号（高低电平），需要C/C++代码获取值，将获取的值传给上层。

3. 复用代码（文件压缩，人脸识别…）

4. 特殊的业务场景

5. 怎样用JNI

1. 掌握C/C++语言
2. 掌握java jni流程
3. NDK（native developp kits）ndk android native develop kits,即android 本地开发工具集

作用：可以把c/c++ ->编译成一个 linux下可以执行的二进制文件java代码里面就可以通过jni 调用执行二进制的文件。

案例：
案例1 类似photoshop的程序，功能为底片效果，素描效果等，例如美图秀秀等。
案例2 wav转mp3，作用：将文件大小压缩
代码库 lame C库，MP3的编码库，开源免费。

5.1 Java通过JNI机制与C/C++沟通的具体步骤

1. 静态注册方式
   (1)编写包含native方法的Java类；
   (2)通过javah生成C/C++的头文件；
   (3)使用C/C++语言实现头文件；
   (4)使用交叉编译工具对C/C++代码进行编译，最后通过链接生成*.so可执行的C/C++库。
   (5)实际执行Java代码与本地C/C++代码相互沟通。

下面以创建HelloWorldNDK为例说明具体过程（基于eclipse NDK）
Java调用C
（1）创建AndroidNDK工程，包名为com.calvin.ndk.hello
（2）加载本地C库，同时声明本地C方法

package com.calvin.ndk.hello;
public class HelloWorldNDK{
	//静态代码块在类加载时会执行，这个时候就会加载本地C库
	static {
		//加载本地的C库文件
		System.loadLibrary("helloWorldNDK");
	}
	
	//声明加载的C库中的本地方法
	public native String sayHelloToNDK();
}

（3）编译Android文件
上述Java文件经过编译后路径在
HelloWorldNDK/bin/classes\com.calvin/ndk/hello/
（4） 使用javah工具产生C语言的.h头文件
具体步骤如下：
1) 在Eclipse的HelloWorldNDK工程的根目录下建立一个名为jni的文件夹；
2) 命令行进入jni目录；
3) 使用javah工具产生HelloWorldNDK.class的头文件

# javah -c classpath ../bin/classes com.calvin.ndk.hello.HelloWorldNDK

	4) 成功执行javah命令后，会在文件夹jni下生成头文件 *com_calvin_ndk_hello_HelloWorldNDK.h*

#include 
/*Header for class com_calvin_ndk_hello_HelloWorldNDK*/
#ifndef
_Included_com_calvin_ndk_hello_HelloWorldNDK
#define
_Included_com_calvin_ndk_hello_HelloWorldNDK
#ifdef __cplusplus
extern "C"{
#endif
/*
Class:
com_calvin_ndk_hello_HelloWorldNDK
Method: sayHelloToNDK
Signature: （）Ljava/lang/String;
*/
JNIEXPORT jstring JNICALL
Java_com_calvin_ndk_hello_HelloWorldNDK_sayHelloToNDK(JNIEnv *env, jobject);
#ifdef __cplusplus
}
#endif
#endif

	5) 编写c语言对上述头文件进行实现。

com_calvin_ndk_hello_HelloWorldNDK.c

# include "com_calvin_ndk_hello_HelloWorldNDK.h"
JNIEXPORT jstring JNICALL
Java_com_calvin_ndk_hello_HelloWorldNDK_sayHelloToNDK(JNIEnv *env, jobject){
	return (*env)->NewStringUTF(env, "HelloWorld, NDK!");
}

	6) 书写jni目录下的Android.mk

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE := helloWorldNDK
LOCAL_SRC_FILES := com_calvin_ndk_hello_HelloWorldNDK.c
include $(BUILD_SHARED_LIBRIARY)

	7) 在jni目录下使用ndk-build编译

# ndk-build

2. 动态注册方式

6. 实际开发知识点

6.1 C代码中Log使用

1. Android.mk文件中添加log依赖库

LOCAL_LDLIBS += -llog

2. C代码中增加宏定义

#include 
#define LOG_TAG "System.out"
#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, __VA_ARGS__)
#define LOGI(...) __android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)
 LOGI("info\n");
 LOGD("debug\n");

6.2 JNI中各参数含义

jstring Java_cn_itcast_ndk_DemoActivity_helloFromJNI(JNIEnv *env, jobject javaThis) {
  return (*env)->NewStringUTF(env, "Hello from native code!");
}

JNIEnv ： 类型代表了java环境 通过JNIEnv* 指针,就可以对java端的代码进行操作。(1) 创建java类的对象,调用java对象的方法； (2) 获取java对象的属性 等等。
jobject ： jobject obj 就是当前方法所在的类代表的对象.

6.3 Java、 C语言数据类型对应关系

下面的表格是Java与C数据类型传递关系

Java类型	本地类型	JNI定义别名
int	long	jint/jsize
long	__int64	jlong
byte	signed char	jbyte
boolean	unsigned char	jboolean
char	unsigned short	jchar
short	short	short
float	float	jfloat
double	double	jdouble
object	_jobject*	jobject

6.4 调试方法

1. 通过log方式来观察程序执行 基本的调试方法，建议使用
   C代码中使用logcat方法
   (1) Android.mk文件中增加

LOCAL_LDLIBS+=-llog

引入C语言的log库位置
android-ndk-r7b\platforms\android-9\arch-arm\usr\lib\liblog.so
,举一反三，引入其他库用法
(2) C代码中增加

#include

库文件位置 android-ndk-r7b\platforms\android-9\arch-arm\usr\include\android

#define LOG_TAG “System.out”
#define LOGD(…)__android_log_print(ANDROID__LOG__DEBUG,LOG__TAG,__VA__ARGS__)
#define LOGI(…)__android_log_print(ANDROID__LOG_INFO,LOG__TAG,__VA__ARGS__)
LOGI(“info\n”);
LOGD(“debug\n”);

重新编译后，先clean一把将老的so库清除掉，F5重新加载一下新的so库

2. 断点调试 ndk-gdb 比较麻烦，不建议使用

Ndk开发中文乱码问题

1. 低版本ndk不支持中文 ndk-r4-crystal
   解决办法：1.hello.c文件属性编码改成utf-8编码
2. 在java代码中将iso-8859-1编码转成UTF-8格式
   new string(getString().getByte(“iso-8859-1”),”utf-8”);

7. Android.mk语法分析

一个Android.mk 文件用来向编译系统描述你的源代码。具体来说：该文件是GNU Makefile的一小部分，会被编译系统解析一次或多次。你可以在每一个Android.mk中定义一个或多个模块，你也可以在几个模块中使用同一个源代码文件。编译系统为你处理许多细节问题。

一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为 makefile就像一个Shell脚本一样，其中也可以执行操作系统的命令。

makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。

Make工具最主要也是最基本的功能就是通过makefile文件来描述源程序之间的相互关系并自动维护编译工作。而makefile 文件需要按照某种语法进行编写，文件中需要说明如何编译各个源文件并连接生成可执行文件，并要求定义源文件之间的依赖关系。makefile 文件是许多编译器–包括 Windows NT 下的编译器——维护编译信息的常用方法，只是在集成开发环境中，用户通过友好的界面修改 makefile 文件而已。

7.1 语法分析

下面是编译App的Android.mk分析基本语法

#它表示是当前文件的路径。在这个例子中， 宏函数‘my-dir’,由编译系统提供,
#用于返回当前路径(即包含Android.mk file文件的目录)
LOCAL_PATH:= $(call my-dir)

# CLEAR_VARS 由编译系统提供(可以在 android 安装目录下的/build/core/config.mk 文件看到其定义，为 CLEAR_VARS:=$(BUILD_SYSTEM)/clear_vars.mk)，指定让GNU MAKEFILE该脚本为你清除许多 LOCAL_XXX 变量 ( 例如 LOCAL_MODULE ， LOCAL_SRC_FILES ，LOCAL_STATIC_LIBRARIES，等等…)，除 LOCAL_PATH。这是必要的，因为所有的编译文件都在同一个 GNU MAKE 执行环境中，所有的变量都是全局的。另外注意，该语句的意思就是把CLEAR_VARS变量所指向的脚本文件包含进来。 
include $(CLEAR_VARS)
# 是否定义FEATURE宏
ifeq ($(MTK_VT3G324M_SUPPORT), yes)
# 定义了AndroidManifest.xml的路径
LOCAL_MANIFEST_FILE := cmcc/AndroidManifest.xml
endif
endif
 
ifeq ($(strip $(HQ_CLIENT)), hosin)
LOCAL_MANIFEST_FILE := hosin/AndroidManifest.xml
endif
# 指该模块在所有版本下都编译， 其他可选项 eng 、user, 编译时会根据不同的选项决定是否加入产品编译 
LOCAL_MODULE_TAGS := optional
# 指定本次要编译的源文件（src文件夹下的所有java文件）
LOCAL_SRC_FILES := $(call all-java-files-under, src)
 
ifeq ($(strip $(HQ_CLIENT)),doov)
  ifeq ($(strip $(HQ_PROJECT)),A51)
     LOCAL_SRC_FILES := $(call all-java-files-under,a51_doov)
  endif
  LOCAL_SRC_FILES := $(filter-out src/com/android/contacts/ContactsGroupsActivity.java, $(LOCAL_SRC_FILES))
 
  LOCAL_SRC_FILES := $(filter-out src/com/android/contacts/ContactsMarkListActivity.java, $(LOCAL_SRC_FILES))
  LOCAL_SRC_FILES := $(filter-out src/com/android/contacts/ExportVCardActivity.java, $(LOCAL_SRC_FILES))
else
 LOCAL_SRC_FILES := $(filter-out src/com/android/contacts/a51_doov/ContactsGroupsActivity.java, $(LOCAL_SRC_FILES))
 LOCAL_SRC_FILES := $(filter-out src/com/android/contacts/a51_doov/ContactsMarkListActivity.java, $(LOCAL_SRC_FILES))
 LOCAL_SRC_FILES := $(filter-out src/com/android/contacts/a51_doov/ExportVCardActivity.java, $(LOCAL_SRC_FILES))
endif
# 该模块在参加编译时需要的java静态库，会打包到app中 
LOCAL_STATIC_JAVA_LIBRARIES := com.android.phone.common \                                                                                 	 com.mediatek.wsp \
com.mediatek.CellConnUtil
# 该模块在参加编译时需要的java库，不会打包到app中，该库属于共享库，运行时从环境变量加载
LOCAL_JAVA_LIBRARIES += com.mediatek.framework
LOCAL_JAVA_LIBRARIES +=com.huaqin.utils
# 编译生成的apk的文件名 
LOCAL_PACKAGE_NAME := Contacts
# 使用共享签名， 允许共享UID，对于几个apk来说要想共享User id，首先需要在AndroidManifest节点中增加android:sharedUserId属性，最后还要把APK的源码放到packages/apps/目录下，用mm进行编译
LOCAL_CERTIFICATE := shared
#LOCAL_CERTIFICATE := platform  # 使用平台签名
#LOCAL_CERTIFICATE := vendor/example/certs/app  #使用特定Key签名
# proguard是将java代码进行混淆的工具，这一句话指定不需要混淆的native方法与变量的proguard.flags文件
LOCAL_PROGUARD_FLAG_FILES := proguard.flags
# 告诉系统编译结束要生成一个apk
include $(BUILD_PACKAGE)
#编译成其他目标
#include $(BUILD_STATIC_LIBRARY)表示编译成静态库
#include $(BUILD_SHARED_LIBRARY)表示编译成动态库。
#include $(BUILD_EXECUTABLE)表示编译成可执行程序。

编译系统模块AudioFlinger的Android.mk语法分析

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)  #模块一
ifeq ($(AUDIO_POLICY_TEST),true)
  ENABLE_AUDIO_DUMP := true
endif
LOCAL_SRC_FILES:= \
    AudioHardwareGeneric.cpp \
    AudioHardwareStub.cpp \
    AudioHardwareInterface.cpp
ifeq ($(ENABLE_AUDIO_DUMP),true)
  LOCAL_SRC_FILES += AudioDumpInterface.cpp
  # 编译C文件的添加额外编译选项（如：宏定义）
  LOCAL_CFLAGS += -DENABLE_AUDIO_DUMP
endif
# 编译该模块所需要依赖的共享库
LOCAL_SHARED_LIBRARIES := \
    libcutils \
    libutils \
    libbinder \
    libmedia \
    libhardware_legacy
ifeq ($(strip $(BOARD_USES_GENERIC_AUDIO)),true)
  LOCAL_CFLAGS += -DGENERIC_AUDIO
endif
# 模块名称
LOCAL_MODULE:= libaudiointerface
ifeq ($(BOARD_HAVE_BLUETOOTH),true)
  LOCAL_SRC_FILES += A2dpAudioInterface.cpp
  LOCAL_SHARED_LIBRARIES += liba2dp
  LOCAL_CFLAGS += -DWITH_BLUETOOTH -DWITH_A2DP
  LOCAL_C_INCLUDES += $(call include-path-for, bluez)
endif
include $(BUILD_STATIC_LIBRARY) # 模块一编译成静态库

include $(CLEAR_VARS)  #模块二
LOCAL_SRC_FILES:=               \
    AudioPolicyManagerBase.cpp
LOCAL_SHARED_LIBRARIES := \
    libcutils \
    libutils \
    libmedia
ifeq ($(TARGET_SIMULATOR),true)
 LOCAL_LDLIBS += -ldl
else
 LOCAL_SHARED_LIBRARIES += libdl
endif
LOCAL_MODULE:= libaudiopolicybase
ifeq ($(BOARD_HAVE_BLUETOOTH),true)
  LOCAL_CFLAGS += -DWITH_A2DP
endif
ifeq ($(AUDIO_POLICY_TEST),true)
  LOCAL_CFLAGS += -DAUDIO_POLICY_TEST
endif
include $(BUILD_STATIC_LIBRARY) #模块二编译成静态库
include $(CLEAR_VARS) #模块三
LOCAL_SRC_FILES:=               \
    AudioFlinger.cpp            \
    AudioMixer.cpp.arm          \
    AudioResampler.cpp.arm      \
    AudioResamplerSinc.cpp.arm  \
    AudioResamplerCubic.cpp.arm \
    AudioPolicyService.cpp
# 编译模块所要依赖的共享库
LOCAL_SHARED_LIBRARIES := \
    libcutils \
    libutils \
    libbinder \
    libmedia \
    libhardware_legacy
ifeq ($(strip $(BOARD_USES_GENERIC_AUDIO)),true)
# 编译模块所要依赖的静态库
  LOCAL_STATIC_LIBRARIES += libaudiointerface libaudiopolicybase
  LOCAL_CFLAGS += -DGENERIC_AUDIO
else
  LOCAL_SHARED_LIBRARIES += libaudio libaudiopolicy
endif
ifeq ($(TARGET_SIMULATOR),true)
 LOCAL_LDLIBS += -ldl
else
 LOCAL_SHARED_LIBRARIES += libdl
endif
# 模块名称
LOCAL_MODULE:= libaudioflinger
ifeq ($(BOARD_HAVE_BLUETOOTH),true)
  LOCAL_CFLAGS += -DWITH_BLUETOOTH -DWITH_A2DP
  LOCAL_SHARED_LIBRARIES += liba2dp
endif
ifeq ($(AUDIO_POLICY_TEST),true)
  LOCAL_CFLAGS += -DAUDIO_POLICY_TEST
endif
ifeq ($(TARGET_SIMULATOR),true)
    ifeq ($(HOST_OS),linux)
        LOCAL_LDLIBS += -lrt -lpthread
    endif
endif
ifeq ($(BOARD_USE_LVMX),true)
    LOCAL_CFLAGS += -DLVMX
    # c、c++头文件路径
    LOCAL_C_INCLUDES += vendor/nxp
    LOCAL_STATIC_LIBRARIES += liblifevibes
    LOCAL_SHARED_LIBRARIES += liblvmxservice
#    LOCAL_SHARED_LIBRARIES += liblvmxipc
endif
include $(BUILD_SHARED_LIBRARY) # 模块三编译成动态库

预编译应用的Android.mk语法分析

  LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)  
  # Module name should match apk name to be installed.
  LOCAL_MODULE := LocalModuleName
  LOCAL_SRC_FILES := $(LOCAL_MODULE).apk
  LOCAL_MODULE_CLASS := APPS
  LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
  include $(BUILD_PREBUILT)

7.2 Android.mk扩展

下面再介绍一下Android.mk文件编写的一些变量：

7.2.1 自定义变量

以下是在 Android.mk中依赖或定义的变量列表， 可以定义其他变量为自己使用

• 以 LOCAL_开头的名字（例如 LOCAL_MODULE）
• 以 PRIVATE_, NDK_ 或 APP_开头的名字（内部使用）
• 小写名字（内部使用，例如‘my-dir’）
  如果为了方便在 Android.mk 中定义自己的变量，建议使用 MY_前缀，一个小例子：

MY_SOURCES := foo.c
ifneq ($(MY_CONFIG_BAR),)
        MY_SOURCES += bar.c
endif
LOCAL_SRC_FILES += $(MY_SOURCES)

注意： ‘: =’是赋值的意思；’+='是追加的意思；‘$’表示引用某变量的值。

7.2.2 GNU Make系统变量

（1）CLEAR_VARS
指向一个编译脚本，几乎所有未定义的LOCAL_XXX变量都在"Module-description"节中列出。必须在开始一个新模块之前包含这个脚本：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 平台的名字.
（6）TARGET_ARCH_ABI
支持多个 value，armeabi 、 armeabi-v7a、 armebi-v8a、 x86等。在现在的版本中一般把这两个值简单的定义为 arm， 通过 android 平台内部对它重定义来获得更好的匹配。其他的 ABI 将在以后的 NDK 版本中介绍，它们会有不同的名字。注意虽然所有基于ARM的ABI都会把 ‘TARGET_ARCH’定义成‘arm’， 但是会有不同的‘TARGET_ARCH_ABI’。
（7） TARGET_ABI
目标平台和 ABI 的组合，它事实上被定义成$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) ，在想要在真实的设备中针对一个特别的目标系统进行测试时，会有用。在默认的情况下，它会是’android-3-arm’。

7.2.3 模块描述变量

下面的变量用于向编译系统描述你的模块。你应该定义在’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的，你可以使用路径部分，例如：

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目录。
示例:LOCAL_C_INCLUDES := sources/foo或LOCAL_C_INCLUDES := $(LOCAL_PATH)/…/foo
LOCAL_C_INCLUDES需要在任何包含LOCAL_CFLAGS/LOCAL_CPPFLAGS标志之前进行设置。

（6）LOCAL_CFLAGS

可选的编译器选项，在编译 C 代码文件的时候使用。这可能是有
用的，指定一个附加的包含路径(相对于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指定最后的目标安装路径.
不同的文件系统路径用以下的宏进行选择：
TARGET_ROOT_OUT：表示根文件系统。
TARGET_OUT：表示 system文件系统。
TARGET_OUT_DATA：表示 data文件系统。

用法如：LOCAL_MODULE_PATH :=$(TARGET_ROOT_OUT)
至于LOCAL_MODULE_PATH 和LOCAL_UNSTRIPPED_PATH的区别，暂时还不清楚。

(15) LOCAL_ASSET_FILES

在Android.mk文件中编译应用程序(BUILD_PACKAGE)时设置此变量，表示资源文件，通常会定义成LOCAL_ASSET_FILES += $(call find-subdir-assets)

(16) LOCAL_COPY_HEADERS
安装应用程序时需要复制的头文件，必须同时定义LOCAL_COPY_HEADERS_TO
(17) LOCAL_COPY_HEADERS_TO
install应用程序时复制头文件的目的路径
(18)LOCAL_CPP_EXTENSION
如果你的C++文件不是以cpp为文件后缀，你可以通过LOCAL_CPP_EXTENSION指定C++文件后缀名
如：LOCAL_CPP_EXTENSION := .cc
注意统一模块中C++文件后缀必须保持一致。
(19) LOCAL_CPPFLAGS
传递额外的标志给C++编译器，如：LOCAL_CPPFLAGS += -ffriend-injection
(20) LOCAL_PREBUILT_EXECUTABLES
预编译including $(BUILD_PREBUILT)或者$(BUILD_HOST_PREBUILT)时所用,指定需要复制的可执行文件
(21) LOCAL_REQUIRED_MODULES
指定模块运行所依赖的模块(模块安装时将会同步安装它所依赖的模块)
其他：
LOCAL_PREBUILT_JAVA_LIBRARIES
LOCAL_PREBUILT_LIBS
预编译including $(BUILD_PREBUILT)或者$(BUILD_HOST_PREBUILT)时所用, 指定需要复制的库
LOCAL_PRELINK_MODULE
是否需要预连接处理(默认需要，用来做动态库优化)