承接上篇分享完JNI的基础和扼要开发流程之后,再来分享下正正在Android情况下的JNI的开发,以及涉及到的NDK相干的操作。当然,本篇仍是以Eclipse作为开发IDE,固然Google官方曾经不再支持Eclipse了,引荐是用AndroidStudio进行开发。但对于逛戏开发来说,IDE的影响并没有那么大,且从Eclipse那个时代过来的,对Eclipse还是感情很深的。后续,还有分外一篇来分享下AndroidStudio的运用以及运用CMake编译等,会提到JNI这方面的实质。

遵照惯例,每一篇文章都喜好附上官方的文档。由于,只有官方的文档才是最切实,最实时,且实质最充裕的。那么,NDK官方开发地址为:


本文目录如下:

1、NDK情况搭建

(1)安装CDT

CDT全成是C/C++ DevelopmentTools,安装该插件使得Eclipse也得支持C/C++的开发。须下载和Eclipse版本对应的CDT插件。是喜好Eclipse的便捷,同时又开发C/C++的必装插件。CDT的下载地址为:

 安装成功后,正正在Eclipse的Window-Preferences中看到众了一项C/C++的支持:

(2)NDK的下载
目前,NDK的最新版本为android-ndk-r13b,下载地址为:

这里需要说明下,为了便当演示笔者所运用的NDK版本为android-ndk-r8b 。最新版本曾经不再支持GCC编译,默认改用Clang。还修复了相干的bug,建议线上的产物更新最新的稳定版。

(3)NDK的集成
 将下载好的NDK解压,并将该路径添加到Path情况变量中,然后集成至Eclipse中。如图:

2、交叉编译

NDK编译的情况有很众,但根蒂都是通过ndk-build东西来完成的。有直接通过Eclipse安装CDT即可完编译,也可以通过安装Cygwin来编译。实情上,正正在android-ndk-r7之后的版本,曾经不需要安装Cygwin就可以编译出.so 了。但这里还是想先容下,由于笔者开发曾用Cygwin编译过一段时间,而且众了解一种编译途径也没什么坏处。当然,熟习Linux平台或者Mac平台开发的朋友会以为更存眷些。

2.1 Cygwin编译

Cygwin是一套正正在Window上模仿类Unix编制情况的东西。而Android底层又是基于Linux的。于是,对Linux情况下的开发支持也更好。只要正正在Cygwin中安装gccg++gdbmakeGUN东西集即可。
(1)Cygwin的安装
Cygwin的下载地址为:

(2)Cygwin的安装步骤:
下载完setup-x86_64.exe,直接下一步:

这里有三个选项,分别是从网络安装,只下载担心装,从当地目录安装(如果,之前安装过)。可依据自己的执行情况选择。这里选择从网络安装。然后,下一步

这里选择第一项,Direct Connection。然后,下一步

这里下载地址选择mirrors.kernel.org即可。也可选择国内163的镜像地址。

这里选择要安装的包(autoconfautomakemakegccg++gdbpcregawk等)。这里偷懒就直接把AdminDebugDevelDocEditorsShells,当然还有Python。然后,下一步

接着经过漫长的等待,大概下载3,4G的文件。

安装完,运行Cygwin,输入如下下令

(3)正正在Cygwin下装备NDK情况变量
正正在当前当前用户目录下运行,(例如,我的目录为D:\env\cygwin\home\John):

装备NDK情况变量,帮理别掩盖原来的PATH情况变量。

(4)验证NDK装备
执行正正在Cygwin下用ndk-build来编译NDK下的hello-jni的samples。如图:

可以看到正确编译出libhello-jni.so库(正正在项目目录下的libs ,折柳cup架构定名的文件夹里)。如遇到种种权限错误,请将samples下的hello-jni项目标权限修改为可写入、可修改等。

2.2 Eclipse编译

(1)将hello-jni的项目导入到Eclipse中。


(2)给hello-jni添加builder,来编译C/C++代码。
右键HelloJni项目,选择Properties,然后,选择Builders,点击New新建一个Builder。选择Program,点击OK即可。

 分别填写Builder名称。找到Cygwin的Shell程序和工作目录。将要编译的项目目录和执行的下令当成参数参数Shell下令执行。

