Android Bugreport and dumpsys Forensics

A bugreport is Android's own diagnostic snapshot: one command, no root, a few minutes, and you have the state of every system service. For investigators it is the fastest way to capture volatile system evidence (recent app usage, battery and screen history, notifications, accounts, installed packages, security configuration) from an unlocked phone, and the standard input for spyware checks with MVT. This guide explains how to take one cleanly, what the main text file contains, which sections matter, and how to handle its timestamps.

When to take a bugreport

• Always on an unlocked phone with ADB access, early in the acquisition, together with a few targeted dumpsys commands. It captures state that a later full file system extraction may not (in-memory history, recent logcat).
• For spyware triage, as MVT input or as part of an androidqf collection.
• When deeper extraction is impossible, it is often the only system-level evidence you will get.

It never replaces a full file system extraction for app content. See the acquisition guide for how it fits.

Taking it

adb devices -l
date -u +%FT%TZ; adb shell date -u          # record both clocks
adb bugreport case0142_bugreport.zip        # takes 1 to 5 minutes
sha256sum case0142_bugreport.zip > case0142_bugreport.zip.sha256
unzip -l case0142_bugreport.zip | head -30

On the device, Developer options > Take bug report offers an interactive report (progress notification, faster) and a full report. The file is saved in the Shell app's private storage and shared through the share sheet: document where it went and hash it there.

Taking a bugreport generates log lines and a notification but changes no user data. Record the start and end time: every section's timestamps are relative to that moment.

Anatomy of the zip

The main text file is organised into sections introduced by lines such as ------ DUMPSYS (dumpsys) ------ and, for each service, DUMP OF SERVICE <name>:. Search for those markers to jump around a file that is often 50 to 200 MB.

grep -n 'DUMP OF SERVICE ' bugreport-*.txt | awk -F'SERVICE ' '{print $2}' | head -100

The sections that matter

System properties

The SYSTEM PROPERTIES section lists every property: build fingerprint, patch level, model, serial, time zone. It is the basis of the device description in your report. See build.prop and device identifiers.

dumpsys package

Every installed package with firstInstallTime, lastUpdateTime, installerPackageName, version, target SDK, flags (including ALLOW_BACKUP), requested and granted permissions. It mirrors packages.xml and is the quickest way to list sideloaded apps.

dumpsys usagestats

Recent usage events (activity resumed and paused, screen, keyguard, notifications) and per-package aggregates. It is the in-memory and recent-file view of usagestats, usually covering days.

dumpsys batterystats

Battery history since the last full charge: screen, plugged state, top app, wakelocks, radios and GPS, plus per-app energy statistics and a --checkin block. Batterystats explains decoding; Battery Historian renders it.

dumpsys account

Accounts per user with types, and a short history of account operations. See accounts databases.

dumpsys notification

Current notifications and a short archive of removed ones, redacted by default on recent releases. For full text on a live phone use adb shell dumpsys notification --noredact separately. See notification history.

dumpsys activity

Recent tasks (dumpsys activity recents), running processes, services and broadcasts. The recents list gives the last active time of each task, the same data as recent tasks without images.

dumpsys wifi and bluetooth_manager

Saved networks (keys masked), connection history and recent scan results; bonded Bluetooth devices and adapter enable history. Complements WifiConfigStore.xml and bt_config.conf.

dumpsys location

Last known location per provider with time and accuracy, and recent location requests by app. Useful for placing the device at seizure and spotting background trackers.

Security configuration

• dumpsys accessibility: enabled and bound accessibility services.
• dumpsys device_policy: device admins, device and profile owners, policies.
• dumpsys appops: last access and reject times per app and operation.
• Settings dumps: secure, global and system settings.

These are the core of the malware triage guide.

Telephony

dumpsys telecom keeps a short call history with masked numbers and call states; dumpsys telephony.registry shows the serving cell and signal. Neither replaces the call log.

Logcat

The bugreport includes the main, system, events, crash and radio buffers. The events buffer is particularly structured: am_proc_start, am_focused_activity or wm_on_resume_called (names vary by release), screen_toggled, boot_progress_*. Crash buffers and tombstones show which apps or native processes crashed, which occasionally reveals exploitation attempts or tampering.

Time handling

A bugreport mixes several time bases, and misreading them is the most common error:

Rules of thumb:

