androidndkr9b

‘壹’ android-ndk-r12b 在eclipse上怎么配置环境变量

一.插件的安装
如果你下载的是Eclipse
Standard,请下载对应版本的cdt（我直接使用的是Eclipse
IDE
for
C/C++
Developers
不要安装cdt的哦，我人比较懒，(*^__^*)
嘻嘻……）
比如
CDT
8.1.2
for
Eclipse
Juno
cdt-master-8.1.2.zip，插入也比较简单和adt安装方式一样。再次不在赘述。以前NDK的版本还要Sequoyah插件(好久不更新了)来进行本地开发，现在不需要了。
二.环境的配置
1）.首先进行配置NDK的配置，打开Eclipse的
Window->preferences->Android->NDK
然后选择路径你的NDK路径我的目录如下D:\android-sdk\android-ndk-r9
这个目录下有docs，sources,tests,samples
e等等。
然后点击Apply，OK即可
2）.首先导入hello—jni工程，然后点击右键->Properties你看见如下图所示的界面，这不是一个可以编译的NDK工程。你需要运行Cygwin或者在Eclipse配置。
我们首先使用Cygwin来生成程序的.so文件。打开Cygwin运行命令cd
$ndk
这个ndk是之前你配置Cygwin环境变量设置的字符。然后cd
samples/hello-jni
然后$ndk/ndk-build,你就可以看见生成.so文件成功的页面，这时候刷新或者clean工程
点击run
as运行android程序。如下图：


三.Eclipse
工程配置在Eclipse中开发c/c++
第二步运行完之后，你会发现你把Hello
from
JNI修改为AAA(随便写的)
这个字符串不好使，输出之后还是Hello
from
JNI
。你需要再次运行Cygwin才可以。当然这样比较麻烦，你可以在Eclipse中配置一下，就不要在运行Cygwin了。直接运行eclipse就可以了。
1）在HelloJni上右键->New->other(这一步一定是other)->c/c++>Convert
to
a
C/C++
Project(Adds
c/c++
Nature)->Next
然后选择你的工程HelloJni，选择转化为c工程，选择Makefile
Project
Cygwin
GCC,点击Finish，再次点击Finish即可
2）你发现你的工程.c文件有很多错误。这个时候点击工程右键->Propreties这个时候你会发现和第二步的2）图多了二项
c/c++
Build
和c/c++
General.
点击
c/c++
Build
Use
defult
build
commond的勾去掉
在Build
command
填入bash
<NDK路径>\ndk-build
例如bash
D:\android-sdk\android-ndk-r9\ndk-build点击Apply
OK即可。
点击c/c++
General
打开列表点击Paths
and
Symbols
在Includes
你看见Assembly
GNU
C
(如果你在1）步选择的C++project还会有GNU
C++)
.这个时候要选择你所要的依赖库，由于hello-jni不需要过多的库文件所以
只需要点击Add
D:\android-sdk\android-ndk-r9\platforms\android-9\arch-arm\usr\include
这样你就可以直接修改在Run
as了。Ok成功运行。

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

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

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

初始化错误

访问错误

数组索引访问越界

指针对象访问越界

访问空指针对象

访问无效指针对象

迭代器访问越界

内存泄露

参数错误

堆栈溢出

类型转换错误

数字除0错误

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

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

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

[plain] view plain

************************************************

Buildfingerprint:'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<<<

signal11(SIGSEGV),code1(SEGV_MAPERR),faultaddr00000000

backtrace:

#00pc00023438/system/lib/libc.so

#01pc00004de8/data/app-lib/com.example.hellojni-2/libhello-jni.so

#02pc000056c8/data/app-lib/com.example.hellojni-2/libhello-jni.so

#03pc00004fb4/data/app-lib/com.example.hellojni-2/libhello-jni.so

#04pc00004f58/data/app-lib/com.example.hellojni-2/libhello-jni.so

#05pc000505b9/system/lib/libdvm.so

#06pc00068005/system/lib/libdvm.so

#07pc000278a0/system/lib/libdvm.so