帮理: cd/cygdrive/d/android-ndk-r8b/samples/hello-jni中间有个空格。
ANDROID_NDK_ROOT:是正正在Cygwin中装备NDK情况变量的名称。

通过Cygwin中输入bash --login -h可以获取更详细的信歇:

Your group is currently "mkpasswd".  This indicates that your gid is not in /etc/group and your uid is not in /etc/passwd.  The /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run  mkpasswd -l [-d] >> /etc/passwd mkgroup  -l [-d] >> /etc/group

如果遇到这种,遵照提示正正在Cygwin着末执行,mkpasswd -l [-d] >> /etc/passwdmkgroup -l [-d] >> /etc/group下令即可。

(3)将装备JNI_Builder优先级设为最高

(4)编译HelloJni工程。
选中HelloJni工程,正正在Eclipse中选择Project-clean。这样,Eclipse便可自动编译HelloJni工程了。

2.3 AndroidStudio和CMake编译

这里就不花篇幅先容这相干的实质,下一篇分外先容下AndroidStudio的运用及正正在AndroidStudio下NDK的开发。希望能给从其它IDE迁移到IntelliJ IDEA系开发可能刚接触AndroidStudio一些诱导。以是,这里先留个伏笔。

ndk-build、Android.mk与Application.mk

固然,曾经成功的将samples下的hell-jni项目成功编译出了.so动态库。正正在整体交叉编译历程中,涉及到了三个比拟浸要的文件,分别是ndk-buildAndroid.mkApplication.mk,以是,有必要了解一下,这三个文件正正在整体交叉编译历程中起了什么作用。

3、ndk-build

起首,ndk-build是一个shell剧本,目标是帮帮你正确的调用NDK的构建剧本。ndk-build正正在<ndk-root-path>(NDK安装目录根路径下)有个ndk-build的shell剧本文件,或ndk-build.cmd的文件。

ndk-build的官方指南为:

3.1 ndk-build用法
cd $PROJECT_PATH $ <ndk>/ndk-build

用法:正正在项目标根目录下,执行ndk-build剧本下令。

例如:

进到hello-jni的项目根目录执行ndk-build,ANDROID_NDK_ROOT 是正正在Cygwin中装备NDK情况变量的名称。

$ <ndk>/ndk-build -C <PROJECT_PATH>

用法:正正在任意目录下执行ndk-build,用-C 来指定要编译的项目标目录。

例如:

执行上:执行ndk-build相当于执行了以下下令:

$GNUMAKE -f <ndk>/build/core/build-local.mk <parameters>

例如:

3.2 ndk-build可选参数
$ ndk-build clean 清除编译天生的二进制文件。  $ ndk-build -C <project> 指定项目路径  $ ndk-build NDK_DEBUG=0 NDK_DEBUG为0是编译为release版,为debug版。

更众的ndk-build的参数先容,请参考上面贴出的ndk-build的官方指南。

4、Android.mk

Android.mk是用来向编译编制指定项目中C/C++源代码文件编译、链接法则的一种描绘文件。它是GUN makefile文件的一小限制。那么,简单来说,就是用来起指定编译援用的头文件目录、编译出的so的名字、需要编译的源文件或库等作用。熟习makefile语法的,肯定熟习这种用法。Android.mk文件正正在$project-path/jni/Android.mk路径下。

Android.mk官方说明文档地址为:

4.1 Android.mk初级

起首,仍以hello-jni为例,看看都定义了哪些实质。打开<ndk-path>/samples/hello-jni/jni/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是由编译编制提供的宏,用来返回当前目录的路径。(帮理:这个路径是包含了Android.mk的路径)

include $(CLEAR_VARS)
CLEAR_VARS变量也是由编译编制提供的,include $(CLEAR_VARS)是援用一个特殊的GUN makefile文件,这个makefile文件所做的就是清除定义了很众LOCAL_XXX(例如: LOCAL_MODULE,LOCAL_SRC_FILES,LOCAL_STATIC_LIBRARIES等)这种格式的变量,但这里不会清除LOCAL_PATH变量。这么做是很有必要的,由于编译编制解析这些编译控制文件都是正正在简单的GUN make上下文情况中,解析出来的LOCAL_XXX变量都是全事务署的。