1. Record the device time zone (persist.sys.timezone) and the device clock offset against a reference when the report was taken.
2. Anchor "ago" values to the report start time printed in the header, not to your analysis time.
3. Add the year to logcat lines from the report date, checking for a year boundary.
4. Convert kernel uptime using the boot time (uptime section or boot_progress_start events).
5. Convert everything to UTC before merging, as the timeline guide describes.

Privacy and handling

A bugreport contains account names, network names, device identifiers, app lists, sometimes notification text, locations and log fragments with personal data. Treat it as evidence: hash on receipt, store with access control, share only the sections needed. Some sections are masked or redacted by the OS on user builds; do not assume the absence of a field means the device lacked it.

Tools

• Text tools (grep, less, awk) are still the fastest way to navigate the main file.
• MVT (mvt-android check-bugreport) extracts packages, accessibility, device admin and other items and checks them against indicators.
• Battery Historian plots the battery section.
• ALEAPP parses some bugreport-derived artifacts; commercial suites can import bugreports as a logical source on some versions.

Targeted dumpsys without a bugreport

When a full bugreport is too slow or you need a section with different options, call the service directly:

adb shell dumpsys -l                              # list services
adb shell dumpsys usagestats > usagestats.txt
adb shell dumpsys batterystats --history > battery_history.txt
adb shell dumpsys notification --noredact > notification.txt
adb shell dumpsys activity recents > recents.txt
adb shell dumpsys package com.example.app > pkg_example.txt
adb shell dumpsys location > location.txt

Avoid options that change state: dumpsys batterystats --reset, dumpsys usagestats flush or reset options, logcat -c. Read-only is the default for these commands, but always check a new option's documentation before running it on evidence.

Worked example: a 15-minute bugreport triage

With a fresh bugreport and no other data, a first pass can answer most "what is this phone and is anything odd on it" questions:

1. Identity. From SYSTEM PROPERTIES: model, Android version, patch level, fingerprint, time zone, verified boot state. Note them in the case file.
2. Accounts. DUMP OF SERVICE account: Google, Samsung and app accounts per user. They name the cloud sources for later requests.
3. Recent installs. In DUMP OF SERVICE package, list packages whose firstInstallTime falls in the period of interest, with their installerPackageName. Anything installed by a browser, a file manager or with no installer goes on the shortlist.
4. Special access. DUMP OF SERVICE accessibility, device_policy and the secure settings dump: any enabled accessibility service, notification listener or device admin that is not obviously legitimate goes on the shortlist.
5. Usage around the incident. DUMP OF SERVICE usagestats: screen, keyguard and foreground events around the time of interest.
6. Last hours. Battery history for screen, charging and top-app transitions up to the moment of seizure; dumpsys location for the last known position.
7. Indicators. Run mvt-android check-bugreport and compare its findings with your shortlist.

BR=bugreport-*.txt
grep -n 'firstInstallTime=2026-09-1' $BR | head          # installs in a date range
grep -n -A2 'Enabled services' $BR                       # accessibility
grep -n 'installerPackageName=' $BR | grep -v com.android.vending | head

The result is not a finished analysis, but it tells you within minutes whether the case needs a malware review, which accounts to name in legal process, and which on-device artifacts to prioritise in the full extraction.

Comparing bugreports over time

When a device is examined twice (at seizure and later, or before and after a suspected compromise), two bugreports make a useful diff: packages added or removed, new accounts, changed settings, new device admins. Normalise each file first (remove timing lines and memory statistics), then diff the sections that describe state rather than activity. The same approach works for bugreports provided by a device owner over several weeks in a stalkerware case, which show when a suspicious app first appeared.

OEM additions

OEM builds add their own dumpsys services and files to the bugreport: Samsung builds, for example, include many Samsung service dumps and vendor logs, and some vendors add modem or connectivity logs. They can extend the reach of usage, network and location data, but their formats are undocumented and change between firmware versions. Treat them as leads, validate them on a test device with the same firmware, and cite the exact section.

Checklist

• Record both clocks and the time zone before starting.
• Take adb bugreport, then targeted dumpsys with --noredact or --history where useful.
• Hash immediately; keep the zip unmodified and work on copies.
• Review properties, packages, usage, battery, accounts, notifications, activity, Wi-Fi, Bluetooth, location, accessibility, device policy and appops.
• Run MVT on it for spyware indicators.
• Convert all times to UTC before merging with other sources.
• Move on to a full file system extraction if app content is needed.