如何分析Android内核panic？获取崩溃转储定位故障根因

首先明确：tombstone是Android用户态崩溃记录机制，仅覆盖APP、Native进程的用户态异常，内核panic触发时用户态日志服务通常已无法正常调度，本身就存在日志丢失、记录不全的问题，可通过以下几类内核原生、硬件级方案绕过常规日志链路直接获取崩溃信息：

• 优先使用pstore/ramoops机制（适配成本最低，适合绝大多数嵌入式场景）
  打开内核以下编译配置：CONFIG_PSTORE、CONFIG_PSTORE_RAM、CONFIG_PSTORE_CONSOLE、CONFIG_PSTORE_PMSG，在设备树中预留一块独立于内核常规内存分配池的保留RAM区域（建议大小256KB~1MB，确保不被U-Boot、硬件外设占用）。panic触发时内核会在进入死循环前，直接将CPU寄存器上下文、栈回溯信息、内核环形缓冲区日志写入该段保留RAM，设备重启后系统会自动挂载pstore虚拟文件系统，直接读取/sys/fs/pstore/目录下的文件就能拿到完整的panic现场，整个过程不依赖用户态服务、不依赖文件系统写入，哪怕中断上下文触发的panic也能正常记录。
• 使用kexec/kdump获取全量内存转储（适合内存余量充足、偶发疑难问题定位）
  打开内核编译配置CONFIG_KEXEC、CONFIG_CRASH_DUMP、CONFIG_PROC_VMCORE，预留64MB~128MB的专用内存运行裁剪后的轻量捕获内核。主内核触发panic时，会直接热跳转到捕获内核运行，此时主内核的内存数据完全保留，捕获内核可以将全量内存镜像导出为vmcore文件写入存储分区，重启后通过crash、gdb工具搭配内核符号表解析vmcore，可以直接定位野指针、内存踩踏、锁竞争等偶发疑难问题。内存小于512MB的设备可以极致裁剪捕获内核，仅保留基础存储驱动即可，可将捕获内核内存占用压到16MB以内。
• 硬件级调试通道兜底（适合连内核panic流程都跑不完的硬挂场景）
  如果遇到内核早期启动崩溃、总线错误直接挂死导致软件记录逻辑完全不执行的场景，可直接利用SoC自带的硬件调试能力：ARM平台开启CoreSight/ETM跟踪，配置panic触发时自动锁存CPU寄存器、最近执行的指令流、栈数据到片上SRAM，复位后通过调试串口或JTAG接口读取即可；多数嵌入式SoC还自带异常状态记录寄存器，复位后无需启动完整系统，直接读寄存器就能拿到异常类型、崩溃时的PC指针值，完全不依赖软件链路。
• 自定义裸扇区写入钩子（极端资源受限场景适配）
  如果设备内存极度紧张、硬件调试接口被裁剪，可以直接修改内核panic()函数执行流程，在panic触发的第一时间绕过文件系统层，直接调用存储驱动的裸扇区写入接口，将关键的栈信息、寄存器值写到eMMC/UFS的固定保留扇区，重启后直接读对应裸扇区就能拿到崩溃信息，该方案依赖的代码路径最短，只要存储驱动基础读写能力正常就能工作。

实操提示：如果只是需要快速定位偶发panic，优先上pstore/ramoops方案，不需要改太多代码，适配工作量通常在1人天以内，90%以上的kernel panic场景都能抓到完整栈信息。

内容的提问来源于stack exchange，提问作者greenfish