Android崩溃日志获取与解析
今天来写点Android崩溃的东西，在我们写代码的过程中，代码写的再好再严谨，也总是会有一些程序的崩溃，对于release出去的APP，我们肯定是希望我们能够拿到崩溃的日志，便于bug的发现以及修复，在下一个版本中再修复。所以，今天我们来说说Android崩溃日志的抓取。
在程序界面有一句话很流行，那就是不要重复造轮子。现在市面上有很多的崩溃日志抓取工具，比如腾讯的bugly，不管是eclipse还是Android Studio，集成都是非常简单，他可以抓取到JAVA的崩溃，同样也可以抓取到NDK代码的崩溃。
Java的崩溃就没有什么好说的，集成的步骤以及实现的原理太简单，下面我们来看看如何集成NDK崩溃的抓取
1、首先在c/c++代码的任意位置添加代码
const char SO_FILE_VERSION[] __attribute__ ((section (".bugly_version"))) = "version name";
注意，如果是cpp文件得话必须加上extern "C"，这一点腾讯给出来的文档里面没有说明。如果不加的话，我们编译出来的动态库是没有版本号信息的，为什么是.bugly_version，这个只有腾讯知道，我们知道腾讯定义了这个一个符号，用来读取出动态库的版本号来。
2、编译出so后，我们可以查看版本号，使用NDK工具arm-linux-androideabi-readelf.exe来读取。
命令行工具下运行arm-linux-androideabi-readelf.exe -p .bugly_version libXXXX.so就可以读取到第一步中写入的version name了。Windows系统arm-linux-androideabi-readelf.exe的路径为android-ndk-r10e\toolchains\arm-linux-androideabi-4.x\prebuilt\windows-x86_64\bin。
3、从编译结果的obj目录取出对应的动态库，利用腾讯提供的批处理文件生成map文件，并将map文件上传给腾讯，这样我们的apk里面发布的动态库是release版本的，但是通过腾讯的网页看到的堆栈还是可以定位到崩溃代码的行数以及所在的文件。
集成就这么结束了，还是很简单的，如下是我测试程序产生的崩溃日志
#00 pc 00000cd4 libErrorReport.so crash (E:/workspace/BuglyErrorTest/app/src/main/jni/ErrorReport.cpp:14-16) [armeabi-v5te] [1.0.1]
#01 pc 00000cdb libErrorReport.so Java_com_openflight_bugly_JniTest_nativeCrash (E:/workspace/BuglyErrorTest/app/src/main/jni/ErrorReport.cpp:21) [armeabi-v5te] [1.0.1]
#02 pc 000d3051 /data/dalvik-cache/arm/data@app@com.openflight.bugly-2@base.apk@classes.dex
bugly的集成就讲到这里了，那么问题来了，bugly是怎么做到的呢？以上都是基于我们的APP运行在有网络的环境下，那么如果我们开发的APP是要运行在一个没有网络的环境中呢，怎么办？怎么办？怎么办？很悲剧，本人是做车载导航开发的，而很多车载设备是没有网络的，那么就只能是抓取log保存在本地，然后取出对应的log来给开发人员分析了。JAVA的崩溃很好办，我们实现一下UncaughtExceptionHandler，然后将crash信息保存到本地的文件中就好了。那么NDK的崩溃呢？我们要感谢伟大的google把google-breakpad（https://github.com/svn2github/google-breakpad）开源出来了。
10年积累的做网站、网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先建设网站后付款的网站建设流程，更有罗湖免费网站建设让你可以放心的选择与我们合作。
那接下来我们来看一下breakpad的集成吧。本例采用eclipse工程的方式，为啥不用Android Studio？因为breakpad给android提供的编译方式就是使用mk文件来编译的，而且个人感觉用eclipse来做NDK开发更方便。
先看一下jni目录的结构
google-breakpad-master中有提供一个android的例子，先不管那么多，直接进入到例子的目录，ndk-build一下再说，什么？编译不过，怎么可能，google一下为什么，好吧，真的是编译不过，为什么，因为谷歌的工程师在写breakpad的mk文件得时候居然漏了一些东西，好吧，我们都给补上。修改google-breakpad-master/android/google-breakpad/Android.mk，把LOCAL_SRC_FILES修改为
LOCAL_SRC_FILES := \
src/client/linux/crash_generation/crash_generation_client.cc \
src/client/linux/handler/exception_handler.cc \
src/client/linux/handler/minidump_descriptor.cc \
src/client/linux/log/log.cc \
src/client/linux/minidump_writer/linux_dumper.cc \
src/client/linux/minidump_writer/linux_ptrace_dumper.cc \
src/client/linux/minidump_writer/minidump_writer.cc \
src/client/linux/microdump_writer/microdump_writer.cc \
src/client/linux/dump_writer_common/ucontext_reader.cc \
src/client/linux/dump_writer_common/seccomp_unwinder.cc \
src/client/linux/dump_writer_common/thread_info.cc \
src/client/minidump_file_writer.cc \
src/common/android/breakpad_getcontext.S \
src/common/convert_UTF.c \
src/common/md5.cc \
src/common/string_conversion.cc \
src/common/linux/elfutils.cc \
src/common/linux/file_id.cc \
src/common/linux/guid_creator.cc \
src/common/linux/linux_libc_support.cc \
src/common/linux/memory_mapped_file.cc \
src/common/linux/safe_readlink.cc
好了，再来一次ndk-build，这次没有问题了，可以正常编译，把编译的结果push到手机上，运行一下，生成了一个dmp文件，恩，这个dmp文件就是我们要的东西了。可以开始移植了，jni的代码和mk文件也都非常简单，直接贴出来
Application.mk
APP_STL := stlport_static
APP_ABI := armeabi
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := ErrorReport
LOCAL_SRC_FILES := ErrorReport.cpp
LOCAL_STATIC_LIBRARIES += breakpad_client
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
LOCAL_STATIC_LIBRARIES += libgcc
include $(BUILD_SHARED_LIBRARY)
ifneq ($(NDK_MODULE_PATH),)
$(call import-module,google_breakpad)
else
include $(LOCAL_PATH)/google-breakpad-master/android/google_breakpad/Android.mk
endif
ErrorReport.cpp
#include
#include
#include
#include "google-breakpad-master/src/client/linux/handler/exception_handler.h"
#include "google-breakpad-master/src/client/linux/handler/minidump_descriptor.h"
#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, "ErrorReport", __VA_ARGS__)
extern "C" {
JNIEXPORT jint JNICALL Java_com_openflight_errorreport_CrashHandler_nativeCrash(
JNIEnv* env, jobject thiz);
JNIEXPORT jint JNICALL Java_com_openflight_errorreport_CrashHandler_setNativeCrashDir(
JNIEnv* env, jobject thiz, jstring path);
}
static google_breakpad::ExceptionHandler *handler = NULL;
bool DumpCallback(const google_breakpad::MinidumpDescriptor& descriptor,
void* context,
bool succeeded) {
LOGD("Dump path: %s", descriptor.path());
return succeeded;
}
void crash(){
volatile int* a = reinterpret_cast(NULL);
*a = 1;
}
JNIEXPORT jint Java_com_openflight_errorreport_CrashHandler_nativeCrash(
JNIEnv* env, jobject thiz){
crash();
}
// 设置dmp文件保存路径
JNIEXPORT jint JNICALL Java_com_openflight_errorreport_CrashHandler_setNativeCrashDir(
JNIEnv* env, jobject thiz, jstring path){
const char *filePath = env->GetStringUTFChars(path, 0);
google_breakpad::MinidumpDescriptor descriptor(filePath);
handler = new google_breakpad::ExceptionHandler(descriptor, NULL, DumpCallback, NULL, true, -1);
}
其中有几个需要注意的地方，大家可能看到Android.mk中加了一句LOCAL_STATIC_LIBRARIES += libgcc，这一句在例子中是没有的，为啥呢，因为本人手上两台手机，N5以及Note2，如果如加这一句的话Note2一运行就崩溃。还有一点，为啥要用static google_breakpad::ExceptionHandler *handler呢，例子里面是直接在main函数里面声明并初始化的，好吧，我最开始也是这么认为的，直接放在Jni_OnLoad里面，结果dmp文件无法生成。那为什么例子中可以正常生成呢？好吧，因为例子中crash是在main函数里面的，handler的作用域是整个main函数，所以他可以生成。如果你把这段代码放到Jni_OnLoad中，那么他的作用域也是Jni_OnLoad，Jni_OnLoad返回之后就没有效果了，这显然不是我们想要的，我们希望它的作用域跟APP的生命周期是一样的，所以把他定义为static。
工作都做完了，拿台手机来跑吧，调用crash方法会崩溃，崩溃之后我们可以看到在我们设置的目录下面已经有一个dmp文件生成了，那dmp文件这么解析呢？windows实在是太不方便了， 下面还是给出ubuntu系统的解析方法吧。
1、下载google-breakpad源代码，编译linux版本，找到以下两个文件
google-breakpad-read-only/src/tools/linux/dump_syms/dump_syms
google-breakpad-read-only/src/processor/minidump_stackwalk
2、任意位置建立一个文件夹，文件夹中包含dump_syms、minidump_stackwalk、*.dmp、所有的动态库文件（多个动态库需要重复3、4步骤）
3、执行命令./dump_syms libXXX.so > libXXX.so.sym
4、创建文件夹 symbols/libgame.so/6D7D7B4FAAE9D2686CF45FA12A9E3AD30，并将生成的libXXX.so.sym拷贝到该文件夹中，6D7D7B4FAAE9D2686CF45FA12A9E3AD30为生成的libXXX.so.sym的第一行的内容
5、执行命令./minidump_stackwalk XXXXXXXXXXX.dmp symbols/ > result.txt
好了，大功告成，我们来看一下解析出来的result.txt里面崩溃的堆栈
Thread 0 (crashed)
0 libErrorReport.so!_Z5crashv + 0x3
r0 = 0x41803818 r1 = 0x59600019 r2 = 0x00000001 r3 = 0x00000000
r4 = 0x00000000 r5 = 0x57ac67b8 r6 = 0x00000000 r7 = 0x57765dac
r8 = 0xbea0a510 r9 = 0x57765da4 r10 = 0x57765da0 r12 = 0x5e0b6555
fp = 0xbea0a524 sp = 0xbea0a508 lr = 0x5e0b655b pc = 0x5e0b6550
Found by: given as instruction pointer in context
这是什么鬼，_Z5crashv是什么东西？应该是armv5架构的CPU，crash函数中崩溃，而且该函数的返回值是void，就这些信息，如果NDK代码多的话， 还是很难定位到崩溃的地方 ，意义不是很大呐，好吧，这个是从libs中取出来的so库，那么我们试试obj中取出来的so去解析结果是怎么样的。
Thread 0 (crashed)
0 libErrorReport.so!crash [ErrorReport.cpp : 27 + 0x4]
r0 = 0x41803818 r1 = 0x59600019 r2 = 0x00000001 r3 = 0x00000000
r4 = 0x00000000 r5 = 0x57ac67b8 r6 = 0x00000000 r7 = 0x57765dac
r8 = 0xbea0a510 r9 = 0x57765da4 r10 = 0x57765da0 r12 = 0x5e0b6555
fp = 0xbea0a524 sp = 0xbea0a508 lr = 0x5e0b655b pc = 0x5e0b6550
Found by: given as instruction pointer in context
1 libErrorReport.so!Java_com_openflight_errorreport_CrashHandler_nativeCrash [ErrorReport.cpp : 32 + 0x3]
r4 = 0x00000000 r5 = 0x57ac67b8 r6 = 0x00000000 r7 = 0x57765dac
r8 = 0xbea0a510 r9 = 0x57765da4 r10 = 0x57765da0 fp = 0xbea0a524
sp = 0xbea0a508 pc = 0x5e0b655b
Found by: call frame info
哇，这个结果就比较完美了，c++中崩溃的堆栈都有了，哪个文件哪一行都有，但是呢，跟bugly比起来还是差了一些，因为bugly中可以看到java层调用的堆栈。结果是比较完美了，可是可是可是，操作还是麻烦了一点，如果我的应用有很多个动态库的话，那解析一个dmp文件就要好久了，很不幸，我曾经开发的应用里面包含了将近10个库，天啊，这就算再熟练解析一个文件也要好几分钟啊，而且中途还不能出错，杀了我吧，我不干了。我的理念是，凡是重复的工作都让电脑去做，脚本是个很好的东西，下面就把shell脚本放出来吧
#!/bin/bash
#[usage]
#将本脚本、dump_sys、minidump_stackwalk放在同级目录下，并创建libs文件夹，所有动态库放到libs文件夹内
#./dump2txt.sh [dmp文件路径] [生成的txt文件路径]
LIBRARY_DIRECTORY="libs"
LIBRARY_EXTENDNAME=".sym"
LIBRARY_KEYPOS=3
Check()
{
if [ $# -ne 2 ];then
echo please input two param,the first param is the dmp file path,the second param is txt file path
exit
fi
if [ ! -f "$1" ]; then
echo $1 is not exsit
exit
fi
}
DealLibrary()
{
if [ ! -f "$LIBRARY_DIRECTORY/$1" ]; then
echo $LIBRARY_DIRECTORY/$1 is not exsit
return
fi
SYM_NAME=$1$LIBRARY_EXTENDNAME
./dump_syms libs/$1 > $SYM_NAME
cat $SYM_NAME | while read line
do
LIBRARY_CODE=$line
ARR=($LIBRARY_CODE)
LIBRARY_CODE="${ARR[$LIBRARY_KEYPOS]}"
mkdir -p symbols/$1/$LIBRARY_CODE
mv $SYM_NAME symbols/$1/$LIBRARY_CODE
break
done
}
Main()
{
#检查参数 $1:dmp文件路径;$2:生成的txt文件的路径
Check $1 $2
echo "start convert "$1" to "$2"...."
#创建解析dmp文件相关的目录以及文件
rm -rf symbols
for file in $LIBRARY_DIRECTORY/*
do
DealLibrary ${file:5}
done
#生成txt文件
./minidump_stackwalk $1 symbols/ > $2
echo $2 is generated!!!!
}
Main $1 $2
好了，写到这里本文也就接近尾声了，什么？不知道怎么用shell脚本？好吧，好人做到底，送佛送到西。新建文件xxx.sh，双击打开，将脚本内容复制进去，控制台执行命令chmod a+x xxx.sh，然后照着脚本里面注释的内容做吧，Good Luck！没有Ubuntu系统怎么办？我是装了个虚拟机跑Ubuntu系统，如果你是做NDK开发的，建议你也这么做，比Windows方便太多了，那如果你不想装，那就用你的手机试试吧，你的手机也是linux系统的，shell脚本也是可以跑，但是本文中提出的dump_sys和minidump_stackwalk两个文件就得编译arm版本的了，这个由于我没有需求，有这个需求的人可以研究一下。
------End------
本文名称：Android崩溃日志获取与解析
标题路径：http://pwwzsj.com/article/ppidsh.html
