Security, storage, logs and crash records from bug reports

Summary

• ALEAPP now has 38 Bug Report artifacts in seven groups: security and device policy (13), vendor services (3), storage and databases (11), settings and config (2), device and build (2), logs (3) and boot, crash and dropbox (4). The pull request was merged on 27 October 2026.
• The log tables are large: on one report the system log alone has 325,705 rows. Times are converted with a stated year rule and the zone the report records, and the kernel log keeps its own clock as printed.
• Row counts equal raw-text counts on every report that has the section, and the logs equal them on all seven. Cases the reports did not contain, such as damaged zip members, exist as synthetic fixtures.
• Crash and ANR files that live inside the zip give rows only when the tool reads the zip. The artifact notes say so.

The issue

An examiner has to say whether a screen lock was set, whether a device administrator or a management policy was active, whether USB debugging was on, how full storage was, what the system logged around a time of interest, and why the device last restarted. A bug report is the one file that carries the device policy and lock settings dumps, the system, event and kernel logs, the crash and hang records, and on some builds a history of restart reasons. The answers are there, but a reader has to get several things right at once.

The logs are the hardest. A system log line prints month, day and clock time with no year and no zone. The body of the log reaches back a few minutes to about three hours, and a few older stray lines can sit above the dense part, so the first line of the section is not the start of the window. In LAB-TR-0041, four of the seven research reports had such head strays. An examiner who takes the first line as the start, and then finds no record of an event before it, has drawn a conclusion from the edge of the log. The kernel log uses a different clock, seconds since boot, and the report does not print when that clock started.

The policy sections have the opposite risk: they are small and easy to misread as complete. A lock settings dump lists the names, sizes and times of the files that hold lock state, and never their contents. Crash and hang records can be in the zip as separate files, not in the main text, so a reader of the text alone finds none and reports none. Figure 1 shows how one log line is read.

The essence

The pull request adds 38 artifacts that read the security, storage, log, crash and reset sections of a bug report in one pass. Each row is what the dump or log printed for one entry. Policy values, flags and counters are shown as printed. A log row keeps the printed time, the user, process and thread ids, the level, the tag and the message, with a UTC time added by the rule in Figure 1 where the report allows it. The kernel log keeps seconds since boot and is not given a clock time.

Two artifacts read members of the finished zip as well as the main text: ANR Trace Threads and Tombstones. The pull request notes that they only produce rows with -t fs, so a bug report text read alone gives none of the zip-member rows.

Our methodology

The method is the one used for the other three pull requests of the stack. We write down the layout of each section from the reports we hold, by Android version and vendor, and write the reader to that layout. The readers plug into the single-pass reader of LAB-TR-0001, which streams the report once and hands each open section only to the readers registered for it (Figure 2).

Three decisions are specific to this group. Log tables stop at a row cap and add one warning to the report, so a very large log cannot grow without limit and cannot be cut without a trace. Long messages are cut at a set length. Encoded blob lines of 60 or more base64 characters in the vendor services are counted in the log and not kept; on one report that was 3,566 lines. And the kernel log is not given a clock time, because computing one would need the start of the kernel clock, which the report does not print.

Checking has four layers. Synthetic fixtures with invented values come first, with cases per layout (l10, l16, old and new), a cut dump, an empty report, a file that is not a report, odd bytes, two reports in one run and a zip kept on the device. The two modules have 244 baselines in two case folders, and all pass under TZ=UTC.

Second, an independent recount. On the five older research reports, security and storage row counts equal an independent raw-text count on every report that has the section, and the log and crash counts equal on all five. The zone conversion left every real row unchanged, because every research report records UTC+0; any other zone is tested only on synthetic fixtures. On the two newer Android 16 reports the whole tool ran with no failed artifact, and counts made with our own line rules equalled the System Log, Event Log, Kernel Log, Device Config Flags, Database Operations and Vendor Service Lines rows (Figure 3).

Third, the 509 bug report unit tests of the stack so far pass, and the changed files score 10.00 of 10 on pylint. Fourth, behavior on missing and damaged data is built as fixtures because no research report supplied it: logcat without a user id column or with a year, a command's time-limit lines, wrapped protobuf, damaged zip members and negative offsets in reset lines. Where a report prints no section, the table is empty, and the section index shows that the section was absent and not unread.

The value

For an examiner the gain is that these questions become lookups. Which device administrators were enabled and what policy state the service printed. Which lock settings files existed for each user and when they were last modified. Which biometric sensors were present and, where a build prints them, which authentication events were recorded. Whether a trust agent was enabled and the state of the ADB manager. How full storage was, which volumes were mounted, which packages were large, and which databases an app had open and what it last executed. What the system, event and kernel logs recorded, and which hang, crash and restart records exist.

The limits come first. A lock settings dump gives names, sizes and times, never contents; the lock secret and ADB keys are never in a bug report. A log window is short, and an examiner should find where the dense part begins and read the last line before concluding that nothing happened. A missing crash or dropbox entry is not proof that nothing happened. Reset Reasons come from the Samsung builds tested only. SQL text in Database Operations is shown as the platform printed it and can contain values an app passed to the database. The tool shows a token value from one Samsung service as printed, because it runs on the examiner's own evidence; this page shows none.

Where this sits in the Lab's research

Three Lab reports apply. LAB-TR-0001, Making Silent Failures Visible: A Single-Pass Section Reader for Android Bug Reports (Zenodo, version 1.1, 10.5281/zenodo.23719508), describes the reader, the section index and the record of cut dumps that these artifacts rely on.

LAB-TR-0041, Attributing Interior Gaps in Phone Logs to Restarts, Log Rotation and Clock Steps, is available on this site as a preprint; the Zenodo deposit is pending. It finds head strays in four of seven bug reports, treats the system log as a dense log, and says that only a restart licenses the claim that nothing happened in a gap. The reset reason and kernel log tables here are places to look for a restart; the paper's rule says what to do with one.

LAB-TR-0017, Where Device Security Settings Live on Disk, is a white paper, available on this site as a preprint; the Zenodo deposit is pending. It maps security settings in 48 full file system extractions, warns about reads that return nothing without an error, and did not examine bug reports. The security artifacts here are the bug report side of the same questions, and the same warning applies. 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.

Related posts

• ALEAPP #1816: permissions, app ops, usage, alarms and notifications, the first of the four.
• ALEAPP #1817: network, Wi-Fi, Bluetooth, NFC, USB and telephony.
• ALEAPP #1818: accounts, power, processes, location, media, display and input.