#08pc0002b7fc/system/lib/libdvm.so

#09pc00060fe1/system/lib/libdvm.so

#10pc0006100b/system/lib/libdvm.so

#11pc0006c6eb/system/lib/libdvm.so

#12pc00067a1f/system/lib/libdvm.so

#13pc000278a0/system/lib/libdvm.so

#14pc0002b7fc/system/lib/libdvm.so

#15pc00061307/system/lib/libdvm.so

#16pc0006912d/system/lib/libdvm.so

#17pc000278a0/system/lib/libdvm.so

#18pc0002b7fc/system/lib/libdvm.so

#19pc00060fe1/system/lib/libdvm.so

#20pc00049ff9/system/lib/libdvm.so

#21pc0004d419/system/lib/libandroid_runtime.so

#22pc0004e1bd/system/lib/libandroid_runtime.so

#23pc00001d37/system/bin/app_process

#24pc0001bd98/system/lib/libc.so

#25pc00001904/system/bin/app_process

stack:

beb12340012153f8

beb1234400054290

beb1234800000035

beb1234cbeb123c0[stack]

……

如果你看过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

adbshelllogcat|ndk-stack-sym$PROJECT_PATH/obj/local/armeabi

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

[plain] view plain

**********Crashmp:**********

Buildfingerprint:'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<<<

signal11(SIGSEGV),code1(SEGV_MAPERR),faultaddr00000000

Stackframe#00pc00023438/system/lib/libc.so(strlen+72)

Stackframe#01pc00004de8/data/app-lib/com.example.hellojni-2/libhello-jni.so(std::char_traits<char>::length(charconst*)+20):Routinestd::char_traits<char>::length(charconst*)at/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229

Stackframe#02pc000056c8/data/app-lib/com.example.hellojni-2/libhello-jni.so(std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(charconst*,std::allocator<char>const&)+44):Routinebasic_stringat/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639

Stackframe#03pc00004fb4/data/app-lib/com.example.hellojni-2/libhello-jni.so(willCrash()+68):RoutinewillCrash()at/home/testin/hello-jni/jni/hello-jni.cpp:69

Stackframe#04pc00004f58/data/app-lib/com.example.hellojni-2/libhello-jni.so(JNI_OnLoad+20):RoutineJNI_OnLoadat/home/testin/hello-jni/jni/hello-jni.cpp:61

Stackframe#05pc000505b9/system/lib/libdvm.so(dvmLoadNativeCode(charconst*,Object*,char**)+516)

Stackframe#06pc00068005/system/lib/libdvm.so

Stackframe#07pc000278a0/system/lib/libdvm.so

Stackframe#08pc0002b7fc/system/lib/libdvm.so(dvmInterpret(Thread*,Methodconst*,JValue*)+180)

Stackframe#09pc00060fe1/system/lib/libdvm.so(dvmCallMethodV(Thread*,Methodconst*,Object*,bool,JValue*,std::__va_list)+272)

……（后面略）

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

[plain] view plain

#03(willCrash()+68):RoutinewillCrash()at/home/testin/hello-jni/jni/hello-jni.cpp:69

#04(JNI_OnLoad+20):RoutineJNI_OnLoadat/home/testin/hello-jni/jni/hello-jni.cpp:61

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

先获取日志，再使用ndk-stack分析

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

[plain] view plain

adbshelllogcat>1.log

ndk-stack-sym$PROJECT_PATH/obj/local/armeabi–mp1.log

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

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

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

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

[plain] view plain

/Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/

假设你的电脑是windows，CPU架构为mips，那么你要的工具可能包含在这个目录中：

[plain] view plain

D:android-ndk-r9d oolchainsmipsel-linux-android-4.8prebuiltwindows-x86_64in

‘叁’ android-ndk-r9d 32位系统能用么吗

android-ndk-r9d 32位系统可以用。
cpu的位是指一次性可处理的数据量是多少，1字节=8位，32位处理器可以一次性处理4个字节的数据量，依次类推。32位操作系统针对的32位的CPU设计。64位操作系统针对的64位的CPU设计。操作系统只是硬件和应用软件中间的一个平台。CPU从原来的8位，16位，到现在的32位和64位。

