Android Native Crash分析详解

### Android Native Crash分析详解 #### 一、何为Native Crash 简单来说，Native Crash是指发生在native层的用户进程崩溃现象。在Android系统中，根据不同的层次可以将Native Crash大致分为以下四类： 1. **Java应用（包括system_server）的native（JNI）层的Native Crash**：这类崩溃通常出现在应用程序或系统服务的JNI代码中。 2. **Native进程（如surfaceflinger、mediaserver等）的Native Crash**：这类崩溃发生在独立运行的native进程中。 3. **Java虚拟机（libart.so）中的Native Crash**：此类崩溃发生在处理Java字节码的原生代码中。 4. **OAT代码中的Native Crash**：这类崩溃发生在预编译后的本地代码中。 从分析的角度来看，前三类Native Crash的分析方法较为相似，而第四类则需要采用特殊的方法来进行诊断。 #### 二、Native Crash的触发原因 Native Crash总是由内核发出特定的signal触发，常见的signal类型及其含义如下： 1. **SIGSEGV（signal 11）**：非法地址访问。进程尝试访问未分配给其的内存地址或试图修改不可写的内存区域。 2. **SIGBUS（signal 7）**：非法地址访问，但与SIGSEGV不同之处在于访问的地址虽在进程地址空间内，但未按字节对齐（例如，访问未被2或4整除的地址）。另一种情况是在使用mmap映射文件后，文件被截断但仍尝试访问已超出当前文件大小的区域。 3. **SIGABORT（signal 6）**：主动调用abort()函数。常见于程序检测到无法恢复的错误时。 4. **SIGPIPE（signal 13）**：当进程尝试向已经关闭的socket或管道写入数据时触发。 5. **SIGSTKFLT（signal 16）**：相对罕见的信号，通常与栈溢出有关。 对于少见的信号类型，可以通过搜索内核源代码或互联网来了解其具体含义及解决策略。 #### 三、Native Crash分析所需材料 1. **Tombstone文件** Tombstone文件是进程崩溃后保留的基本信息，其中包含了Native Crash分析的必要信息。此文件由debuggerd进程抓取，并存储在/data/tombstone目录下。Snapshot机制会收集相关文件并生成最终的Snapshot文件。原始的Tombstone文件可能也可以在slog的dropbox目录中找到。如果是本地复现的Native Crash，则可以直接从/data/tombstone目录中获取。 **典型Tombstone文件内容：** - **头信息**：例如，“*** Native Crash TIME: 8388223 ***”、“Build fingerprint: 'SPRD/sp9832a2_32v4_4mvolsea/sp9832a_2h11_volte:6.0/MRA58K/W16.14.4N00:userdebug/test-keys'”和“Revision: '0'”。这些信息表明了这是一个Native Crash事件及其发生时间、系统镜像生成时的指纹信息，可用于确定问题的具体版本。 - **进程信息和寄存器信息**：例如，“pid: 10067, tid: 10067, name: mediaserver”以及具体的寄存器值。这些信息提供了关于发生崩溃时进程的状态和寄存器的快照。 通过上述信息，开发人员可以初步判断崩溃的原因，并结合其他工具和技术进行更深入的分析。例如，可以通过反汇编崩溃时的指令指针（PC）所指向的代码段，查看具体的汇编指令；通过查看堆栈信息（如调用栈）来追踪崩溃前的调用路径等。此外，还可以利用各种调试工具如GDB等，辅助定位问题的具体位置。 Native Crash的分析是一项复杂但至关重要的工作，它有助于提高Android应用的稳定性和用户体验。通过对Tombstone文件的细致解析和相关技术的应用，开发者可以有效地诊断和修复这类问题。