AOSP Framework & Internals
3 min read

Crash Dumps

Discover the mechanisms Android uses to save kernel panic logs so they survive a hard reboot for debugging.

When a Kernel Panic occurs, the phone instantly reboots. This creates a massive problem: how do you read the panic log if the phone just wiped its volatile RAM during the reboot?

Standard desktop Linux solves this by saving the crash log to the hard drive before rebooting. But writing to a slow flash storage chip requires complex filesystems and block drivers to be working perfectly. If the kernel is panicking, those drivers are likely corrupted and cannot be trusted to write to the disk without destroying user data.

Android solves this using special persistence mechanisms that bypass the filesystem entirely.

Ramoops (Persistent Memory Logging)

The most common technique in Android devices is Ramoops.

When the bootloader first powers on the phone, it reserves a tiny, specific chunk of the physical RAM (e.g., 1MB) and hides it from the main OS.

When the kernel panics, it formats the panic log and writes the raw text directly into this reserved RAM chunk. It then triggers the reboot.

Crucially, modern smartphone RAM does not instantly lose its data when the system soft-reboots. When the phone boots back up, the new kernel reads that reserved 1MB of RAM, realizes there is a panic log leftover from the previous crash, and saves it safely to the filesystem.

You can actually pull these logs after your Android phone randomly reboots!

# Pull the panic log from the previous boot
adb shell cat /sys/fs/pstore/console-ramoops

pstore (Platform Storage)

Ramoops is actually a backend for a wider kernel subsystem called pstore (Platform Storage).

pstore provides a generic interface for saving panic logs across reboots. While Ramoops uses preserved RAM, other backend implementations exist depending on the vendor:

  • Some devices write the panic log to a dedicated, unformatted raw partition on the eMMC storage chip, completely bypassing the complex EXT4/F2FS filesystems.

kdump and the Crash Kernel

For incredibly severe bugs where engineers need to see the entire contents of the phone's 8GB of RAM at the moment of the crash (not just a text log), standard Linux uses kdump.

When the main kernel panics, instead of rebooting the hardware, it instantly boots a secondary, tiny "Crash Kernel" that was pre-loaded into a hidden corner of RAM. This Crash Kernel wakes up, sees the frozen main kernel, and copies the entire 8GB of frozen RAM to the storage drive as a massive vmcore file.

While incredibly powerful, kdump is rarely used on production Android phones because saving an 8GB file takes minutes, and users hate waiting for their crashed phones to reboot. It is heavily used by SoC vendors (like Qualcomm) in laboratory testing environments.