Summary
- ALEAPP now has 59 Bug Report artifacts in six groups: accounts, sync and backup (16), battery and power (12), processes and memory (5), location and sensors (10), camera and media (7), display and input (9). The pull request was merged on 27 October 2026.
- It is the largest of the four in the stack. The pull request offers a split into accounts and power (33) and sensors and media (26) on request.
- Most of these tables are snapshots or rings of recent events. The notes of each artifact state the window, and the reader caps long streams.
- Every row count equals a count from the raw text on five reports, and the whole tool ran on all seven. Sections that no artifact reads are listed as not read.
- 59artifacts added in six groups
- 328test baselines in 2 case folders
- 7,336battery history rows on the larger of two reports
- 5,744process thread rows on the second report, equal to a raw-text count
Methodology note
Drafted with AI assistance and reviewed by the author before publication. Every figure uses synthetic example values or counts taken from the pull request.
The issue
An examiner asks which accounts were signed in, whether a work profile existed, when sync last ran, what used the battery over the last day, which app opened the camera, and which keyboard and accessibility services were active. In a bug report these are six families of service dumps with six layouts, and the layouts differ between Android versions. The media metrics dump has one record form on Android 15 and 16 and another on Android 10, where the time is a 19-digit count of nanoseconds. The window dump is printed twice on the Samsung and Motorola reports, a short copy and a full one, so lines of the full copy can repeat.
Time is the second difficulty. Location events and many logs print month, day and clock time with no year. A battery daily summary on one report prints a period end of 1970-01-01, the zero of the clock, which is not a date anyone should convert. Battery history prints only what changed since the previous record, so the first record after a reset is long and the rest are short.
Volume is the third. One report prints 7,336 battery history records, another 2,500 media metrics records, and a sensor service keeps a ring of recent events per sensor. A tool that stores everything without limits is easy to overwhelm, and a tool that cuts silently hides the cut. LAB-TR-0001 found that about 80 percent of the sections of two reports were read by no artifact, which is why this contribution also lists what remains unread. Figure 1 shows the smallest case, one account line.
Show this figure as a table
| Field | Value (synthetic example) |
|---|---|
| User | 0 |
| User Name | Example User |
| User Flags (stored) | 4c13 |
| Account Name | pat@example.org |
| Account Type | com.example.mail |
The essence
The pull request adds 59 artifacts that read the accounts, power, process, location, sensor, camera, audio, display and input sections of the report text in one pass. Each row is what the dump printed for one entry. Flags, state bits and sensor values are kept as stored and are not decoded, because their meaning belongs to the platform component that wrote them. Where a dump prints a time, the row keeps it as printed and a UTC column is added by a stated rule.
A row says that the service listed or logged the entry. For accounts, it does not say who used the account. For the sensor and location rings, it does not say that anyone was present.
| Group | Artifacts | What the dumps hold |
|---|---|---|
| Accounts, Sync and Backup (16) | Accounts, Account History, Authenticators, Visibility; Sync Adapter Status, Recent History, Last Syncs, Jobs, State; Backup State, Transports, Package State, Participants, Queues; Users, User Manager Facts | Accounts per user, sync adapters and their last runs, backup state, the Android users |
| Battery and Power (12) | Battery History, Daily Summary, Package Changes, Power Use, Wake Locks, Service State; Thermal Service State; Power Manager State, Wake Locks, Events; Device Idle State, History | Battery history and per-app power, wake locks, power and idle events |
| Processes and Memory (5) | Process Stats, Process Threads, Memory By Process, Memory Process Detail, Memory Summary | Process statistics, a thread list from the PROCESSES AND THREADS section, memory use |
| Location and Sensors (10) | Location Providers, Last Known, Requests, Events, Usage, Time Zone Detection State; Sensors, Sensor Connections, Registrations, Events | Location manager state and its recent event ring, sensor list and recent events |
| Camera and Media (7) | Camera Service Events, Camera Devices, Audio Events, Audio Clients, Media Sessions, Audio Playback Order, Media Metrics | Events of apps that use the camera, audio and media state |
| Display and Input (9) | Accessibility Services, Input Methods, Input Start History, Soft Input History, Display States, Brightness Events, Window Focus, Windows, SurfaceFlinger Layers | Enabled services, keyboards, display and window state |
Our methodology
As for the earlier artifacts, we write the layout of each service down from the reports we hold, by Android version and vendor, and then write the reader. The readers plug into the single-pass reader of LAB-TR-0001, which streams the report once and hands each open section to the readers registered for it (Figure 2).
Streams get explicit bounds. The location event ring held 13 to 1,000 lines on the reports tested, and 1,000 lines on one report suggests a full ring, which was not confirmed. Sensor Events reads at most 100 lines per sensor. Process Threads leaves out a line with fewer columns than its header and counts it in the log, so a damaged line is visible and not silent. Where a time has no year, the year is the latest one, the report's or the one before, that does not put the line more than a day after the report time, and the zone the report records is then applied. In the battery daily summary, a time before 2009 gets no UTC value.
Show this figure as a table
| Step | What happens |
|---|---|
| 1. Find the file | The same path set as the earlier bug report artifacts. |
| 2. Index the sections | Every section is entered with kind, name, lines and duration; a time-limit marker is stored on a cut service. |
| 3. Hand over the lines | Readers registered for the account, sync, backup, user, battery, power, device idle, process, memory, location, sensor, camera, audio, media, accessibility, input, display and window sections. |
| 4. Keep bounded rows | Rows as printed, text cut at set sizes, at most 100 sensor event lines per sensor, row caps logged. |
| 5. Present | 59 artifacts in six groups; UTC added where the printed time allows it. |
Checking has four layers. Synthetic fixtures with invented values come first: cases per Android layout (a10, a16), a cut dump, an empty report, a file that is not a report and two reports in one run, among others. The two modules have 328 baselines in two case folders, and all pass under TZ=UTC.
Second, an independent recount. On the five older research reports, every row count equals a count made from the raw text with plain regular expressions, except where a note says otherwise. On the two newer Android 16 reports the whole tool ran with no failed artifact, and Process Threads (5,027 and 5,744 rows) equals a raw-text count made with our own line rules (Figure 3). The pull request reports count agreement for these tables. It does not report a field-by-field comparison with a second parser, which is why the confidence on this page is moderate.
Third, the 386 bug report unit tests of the stack so far pass, and the changed files score 10.00 of 10 on pylint. Fourth, absent sections are recorded and not guessed. The thermal service state is empty on one report because the report has no such section, and the time zone detection state logs a line when the dump is missing. Sections with content that no artifact reads are listed in the Sections artifact with Read By set to not read. The cases that no research report printed, such as time zones with offsets, a second Android user and some location and sensor shapes, exist only as synthetic fixtures.
Show every artifact of this pull request as a table
| Artifact | Report 1 rows | Report 2 rows |
|---|---|---|
| Accounts (Accounts, Sync and Backup) | 7 | 19 |
| Account History (Accounts, Sync and Backup) | 51 | 47 |
| Account Authenticators (Accounts, Sync and Backup) | 9 | 31 |
| Account Visibility (Accounts, Sync and Backup) | 14 | 61 |
| Sync Adapter Status (Accounts, Sync and Backup) | 31 | 73 |
| Sync Recent History (Accounts, Sync and Backup) | 90 | 100 |
| Sync Adapter Last Syncs (Accounts, Sync and Backup) | 192 | 540 |
| Sync Jobs (Accounts, Sync and Backup) | 33 | 63 |
| Sync State (Accounts, Sync and Backup) | 25 | 23 |
| Backup State (Accounts, Sync and Backup) | 18 | 18 |
| Backup Transports (Accounts, Sync and Backup) | 10 | 10 |
| Backup Package State (Accounts, Sync and Backup) | 30 | 31 |
| Backup Participants (Accounts, Sync and Backup) | 25 | 28 |
| Backup Queues (Accounts, Sync and Backup) | 135 | 151 |
| Users (Accounts, Sync and Backup) | 1 | 0 |
| User Manager Facts (Accounts, Sync and Backup) | 31 | 0 |
| Battery History (Battery and Power) | 7,336 | 1,634 |
| Battery Daily Summary (Battery and Power) | 11 | 11 |
| Battery Package Changes (Battery and Power) | 4 | 319 |
| Battery Power Use (Battery and Power) | 145 | 153 |
| Battery Wake Locks (Battery and Power) | 277 | 155 |
| Battery Service State (Battery and Power) | 79 | 78 |
| Thermal Service State (Battery and Power) | 39 | 0 |
| Power Manager State (Battery and Power) | 115 | 109 |
| Power Wake Locks (Battery and Power) | 10 | 5 |
| Power Events (Battery and Power) | 138 | 150 |
| Device Idle State (Battery and Power) | 58 | 59 |
| Device Idle History (Battery and Power) | 100 | 100 |
| Process Stats (Processes and Memory) | 2,018 | 2,995 |
| Process Threads (Processes and Memory) | 5,027 | 5,744 |
| Memory By Process (Processes and Memory) | 374 | 404 |
| Memory Process Detail (Processes and Memory) | 73 | 85 |
| Memory Summary (Processes and Memory) | 15 | 14 |
| Location Providers (Location and Sensors) | 4 | 4 |
| Location Last Known (Location and Sensors) | 4 | 4 |
| Location Requests (Location and Sensors) | 4 | 9 |
| Location Events (Location and Sensors) | 600 | 1,000 |
| Location Usage (Location and Sensors) | 6 | 22 |
| Time Zone Detection State (Location and Sensors) | 14 | 14 |
| Sensors (Location and Sensors) | 15 | 34 |
| Sensor Connections (Location and Sensors) | 7 | 9 |
| Sensor Registrations (Location and Sensors) | 500 | 500 |
| Sensor Events (Location and Sensors) | 368 | 1,265 |
| Camera Service Events (Camera and Media) | 200 | 138 |
| Camera Devices (Camera and Media) | 7 | 10 |
| Audio Events (Camera and Media) | 605 | 913 |
Audio Clients (Camera and Media) | 17 | 21 |
| Media Sessions (Camera and Media) | 1 | 1 |
| Audio Playback Order (Camera and Media) | 7 | 2 |
| Media Metrics (Camera and Media) | 2,500 | 2,500 |
| Accessibility Services (Display and Input) | 3 | 5 |
| Input Methods (Display and Input) | 6 | 10 |
| Input Start History (Display and Input) | 64 | 64 |
| Soft Input History (Display and Input) | 32 | 32 |
| Display States (Display and Input) | 2 | 2 |
| Brightness Events (Display and Input) | 100 | 189 |
| Window Focus (Display and Input) | 4 | 4 |
| Windows (Display and Input) | 18 | 22 |
| SurfaceFlinger Layers (Display and Input) | 4 | 6 |
The value
For an examiner the gain is a table behind each question. Which accounts and account types each user has, and which sync adapters ran last. Whether backup is configured and which transports exist. Which apps held wake locks and how battery was used per package. What processes and threads existed when the dump ran, and how much memory each held. Which location providers were enabled, which apps requested location, and what the location event ring recorded. Which sensors exist and which connections to the sensor service were open. Which app opened the camera recently, and which processes the audio server and media session service held registrations for. Which keyboard and accessibility services were enabled, and what had window focus.
The windows are short, and the notes say so. Battery history reaches back about a day, and its size does not mean a long window. The location tables are the state of the location manager and a short ring, not a location history. Camera tables hold recent events only; pictures and recordings are never in a bug report. An enabled accessibility service shows configuration, not use. Window focus is the focus when the dump ran. Account names are personal data and are shown in the tool as printed, because the tool runs on the examiner's own evidence; this page shows none.
Because the pull request is large, a reviewer can ask for the two halves separately. The pull request says so, and it was merged as one change.
Show this figure as a table
| Column | Items |
|---|---|
| Checked on research reports | Every row count equals a plain regular-expression count of the raw text on five reports, except where a note says otherwise; Process Threads equals a raw-text count on two more reports; Whole tool ran with exit 0 on all seven reports |
| Synthetic fixtures only | Time zones with offsets or daylight saving; A second Android user; Sensor and location cases that no research report printed |
| Not examined | Android 11 to 14; Vendors other than the four seen; Field values against a second parser: the pull request reports count agreement for these tables; Sections no artifact reads (listed as not read) |
Where this sits in the Lab's research
The reader these artifacts plug into is described in LAB-TR-0001, Making Silent Failures Visible: A Single-Pass Section Reader for Android Bug Reports (Zenodo, version 1.1, 10.5281/zenodo.23719508). Its section index is what lets this contribution say which sections remain unread, and its record of cut dumps is why a missing table can be told from a quiet device.
LAB-TR-0016, Seven Kilobytes per Event: Storage Amplification and Memory Peaks When Persisting Parsed Log Events from Android Bug Reports, is available on this site as a preprint; the Zenodo deposit is pending. It measured a reference implementation, not ALEAPP, in which 1,532,676 parsed events from seven bug reports took 11.02 GB. It is cited here because tables such as battery history, sensor events and media metrics are the event-like streams where that cost arises, and the readers on this page bound them. The grouping follows Android bug reports, category by category.
Sources
Every number and claim on this page, with where it came from. Figure values are either synthetic examples (marked) or counts from the pull request.
| Number or claim | Where it came from |
|---|---|
| 59 artifacts in 6 groups (16, 12, 5, 10, 7, 9) | Pull request description, 'What this changes'; artifact list in bugreportAccountsPower.py (33) and bugreportSensorsMedia.py (26) |
| The pull request offers a split into accounts and power (33) and sensors and media (26) on request | Pull request description, 'What this changes' |
| Merged on 27 October 2026 | Pull request state and merge time (mergedAt); the review and comment lists are empty |
| 328 baselines in 2 case folders, all pass; 386 cumulative unit tests; pylint 10.00/10 | Pull request description, 'Test record' table |
| Every row count equals a plain regular-expression count on five reports; Process Threads 5,027 and 5,744 equal on two more | Pull request description, 'Proven on real reports' |
| All other row counts in Figure 3 (for example Battery History 7,336 and 1,634; Media Metrics 2,500 and 2,500) | Pull request description, table of rows per artifact (two newest Samsung reports) |
| Constructed only and not examined lists (Figure 4) | Pull request description, 'Constructed only' and 'Not examined' |
| Seven reports in four vendor families, Android 10, 15 and 16; whole tool exit 0 in 20 to 55 s per report | Pull request description; device classes only |
| Location Events: no year; year rule; ring of 13 to 1,000 lines; 1,000 may mean a full ring (not confirmed) | Notes of Location Events in bugreportSensorsMedia.py |
| Sensor Events: at most 100 lines per sensor; values not decoded | Notes of Sensor Events in bugreportSensorsMedia.py |
| Window dump printed twice on Samsung and Motorola reports, so lines can repeat | Notes of Window Focus in bugreportSensorsMedia.py |
| Media Metrics has two record forms (Android 15 and 16; Android 10 with a 19-digit nanosecond time) | Notes of Media Metrics in bugreportSensorsMedia.py |
| Battery History records what changed since the previous record; the first record after a reset is long | Notes of Battery History in bugreportAccountsPower.py |
| Battery Daily Summary: UTC empty for a time before 2009; one period end printed as 1970-01-01 | Notes of Battery Daily Summary in bugreportAccountsPower.py |
| Process Threads: lines with fewer columns than the header are not listed and are counted in the log | Notes of Process Threads in bugreportAccountsPower.py |
| Thermal Service State is empty on one report (no section); Time Zone Detection State logs when the dump is missing | Pull request description, 'Anything reviewers should know' |
| About 80 percent of sections (546 of 681 and 544 of 672) are read by no artifact; sections not read are listed as such | LAB-TR-0001, abstract, Table 9; pull request description |
| 1,532,676 parsed events took 11.02 GB in a reference implementation (not ALEAPP) | LAB-TR-0016, abstract and section 1 |
| Battery history reaches back about a day; location is not a history; pictures and recordings are never in a bug report | Lab article LAB-0002, categories 'Battery and power', 'Location and sensors' and 'Camera, microphone and media' |