AOSP: Extracting Logs with adb bugreport
How adb bugreport works internally in AOSP, what it collects, and how to pull out specific logs from the zip.
August 6, 2026
AOSP: Extracting Logs with adb bugreport
adb bugreport is the most basic debugging command that takes a snapshot of the device's state all at once.Without the need to pull
logcat, dmesg, dumpsys, ANR traces, or tombstones individually, you can collect most of the information at once with this single command.Basic usagesh
Under the Hood
adb bugreport actually doesn't perform new logic directly, but is a wrapper that triggers the dumpstate binary inside the device.On API 24 and above, it uses the zipped bugreport method, and the flow is roughly as follows.
What adb actually triggers on-devicesh
When
Once
The actual log collection is entirely handled by
bugreportz continuously streams PROGRESS: lines, adb receives them to display the progress.Once
OK: is printed, it pulls the file from that path to the host using adb pull and then cleans up the temporary files on the device.The actual log collection is entirely handled by
dumpstate on the device.What's Inside the Zip
Unzipping it reveals a wider variety of files than expected.
| Path | Content |
|---|---|
bugreport-*.txt | Main text report. All output of dumpstate is sequentially accumulated in this single file |
main_entry.txt | Pointer indicating which file is the main text file within the zip |
version.txt | Bugreport format version |
FS/data/anr/traces.txt | Full thread dump at the time of ANR occurrence |
FS/data/tombstones/ | Native crash tombstone files |
proto/*.proto | Binary service state collected via dumpsys --proto (activity, meminfo, etc.) |
screenshot.png | Screen capture at the time of report generation (supported devices only) |
Ultimately, the core is the single
bugreport-*.txt, and the rest are closer to raw attachments of content that has already been summarized or included in the text report.Commands Dumpstate Runs Internally
Opening
In other words, which command was used to extract that data remains directly in the report itself.
bugreport-*.txt shows that each section is separated by a header in the format of ------ Section Name (Executed Command) ------.In other words, which command was used to extract that data remains directly in the report itself.
Section headers found inside bugreport-*.txtsh
The final
Within it, the results of
The main reason a bugreport pulled from a busy device reaches tens of megabytes is mostly due to this
DUMPSYS section is actually the most massive.Within it, the results of
dumpsys <service> executed repeatedly for each registered system service (such as activity, meminfo, batterystats, package, window, etc.) follow one after another.The main reason a bugreport pulled from a busy device reaches tens of megabytes is mostly due to this
DUMPSYS section.Additional logs may be appended depending on the vendor board, because
dumpstate calls the IDumpstateDevice vendor HAL to append board-specific information such as modem or Wi-Fi firmware logs.Result
With a single
When you need to capture the state after reproducing a bug, this single line is often more than enough rather than pulling multiple logs separately.
adb bugreport, you can acquire snapshots of logcat + dmesg + ANR trace + tombstone + dumpsys all at once, and easily check which command each dataset originated from directly in the report's section headers.When you need to capture the state after reproducing a bug, this single line is often more than enough rather than pulling multiple logs separately.