LOCAL_MODULE := hello-jni
LOCAL_MODULE必须是独一的,且不行包含空格。编译编制会依据这个名字天生相应的共享库,并自动添加前缀和后缀。本例中,最终天生的共享库的名称为libhello-jni.so

帮理:编译天生的共享库都是lib由来的,如果,你声明的名称曾经包含lib(libhello-jni),那么,最终天生的共享库名称就不添加lib前缀了,天生的仍为libhello-jni.so

LOCAL_SRC_FILES := hello-jni.c
LOCAL_SRC_FILES用来指明要编进共享库(.so)的C/C++源文件的列表。

帮理:这里只需要指定要编译的.c或者.cpp等源文件即可,不需要指定.h头文件。

include $(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY变量是由编制提供,include $(BUILD_SHARED_LIBRARY)会援用一个Gun makefile剧本,用来征采你定义的LOCAL_XXX 格式的变量。同时,决定哪些要编译,怎样编译等。

帮理:显然BUILD_SHARED_LIBRARY是用来编译出共享库.so文件的,同理,也可以运用BUILD_STATIC_LIBRARY来编译出静态库.a文件。

以上便是编写一个简单的Android.mk文件的所有元素。通过上面的描绘发现,如果银河文娱有哪些网站_云顶文娱场7610_bet9九州 网站要编写一个自己的Android.mk文件,没有特殊需求的话,可以直接将hello-jni工程中的Android.mk文件拷贝,然后,修改库的名称(LOCAL_MODULE)和要编译的源文件列表(LOCAL_SRC_FILES)变量即可。

4.2 Android.mk高级

这里来详细了解下Android.mk其他的一些变量及语法法则。

(1)NDK变量与宏
正正在Android.mk 中还有一些其他变量,是作为NDK编译编制的保存变量,你只可依赖它或者定义它。这些变量的法则如下:

  • LOCAL_由来的变量名称(如:LOCAL_MODULELOCAL_PATH等)
  • PRIVATE_NDK_APP由来的变量名称(编译编制内部运用)
  • 小写的名称(例如:my-dir,同样,也是作为内部运用)

如果你需要正正在Android.mk中定义自己的变量,引荐用MY_作为前缀。

(2)NDK定义的变量
CLEAR_VARS
上面曾经先容过了,这里就不正正在赘述。记住一点,正正在定义LOCAL_XXX 前,必须援用这个剧本。用法:

include $(CLEAR_VARS)

BUILD_SHARED_LIBRARY
该变量指向了一个剧本,这个剧本会征采你正正在每个模块定义的LOCAL_XXX变量信歇,而且这个变量还确定了怎样运用你的源码去编译一个共享库。帮理,运用这个变量需要你最少曾经定义了LOCAL_MODULELOCAL_SRC_FILES。该变量会使编译编制天生一个以.so结尾的库。用法:

include $(BUILD_SHARED_LIBRARY)

BUILD_STATIC_LIBRARY
该变量是BUILD_SHARED_LIBRARY的一个变体,是用来天生一个静态库。构建编制并不会把静态库包含进你的工程里面,可是可以诈欺静态库天生共享库。该变量会使编译编制天生一个以.a结尾的库。

include $(BUILD_STATIC_LIBRARY)

PREBUILT_SHARED_LIBRARY
指向一个剧本,这个剧本被用来指定一个预构建的共享库。与BUILD_SHARED_LIBRARYBUILD_STATIC_LIBRARY折柳,LOCAL_SRC_FILES的值不行是一个源文件,它必须是一个单独的指向预构建的共享库的路径,例如:foo/libfoo.so。用法:

PREBUILT_STATIC_LIBRARY
该变量与PREBUILT_SHARED_LIBRARY 相同,只是指向的一个预构建的静态库。

TARGET_ARCH
这个变量是目标CPU架构的名字,就像Android Open Source Project里面指定了目标CPU架构。这个变量用于任意的ARM兼容的构建,或者ARM,或者是单独于CPU构制的修订,或者ABI。

TARGET_PLATFORM
编译到目标平台的api等级。例如,Android5.1对应的是Android api22。用法:

TARGET_PLATFORM := android-22

TARGET_ARCH_ABI
当编译编制解析Android.mk文件的时候,这个变量存储CPU和架构的名字。你可以指定一个或者众个下面列出的名字,运用空格离开两个名字

用法:

TARGET_ARCH_ABI := arm64-v8a

 帮理:android-ndk-1.6_r1之前这个这个变量被定义为arm。

TARGET_ABI
 该变量将API的级别和ABI联系正正在一起,当你正正在真机上调试编制的时候特别有效。用法:

TARGET_ABI := android-22-arm64-v8a

LOCAL_MODULE_FILENAME
这是一个可选变量。允许你浸新指定一个变量的名称来掩盖默认天生的名称。例如:强逼天生libnewfoo.so

LOCAL_MODULE := foo LOCAL_MODULE_FILENAME := libnewfoo

LOCAL_MODULE_FILENAME 不需要指定文件路径或扩展名

LOCAL_SRC_FILES:
该变量用来指定要编译的源文件列表。这里引荐运用相对路径。用法:

LOCAL_SRC_FILES := foo1.c \ ../Module2/foo2.c

帮理:运用Unix风格的/,众个文件运用\换行,帮理\后面没有空格。

LOCAL_CPP_EXTENSION
同样,LOCAL_CPP_EXTENSION也是一个可选变量。用来指定C++源文件的扩展名。默认是.cpp。从NDK r7版本后,可以指定一系列的扩展名。用法:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES
同样,LOCAL_CPP_FEATURES也是一个可选变量。如果,你用到了C++的一些特殊功能(例如:RTTI,分外支持等),而且正确的编译和链接,可以运用该变量来声明。用法:

LOCAL_CPP_FEATURES := rtti exceptions

建议运用该变量来替代LOCAL_CPPFLAGS中直接定义-frtti-fexceptions这种用法

LOCAL_C_INCLUDES
可选变量,可以通过该变量来指定一个相对于NDK根目录的路径列表,并正正在编译C/C++时添加到搜索路径中。用法:

LOCAL_C_INCLUDES := $(LOCAL_PATH)//foo

帮理:该声明要放正正在LOCAL_CFLAGSLOCAL_CPPFLAGS的声明前面。

LOCAL_CFLAGS
 可选变量,正正在编译C/C++源代码时,能给编译器传递一个编译标志集合。用来指定附加宏的定义和编译选项是很有效的。

LOCAL_CPPFLAGS
可选变量,正正在编译C++源代码时(只编译C++),能给编译器传递一个编译标志集合。

LOCAL_STATIC_LIBRARIES:
 该变量定义了本模块编译链接历程顶用到的静态库列表。

LOCAL_SHARED_LIBRARIES
该变量定义了本模块编译链接历程顶用到的共享库列表。

LOCAL_WHOLE_STATIC_LIBRARIES
该变量跟LOCAL_STATIC_LIBRARIES雷同,折柳的是正正在编译链接历程中会载入静态库的所有源代码目标文件。这正正在解决几个库之间循环援用时,非常有效。可以通过GUN的--whole-archive标志来查看相干说明。

LOCAL_LDLIBS
该变量用来定义本模块编译时用到的附加的链接器选项。用-l前缀指定。例如:要链接/system/lib/libz.so

LOCAL_LDLIBS := -lz

帮理:如果,你编译一个静态库是定义了该变量,编译编制会忽略它,而且ndk-build会打印一个警备。

LOCAL_LDFLAGS
该变量定义了正正在编译给编译编制传递一些其他的链接标志。用法:

LOCAL_LDFLAGS += -fuse-ld=bfd

帮理:如果,你编译一个静态库是定义了该变量,编译编制会忽略它,而且ndk-build会打印一个警备。

LOCAL_ALLOW_UNDEFINED_SYMBOLS
默认情况下,正正在编译一个共享库的时候,任何未定义的援用,将会扔出"符号未定义(undefined symbol)"的错误。该变量能帮帮你捕捉代码中的bug。如果,要禁用这项反省可以把该变量设置为true。这么设置

帮理:如果,你编译一个静态库是定义了该变量,编译编制会忽略它,而且ndk-build会打印一个警备。

LOCAL_ARM_MODE
 默认情况下,编译编制会正正在ARM平台"thumb"模式下天生16位的二进制文件。定义该变量则强逼天生32位"arm"模式下的对象文件。例如:

LOCAL_ARM_MODE := arm

你也可以加上.arm后缀来告诉编译编制,只想对某个源文件运用arm指令。例如:

LOCAL_SRC_FILES := foo.c bar.c.arm

LOCAL_ARM_NEON
只有当目标平台为armeabi-v7a指令集时,才定义它。它允许你的C/C++代码中运用ARM高级指令。也可以正正在汇编文件中运用NEON指令。你可以运用.neon 后缀来指定编译器支持NEON指令编译。例如:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

 帮理:不是所有的ARMv7架构的CPU都支持NEON扩展。

LOCAL_DISABLE_NO_EXECUTE
Android NDK r4版本开始支持这种"NX bit"的幽静功能。默认是启用的,你也可以设置该变量的值为true来禁用它。但不引荐这么做。该功能不会修改ABI,只正正在ARMv6+CPU的竖立内核上启用。

LOCAL_DISABLE_RELRO
默认情况下,NDK编译代码是只读浸定位和GOT保护的。这个会指示运行时链接器标志特定的内存区是只读的,正正在移动位置之后。这样会使得某些幽静漏洞(如GOT掩盖)更难执行。默认是启用的,你也可以把该变量的值设为true来禁用。但不引荐这么做。

LOCAL_DISABLE_FORMAT_STRING_CHECKS
 默认情况下,编译编制编译代码时会反省格式化字符串,如果printf样式的函数运用了非常严格的字符串,那么编译出错。默认是开启的,你也可以通过设置该变量的值为true来禁用。但不引荐这么做。

LOCAL_EXPORT_CFLAGS
该变量是用来记录C/C++编译器标志集合,这些编译器标志会被添加到通过变量LOCAL_STATIC_LIBRARIESLOCAL_SHARED_LIBRARIES运用本模块的其他模块的LOCAL_CFLAGS变量中。例如:

include $(CLEAR_VARS) LOCAL_MODULE := foo LOCAL_SRC_FILES := foo/foo.c LOCAL_EXPORT_CFLAGS := -DFOO=1 include $(BUILD_STATIC_LIBRARY)   include $(CLEAR_VARS) LOCAL_MODULE := bar LOCAL_SRC_FILES := bar.c LOCAL_CFLAGS := -DBAR=2 LOCAL_STATIC_LIBRARIES := foo include $(BUILD_SHARED_LIBRARY)

编译bar 模块时,"-DFOO=1 -DBAR=2"标志将一起传递给编译器。

LOCAL_EXPORT_CPPFLAGS
该变量与LOCAL_EXPORT_CFLAGS雷同,但只适用于C++。

LOCAL_EXPORT_C_INCLUDES
该变量与LOCAL_EXPORT_CFLAGS雷同,可是该变量用来包含路径的。例如,上例中bar.c需要包含foo模块的头文件。

LOCAL_EXPORT_LDFLAGS:
该变量与LOCAL_EXPORT_CFLAGS雷同,可是它用作链接器标志。

LOCAL_EXPORT_LDLIBS
该变量与LOCAL_EXPORT_CFLAGS往往,该变量的值将会被添加到其它模块援用到本模块的其它模块的LOCAL_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)

