Android中怎么利用JNI和Crash实现定位

本篇文章为大家展示了Android中怎么利用JNI和Crash实现定位，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

成都创新互联专业为企业提供玛多网站建设、玛多做网站、玛多网站设计、玛多网站制作等企业网站建设、网页设计与制作、玛多企业网站模板建站服务，10年玛多做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

1. 巧妇内为无米之炊，找到未strip的, 符号表完整的so库文件

在Android Studio 3.2.1:

strip之前的文件所在目录:

app/build/intermediaters/transforms/mergejniLibs/debug

或者根据Crash的APP是debug还是release版本选择

app/build/intermediates/cmake/debug/obj或app/build/intermediates/cmake/release/obj

如果依赖的是Native module或者aar, 那么

strip之前的文件所在目录:

yourNativeLibModule/build/intermediates/transforms/mergeJniLibs/debug

由于CMake/CXX_FLAGS的配置等原因，以上目录下的文件可能还是被strip了。如何准确判断so有没有被strip请参照文章下面提到的readelf工具。

如果发现so被strip，尝试在CMake添加如下配置：

# 这几行代码表示debug版本的so文件保留so保留符号库，这样会导致so文件很大，# 如果要让release版本保留符号库文件，就替换成CMAKE_C_FLAGS_RELEASE和CMAKE_CXX_FLAGS_RELEASE# 但务必在正式对外发布的时候去掉release 配置的-g选项，以免增加文件sizeset(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -g")set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g")# R16之前版本的NDK默认是编译时加-g的，新版本不确定，所以需要不strip的 so文件，最好在CMake里配置一下-g

strip之后的文件所在目录:

app/build/intermediaters/transforms/stripDebugSymbol/debug

2. 打蛇要打七寸，确定发生Crash的设备对应的CPU架构

在JNI Crash的日志里

如果有lib/arm, 则是armeabi-v7a架构;

如果有lib/arm64, 则是arm64-v8a架构

然后根据CPU架构找相应的toolchain：

arm64-v8a对应的是aarch74-linux-android-4.9

armeabi-v7a对应的是arm-linux-androideabi-4.9

4. 工欲善其事必先利其器，使用add2line 和ndk-stack等工具分析JNI Crash的log

addr2line

作用是根据内存地址找到对应的报错代码的文件名和行号

所在目录是toolchain的bin文件夹,

比如 aarch74-linux-android-4.9对应的bin文件夹是

/Android/Sdk/ndk-bundle/toolchains/aarch74-linux-android-4.9/prebuilt/linux-x86_64/bin

arm-linux-androideabi-4.9,对应的bin文件夹是

/media/kyle/a393d005-ebe5-42a0-8c6a-c86fdfb185c1/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin

用法:

# -f表示显示函数名, -e表示execution，后面是包含符号库的文件 以及报错的内存地址（即Crash log里pc后的字段）arm-linux-androideabi-addr2line -f -e xxx.so 0x8eb09258

ndk-stack

作用是一键生成更可读的Crash 日志

所在目录是

/media/kyle/a393d005-ebe5-42a0-8c6a-c86fdfb185c1/Android/Sdk/ndk-bundle/ndk-stack

用法:

# -sym表示symbolsndk-stack -sym App/build/intermediates/transforms/mergeJniLibs/release/0/lib/对应的abi目录 -dump jniCrash.log

或者

adb logcat | ndk-stack -sym  App/build/intermediates/transforms/mergeJniLibs/release/0/lib/对应的abi目录

------------------------分隔符------------------------

其他工具补充

toolchain下的:

arm-linux-androideabi-readelf

1. 有时候用addr2line发现能显示函数名但行号是乱码？？，有可能是因为这个so被strip了。被strip的so的

readelf结果里“section headers”的个数会比未strip后的少，所以可以根据readelf来判断so是否是真的被strip了

命令格式：

arm-linux-androideabi-readelf -S xx.so

2. 可以用于查看so文件中的所有函数。所以如果遇到JNI方法找不到的错误，就可以使用该工具查看so库中的所有函数，然后搜索对应的JNI方法，看到底有没有被编译到动态库中。

命令格式：

arm-linux-androideabi-readelf -a xx.so > fun.txt # 注意：仍需要使用未strip之前的so文件， 上面的命令会把结果写入fun.txt

arm-linux-androideabi-objdump

可以获取so文件的符号表信息，可以看到编译进来的所有方法以及调用堆栈的地址.

命令格式：

arm-linux-androideabi-objdump -dx xx.so > stacktrace.txt 或aarch74-linux-android-objdump -dx xx.so > stacktrace.txt

arm-linux-androideabi-nm

可以查看静态库中的符号，比如查看所有方法的声明。

如果在用静态库编译so动态库的过程中碰到undefined reference类型的错误，或者

duplicated reference，可以使用这条指令将对应静态库的所有方法都导出来，然后看一下是否有某方法

命令格式：

arm-linux-androideabi-nm xx.a > symbol.txt

常用信号量的含义：

#define SIGABRT 6 // abort() 调用abort函数生成的信号，表示程序运行异常被中止#define SIGSEGV 11 // segmentation violation 指针所对应的地址是无效或非法地址，比如访问越界/stack overflow/文件操作不被允许( fault addr 0x0一般是空指针错误)#define SIGILL 4 // Illegal instruction 执行了非法指令，比如第三方库的兼容性问题，权限问题#define SIGSYS 31 // bad argument to system call 非法的系统调用#define SIGBUS 7 // 非法地址，包括内存地址对齐出错，比如访问一个4字节的整数, 但其地址不是4的倍数#define SIGFPE 8 // 进程执行了一个错误的算术操作，比如除0、溢出#define SIGKILL 9 // 强制结束程序，本信号不能被捕获#define SIGPIPE 13 // write on a pipe with no one to read it 管道破裂，通常在进程间通信产生

上述内容就是Android中怎么利用JNI和Crash实现定位，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注创新互联行业资讯频道。

名称栏目：Android中怎么利用JNI和Crash实现定位
文章地址：https://www.cdcxhl.com/article20/gepsco.html

成都网站建设公司_创新互联，为您提供外贸网站建设、静态网站、手机网站建设、网站建设、商城网站、网站改版

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容