linux android ndk android与linux的关系

大家好，今天来为大家分享linux android ndk的一些知识点，和android与linux的关系的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！

如何使用android的ndk编译器 编译c++的库

1.概述首先回顾一下 Android NDK开发中，Android.mk和 Application.mk各自的职责。
Android.mk，负责配置如下内容：（1）模块名（LOCAL_MODULE）（2）需要编译的源文件（LOCAL_SRC_FILES）（3）依赖的第三方库（LOCAL_STATIC_LIBRARIES，LOCAL_SHARED_LIBRARIES）（4）编译/链接选项（LOCAL_LDLIBS、LOCAL_CFLAGS）
Application.mk，负责配置如下内容：（1）目标平台的ABI类型（默认值：armeabi）（APP_ABI）（2） Toolchains（默认值：GCC 4.8）（3） C++标准库类型（默认值：system）（APP_STL）（4） release/debug模式（默认值：release）由此我们可以看到，本文所涉及的编译选项在Android.mk和Application.mk中均有出现，下面我们将一个个详细介绍。
2. APP_ABI
ABI全称是：Application binary interface，即：应用程序二进制接口，它定义了一套规则，允许编译好的二进制目标代码在所有兼容该ABI的操作系统和硬件平台中无需改动就能运行。（具体的定义请参考百度百科或者维基百科）由上述定义可以判断，ABI定义了规则，而具体的实现则是由编译器、CPU、操作系统共同来完成的。不同的CPU芯片（如：ARM、Intel x86、MIPS）支持不同的ABI架构，常见的ABI类型包括：armeabi，armeabi-v7a，x86，x86_64，mips，mips64，arm64-v8a等。这就是为什么我们编译出来的可以运行于Windows的二进制程序不能运行于Mac OS/Linux/Android平台了，因为CPU芯片和操作系统均不相同，支持的ABI类型也不一样，因此无法识别对方的二进制程序。而我们所说的“交叉编译”的核心原理也跟这些密切相关，交叉编译，就是使用交叉编译工具，在一个平台上编译生成另一个平台上的二进制可执行程序，为什么可以做到？因为交叉编译工具实现了另一个平台所定义的ABI规则。我们在Windows/Linux平台使用Android NDK交叉编译工具来编译出Android平台的库也是这个道理。这里给出最新 Android NDK所支持的ABI类型及区别：那么，如何指定ABI类型呢？在 Application.mk文件中添加一行即可：
APP_ABI:= armeabi-v7a//只编译armeabi-v7a版本
APP_ABI:= armeabi armeabi-v7a//同时编译armeabi，armeabi-v7a版本
APP_ABI:= all//编译所有版本
3. LOCAL_LDLIBS
Android NDK除了提供了Bionic libc库，还提供了一些其他的库，可以在 Android.mk文件中通过如下方式添加依赖：
LOCAL_LDLIBS:=-lfoo其中，如下几个库在 Android NDK编译时就默认链接了，不需要额外添加在 LOCAL_LDLIBS中：（1） Bionic libc库（2） pthread库（-lpthread）（3） math（-lmath）（4） C++ support library(-lstdc++)下面我列了一个表，给出了可以添加到“LOCAL_LDLIBS”中的不同版本的Android NDK所支持的库：下面是我总结的一些常用的CFLAGS编译选项：（1）通用的编译选项-O2编译优化选项，一般选择O2，兼顾了优化程度与目标大小-Wall打开所有编译过程中的Warning-fPIC编译位置无关的代码，一般用于编译动态库-shared编译动态库-fopenmp打开多核并行计算，-Idir配置头文件搜索路径，如果有多个-I选项，则路径的搜索先后顺序是从左到右的，即在前面的路径会被选搜索-nostdinc该选项指示不要标准路径下的搜索头文件，而只搜索-I选项指定的路径和当前路径。--sysroot=dir用dir作为头文件和库文件的逻辑根目录，例如，正常情况下，如果编译器在/usr/include搜索头文件，在/usr/lib下搜索库文件，它将用dir/usr/include和dir/usr/lib替代原来的相应路径。-llibrary查找名为library的库进行链接-Ldir增加-l选项指定的库文件的搜索路径，即编译器会到dir路径下搜索-l指定的库文件。-nostdlib该选项指示链接的时候不要使用标准路径下的库文件（2） ARM平台相关的编译选项-marm-mthumb二选一，指定编译thumb指令集还是arm指令集-march=name指定特定的ARM架构，常用的包括：-march=armv6，-march=armv7-a-mfpu=name给出目标平台的浮点运算处理器类型，常用的包括：-mfpu=neon，-mfpu=vfpv3-d16-mfloat-abi=name给出目标平台的浮点预算ABI，支持的参数包括：“soft”,“softfp” and“hard”