编译bar的时候,会正正在链接log的编制日志库。

LOCAL_SHORT_COMMANDS
当你的模块有很众源代码文件或依赖很众静态库或者共享库时,设置为true。这样会强逼编译编制运用@语法来包含中间对象或链接库来天生归档文件

 帮理:这个功能正正在Windows上很有效,由于Windows上的下令行支持的最大字符数为8191个,这对于复杂的项目来说太小。默认是不引荐启用这个功能,由于它会使编译变得很慢。

LOCAL_THIN_ARCHIVE
编译静态库是,如果该变量值设为true,会天生一个较小的归档文件。并不包含目标文件,而是用目标文件的路径替代。有效值是truefalse和空。

 帮理:如果该模块不是编译为静态块,或者预编译静态库,该值将被忽略。

LOCAL_FILTER_ASM
该变量的值将作为一个Shell下令,它会过滤从LOCAL_SRC_FILES 天生的文件或汇编文件。定义该变量将会发生下面的情况:

  • 编译编制会将C/C++源文件天生临时的汇编文件,而不是将他们编译到目标文件中。
  • 编译编制会对汇编文件和LOCAL_SRC_FILES中列出的文件执行LOCAL_FILTER_ASM中的Shell下令,天生另外一个汇编文件。
  • 编译编制将这些过滤后的汇编文件编译进目标文件。

