Cite as
Addai, D., SectraTEK Lab (2026). Android bug reports, category by category. LAB-0002, version 1.1. https://lab.sectratek.com/research/lab-0002/
Methodology note
Drafted with AI assistance and reviewed by the author before publication.
Summary
- A bug report is mostly a set of snapshots. Each section is the state of one service at the moment of capture. A few sections hold a window of events: logs, usage events, battery history.
- In our sample of five reports a report had between 355 and 669 sections. The 22 categories below cover the ones that carry evidence for common questions.
- Core sections such as package, app ops, battery statistics and the system log were in all five reports. Vendor sections were in one or two.
- Three of the five reports had sections cut by the device time limit. A cut section is not a clean one: it says nothing about what it did not reach.
- A bug report cannot give file contents, message bodies, network destinations or ADB keys, and it reaches back about a day for most event sections.
What a bug report is
A bug report is a zip file the phone builds on request, from developer options or from a computer with adb bugreport. Its main file is a long text file in numbered sections, usually headed by the name of a system service (for example DUMP OF SERVICE appops) or a log. Beside it sit a few other parts: copies of some files, protobuf dumps, and hardware interface listings.
It was written to help a developer find a fault, not to answer questions about a person, so its order follows the system and not the question. That is why this article sorts it by question.
- 5Reports read
- 355 to 669Sections per report
- 3 of 5Reports with cut sections
Counts from our sample of five reports, not a statistic.
The categories
We group sections into 22 categories. The grouping is by hand, and some choices are judgment calls (the database section sits under storage, the content and sync sections under accounts). Pick a category to see what it holds, which questions it can answer, and where it stops.
Device and software
Access and policy
Activity
Connectivity
Power, location and sensors
Logs and failures
Device and software
Device and build
The description of the build: Android version, patch level, build identity and the properties the system reports about itself.
Questions it can answer
- Which Android version and patch level is this?
- Is this the manufacturer build the examiner expects?
- Which time zone data does the device carry?
Where to look
System properties, report header, time zone data, hardware properties, build flags (3 of 5), platform compatibility (3 of 5), fonts.
Limit
Values at capture time. A property that changed earlier is not shown unless the section keeps history.
Anchor section: SYSTEM PROPERTIES
Present in 5 of 5 reports (sample of 5, not a statistic).
Device and software
Installed apps and components
Every installed package with its version, installer, install and update times, flags and the components it declares.
Questions it can answer
- Which apps are installed, and which installer put them there?
- When was an app installed or last updated?
- Which components does an app expose to others?
Where to look
package (tens of thousands of lines), check-in package data, application activities, services and providers, overlays, widgets, shortcuts (3 of 5).
Limit
State at capture: what is installed now. Cut by the time limit in one report of five.
Anchor section: package
Present in 5 of 5 reports (sample of 5, not a statistic).
Device and software
Settings and configuration flags
The values of the settings tables, and on Android 16 a history of changes to them.
Questions it can answer
- Is developer mode or USB debugging on?
- Is installing from unknown sources allowed?
- Did a setting change, and in what order?
Where to look
settings (system, secure and global tables, with history on Android 16), device config (3 of 5).
Limit
A setting says what is configured, not who set it. History exists only where the build keeps it.
Anchor section: settings
Present in 5 of 5 reports (sample of 5, not a statistic).
Device and software
Vendor and hardware
What the manufacturer added: its own services and their dumps, next to the common hardware interface list.
Questions it can answer
- Which vendor services exist on this build?
- Which hardware interfaces does the device declare?
Where to look
Hardware interface list (5 of 5), Samsung quality-monitoring and security services (2 of 5), Motorola settings, Huawei power manager, Transsion performance framework.
Limit
No common layout. Names and contents differ for every manufacturer, so read each as its own format.
Anchor section: HARDWARE HALS
Present in 5 of 5 reports (sample of 5, not a statistic).
Access and policy
Permissions, app ops and roles
Which permissions each app holds, which operations it is allowed to perform, and when an operation was last used.
Questions it can answer
- Which apps hold a sensitive permission?
- When did an app last use an operation such as camera or location?
- Which app holds a role such as default dialer?
Where to look
app ops (thousands to over a hundred thousand lines), permission lines inside package, permission manager (3 of 5), roles (3 of 5).
Limit
Grants and last-use times, not what the app did with the access.
Anchor section: appops
Present in 5 of 5 reports (sample of 5, not a statistic).
Access and policy
Security and device policy
Whether a screen lock is set, which biometrics are enrolled, whether a device administrator or management policy is active, and the ADB state.
Questions it can answer
- Is a screen lock configured, and of which type?
- Is a device administrator or management policy active?
- Is USB debugging enabled?
Where to look
Device policy, lock settings (3 of 5), fingerprint (3 of 5), face (4 of 5), trust agents (3 of 5), ADB state, Samsung security services (2 of 5).
Limit
ADB keys and signer certificates are not in a bug report, and the lock secret never is.
Anchor section: lock_settings
Present in 3 of 5 reports (sample of 5, not a statistic).
Access and policy
Accounts, users, sync and backup
Which accounts are on the device and of what type, which users exist, which sync adapters ran and when, and the backup state.
Questions it can answer
- Which accounts are signed in?
- Is there more than one user or a work profile?
- Is backup on, and when did a sync last run?
Where to look
accounts, content and sync (5 of 5), backup (5 of 5), users (3 of 5), health data service (3 of 5).
Limit
Account names are personal data. Public articles describe the field, never a value.
Anchor section: account
Present in 5 of 5 reports (sample of 5, not a statistic).
Activity
App usage
Which apps came to the foreground and left it, over about the last 24 hours, with the usage buckets the system assigned.
Questions it can answer
- Which app was in use around a time of interest?
- How long was an app in the foreground in the last day?
Where to look
usage statistics check-in (5 of 5), usage events (3 of 5), graphics statistics, frame statistics (4 of 5).
Limit
A window of about 24 hours. Nothing before it is available.
Anchor section: CHECKIN USAGESTATS
Present in 5 of 5 reports (sample of 5, not a statistic).
Activity
Running processes, memory and app kills
What was running at capture, how much memory each app held, and why recent processes were stopped.
Questions it can answer
- What was running when the report was taken?
- Why did an app process end (crash, kill, user)?
Where to look
activity manager (5 of 5), process statistics, processes and threads, memory (cut in two reports), CPU, binder state, process exit info (3 of 5).
Limit
A snapshot plus a short exit history. The activity section was cut by the time limit in two reports of five.
Anchor section: activity
Present in 5 of 5 reports (sample of 5, not a statistic).
Activity
Alarms and jobs
Work apps have scheduled for later, and the alarms that were set or fired.
Questions it can answer
- What is an app set to run later, and when?
- Which alarms woke the device?
Where to look
job scheduler (5 of 5, thousands of lines), alarm manager (5 of 5).
Limit
Shows what is scheduled, not what ran. Scheduled work is not evidence of use.
Anchor section: jobscheduler
Present in 5 of 5 reports (sample of 5, not a statistic).
Activity
Notifications
Notification channels per app, the apps allowed to listen to notifications, and recent notification records.
Questions it can answer
- Which apps can post or read notifications?
- Which channels does an app define?
Where to look
notification service (5 of 5), status bar.
Limit
A snapshot of channels, listeners and recent records, not a full history.
Anchor section: notification
Present in 5 of 5 reports (sample of 5, not a statistic).
Activity
Display, input and accessibility
The keyboards installed and selected, the accessibility services that are enabled, and the display and window state.
Questions it can answer
- Which keyboard is active?
- Which accessibility services are enabled?
Where to look
accessibility, input method (4 of 5), window manager, display, compositor, input.
Limit
Configuration at capture. An enabled service is not proof that it was used.
Anchor section: input_method
Present in 4 of 5 reports (sample of 5, not a statistic).
Connectivity
Network and connectivity
The network state at capture: interfaces, policy and restrictions, resolver settings, and where it exists, per-app data counters.
Questions it can answer
- Which network was the device on?
- Which apps have data restrictions?
- Which apps used mobile or Wi-Fi data (where per-app counters exist)?
Where to look
network policy, connectivity, name resolver, network daemon, sockets, firewall rules and routes, tethering (3 of 5), per-app data check-in (2 of 5).
Limit
No network destinations. Per-app counters were in only the two Samsung reports of our sample.
Anchor section: netpolicy and connectivity
Present in 5 of 5 reports (sample of 5, not a statistic).
Connectivity
Wi-Fi
Saved networks, connection events and the scanner state.
Questions it can answer
- Which Wi-Fi networks does the device know?
- When did it connect or disconnect?
Where to look
Wi-Fi service (5 of 5), scanner, direct connections, Samsung Wi-Fi extension (2 of 5; cut in one).
Limit
Saved-network names are personal data. Public articles describe the field, never a value.
Anchor section: wifi
Present in 5 of 5 reports (sample of 5, not a statistic).
Connectivity
Bluetooth, NFC and USB
Paired Bluetooth devices and recent adapter events, NFC state, and USB mode and connection events.
Questions it can answer
- Which Bluetooth devices has the phone paired with?
- Was a USB connection made?
Where to look
Bluetooth manager (5 of 5, bonded devices and events), NFC (4 of 5), USB (3 of 5), USB log (2 of 5).
Limit
Event windows are short; the USB log was in two reports of five.
Anchor section: bluetooth_manager
Present in 5 of 5 reports (sample of 5, not a statistic).
Connectivity
Telephony and messaging
The radio layer: registration state, carrier configuration, subscriptions and what the radio logged.
Questions it can answer
- Which carrier configuration is active?
- What did the radio layer log around a time of interest?
Where to look
radio log (5 of 5), phone, carrier configuration, messaging and subscription services, telephony registry (3 of 5), telecom (3 of 5).
Limit
No message bodies and no call content: only state and logs of the radio layer.
Anchor section: RADIO LOG
Present in 5 of 5 reports (sample of 5, not a statistic).
Power, location and sensors
Battery and power
Per-app power use, screen and charging events and idle behaviour, over about one day.
Questions it can answer
- Which apps used the most power?
- When was the screen on, and when was the device charging?
Where to look
battery statistics (5 of 5, the largest section), battery check-in, power manager, idle controller, battery, thermal (3 of 5).
Limit
About one day. The very large size does not mean a long window.
Anchor section: batterystats
Present in 5 of 5 reports (sample of 5, not a statistic).
Power, location and sensors
Location and sensors
The state of the location manager: providers, and the apps that request location.
Questions it can answer
- Which location providers are on?
- Which apps request location?
Where to look
location manager (5 of 5), sensor service, location time-zone manager (3 of 5).
Limit
Not a location history.
Anchor section: location
Present in 5 of 5 reports (sample of 5, not a statistic).
Power, location and sensors
Camera, microphone and media
Events of apps that use the camera, audio state and which app is projecting or recording.
Questions it can answer
- Which app opened the camera recently?
- Is a screen recording or projection active?
Where to look
camera service (5 of 5, thousands of lines), audio, audio flinger, audio policy, media metrics, player, session and projection.
Limit
Recent events only. Pictures and recordings are never in a bug report.
Anchor section: media.camera
Present in 5 of 5 reports (sample of 5, not a statistic).
Power, location and sensors
Storage, filesystem and databases
Mounted volumes, free space and the databases apps have open, by name and size.
Questions it can answer
- How full is storage?
- Which databases does an app hold open?
Where to look
database info (5 of 5, cut in one), mounts, storage daemon (3 of 5), disk statistics, filesystems and free space.
Limit
Names and sizes, never the contents of a file or database.
Anchor section: dbinfo
Present in 5 of 5 reports (sample of 5, not a statistic).
Logs and failures
Logs
The system and event logs, and the kernel log of the last boot where it is kept.
Questions it can answer
- What happened around a time of interest?
- Which component logged an error?
Where to look
system log (5 of 5), event log, radio log, kernel log (4 of 5), last kernel messages (3 of 5), statistics log.
Limit
The body of the log runs from a few minutes to about three hours between reports. A few older stray lines can sit above it, so find where the dense part begins as well as the first line. Check the start of the body and the last line before concluding that nothing happened.
Anchor section: SYSTEM LOG
Present in 5 of 5 reports (sample of 5, not a statistic).
Logs and failures
Boot, crash, ANR and tombstones
Crash and not-responding records, native crash dumps, why the device last restarted, and whether an update ran.
Questions it can answer
- Did an app crash or hang?
- Why did the device last restart?
Where to look
dropbox entries (5 of 5), tombstones, ANR traces, VM traces, reset reasons (2 of 5), boot properties, update engine (1 of 5).
Limit
Includes the boot reason history discussed in LAB-0001. A missing entry is not proof that nothing happened.
Anchor section: dropbox
Present in 5 of 5 reports (sample of 5, not a statistic).
Select a category, or move between categories with the arrow keys. Dots show in how many of the five sample reports the anchor section was present.
Show this figure as a table
| Category | Anchor section | In reports | What it holds |
|---|---|---|---|
| Device and build | SYSTEM PROPERTIES | 5 of 5 | The description of the build: Android version, patch level, build identity and the properties the system reports about itself. |
| Installed apps and components | package | 5 of 5 | Every installed package with its version, installer, install and update times, flags and the components it declares. |
| Settings and configuration flags | settings | 5 of 5 | The values of the settings tables, and on Android 16 a history of changes to them. |
| Vendor and hardware | HARDWARE HALS | 5 of 5 | What the manufacturer added: its own services and their dumps, next to the common hardware interface list. |
| Permissions, app ops and roles | appops | 5 of 5 | Which permissions each app holds, which operations it is allowed to perform, and when an operation was last used. |
| Security and device policy | lock_settings | 3 of 5 | Whether a screen lock is set, which biometrics are enrolled, whether a device administrator or management policy is active, and the ADB state. |
| Accounts, users, sync and backup | account | 5 of 5 | Which accounts are on the device and of what type, which users exist, which sync adapters ran and when, and the backup state. |
| App usage | CHECKIN USAGESTATS | 5 of 5 | Which apps came to the foreground and left it, over about the last 24 hours, with the usage buckets the system assigned. |
| Running processes, memory and app kills | activity | 5 of 5 | What was running at capture, how much memory each app held, and why recent processes were stopped. |
| Alarms and jobs | jobscheduler | 5 of 5 | Work apps have scheduled for later, and the alarms that were set or fired. |
| Notifications | notification | 5 of 5 | Notification channels per app, the apps allowed to listen to notifications, and recent notification records. |
| Display, input and accessibility | input_method | 4 of 5 | The keyboards installed and selected, the accessibility services that are enabled, and the display and window state. |
| Network and connectivity | netpolicy and connectivity | 5 of 5 | The network state at capture: interfaces, policy and restrictions, resolver settings, and where it exists, per-app data counters. |
| Wi-Fi | wifi | 5 of 5 | Saved networks, connection events and the scanner state. |
| Bluetooth, NFC and USB | bluetooth_manager | 5 of 5 | Paired Bluetooth devices and recent adapter events, NFC state, and USB mode and connection events. |
| Telephony and messaging | RADIO LOG | 5 of 5 | The radio layer: registration state, carrier configuration, subscriptions and what the radio logged. |
| Battery and power | batterystats | 5 of 5 | Per-app power use, screen and charging events and idle behaviour, over about one day. |
| Location and sensors | location | 5 of 5 | The state of the location manager: providers, and the apps that request location. |
| Camera, microphone and media | media.camera | 5 of 5 | Events of apps that use the camera, audio state and which app is projecting or recording. |
| Storage, filesystem and databases | dbinfo | 5 of 5 | Mounted volumes, free space and the databases apps have open, by name and size. |
| Logs | SYSTEM LOG | 5 of 5 | The system and event logs, and the kernel log of the last boot where it is kept. |
| Boot, crash, ANR and tombstones | dropbox | 5 of 5 | Crash and not-responding records, native crash dumps, why the device last restarted, and whether an update ran. |
How far back it reaches
Most sections are a snapshot, so they cannot be placed on a timeline. Event sections have a window, and the window is short. Do not place a dump-time snapshot on a timeline as if it were an event.
| Kind of section | Window in our sample | Note |
|---|---|---|
| System log (logcat) | From a few minutes to about 3 hours (the dense body of the log) | The window differs between reports. A few older stray lines can sit above the body, so the first line is not the start of the window; find where the dense part begins, and read the last line. |
| Battery history | About 1 day | Per-app power and screen events. |
| Usage events | About 24 hours | Foreground and background changes. |
| Settings history | Android 16 only in our sample | Changes to setting values, where the build keeps them. |
| Package, permissions, accounts, Wi-Fi | State at capture | A snapshot. It is not an event history. |
What changes between versions and vendors
The same Android version can differ between manufacturers, and the same manufacturer can differ between versions. Figure 2 compares five reports. Switch the columns to Android version order to see whether a difference follows the version or the manufacturer.
| Section | Report ASamsungAndroid 16 | Report BSamsungAndroid 16 | Report CHuaweiAndroid 10 | Report DMotorolaAndroid 15 | Report ETranssion-brandAndroid 10 |
|---|---|---|---|---|---|
| In all five reports | |||||
| System properties | Present | Present | Present | Present | Present |
| Package list | Cut | Present | Present | Present | Present |
| App ops | Present | Present | Present | Present | Present |
| Activity manager | Cut | Present | Present | Present | Cut |
| Battery statistics | Present | Present | Present | Present | Present |
| System log | Present | Present | Present | Present | Present |
| Dropbox entries | Present | Present | Present | Present | Present |
| Cut by the device time limit in some reports | |||||
| Database info | Present | Cut | Present | Present | Present |
| Differs by manufacturer or version | |||||
| Per-app data usage | Present | Present | Absent | Absent | Absent |
| Lock settings | Present | Present | Absent | Present | Absent |
| Samsung Wi-Fi extension | Cut | Present | Absent | Absent | Absent |
| Samsung security services | Present | Present | Absent | Absent | Absent |
| Motorola settings service | Absent | Absent | Absent | Present | Absent |
| Huawei power manager | Absent | Absent | Present | Absent | Absent |
| Transsion performance framework | Absent | Absent | Absent | Absent | Present |
| Update engine | Absent | Absent | Absent | Present | Absent |
| Sections in the report | 622 | 669 | 422 | 551 | 355 |
| Cut by the device time limit | 3 | 5 | 0 | 0 | 3 |
17 rows shown.
Two things stand out in this sample. Vendor sections (Samsung, Motorola, Huawei, Transsion-brand) exist only on that vendor and have no common layout. And the device time limit cut sections in the larger reports of both Samsung phones and in one of the two Android 10 reports, which is why presence alone is not enough: a cut section has to be read as not captured.
What this does not prove
Five reports are a handful, not a survey. A row that differs here may not differ across a manufacturer's range. Android 11 to 14 were not in our sample.
What a bug report cannot give
- File contents and message bodies.
- Short windows: the body of the system log ran from a few minutes to about three hours, battery history about a day, usage events about 24 hours.
- Per-app network history, except in the two Samsung reports of our sample.
- Network destinations.
- ADB keys or signer certificates.
- Events for sections that are dump-time snapshots.
A section cut by the device time limit says "not captured", never "nothing happened".
Reproduce
- On a test device you own, take a bug report from developer options, or run
adb bugreport. - Open the main text file and list its section headings. Count them.
- Check the end of each large section for a note that it was cut by the time limit.
- Compare your headings with Figure 2, and with the anchor sections in Figure 1.
Publish counts and section names, never values from a report that holds personal data.
Open-source parsers
Merged The category names above follow the grouping we use for bug report parsers in an open-source parser project, under the heading "Android Bug Report". Seven pull requests are merged in ALEAPP: #1795, #1796, #1809, #1816, #1817, #1818 and #1819. Categories that these pull requests do not cover may not have a parser yet. Each parser needs a synthetic test fixture, because real reports hold personal data. See Open Source for status.
Appendix: downloads
Section names and counts only. Licence: CC BY 4.0.
- Download lab-0002-category-map.json
lab-0002-category-map.jsonJSONThe 22 categories of Figure 1 with sections, questions and limits.
d9df5ec1a8ea105ec56baf6677135c740cd72b4082982161bc3366ba087b70b4 - Download lab-0002-section-matrix.csv
lab-0002-section-matrix.csvCSVThe table of Figure 2, one row per section and one column per report.
0a8d92407dcfa359162460cbeb58fbe7769a36d90912c30a0e8d6a0d3987bceb
References
- Android Developers. Capture and read bug reports (documentation). developer.android.com
- ALEAPP, Android Logs, Events, And Protobuf Parser (open source). github.com/abrignoni/ALEAPP
- Addai, D., SectraTEK Lab. Samsung recovery and reset trail. LAB-0001
Version history and corrections
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-10-27 | First publication. |
| 1.1 | 2026-11-07 | Open-source status updated: the bug report parsers are merged in ALEAPP (#1795, #1796, #1809, #1816 to #1819). |
Corrections log
No corrections have been published for this article. Corrections to any article are listed on Corrections.