‘肆’ cocos2dx在windows下开发怎么编译成apk

下面一段是网络的说明：
Cocos2d-x 是一个支持多平台的 2D 手机游戏引擎，使用 C++ 开发，基于OpenGL ES，基于Cocos2d-iphone，支持 WOPhone, iOS 4.1, Android 2.1 及更高版本, WindowsXP & Windows7，WindowsPhone 8.[1]Cocos2d-x是一个开源的移动2D游戏框架，MIT许可证下发布的。这是一个C++ Cocos2d-iPhone项目的版本。Cocos2d-X发展的重点是围绕Cocos2d跨平台。Cocos2d-x提供的框架外，手机游戏，可以写 在C++或者Lua中，使用API是Cocos2d-iPhone完全兼容。Cocos2d-x[2]项目可以很容易地建立和运行iOS，Android 的三星Bada，黑莓Blackberry操作系统和更多。Cocos2d-x还支持Windows、Mac和Linux等桌面操作系统，因此，我们可以 编写的源代码很容易在桌面操作系统中编辑和调试。

总的来说，cocos2dx的android交叉编译环境还是蛮麻烦的。下面内容就是我一步一步实现的过程。
第一部分 安装
一、Cygwin安装
这个安装比较简单，网上也有大把的例子，这里我只是简述一下。
首先去官网www.cygwin.com下载安装,安装包分32位和64位两种.视情况选择了。因为只是编译，这里选择的是32位版本。
下载地址：http://cygwin.com/setup-x86.exe
然后默认安装，在安装源的时候，选择
http://mirrors.sohu.com/cygwin 或 http://mirrors.163.com/cygwin ,哪个好用，就哪个。
安装的时候，把开发包都选上就可以了。
我这里是把cygwin安装在c:\cygwin目录下面了。
注：这里默认的vi不是我们常用的vim，使用起来会很不习惯，你可以根据实际情况下载，在安装的时候，选择编辑器的vim，然后就可以用了。如果没有vim，你用的时候在vi命令行输入set nocp，就可以正常习惯使用了。
二、 adt-bundle安装
现在adt-bundle都集成了下面的功能，这样就不用再去配置eclipse插件了。
l Eclipse + ADT plugin
l Android SDK Tools
l Android Platform-tools
l The latest Android platform
l The latest Android system image for the emulator
下载地址：
Adt-bundle也同样分32位和64位的，在这里照样下载32位的版本
http://dl.google.com/android/adt/adt-bundle-windows-x86-20131030.zip。64位的地址我也加上http://dl.google.com/android/adt/adt-bundle-windows-x86_64-20131030.zip
下载完成后，解压就可以使用。我这里是解压到e:\adt-bundle
里面有eclipse，sdk两个目录和一个SDK Manager管理软件。运行SDK Manager可以下载你需要的SDK版本。
注意：你下载的java也要对应的32位和64位的环境，否则eclipse将会启动不了。牢骚一句，oracle把java和mysql并入后，真是开源的最大悲剧。你去下载它，就明白了。祝愿oracle早点倒闭。
三、ndk安装
下载地址：
32位下载地址
http://dl.google.com/android/ndk/android-ndk-r9b-windows-x86-legacy-toolchains.zip
http://dl.google.com/android/ndk/android-ndk-r9b-windows-x86.zip
64位下载地址
http://dl.google.com/android/ndk/android-ndk-r9b-windows-x86_64-legacy-toolchains.zip
http://dl.google.com/android/ndk/android-ndk-r9b-windows-x86_64.zip
然后解压就可以了，我这里解压到
E:\android-ndk-r9b
四、cocos2dx安装
我这里下载的版本是cocos2dx v2.2。同时还有一个免费的编辑器CocoStudio，它提供了UI和动画，资源编辑功能。可以不用mac下面那个收费的软件了。
今天突然http://www.cocos2d-x.org/怎么都下载不了，没办法，只好到https://github.com/cocos2d/cocos2d-x/这里下载了。找到对应的2.2版本。
Cocos2dx下载地址：
https://codeload.github.com/cocos2d/cocos2d-x/zip/cocos2d-x-2.2
Cocostudio下载地址：
http://d001.download.appget.cn/CocoStudio/DownLoad/v1.0.0.1/CocoStudio_Full_V1.0.0.1.exe
然后cocostudio默认安装就可以了，我这里把cocos2dx解压到e:/cocos2dx
五、python安装
因为，cocos2dx创建工程，需要python，所以这里还需要下载python，去他的官网http://www.python.org/下载就可以了
下载地址：
http://www.python.org/ftp/python/2.7.5/python-2.7.5.msi 这个下载32位版本就可以了。然后默认安装。我这里安装到了C:\Python27
六、ant安装
这个是一个将软件编译、测试、部署等步骤联系在一起加以自动化的一个工具，大多用于Java环境中的软件开发。这里在生成apk的时候，也用到了。所以也要下载安装。
http://mirrors.cnnic.cn/apache//ant/binaries/apache-ant-1.9.2-bin.zip
解压到c:\ant就可以了
到这里，所以需要的软件，都已经下载，并安装了。
第二部分：配置
第一步：新建环境变量
点windows的开始菜单－〉计算机 右键菜单选择属性，弹出属性对话框。然后选择高级系统设置，如下图

