NDK版本与Android固件要求对应表

NDK版本与Android固件要求对应表

对于Android NDK版本来说，编译出来的so文件对应运行的Android固件最小版本是有一定要求的，高版本的NDK编译出的.so文件由于包含了一些新的特性，新特性可能在低版本的Android固件上无法运行，目前最新的对着表Android开发网总结如下

API Level 1 --- Android 1.0 不支持NDK

API Level 2 --- Android 1.1 不支持NDK

API Level 3 --- Android 1.5 NDK 1

API Level 4 --- Android 1.6 NDK 2

API Level 5 --- Android 2.0

API Level 6 --- Android 2.0.1

API Level 7 --- Android 2.1 NDK 3

API Level 8 --- Android 2.2 NDK 4

API Level 9 --- Android 2.3 NDK 5

API Level 10 --- Android 2.3.3

API Level 11 --- Android 3.0

API Level 12 --- Android 3.1 NDK 6

API Level 13 --- Android 3.2

API Level 14 --- Android 4.0.1 NDK 7

API Level 15 --- Android 4.0.3

从上面来看，在Android关键版本更新上，NDK加入了很多新的特性，从简单的C/C++知道到兼容STL，再到硬件扩展等，使得Android更开放，更强大。

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的常见的有哪些类型异常？

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

“符号化”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命令也有两种方式

使用ndk-stack实时分析日志

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

[plain] view

plain copy

adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

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

[plain] view

plain copy

********** Crash dump: **********

Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'

pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com