如何定位Android NDK开发中遇到的错误

如何定位Android NDK开发中遇到的错误

Android NDK中的错误定位对很多开发者来说是一件头疼的事，本文通过一个Demo程序详细讲解了NDK的错误是如何产生的，以及如何通过命令行工具定位NDK的问题所在。

Android NDK是什么？

Android NDK是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C/ C++之类的原生代码语言执行部分程序。NDK包括：

从C/ C++生成原生代码库所需要的工具和build files；

将一致的原生库嵌入可以在Android设备上部署的应用程序包文件（application packages files，即.apk文件）中；

支持所有未来Android平台的一系列原生系统头文件和库。

为何要用到NDK？概括来说主要分为以下几种情况：

代码保护，由于APK的Java层代码很容易被反编译，而C/C++库反汇难度较大；

在NDK中调用第三方C/C++库，因为大部分的开源库都是用C/C++代码编写的；

便于移植，用C/C++写的库可以方便地在其他的嵌入式平台上再次使用。

Android JNI与NDK的关系

Java Native Interface（JNI）标准是Java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI是本地编程接口，它使得在Java虚拟机（VM）内部运行的Java代码能够与用其它编程语言（如C、C++和汇编语言）编写的应用程序和库进行交互操作。

简单来说，可以认为NDK就是能够方便快捷开发.so文件的工具。JNI的过程比较复杂，生成.so需要大量操作，而NDK的作用则是简化了这个过程。

哪些常见的NDK类型异常会导致程序Crash？

NDK编译生成的.so文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。不同于Java代码异常造成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会立即退出，即通常所说的闪退，而不会弹出“程序xxx无响应，是否立即关闭”之类的提示框。

NDK是使用C/C++来进行开发的，熟悉C/C++的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题，最后都是同一个结果：程序崩溃。例如我们常说的空指针错误，就是当一个内存指针被置为空（NULL）之后再次对其进行访问；另外一个经常出现的错误是，在程序的某个位置释放了某个内存空间，而后在程序的其他位置试图访问该内存地址，这就会产生无效地址错误。常见的错误类型如下：

初始化错误；

访问错误；

内存泄露；

参数错误；

堆栈溢出；

类型转换错误；

数字除0错误。

如何发现并解决NDK错误？

利用Android NDK开发本地应用时，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，如何通过两种不同的方法，来定位错误的函数名和代码行。

首先，来看看我们在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），下面代码中：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中， std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。我们记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃。

下面我们来看看发生崩溃（闪退）时系统打印的logcat日志：

如果你看过logcat打印的NDK错误的日志就会知道，我省略了后面很多的内容，很多人看到这么多密密麻麻的日志就已经头晕脑胀了，即使是很多资深的Android开发者，在面对NDK日志时也大都默默地选择了无视。

其实，只要你细心的查看，再配合Google提供的工具，完全可以快速地准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对NDK错误进行符号化的工作，需要保留编译过程中产生的包含符号表的so文件，这些文件一般保存在$PROJECT_PATH/obj/local/目录下。

第一种方法：ndk-stack

这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk–stack命令也有两种方式

实时分析日志

在运行程序的同时，使用adb获取logcat日志，并通过管道符输出给ndk-stack，同时需要指定包含符号表的so文件位置；如果你的程序包含了多种CPU架构，在这里需求根据错误发生时的手机CPU类型，选择不同的CPU架构目录，如：

当崩溃发生时，会得到如下的信息：

我们重点看一下#03和#04，这两行都是在我们自己生成的libhello-jni.so中的报错信息，因此会发现如下关键信息：

回想一下我们的代码，在JNI_OnLoad()函数中（第61行），我们调用了willCrash()函数；在willCrash()函数中（第69行），我们制造了一个错误。这些信息都被准确无误的提取了出来！是不是非常简单？

先获取日志再分析

这种方法其实和上面的方法没有什么大的区别，仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件，甚至可以在崩溃发生时，快速的将logcat日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。

第二种方法：使用addr2line和objdump命令

这个方法适用于那些不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但可以稍稍满足一下程序员的好奇心。

先简单说一下这两个命令，在绝大部分的Linux发行版本中都能找到他们，如果你的操作系统是Linux，而你测试手机使用的是Intel x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。

在NDK中自带了适用于各个操作系统和CPU架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，你可以在NDK目录的toolchains目录下找到他们。以我的Mac电脑为例，如果我要找的是适用于armeabi架构的工具，那么他们分别为arm-linux-androideabi-addr2line和arm-linux-androideabi-objdump；位置在下面目录中，后续介绍中将省略此位置：

假设你的电脑是Windows系统，CPU架构为mips，那么你要的工具可能包含在一下目录中：

接下来就让我们来看看如何使用这两个工具，下面具体介绍。