然后选择环境变量
增加
ANT_HOME=C:\ant
PYTHON_HOME=C:\Python27
JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_16
NDK_ROOT=E:\android-ndk-r9b
ANDROID_SDK=E:\adt-bundle\sdk
然后编辑环境变量path，追加 %JAVA_HOME%\bin;%ANT_HOME%\bin;%PYTHON_HOME%;%NDK_ROOT%;%ANDROID_SDK%\tools;%ANDROID_SDK%\platform-tools;
这样，就可以在CMD窗口执行相关的命令了。
第三部分 cocos2dx的工程准备
第一步：增加android_update.bat
在ant生成apk的时候，会需要知道，你编译的目标是什么版本和src.dir等信息。创建这个工程，就是为了自动更新它。批处理的内容是
android update project -p . -t android-10
该文件建好后，命名为android_update.bat，放在E:\cocos2dx\template\multi-platform-cpp\proj.android
注意，请先确认你的ANDROID_SDK是否安装了对就的版本，android-10是对应的是android2.3，其他的版本请用对应的数字。执行e:\adt-bundle\SDK Manager.exe，如下图所示：

这里的数字是19
那么批处理的内容改为
android update project -p . -t android-19
第二步：修改build_native.sh
该文件在E:\cocos2dx\template\multi-platform-cpp\proj.android目录中，因为在执行build_native.sh的时候，会出现的权限的问题，所以在这个脚本中，增加了权限设置，来解决这个问题。
在第67行后面，也就是复制资源的后面增加下面一行
chmod 666 -R "$APP_ANDROID_ROOT"/assets就可以了。如下图所示

第三步，创建工程复制批处理
在cocos2dx的2.2中，已经少了一些批处理来创建工程，现在全部改用python来创建工程。
现在到E:\cocos2dx\tools\project-creator下，创建一个批处理demo.bat,内容如下
python create_project.py -project %~n0% -package com.android.zdhsoft -language cpp
x ..\..\cocos2dx\platform\android\java\src\* ..\..\projects\%~n0%\proj.android\src /E
上面批处理的
第一行的意思是，建一个工程为%~n0%的工程，包名是com.android.zdhsoft，使用的语言是cpp。%~n0%在批处理表示的是 批处理的文件名，在demo.bat中，%~n0%的值是demo。使用该批处理的好处是，如果建议某一个工程，只有把批处理复制一个，然后重新命名就可 以了。如命名为sample.bat，执行后，就可以行到一个sample的cocos2dx工程。
创建的工程在E:\cocos2dx\projects目录中。
第二行的意思，复制编译andiroid工程需要的java文件。否则编译的时候，会提示找不到对应的类。

