Analysis output & dashboards

Every analyzed file gets a dashboard: a view of what’s in the file, the charts that matter for that kind of log, and the issues the analysis found. Search (Quick Search, Deep Research) is how you drill in once you’ve seen it.

The dynamic dashboard

A bugreport, a pcap, a Perfetto trace, and a ramdump each get a dashboard with charts appropriate to that format. You don’t configure it.

A bundle dashboard: the AI-composed insight summarizing what happened across the log set, with the findings that back it.
A bundle dashboard: the AI-composed insight summarizing what happened across the log set, with the findings that back it.
  • Summary and device identity: every analyzed file opens with a short written read of what happened in it, and the device it came from (model, build, kernel, carrier) as far as the file itself evidences it. Both are drawn only from what the analysis confirmed in that file, so a file that says nothing about its device simply shows nothing.
  • Curated charts: a fixed set that always renders for a given format. For an Android bugreport that’s the event timeline, battery-by-component, and severe-events-over-time; for telecom, a signal-strength timeline and RRC-state spans; for automotive, CAN-frames-by-ID; for a pcap, top talkers, protocols over time, transport health, and for wireless traffic the join sequence and the radio link. A file made of several sections, such as a command-output dump or a multi-part support snapshot, also gets a table of its sections in the order they appear: each one’s size and the lines it spans, which open the file at that section. A plain log has no sections and gets no table, and neither does a file with only one.
  • Event timeline: for logs, a multi-lane timeline anchored to boot is the dashboard’s hero. It lays out what happened when, across subsystems, so you can see the sequence that led to a failure at a glance. A kernel log that spans more than one boot shows each boot in turn on the same axis, with every reboot marked.
  • Explorer: additional charts generated on demand from what’s actually in your file, beyond the curated set.

A file reads as completed once its results are ready to open. If you poll the API, wait for COMPLETED before fetching results; see Analysis lifecycle & polling.

Subsystem analysis

Each of these areas is analyzed, and contributes its findings:

  • Application: crashes, ANRs, app lifecycle issues.
  • CPU: load, scheduling, hot threads.
  • Memory: pressure, leaks, low-memory kills.
  • Network: connectivity, radio, data-path issues.
  • Power: battery drain, wakelocks, thermal.
  • Security: SELinux denials, permission anomalies.
  • Storage: I/O, filesystem, space.
  • System services: framework and system-server health.
  • Timeline: the sequence of significant events.
  • System health: overall device state.

The exact set depends on the format. A pcap or a Perfetto trace is analyzed across the areas that make sense for it. When you ask a question, the answer is grounded in these findings.

On a bugreport, the overview lists each subsystem, and selecting one shows two things. The first is every finding that subsystem reported, ranked by severity. Findings no subsystem reported are listed on their own, below the subsystems. The second is the readings that subsystem measured: the values read out of the capture without a judgement attached, such as the device’s own filesystem sizes or its running, sleeping and zombie thread counts. A reading that the capture did not carry says so rather than showing a zero, and a reading shows where in the capture it was read.

Grouped findings

Findings that describe one situation on the device are grouped into one story, so a single failure that shows up in four subsystems reads as one thing rather than four. Each group says what it is claiming about the findings in it, which is one of: they are the same event seen from several places, one of them caused another, they share an underlying cause, or they simply happened together. It also says how sure we are, and where we are not sure it says what would settle it. The overview shows the most serious of these groups and says how many findings did not join any group. Every finding stays reachable under its subsystem whether or not it grouped, and selecting a finding in a group opens its subsystem at that finding. Captures analyzed before this shipped keep their earlier grouping, which links findings that name the same app or process.

Insights

Every file’s dashboard opens with a summary of that file’s own findings: what the dominant failure is, whether several findings are facets of one incident or unrelated problems, and how much of the file they account for.

On multi-file uploads, findings also roll up to a bundle-level view: insights that no single file’s dashboard would show on its own, such as the same identifier failing across several logs. See Multi-file bundles.

Findings located in source

On Android and Linux kernel logs from a supported platform version, the dashboard adds a Findings located in source card: the file and line of platform code that emitted each finding, and what that code does. Findings in the list carry the same citation as a chip you can click to copy.

The card appears only when a capture could be grounded, which depends on its platform and version. See Source-grounded findings.

An OS version you state

When we couldn’t detect a capture’s OS version, a note at the top of the Overview says so and lists what was detected. It also appears wherever your capture list offers to take the version, and then shows what the capture does state. On an Android or Linux kernel capture, its owner can tell us that platform’s OS version there: pick it from the list, or type it if it isn’t listed. Another platform’s version can be typed too, as context. The list holds the OS versions we have platform source for, and is offered only on accounts with source-grounded analysis; on any other account you type it. The note then shows the OS version you stated, beside the capture’s own where the two differ; anyone else who can open the capture sees it as its owner’s, without any text the owner typed. Nothing is re-run and nothing is charged. Investigations of that one capture started afterwards use it, as follows. If the capture states an OS version of its own, that version is used, and where it differs from the stated one the report’s context names both and says the findings rely on the capture’s. Otherwise an OS version picked from the list is matched to the platform source we hold for it, and the investigation cites that source and may propose fixes against it, labelled as matched on the stated version. An Android version we hold no source for is read at the nearest version we do hold, or from the public source for that version, as a reference only; a Linux kernel version is matched exactly or not at all. A typed version, and a comparison of several captures, use it as context only.

Reading a dashboard

  1. Start at the top. The dashboard leads with identity and the highest-signal charts for that format: for a log, the event timeline, and for a kernel log that holds a crash, the crash’s call chain with the source line of every frame a matching debug image could place; for a kernel dump, the fault that brought the machine down; for a pcap, the flagged behaviors.
  2. Scan the subsystem findings. Each analyzer’s issues are called out with severity, so triage is a glance, not a read-through.
  3. Drill in with search. When something looks wrong, ask about it: Quick Search for a fast answer, Deep Research for a full investigation. For a pcap, Perfetto trace, or ramdump, search queries the decoded capture itself, so you can ask for exact counts and slices.
  4. Export or share. Reports export to PDF and share via public link, with citations back to the source lines.

Next