Usage, settings and boot history from bug reports

Summary

• A bug report holds the last day of app foreground changes, a history of ended app processes, every settings table and the boot reason history. After the first reader was merged, the Sections table listed these parts of the text as "not read".
• This change adds five artifacts on the same one-pass reader: Usage Events, Process Exit Info, Settings, Settings Changes and Boot Reasons. The five boot reason properties also become rows of Device Facts.
• Each time follows a stated rule. Epoch milliseconds are read as UTC, wall-clock text is converted with the report's own time zone, and a value that is not a time keeps its printed text and gets no UTC value.
• Reason words, event types and setting names are shown as the platform printed them. The artifacts present data only: no severity, no finding, no interpretation.
• The pull request was stacked on ALEAPP #1795 and merged on 26 October 2026.

The issue

An examiner has one question about the last day and three about the longer past. Which app was in the foreground around a time of interest? Did an app process end, and with which reason? Is a debugging or developer setting on, and did a setting change? Why did the phone last start? A bug report holds material for all four, spread over five places, each with its own shape. After the first reader was merged, the Sections table listed all of them as "not read" (Figure 1).

The usage list comes in two forms. The Android 16 phones in the research reports print epoch milliseconds; the Android 10 and Android 15 reports print wall-clock text without a zone. Three of the five reports print the list twice, once in the usagestats service dump and once in the CHECKIN USAGESTATS section, so an event can appear twice (3,075 and 3,079 rows on the Huawei report, for example). The two Samsung reports print only the check-in list. Some builds also print a time that was never set, such as 1970-01-01 or 1973-08-29 05:00:27, which would read as a real date if converted without care.

The other parts have their own traps. The settings history prints a month, day and clock time with no year. The activity dump is written more than once, and in the Samsung A-series report the first copy ends at the platform's 500 millisecond limit and holds no exit entries; they are in the second copy. A settings value can run over several lines. Each is a place where a quick extraction returns a plausible table that is short or wrong.

The essence

Five artifacts are added. Each reads one part of the text through a reader registered for that section, in the same single pass that the earlier artifacts use. Every row carries its source line, and every time keeps its printed text beside the UTC value.

The CONFIG SETTINGS table, which held 651 to 2,013 entries in the tested reports, is counted in the log and not listed. The pending-events list and the interval statistics of the usage dump are not read; the notes say so.

Our methodology

Each section was read in real reports before a reader was written for it. A usage line is a set of key=value pairs. An exit entry starts with ApplicationExitInfo #N and continues over several lines. A settings entry starts with _id: and ends in trailing fields. A change entry sits under a History (name) line. Figure 2 shows how each section reaches its artifact.

Time got the most care. A number is read as epoch milliseconds only when it falls between 2009 and 2100, which rejects zero, small counters and garbage without guessing a unit. Wall-clock text is converted only with the zone the report records. A change in the settings history has no year, so the reader takes the latest year, this one or the one before, that does not put the change more than a day after the report time (Figure 4).

The counts were checked the way the first pull request's were. Each row count equals a count made from the raw text with plain regular expressions and the rows of an independent parser written for another tool, compared field by field and, for times, in UTC to the millisecond. The only fields that differ are three settings values with line breaks. The other parser keeps trailing default: tokens in such a value; here the value ends at the first trailing token of its last line and the line break is shown as a space.

One report staged twice in two folders doubled every artifact exactly. Two Android users are in real data too: the Motorola report has 1,229 exit entries and 146 settings rows for user 11. A second user in the usage events was built on constructed text, because only user 0 had events.

The 82 new unit tests add cases that real reports did not contain: calendar edge times (year 1 and year 9999), non-ASCII digits, a damaged line at column 0, a settings value with line breaks that contains the word default:, a last exit entry at the end of the dump, change times around the report time, and a boot history with blank lines, a missing stamp and 550 entries.

Damaged input was tried on the same 14 variants of one real text as in the first pull request. No variant raised an error or failed an artifact. The text repeated twelve times gave exactly twelve times the usage events (118,092) and settings rows (5,268), in 24 seconds with a 318 MB peak. One variant replaces one space in 5,000 with a carriage return, a form feed or a NUL byte. It damages headings, and one usage list (4,884 of 9,841 rows) is lost with its damaged heading. The pull request records that as expected. LAB-TR-0001 lists the same variant as the one altered input that did not meet its expectation, and leaves open whether it is a defect.

Figure 3 shows the real-data runs. Zeros are results: the Android 10 builds print no exit entries, and the settings history exists in the two Android 16 Samsung reports only. An empty table says nothing about the device. Zone conversion was the identity on every real row because all five reports record UTC+0; other zones are in the constructed fixtures.

The value

The first answer is about time. The usage list covers the last 17 to 24 hours in the tested reports, so it can place an app in the foreground around a moment of interest, and the Source Section column tells a duplicate from a new event. The exit history reaches much farther, because it is the history the platform kept and not a log of the last day: the tested reports held entries spanning about six months (Samsung A-series), two and a half years (Samsung S-series) and two years (Motorola). Boot reasons give the last two to four starts with the platform's own words.

The second answer is about state. The Settings table lists what the settings provider held when the dump ran, per user, with the package that wrote each entry. The Settings Changes table, where a build prints it, adds the order in which values changed. Together they let an examiner ask whether a setting was different earlier, which a bare value cannot answer.

Several limits matter in a case. A usage row records that the usage statistics service noted that event type for that package; it does not say what caused it. An exit row says the platform recorded that a process ended with the printed reason, not who ended it. A boot reason entry says the platform recorded a start with that reason, not why. A setting row says what was configured, not who set it.

Settings also describe the moment of capture, which can include what taking the report required. In the Lab's seven research bug reports, developer options were on in six and USB debugging was off in all seven, a pattern that fits reports taken from the developer options on the device (LAB-TR-0019). Treat such values as observed, not as the user's choice. Values can include text such as device and Bluetooth names, so an export deserves the same care as the report.

Unverified on real data: Android 11 to 13, other vendors, and a second user's usage events. A settings change older than a year would be given a year too late; the tested spans are 297 and 362 days.

Where this sits in the Lab's research

The artifacts support Lab Technical Report LAB-TR-0001, "Making Silent Failures Visible: A Single-Pass Section Reader for Android Bug Reports". Its Table 5 reports that usage events, process exits, settings changes and boot history agreed with a second parser on counts, fields and UTC values on all five reports, and that settings entries differed in three values that span several lines, which the two parsers split differently on purpose. Its Table 7 lists three reader defects that concern this change, all found in validation: a lost last exit entry, wrongly split multi-line settings values, and a pending-events list read as events.

Cite: Addai, D. (2026). Making Silent Failures Visible: A Single-Pass Section Reader for Android Bug Reports. Lab Technical Report LAB-TR-0001, version 1.1. Zenodo. doi:10.5281/zenodo.23719508. Read it on this site at LAB-TR-0001.

The report LAB-TR-0019, "Not Found Is Not Off", is available on this site as a preprint; the Zenodo deposit is pending. It measures what full file systems and seven research bug reports can establish about a phone's security settings. LAB-TR-0017, a white paper also available on this site as a preprint, maps where the same settings tables live in a full file system; it did not examine bug reports.

Sources

Every number and claim in this post, and where it comes from. Numbers that could not be sourced were left out.

Related posts

• Reading Android bug reports in a single pass. The reader and the first four tables.
• Bug report artifact groups and invented fixture values. Categories per question, device identifiers, and the fixture numbers replaced.