Bug report artifact groups and invented fixture values

Summary

• The bug report artifacts merged so far shared one category, Android Bug Report. This change sorts them into six groups named for the question they answer, such as App Usage and Settings and Config. Only the category text changes: it names the report folder and the LAVA category.
• Serial numbers, IMEIs, SIM card numbers and addresses were left out of the first tables on purpose. The change adds them, as printed, in their own artifact, Device Identifiers: 25 listed properties, the kernel command line and the bootconfig lines.
• Three fixture numbers that also occur in real bug reports, and that the earlier privacy scan had missed, are replaced by invented numbers of the same shape. A new case, synthetic_identifiers, uses invented values only.
• The pull request text describes the first commit, which put the identifier rows into Device Facts. A second commit moved them into the Device Identifiers artifact before the merge, and the merged code has that artifact.
• The pull request was merged on 27 October 2026.

The issue

The nine bug report artifacts merged so far all carried one category, Android Bug Report. In ALEAPP the category text names the HTML report folder and the LAVA category, so every table landed in one place, however different the questions were: build and time zone, installed apps, usage, settings, boot. A report folder showed a flat list of nine names (Figure 1).

The first tables also left out serial numbers, IMEIs and similar values on purpose. That is a cautious default, and it has a cost. Examiners commonly tie an evidence item to a handset or a SIM card by exactly these values, and a table that omits them sends the examiner back to the raw text to find them. The change adds them as printed, in a table of their own, and says plainly that serial numbers, IMEIs, SIM card numbers and addresses now appear in the HTML, TSV and LAVA output of that artifact.

The third problem was in the test data. The shared fixture merged with the first reader held two Module Metadata version numbers, and one test file held an epoch number, that also appear in real bug reports. The privacy scan described in the first two pull requests had not caught them. Whether such a number is harmless is a judgment that a project should not have to make about its own fixtures; the rule is invented values only. The change replaces the three numbers with invented ones of the same shape and rebuilds the case zips and baselines that held them. The earlier commits remain in the repository history.

The essence

Three changes. The categories are now six groups. One new artifact, Bug Report - Device Identifiers, shows the identifier values a report prints. Three fixture numbers are invented.

Device Identifiers has five columns: Name, Value, Origin, Source Line and Source File. A row is one of three things: a listed identifier property from the system properties (25 names covering serial numbers, IMEI and MEID values, SIM card numbers, Bluetooth and Wi-Fi addresses and device ids); the Command line header line, which is the kernel command line and is cut at 4,000 characters; or a bootconfig line, up to 1,000 lines with values cut at 400 characters. Origin says which. A property that is not on the list is not read, whatever its name says, and Device Facts no longer carries these rows.

Our methodology

The 25 names are those seen on the research reports and names that other builds are documented or known to use. No property named for an account or an advertising identifier is on the list. A search of the property names on the seven real reports for "account" and "advertis" found only cache keys and a Bluetooth advertising setting, so none was added; an identifier that another build prints under another name is not read, and the notes say so.

The split between the two artifacts is one small test on each fact, shown in Figure 2. A fact read from the header or from a property is first limited to the allow list; the test then sends identifier properties, the command line and bootconfig lines to Device Identifiers, and everything else to Device Facts. That keeps the older artifact free of identifiers, and it keeps the new one from picking up a property just because its name sounds like an identifier.

The identifier rows were compared with an independent count made from the raw text with plain regular expressions, name and value by name and value. Over the seven reports there are 31 identifier property rows (3 to 8 per report), 7 command line rows (one on each) and 306 bootconfig rows (none on the two Android 10 reports, 35 to 105 on each of the other five). All equal. Of the 25 listed names, 16 occur on at least one report, and the other nine are exercised by invented text only (Figure 3). The synthetic case also includes a property named like a serial number that is not on the list, to show that it is not read.

Four extractions in the Lab's research corpus (Android 13 and 14 builds) were also run. They print identifier property rows and a command line but no bootconfig row; one prints a Bootconfig line that holds a read error and no key = value line, which gives no row.

Two unit-test files guard the structure. The new test_bugreport_all.py fixes the group counts (3, 2, 1, 1, 2 and 1, ten in all), checks that every name starts with "Bug Report - ", that every artifact uses the same six path patterns, and that every artifact named in the section index exists. The bug report tests number 92 against 86 before.

The other eight artifacts are unchanged in code. On the five earlier reports their counts equal those recorded in the first two pull requests. On the Samsung A07 and A26 reports they ran without error; an independent raw-text count was made there for Process Exit Info only. Two different reports staged together gave rows equal to the sum of the two single runs, and the same report staged twice is read once.

The privacy scan covered all changed files, with zip members opened, the commit message and the commit author, against the tokens and lines of the seven reports. It found no device-specific value; what matches is platform vocabulary. The earlier scan of the same kind had missed three numbers, and LAB-TR-0001 draws the lesson that a leak scan should be run independently of whoever builds the fixtures.

The value

For an examiner, the groups make a report folder readable by question, and the identifier table puts the values that tie a report to a handset or a SIM card in one place, each with its source line. Where a report prints a value in a property, in the command line and in the bootconfig, each is its own row, so the examiner can see how many places the text repeats it.

For a project, the change fixes a convention: bug report artifacts go into these six groups, and fixtures hold invented values only. The test file checks the first half automatically. Figure 4 shows what the identifier view looks like with invented values.

The behavior change is the main point to carry into a case. An export of Device Identifiers contains serial numbers, IMEI-style numbers, SIM card numbers and addresses exactly as printed. Handle the export as you would the report itself, and think before it leaves the case file. Anyone with scripts that match the old category name, Android Bug Report, must update them to the group names.

Limits: the list is not exhaustive, a printed identifier shows what the report says and not that it is the handset in front of you, and the nine unseen names have only invented-text tests. The Device Facts sample_data counts for four corpus extractions were recorded before the identifier rows moved and were not re-run; the notes say so. Android 11 to 14, vendors beyond the four, and the Shell app's finished bug report zip in a file system extraction were not examined for these rows.

Where this sits in the Lab's research

The change supports Lab Technical Report LAB-TR-0001, "Making Silent Failures Visible: A Single-Pass Section Reader for Android Bug Reports". Its artifact availability section lists this pull request among the seven that released the work. Its table of agreement checks reports the 31, 7 and 306 identifier, command line and bootconfig rows as equal to raw-text counts on all seven reports. Its reproducibility section records the two module version numbers replaced here and the lesson about independent leak scans.

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 public article Android bug reports, category by category (LAB-0002, early research) sorts the sections of a bug report into 22 categories by the question they answer. The six groups here are a coarser grouping of artifacts, not of sections. A further Lab report on validating community parsers, covering fixtures, independent recounts and leak scans, is in preparation (LAB-TR-0014) and has no page yet.

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.
• Usage, settings and boot history from bug reports. Five more artifacts on the same reader.