找到日志中的关键函数指针

其实很简单，就是找到backtrace信息中，属于我们自己的so文件报错的行。

首先要找到backtrace信息，有的手机会明确打印一行backtrace（比如我们这次使用的手机），那么这一行下面的一系列以“#两位数字 pc”开头的行就是backtrace信息了。有时可能有的手机并不会打印一行backtrace，那么只要找到一段以“#两位数字 pc”开头的行，就可以了。

其次要找到属于自己的so文件报错的行，这就比较简单了。找到这些行之后，记下这些行中的函数地址。

使用addr2line查找代码位置

执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可

结果如下：

从addr2line的结果就能看到，我们拿到了我们自己的错误代码的调用关系和行数，在hello-jni.cpp的69行和61行（另外两行因为使用的是标准函数，可以忽略掉），结果和ndk-stack是一致的，说明ndk-stack也是通过addr2line来获取代码位置的。

使用objdump获取函数信息

通过addr2line命令，其实我们已经找到了我们代码中出错的位置，已经可以帮助程序员定位问题所在了。但是，这个方法只能获取代码行数，并没有显示函数信息，显得不那么“完美”，对于追求极致的程序员来说，这当然是不够的。下面我们就演示一下怎么来定位函数信息。

首先使用如下命令导出函数表：

在生成的asm文件中查找刚刚我们定位的两个关键指针00004fb4和00004f58：

从这两张图可以清楚的看到（要注意的是，在不同的NDK版本和不同的操作系统中，asm文件的格式不是完全相同，但都大同小异，请大家仔细比对），这两个指针分别属于willCrash()和JNI_OnLoad()函数，再结合刚才addr2line的结果，那么这两个地址分别对应的信息就是：

相当完美，和ndk-stack得到的信息完全一致！

Testin崩溃分析如何帮开发者发现NDK错误

以上提到的方法，只适合在开发测试期间，如果你的应用或游戏已经上线，而用户经常反馈说崩溃、闪退，指望用户帮你收集信息定位问题几乎是不可能的。这个时候，我们就需要用其他的手段来捕获崩溃信息。

目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入SDK，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，国内的Testin和国外的crittercism都可以提供类似服务。

Testin从1.4版本开始支持NDK的崩溃分析，其最新版本已升级到1.7。当程序发生NDK错误时，其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过logcat日志获取到的函数指针）、设备信息、线程信息等，SDK将这些信息上报至Testin云服务平台，在平台进行唯一性的处理、并可以自定义时段进行详尽的统计分析，从多维度展示程序崩溃的信息和严重程度；最新版本还支持用户自定义场景，方便开发者定位问题所在。

从用户手机上报的堆栈信息，Testin为NDK崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的so文件上传，就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。而且使用这个功能还有一个好处：这些包含符号表的so文件，在每次开发者编译之后都会改变，很有可能我们发布之后就已经变了，因为开发者会修改程序。在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。我们可以将这些文件上传到Testin进行符号化的工作，Testin会为我们保存和管理不同版本的so文件，确保信息不会丢失。

出自：

深入Linux环境下NDK的配置方法linux配置ndk

《深入Linux环境下NDK的配置方法》

Linux环境下的NDK（Native Development Kit）是一种开发工具，它使开发者能够使用C和C++编写针对Android设备的原生应用程序。在此文中，我们将详细介绍如何在Linux环境下配置NDK。

第一步：下载并安装NDK。下载最新版本的Android NDK，按照官方文档指导安装即可。如果要使用不同版本的NDK，请下载女性对应版本的文件并完成安装。

第二步：配置环境变量。配置NDK的环境变量很重要，它将是以后使用NDK的基础。执行下面的指令，把NDK的路径添加到PATH环境变量中：

export NDK_ROOT=[ndk install path]

export PATH=$NDK_ROOT:$PATH

如果要在终端中添加长期可使用的路径，请在.profile文件中添加上面的指令，并执行：

source~/.profile

第三步：安装NDK工具。安装完NDK之后，需要安装相关的NDK工具，包括：make，gcc，gdb等。使用如下指令查看是否已安装：

which make

which gcc

如果返回的信息是一个空，则表示这些工具都没有安装。下载一个可执行文件并运行它以完成安装：make– v；gcc-v；gdb-v。

第四步：编写和编译C/C++项目。完成上述步骤之后，现在可以使用Android NDK开发应用了。使用以下指令编译所有C/C++源文件：

ndk-build

该指令会生成编译后的可执行文件，如果有任何错误，可以再次检查上述步骤，确保未出错。

以上是Linux环境中NDK的配置方法。配置完成后，可以利用NDK开发丰富多彩的Android原生应用程序。此外，也可以借助官方文档和支持社区了解更多有关NDK的信息。