‘伍’ opencv 编译的时候找不到文件 但是文件夹下确实存在啊

很明显 你在编译的时候 确实是少了个文件 可能被隐藏了 用管理员的身份打开试试呢

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

Android NDK是什么，为什么我们要用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的常见的有哪些类型异常？
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日志：

[plain] view plain
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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 <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
r0 00000000 r1 beb123a8 r2 80808080 r3 00000000
r4 5d635f68 r5 5cdc3198 r6 41efcb18 r7 5d62df44
r8 4121b0c0 r9 00000001 sl 00000000 fp beb1238c
ip 5d635f7c sp beb12380 lr 5d62ddec pc 400e7438 cpsr 60000010

backtrace:
#00 pc 00023438 /system/lib/libc.so
#01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#05 pc 000505b9 /system/lib/libdvm.so
#06 pc 00068005 /system/lib/libdvm.so
#07 pc 000278a0 /system/lib/libdvm.so
#08 pc 0002b7fc /system/lib/libdvm.so
#09 pc 00060fe1 /system/lib/libdvm.so
#10 pc 0006100b /system/lib/libdvm.so
#11 pc 0006c6eb /system/lib/libdvm.so
#12 pc 00067a1f /system/lib/libdvm.so
#13 pc 000278a0 /system/lib/libdvm.so
#14 pc 0002b7fc /system/lib/libdvm.so
#15 pc 00061307 /system/lib/libdvm.so
#16 pc 0006912d /system/lib/libdvm.so
#17 pc 000278a0 /system/lib/libdvm.so
#18 pc 0002b7fc /system/lib/libdvm.so
#19 pc 00060fe1 /system/lib/libdvm.so
#20 pc 00049ff9 /system/lib/libdvm.so
#21 pc 0004d419 /system/lib/libandroid_runtime.so
#22 pc 0004e1bd /system/lib/libandroid_runtime.so
#23 pc 00001d37 /system/bin/app_process
#24 pc 0001bd98 /system/lib/libc.so
#25 pc 00001904 /system/bin/app_process

stack:
beb12340 012153f8
beb12344 00054290
beb12348 00000035
beb1234c beb123c0 [stack]

……

如果你看过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
adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

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

[plain] view plain
********** Crash mp: **********
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 <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
Stack frame #00 pc 00023438 /system/lib/libc.so (strlen+72)
Stack frame #01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::char_traits<char>::length(char const*)+20): Routine std::char_traits<char>::length(char const*) at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229
Stack frame #02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)+44): Routine basic_string at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639
Stack frame #03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69
Stack frame #04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61
Stack frame #05 pc 000505b9 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+516)
Stack frame #06 pc 00068005 /system/lib/libdvm.so
Stack frame #07 pc 000278a0 /system/lib/libdvm.so
Stack frame #08 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)
Stack frame #09 pc 00060fe1 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)
……（后面略）
我们重点看一下#03和#04，这两行都是在我们自己生成的libhello-jni.so中的报错信息，那么会发现如下关键信息：

[plain] view plain
#03 (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69
#04 (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61

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

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

[plain] view plain
adb shell logcat > 1.log
ndk-stack -sym $PROJECT_PATH/obj/local/armeabi –mp 1.log
第二种方法：使用addr2line和objmp命令

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

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

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

[plain] view plain
/Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/
假设你的电脑是windows， CPU架构为mips，那么你要的工具可能包含在这个目录中：

[plain] view plain
D:\ android-ndk-r9d\toolchains\mipsel-linux-android-4.8\prebuilt\windows-x86_64\bin\

好了言归正传，如何使用这两个工具，下面具体介绍：

1. 找到日志中的关键函数指针
其实很简单，就是找到backtrace信息中，属于我们自己的so文件报错的行。

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

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

2. 使用addr2line查找代码位置
执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可

[plain] view plain
arm-linux-androideabi-addr2line –e obj/local/armeabi/libhello-jni.so 00004de8 000056c8 00004fb4 00004f58

