A logcat dump captures the app's runtime messages, but it says nothing about battery history, running services, memory pressure, or which process was foreground when something went wrong. adb bugreport pulls all of that into one archive in a single command, which is why Google's own bug tracker asks for a bugreport rather than a plain log whenever a report involves system behavior instead of a single app crash.
adb bugreport ./report.zipIf no filename is given, ADB writes a timestamped ZIP to the current directory instead. On most phones the command takes anywhere from 30 seconds to several minutes, noticeably longer than a screenshot or a short logcat capture, because the device is compiling dozens of separate system dumps rather than reading one buffer.
Unzipping the archive reveals a handful of key files, the most useful of which is bugreport-*.txt, a plain-text concatenation of:
Some device manufacturers add their own sections — Samsung devices, for example, often include additional vendor diagnostic dumps not present on stock Android bugreports.
Rather than scrolling a multi-megabyte text file, search it directly:
unzip -p report.zip "bugreport-*.txt" | grep -A 30 "FATAL EXCEPTION"The -A 30 prints 30 lines of context after the match, which is usually enough to capture the full stack trace without needing to open the file in an editor at all.
The dumpsys batterystats section inside the report is dense but answers a question logcat cannot: what was actually keeping the device awake. Search for Wakelock entries sorted by held time, and cross-reference the package name against the process list captured at the top of the report. This is the standard way to diagnose an app draining battery in the background without instrumenting the app itself.
A full bugreport includes installed package names, recent notification content in some Android versions, Wi-Fi network names, and account identifiers tied to the device. Before sharing a bugreport ZIP with anyone outside your own team — including pasting excerpts into a public forum post — strip or redact the sections that are not relevant to the bug being reported. Google's own developer documentation flags this explicitly when describing the bugreport format, since it is easy to assume a "diagnostic log" is less sensitive than it actually is.
If the question is narrow — "what does the battery stats service currently report" — a direct call is faster and produces a much smaller file:
adb shell dumpsys batterystats > battery.txtReach for the full adb bugreport only when the cause is unknown and the investigation needs the whole system picture at once, such as debugging an intermittent freeze that could originate in any subsystem. For a known, narrow question, a single dumpsys call avoids generating and transferring a multi-megabyte archive for no benefit.
On Android 6.0 and earlier, adb bugreport without a filename argument streams plain text to stdout instead of producing a ZIP, and lacks several of the newer structured sections. Anyone supporting legacy devices should redirect the output manually:
adb bugreport > report.txtFor UI bugs where the report alone does not make the reproduction steps obvious, the Developer Options menu has a "Take bug report" entry that captures a short screen recording alongside the same dumpstate and dumpsys data the command-line version collects. This UI-triggered version is generated on-device and shared directly from the phone rather than pulled over ADB, which is more convenient when the person capturing the bug does not have a PC handy at the moment it happens.
Some Android versions offer a choice between an "interactive" report (which shows progress and lets the user add a screenshot before sharing) and a "full" report generated silently in the background. The command-line adb bugreport always produces the full, non-interactive version, since there is no phone-side UI involved in triggering it from a PC in the first place.