NDK提供的函数宏
NDK提供了GNU Make的函数宏。运用$(call <function>)的格事务署调用,它们会返回相应的文本信歇。
my-dir
该宏返回的是着末包含的makefile文件路径,一般是当前Android.mk的路径。my-dir 对于Android.mk由来定义的LOCAL_PATH变量很有效。例如:

LOCAL_PATH := $(call my-dir)

由于GNU Make的工作格事务署,这个宏返回的是构建编制正正在解析构建剧本时包含的着末一个makefile的路径。于是,你不应该正正在include其他的文件之后再继续运用my-dir。例如:

LOCAL_PATH := $(call my-dir)  # ... declare one module  include $(LOCAL_PATH)/foo/`Android.mk`  LOCAL_PATH := $(call my-dir)  # ... declare another module

这里的问题正正在于第二个my-dir的调用将LOCAL_PATH的值设置为了$PATH/foo,由于$PATH/foo才是最近包含的路径。你可以通过正正在Android.mk文件中陈设分外的包含来避免这个问题。例如:

LOCAL_PATH := $(call my-dir)  # ... declare one module  LOCAL_PATH := $(call my-dir)  # ... declare another module  # extra includes at the end of the Android.mk file include $(LOCAL_PATH)/foo/Android.mk

如果这种格事务署不可行,那么可以将第一次调用my-dir的值存正正在另外一个变量里面,例如:

MY_LOCAL_PATH := $(call my-dir)  LOCAL_PATH := $(MY_LOCAL_PATH)  # ... declare one module  include $(LOCAL_PATH)/foo/`Android.mk`  LOCAL_PATH := $(MY_LOCAL_PATH)  # ... declare another module

all-subdir-makefiles
该宏返回的是当前my-dir 路径下的所有子目录中的Android.mk文件的列表。你可以运用此函数向构建编制提供深层嵌套的源目录目标构制。默认情况下,NDK仅查找包含Android.mk文件的目录中的文件。

this-makefile
 该宏返回的是当前makefile文件的路径(从构建编制调用这个函数中)。

parent-makefile
该宏返回当前目录树中的父makefile的路径(包含当前makefile的makefile路径)。

grand-parent-makefile
该宏返回包含树中的祖父类makefile的路径(包含当前makefile的makefile的路径)。

import-module
 该宏允许你通过模块的名称找到并包含模块的Android.mk文件。例如:

$(call import-module,<name>)

正正在这个示例中,构建编制会依据NDK_MODULE_PATH这个情况变量所指示的目录里面寻觅名为<name> 的模块,然后自动为你include对应的Android.mk文件。

5、Application.mk

通过上面的先容,大略了解了Android.mk文件的用法及法则。但通常编译当地C/C++代码光有Android.mk还不够,还得需要Application.mk文件。Application.mk也是一种makefile文件,跟Android.mk有相同之处。如果说,Android.mk用来描绘单独某个模块的编译法则的描绘文件,那么Application.mk则是描绘整体运用程序的模块的描绘文件。Application.mk文件一般正正在$project-path/jni/Application.mk下($project-path是项目根目录)。当然,也可以放正正在$NDK/apps/<myapp>/Application.mk路径下。这两种格事务署,制成Application.mk也有纤细的分别。

(1)变量
APP_PROJECT_PATH
 该变量用来指定项目根目录的绝对路径。

帮理:假如Application.mk文件的路径是$NDK/apps/<myapp>/Application.mk,那么该变量为强逼定义的。如果,Application.mk文件正正在$project-path/jni/Application.mk路径下,则是可选变量。