结果如下
[plain] view plain
/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229
/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639
/WordSpaces/hello-jni/jni/hello-jni.cpp:69
/WordSpaces hello-jni/jni/hello-jni.cpp:6

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

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

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

[plain] view plain
arm-linux-androideabi-objmp –S obj/local/armeabi/libhello-jni.so > hello.asm

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

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

[plain] view plain
00004fb4: willCrash() /WordSpaces/hello-jni/jni/hello-jni.cpp:69
00004f58: JNI_OnLoad()/WordSpaces/hello-jni/jni/hello-jni.cpp:61

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

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

目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入SDK，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，处于领先地位的是国内的Testin和国外的crittercism，其中crittercism需要付费，而且没有专门的中国开发者支持，我们更推荐Testin，其崩溃分析服务是完全免费的。

Testin从1.4版本开始支持NDK的崩溃分析，其最新版本已经升级到1.7。当程序发生NDK错误时，其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过logcat日志获取到的函数指针）、设备信息、线程信息等等，SDK将这些信息上报至Testin云服务平台，只要登陆到Testin平台，就可以看到所有用户上报的崩溃信息，包括NDK；并且这些崩溃做过归一化的处理，在不同系统和ROM的版本上打印的信息会略有不同，但是在Testin的网站上这些都做了很好的处理，避免了我们一些重复劳动。

上图的红框部分，就是从用户手机上报的，我们自己的so中报错的函数指针地址堆栈信息，就和我们开发时从logcat读到的日志一样，是一些晦涩难懂的指针地址，Testin为NDK崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的so文件上传（上文我们提到过的obj/local/目录下的适用于各个CPU架构的so），就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。

而且使用这个功能还有一个好处：这些包含符号表的so文件，在每次我们自己编译之后都会改变，很有可能我们刚刚发布一个新版本，这些目录下的so就已经变了，因为开发者会程序的修改程序；在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。所以我们在编译打包完成后记得备份我们的so文件。这时我们可以将这些文件上传到Testin进行符号化的工作，Testin会为我们保存和管理不同版本的so文件，确保信息不会丢失。来看一下符号化之后的显示：

‘柒’ android ndk r9如何运行ndk程序.so文件没有生成

打开cmd，进入android ndk r9 所在的文件夹，执行命令：ndk-build -C [path] 就可以了，path是你的工程路径。这样就会生成.so文件的

‘捌’ 用cocos Creator发布到android平台报错，这是什么原因

原生打包环境的注意事项：

1. 检查路径

在偏好设置中设置好的路径必须确保是正确的，比如：ant 路径需要设置到 ant 安装目录内的 bin 目录下，NDK 是其根目录，而 Android SDK 的目录下应该包含 build-tools、platforms 等文件夹。

2. 检查 Xcode 和 Visual Studio

打包 Mac 版本和 iOS 版本需要 Xcode 支持。打包 Windows 版本需要安装 Visual Studio，同时在安装 Visual Studio 时，默认并没有勾选 C++ 编译组件。如果没有安装，则需要重新安装并选择 C++ 相关编译组件。

3. 检查 NDK 版本

不论使用什么版本的引擎，都需要使用 NDK r9b 以上版本。如果使用了 Cocos2d-x framework, 请使用 NDK r10 以上的版本，推荐 r10e。

4. Windows 平台需要检查 JAVA_HOME 环境变量

如果使用 Windows 平台，请确认你的环境变量中包含 JAVA_HOME，可以通过右键点击我的电脑，选择属性，打开高级选项卡中来查看和修改环境变量。Windows 平台可能需要重启电脑才会生效。

参考[如何设置或更改 JAVA 系统环境变量？](https://www.java.com/zh_CN/download/help/path.xml)

5. 检查 JAVA 环境

在 Mac 终端或者 Windows 命令行工具中输入下面代码来查看：

```
java -version
```

如果显示为 JAVA SE 则没有问题，如果系统中使用的是 JRE，则需要安装 [JAVA SE 运行环境]
6. 包名问题

检查构建发布面板中的包名，包含空格，`-`等都是非法的包名。

‘玖’ 如何定位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架构目录，如：

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