androidobjdump

A. 如何定位android NDK开发中遇到的错误法

Android NDK定义：
Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。
常见的NDK类型异常会导致程序错误：
NDK编译生成的。so文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。
不同于Java代码异常造成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会立即退出，即通常所说的闪退，而不会弹出“程序xxx无响应，是否立即关闭”之类的提示框。
NDK是使用C/C++来进行开发的，熟悉C/C++的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题。
在程序的某个位置释放了某个内存空间，而后在程序的其他位置试图访问该内存地址，这就会产生无效地址错误。
发现并解决NDK错误：
ndk-stack。
这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令。
使用addr2line和objmp命令。
这个方法适用于那些不满足于上述ndk-stack的简单用法，在NDK中自带了适用于各个操作系统和CPU架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，可以在NDK目录的toolchains目录下找到。
注意：以上提到的方法，只适合在开发测试期间，如果应用或游戏已经上线，而用户经常反馈说崩溃、闪退，指望用户收集信息定位问题几乎是不可能的。这个时候，就需要用其他的手段来捕获崩溃信息。

B. android下有没有objmp的方法

你好，有的，方法如下：
1. NDK的toolchain里应该有可以运行于本地的arm eabi的objmp，

可以把so文件adb pull到计算机上，用NDK里的这个看

2. 找找objmp for arm

如果我的回答没帮助到您，请继续追问。

C. 如何调试分析Android中发生的tombstone

Android中较容易出现以下三类问题:Force close / ANR / Tombstone

前两者主要是查看当前的进程或者系统框架层的状态和堆栈就基本可以分析出来，本文主要讨论一下tombstone的情况。

tombstone一般是由Dalvik错误、状态监视调试器、C层代码以及libc的一些问题导致的。

当
系统发生tombstone的时候，kernel首先会上报一个严重的警告信号（signal）,上层接收到之后，进程的调试工具会把进程中当时的调用栈
现场保存起来，并在系统创建了data/tombstones目录后把异常时的进程信息写在此目录里面，开发者需要通过调用栈来分析整个调用流程来找出出
问题的点。

基本工具：

prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin

在分析的时候仔细读取汇编会获得更多有用的异常发生时的信息。

1.arm-eabi-addr2line 将类似libxxx.so 0x00012345的调用栈16进制值翻译成文件名和函数名

arm-eabi-addr2line -e libxxx.so 0x00012345

2.arm-eabi-nm 列出文件的符号信息

arm-eabi-nm -l -C -n -S libdvm.so > dvm.data

3.arm-eabi-objmp 列出文件的详细信息

arm-eabi-objmp -C -d libc.so > libc.s

通过以上工具的分析 ，我们可以得到较完整的调用栈以及调用逻辑的汇编码。

然后需要结合ARM架构及ARM汇编的知识（有些情况下可能需要使用gdb）

来分析出现tombstone的原因，以下是本人遇到过的一些tombstone的情况：

1.无效的函数指针：指针为NULL或者已经被重新赋值

2.strlen崩溃：导致不完全的栈信息，栈被破坏
3.FILE操作：因为stdio并非线程安全的，多线程操作时，容易出现异常。

D. 如何定位Android 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和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；位置在下面目录中，后续介绍中将省略此位置：

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

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

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

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

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

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

使用addr2line查找代码位置

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

结果如下：

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

使用objmp获取函数信息

通过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文件，确保信息不会丢失。

E. 如何调试分析android中发生的tombstone

1.arm-eabi-addr2line 将类似libxxx.so 0x00012345的调用栈16进制值翻译成文件名和函数名
arm-eabi-addr2line -e libxxx.so 0x00012345
2.arm-eabi-nm 列出文件的符号信息
arm-eabi-nm -l -C -n -S libdvm.so > dvm.data
3.arm-eabi-objmp 列出文件的详细信息
arm-eabi-objmp -C -d libc.so > libc.s
通过以上工具的分析 ，我们可以得到较完整的调用栈以及调用逻辑的汇编码。
然后需要结合ARM架构及ARM汇编的知识（有些情况下可能需要使用gdb）
来分析出现tombstone的原因，以下是本人遇到过的一些tombstone的情况：
1.无效的函数指针：指针为NULL或者已经被重新赋值
2.strlen崩溃：导致不完全的栈信息，栈被破坏
3.FILE操作：因为stdio并非线程安全的，多线程操作时，容易出现异常。

F. 如何定位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

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

第一种方法：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和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；位置在下面目录中，后续介绍中将省略此位置：

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

接下来就让我们来看看如何使用这两个工具，下面具体介绍。
找到日志中的关键函数指针
其实很简单，就是找到backtrace信息中，属于我们自己的so文件报错的行。
首先要找到backtrace信息，有的手机会明确打印一行backtrace（比如我们这次使用的手机），那么这一行下面的一系列以“#两位数字 pc”开头的行就是backtrace信息了。有时可能有的手机并不会打印一行backtrace，那么只要找到一段以“#两位数字 pc ”开头的行，就可以了。

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

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

结果如下：

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

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

• Android NDK定义

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

  
  

• NDK作用

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

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

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

   
   

• 及时发现NDK错误

第一种：ndk-stack

1. 这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起。

2. 例子：假如其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果用的之前的版本，建议还是尽快升级至最新的版本。

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

   

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

I. 如何利用android studio 编译c code

学习 android 逆向分析过程中，需要学习 Arm 指令，不可避免要编写一些 test code 并分析其指令，这是这篇文档的背景。

在目前 android 提供的开发环境里，如果要编写 c / cpp code， 一般是通过 ndk 开发套件，基本方法就是在
windows 或 linux 发行版上下载 ndk 环境，然后编写 c / cpp code 然后编写 Android.mk 文件，最后用
ndk-build 等工具进行编译，编译出来的可执行文件再通过 adb push 的方式提交到 devices 或 emulator
运行，如果要分析其指令，需要下载 android 提供的 prebuilts binutils 工具集（如android 源码的
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/arm-linux-androideabi/bin/
目录），如果你在linux上用file命令查看一下这些工具，会发现 ：

root@ubuntu:bin# file objmp
objmp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

它们是x86架构的，这样，你要分析devices或emulator里的elf文件，需要adb pull 下来，放在本地的linux环境或者windows里，用上述prebuilt工具分析。

稍微思考一下就会发现上述 ndk
的方式，对我们的需求来说有点太复杂了，我们真正希望的是像在标准linux发行版上那样，可以用vi/vim等编辑工具写 c/cpp
code,然后用 gcc /g++ 等编译工具编译，然后能直接运行或者用gdb调试，
或者用readelf/objmp等命令查看elf结果和汇编码。问题变成了：如何在android上实现这一切？

下面的方式是经过本人收集和实际测试证明可行的，我的环境是：

目标机：小米2手机， android4.4.4, miui 6.3.5

本地机： win7

效果：在本地机adb目标机的shell, 然后用vi写 c/cpp code, 直接在shell上用gcc编译，用objmp分析指令

实现步骤如下：

1. 首先安装 busybox apk . 这个app提供了后续需要的 busy vi, busy tar 等工具

2. 下载 adb putty ,http://yunpan.cn/cZ5x9UrDFUDdK （提取码：e70e）

这个工具用来做终端，这里为什么不用win7自带的cmd或者其他增强版如 powerCmd 呢？ 因为用 windows 的 cmd 终端，adb shell 连接上手机后，执行 busybox vi 等命令，会出现乱码，参考http://www.hu.com/question/20624475， 用这款 adb putty 终端则可以正常使用。

3. 下载 gcc arm,http://yunpan.cn/cZ5YVZzbvJqq4 （提取码：80b8）