APP_OPTIM:
该变量为可选变量,值为releasedebug。编译运用程序模块的时,可以用来改变优化级别。默认是release模式,而且会天生高度优化的二进制文件。debug模式天生的是未优化的二进制代码,但更搪塞调试。

APP_CFLAGS
正正在编译任何模块的任何C/C++代码时,构建编制会通过该变量给编译器传递一个C编译标志集合。你可以运用该变量依据运用程序中给定的模块的需要来改变其构建,而不需要修改Android.mk文件本身了。
这些标志的所有路径必须相对于NDK的顶级目录。例如:如果你有以下设置:

sources/foo/Android.mk sources/bar/Android.mk

正正在编译功夫,你需要正正在foo/Android.mk中指定你要添加的foo的源路径,你应该运用:

APP_CFLAGS += -Isources/bar

或者:

APP_CFLAGS += -I$(LOCAL_PATH)/../bar

运用-I../bar将不行正常工作,由于它等价于-I$NDK_ROOT/../bar

帮理:正正在android-ndk-1.5_r1版本中,该变量只适用于C,不行作用于C++。之后的所有的版本,该变量可适用C/C++源码上。

APP_CPPFLAGS
 该变量包含一组C++编译器标志,构建编制仅正正在构建C++源代码时传递给编译器。

APP_LDFLAGS
 正正在链接的时候,构建编制编制会想链接器传递一组链接标志。该变量仅正正在构建编制构建共享库和可执行文件的时候才生效,当构建静态库时,将被忽略。

APP_BUILD_SCRIPT
默认情况下,NDK构建编制会正正在$project-path/jni/目录下查找Android.mk文件。如果你想修改此行为,你可以定义APP_BUILD_SCRIPT变量,并指向备用的构建剧本。编译编制总是将一个非绝对路径解释为NDK的顶级目录。

APP_ABI
默认情况下,编译编制会依据armeabi ABI天企望器码。该机器码基于ARMv5TE而且支持浮点运算的CPU。你可以运用APP_ABI参数来指定折柳的ABI。折柳的指令集的APP_ABI设置如下:

帮理:all是android-ndk-r7版本开始支持的。
你也可以指定众个值,将它们放正正在同一行,中间用空格离隔。例如:

APP_ABI := armeabi armeabi-v7a x86 mips

APP_PLATFORM
 此变量包含目标Android的名称。例如:android-3对应的是Android1.5的编制镜像。

APP_STL
默认情况下,NDK构建编制只为最小的C++运行库(/system/lib/libstdc++.so)提供C++头文件。此外,你还可以正正在自己的运用程序中运用或链接其他C++实现。可以运用APP_STL来选择其中的一个。例如:

APP_STL := stlport_static APP_STL := stlport_shared APP_STL := system

APP_SHORT_COMMANDS
该变量相当于整体项目标Android.mk中定义了LOCAL_SHORT_COMMANDS

NDK_TOOLCHAIN_VERSION
 将此变量定义为4.9版本的GCC编译器。正正在android-ndk-r13默认是Clang编译器。

APP_PIE
从Android 4.1(API级别16)开始,Android的动态链接器支持位置无关可执行文件(PIE)。从Android 5.0(API级别21),可执行文件需要PIE。要运用PIE构建可执行文件,需设置-fPIE标志。这个标志会使得通过随机代码的位置来查找内存损坏的bug越发贫窭。默认情况下,如果您的项目目标为Android-16或更高版本,ndk-build会自动将此值设置为true。您可以将其手动设置为true或false。

帮理:此标志仅适用于可执行文件。它正正在构建共享或静态库时没有任何作用。

APP_THIN_ARCHIVE
相当于正正在Android.mk文件中为此项目中的所有静态库模块设置LOCAL_THIN_ARCHIVE的默认值。

以上实质可能不一定绝对正确,大限制实质是依据Android官方文档,通过自己的理解转述的。并没有每个变量正正在.mk文件中有执行过。以是,如果遇到你以为有问题的地方,欢迎与我交换。

本文楬橥:Android开发网
2017年8月14日
楬橥:鸡啄米 分类:Android逛戏开发 浏览: 评论:0