Bugreport analyzer · Report no. 01
Android bugreport · .zip or .txt
A bugreport is a core sample of the device. The root cause runs through three of its strata.
Thirty-odd top-level sections, a hundred-plus dumpsys services inside one of them, 2.4 million lines. logcat.ai reads the whole column at once, correlating kernel events, framework state and app behavior, and follows one fault through every section it touched, cited to the line.
Specimen
bugreport-evb-0000.zip
Size
178 MB compressed
Depth
2.4 M lines, 312 sections
Full read
3 to 4 min, in parallel
Question
answered under 5 s
Drill
1 fault, 3 strata, cited
Exhibit 1 · Stratigraphy of one bugreport
Illustrative. Synthetic data.
0
500 K
1.0 M
1.5 M
2.0 M
2.4 M
lines
drill
Header, build, properties
Processes and threads
Memory, procrank, wakelocks
Kernel log
Event log
System log, main
Radio log
Dumpsys, 130 services
ANR traces
Tombstones
Vendor, footer
1 Root cause
Kernel log · line 512,904
Kernel memory pressure, 41 seconds of it
Free memory sat under the kill threshold and the kernel started reclaiming. The framework felt it next; the user felt it last.
2 Mechanism
System log, main · line 1,102,377
Nine GC pauses in twelve seconds
Each collection stalls the main thread. This layer is the symptom's engine, not its cause; read alone it points the wrong way.
3 Symptom
ANR traces · line 2,214,905
The ANR the user reported as "it just froze"
The trace names the lock. The two strata above it say why the lock was held, and both are cited so you can check the reading.
Fig. 1. One bugreport drawn as a stratigraphic column: every band is a section, its thickness the section's share of the file. One fault runs through three of the bands, and the drill is the investigation that follows it from the kernel to the screen.
Exhibit 2 · The full investigation, end to end
logcat.ai · Report no. 01 · Sheet 2 of 11
Watch it work on a real one.
One bugreport, one question. The run forks three hypotheses and shows the three symptoms are not one fault: an orderly battery shutdown, one cached thermal reading, and real memory pressure. Not a highlight: the entire deep-research run, from the three symptoms to the verdict.
Run notes
Source
Real Deep Research · Android bugreport · device identity substituted
Input
one bugreport, one question
Forked
three hypotheses, tested in turn
Proved
three symptoms, three separate answers
Outcome
the reboot traced to a battery shutdown, cited
Footage
0:51 · runs typically finish in 5 to 10 min
16:10 · findings cited to the line
16:10 · 0:51
Real Deep Research · Android bugreport · device identity substituted
Fig. 2. The strip beside the footage is the same core as Exhibit 1: each amber tick is a depth the run read on its way to the answer. The footage and the card are real product output and are not redrawn here.
Strip illustrative. Footage real.
Exhibit 3 · Before it answers, it reads the device
logcat.ai · Report no. 01 · Sheet 3 of 11
The core log: identity first, then ten scores.
Every bugreport is first reduced to a cited identity and a scored, cross-layer health profile: the deterministic floor every investigation builds on. Each value points at the line it was read from.
Identity, cited
5 fields
Device model
reference handset
Codename
ref0
OS version
Android 14
Build
REF.0000.000
Device class
android_phone
Marginal note. Every field is read back from a line in the header band at the top of the column. Only fields with a source line are listed, which is why there are five.
Ten analyzers, scored
score · 0 to 100 · one finding each
Memory
31
Critical
Free memory under the kill threshold for 41 s; 6 processes killed.
Apps
44
Critical
ANR in the foreground app: input dispatching timed out, 5,012 ms.
Performance
52
Degraded
Nine concurrent GC pauses in 12 s, longest 412 ms.
System services
58
Degraded
system_server main thread blocked on a lock held by thread 41.
Power
63
Degraded
One wakelock held 38 min across the capture window.
Errors
66
Degraded
2 native crashes, both in the same vendor library.
Storage
78
Minor
/data at 91%; no write failures in the window.
Network
84
Minor
Two short data stalls, both recovered.
Security
90
Nominal
3 SELinux denials, all from one test daemon.
Device info
100
Nominal
Identity fully cited; no conflicting build strings.
Fig. 3. The two ledgers every investigation starts from. Scores are a deterministic reading of the whole column, so a question asked later is answered against the same floor.
Illustrative. Synthetic data.
Exhibit 4 · The whole capture, on one timeline
logcat.ai · Report no. 01 · Sheet 4 of 11
The same core, read across time.
Every bugreport opens to a multi-lane event timeline: crashes, process churn, security denials and foreground activity on a shared axis, so a burst at 3am lines up with the reboot that followed it.
00:00
01:00
02:00
03:00
04:00
05:00
Crashes
Process churn
Security denials
Foreground activity
Watchdog reboot · 03:12
Battery level over time
%, 5 h window
00:00
05:00
Issues by subsystem
count · critical in red
Memory
14
Apps
9
Performance
7
System services
5
Power
3
Errors
2
Fig. 4. The column turned on its side. Each lane is a section read by timestamp instead of by depth, and the charts under it are drawn from the report's own structure, every value traced back to a line.
Illustrative. Synthetic data.
Exhibit 5 · Why manual analysis takes hours
logcat.ai · Report no. 01 · Sheet 5 of 11
Bugreports are notoriously difficult to read by hand.
The cause of a freeze in the app layer can sit in the kernel, a million lines above it. Finding it means correlating timestamps across sections that were never written to be read together, on a device you may not have.
2 to 8h
Senior engineer time per bugreport,
hunting through it rather than fixing it
hunting through it rather than fixing it
100+
System services inside the dumpsys band,
each with a format of its own
each with a format of its own
1 M+
Lines once uncompressed; a single logcat
buffer can hold 50 K entries on its own
buffer can hold 50 K entries on its own
Four reasons
01
Massive scale
100 MB+ compressed, 500 K to 1 M+ lines uncompressed. A single logcat buffer can have 50 K+ entries. dumpsys alone spans 100+ system services.
02
Cross-subsystem issues
Root cause in the kernel, symptom in the app layer. Memory pressure to GC pauses to ANR. Thermal throttling to CPU scheduling to jank. It takes correlating timestamps across sections.
03
OEM fragmentation
Samsung, Xiaomi, OnePlus and Pixel each ship custom services, modified frameworks, proprietary dumpsys outputs and vendor-specific kernel drivers.
04
Android version differences
The bugreport format changes between versions. New sections added, deprecated ones removed, different log tag conventions and API behavior.
The real cost
01
Senior engineers spend 2 to 8 hours hunting through logs instead of solving the actual problem.
02
Teams lose context when only senior engineers can debug complex issues.
03
Critical issues get buried in noise.
04
No systematic coverage: easy to miss subsystems.
05
Knowledge silos: only experts know where to look.
Exhibit 6 · What logcat.ai does differently
logcat.ai · Report no. 01 · Sheet 6 of 11
Cross-subsystem reasoning that connects symptoms to root causes.
Four things the reading does that a grep session cannot: follow a chain across strata, score every layer at once, keep the raw logs one click away, and answer a question in plain English.
ten drills, one column
0
2.4 M
1 Cross-subsystem root cause analysis
Kernel log, system log, ANR traces
Traces causal chains across layers: kernel memory pressure causing GC storms causing ANRs.
Correlates timestamps across 30+ sections automatically.
Finds the root cause behind the symptom, and cites the line it read.
2 Ten specialized analyzers, one unified view
Every stratum, in parallel
Apps, System Services, Memory, Power, Network, Storage, Security, Performance, Device Info and Errors, analyzed in parallel.
Results merged into a single prioritized view.
Severity ranked from Critical to Low, with a recommendation on each.
3 Full log viewers built in
Logcat, kernel log, every service
Logcat and kernel logs extracted and indexed from the bugreport.
An interactive timeline across every log source, as in Exhibit 4.
Filter by tag, priority and time range, all in one place.
4 Ask questions in plain English
Any depth, under 5 seconds
"What caused the ANR at 2:15pm?" is a complete query.
Answers in under 5 seconds, each pointing at the lines it used.
No grep or logcat expertise required.
Fig. 5. The ten analyzers drawn as ten drills through the same column. Each reads every band; the merged view ranks what they found.
Illustrative. Synthetic data.
Exhibit 7 · Legend: what is inside an Android bugreport
logcat.ai · Report no. 01 · Sheet 7 of 11
Thirty-plus sections, read as strata.
A bugreport is a comprehensive diagnostic snapshot of an Android device, generated with adb bugreport or from device settings. It captures everything needed to diagnose an issue; this is the key to the column in Exhibit 1.
Band
Section
What it holds
Share in the specimen
logcat
System logs, app logs, crash traces, ANR traces
thick · 20 to 30%
event_log
System events, activity lifecycle, broadcasts
8%
dmesg / kernel
Kernel logs, driver errors, hardware events
9%
dumpsys
State of all system services (100+ services)
130 thin bands · 27%
procrank / meminfo
Memory usage by process, OOM scores
4%
batterystats
Battery usage, wakelocks, power events
inside dumpsys · 6%
package
Installed apps, permissions, versions
inside dumpsys · 4%
system_properties
Build info, device config, feature flags
1%
ANR traces
Thread dumps at the time of the ANR
5%
tombstones
Native crash dumps with stack traces
2%, when present
Fig. 6. Shares are the specimen's in Exhibit 1 and vary by device and Android version; the parser handles vendor sections and version differences automatically. Amber marks the bands the specimen's fault touched.
Illustrative. Synthetic data.
Exhibit 8 · How a bugreport reaches you
logcat.ai · Report no. 01 · Sheet 8 of 11
From a tester, a field ticket, or a customer.
A bugreport arrives three ways. Three of those, and what each one gets back.
Case 01
Field crash
A field crash you can't reproduce
A user hit it once, on a device you don't have, and the repro steps are "it just froze." The investigation in Exhibit 2 traced that exact capture to an orderly battery shutdown, not a crash, cited to the line, no re-run needed.
Gets back
the line, cited
Case 02
Fleet
A fleet of captures, no time to read them
Hundreds of bugreports from QA and the field, each a hundred megabytes. The analysis ranks them by what actually broke and groups the ones sharing a root cause, so you triage the pattern instead of the pile.
Gets back
a ranked pile, grouped by root cause
Case 03
Visualize
A log you need to see, not read
Sometimes you don't want findings prose: you want the shape of what happened. The timeline in Exhibit 4 wasn't a template; it read this bugreport's structure and what was breaking, then drew the charts that fit it.
Gets back
the charts that fit this file
Exhibit 9 · Part of the logcat.ai platform
logcat.ai · Report no. 01 · Sheet 9 of 11
Bugreport analysis is just the starting point. Investigate deeper, compare across devices with Delta, or analyze individual log types on their own.
4 related pages
Exhibit 10 · Frequently asked questions
logcat.ai · Report no. 01 · Sheet 10 of 11
Everything you need to know about bugreport analysis.
Six questions engineers ask before the first upload, answered as they stand today.
01
What bugreport formats are supported?
We support .zip files from adb bugreport (Android 7+) and .txt files from older devices. The parser automatically handles different Android versions and OEM-specific formats, including vendor-specific sections from Samsung, Xiaomi, OnePlus, and other manufacturers.
02
How long does analysis take?
Quick Search answers questions in under 5 seconds. Full parallel subsystem analysis takes 3 to 4 minutes depending on file size and complexity. Deep Research investigations, which search across all sections and reference external documentation, typically complete in 5 to 10 minutes.
03
What issues can it detect?
App crashes and ANRs with full stack traces, memory leaks and OOM events with allocation patterns, battery drain from wakelock abuse, thermal throttling and CPU scheduling issues, SELinux denials and security policy violations, and network connectivity problems. Each issue includes a severity ranking and actionable recommendations.
04
Does it work with OEM-specific bugreports?
Yes. We support all major manufacturers including Samsung, Xiaomi, OnePlus, Pixel, Oppo, Vivo, and any AOSP-based device. The parser handles vendor-specific sections, custom dumpsys outputs, and proprietary logs. Tested across Android 8 through 15 with continuous updates for new versions.
05
Is my log data secure?
Your log data is encrypted in transit (TLS 1.3) and at rest (AES-256), processed in your own tenant, and never used to train AI models. Files are deleted after 90 days, or immediately from your dashboard. Enterprise plans offer on-premise deployment for regulated or air-gapped environments.
06
Can I analyze 100MB+ bugreports?
Yes. Optimized for large files with streaming upload that won't crash your browser. Processing is parallelized across our infrastructure for fast analysis regardless of file size.
Exhibit 11 · End of report
logcat.ai · Report no. 01 · Sheet 11 of 11
core recovered
Start debugging the whole system.
Upload a bugreport and let logcat.ai connect the dots across every layer, from the kernel band to the screen, cited to the line.
Bugreport analyzer · Report no. 01 · 11 exhibits