Network, radio and telephony state from bug reports

Summary

• ALEAPP now has 37 Bug Report artifacts for connectivity in four groups: Wi-Fi (6), network (14), Bluetooth, NFC and USB (10) and telephony (7). The pull request was merged on 27 October 2026.
• Most timestamps in these dumps carry no year, and one list carries no date at all. The readers keep the printed text and add a UTC value only where the report holds enough to compute it.
• Counts equal counts made from the raw text on every report that has the section. Five Wi-Fi and usage tables also equal a second parser, with one named difference.
• Sections that a report does not print, and sections that are printed but not read, are listed, so an empty table is not mistaken for a quiet radio.

The issue

An examiner is asked whether a phone had been on a particular Wi-Fi network, whether it had paired with a Bluetooth device, whether a USB connection was made, or which SIM and carrier configuration it used. A bug report prints the state of each of those services, but in a different layout for each service. Many of the timestamped lines carry month, day and clock time with no year, and one list, the private DNS log, carries only the time of day.

Small differences decide whether a reading is right. Android 10 builds print fewer pairs in a connection event, so two columns are empty there. Some builds print a network name in quotes, some shortened or masked. Bluetooth addresses are partly masked by the platform in three of the five early reports, and the Motorola report prints complete addresses. The network statistics can be printed twice, in the netstats dump and again in the CHECKIN NETSTATS section, so a report that prints both lists its buckets twice. The artifact says which section printed each row, so the two copies are visible and are not merged.

Absence is the third problem. One Android 16 report has no NFC section, so the NFC artifacts are empty for it, and another has no USB or telecom section. Without a record of which sections exist, those empty tables look like a quiet radio. The Lab's section index (LAB-TR-0001) keeps that record. Figure 1 shows how one event line becomes one row, including the missing year.

The essence

The pull request adds 37 artifacts that read the Wi-Fi, network, Bluetooth, NFC, USB and telephony sections of the report text. Each row is what the dump printed for one entry: a saved network, a connection event, a usage bucket, a paired device, a SIM subscription, a carrier setting. Numbers such as connection results and class codes are shown as stored, with no meaning attached. A row says that the service listed or logged that entry. It does not say what a person did.

Two choices keep the tables honest. Where a time has a date but no year, the year follows a stated rule. Where a time has no date, no UTC value is made.

Our methodology

We read each service from the text of the reports we hold and write down its layout by Android version and vendor before writing a reader. For Wi-Fi, the saved networks are in one block of the wifi dump; a second block that follows repeats the same networks and is not read, so each network is listed once. The readers plug into the single-pass reader of LAB-TR-0001: the report is streamed once, each open section goes only to its registered readers (Figure 2), and every section, read or not, is entered in the index.

Time is handled in three ways. A wall time with month and day gets a year by the rule in Figure 1 and is converted with the zone the report records. A time of day without a date, as in the private DNS log, gets no UTC value, because any date would be a guess. A count of seconds on the kernel clock, as in the NFC and USB logs, is kept as printed; about one NFC log line in 20 also prints a wall time, and only those lines get a UTC value, left empty with a note when the wall time is earlier than the device start.

Checking follows the same layers as the earlier artifacts in the stack. First, synthetic fixtures with invented values: cases per Android layout (a10, a16), 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 245 baselines in two case folders, and all pass under TZ=UTC.

Second, an independent recount. On the five older research reports, the Wi-Fi saved networks, connection events, scan results and state machine records, and the network usage buckets, equal a second parser written separately. One field differs on 5 saved-network entries of one report, and the notes name it. For the radio artifacts, counts equal a raw-text count on every report that has the section. Field values of the radio artifacts were checked by eye on samples and not against a second parser, and the limits table says so.

Third, two newer Android 16 reports went through the whole tool with no failed artifact, and counts made with our own line rules equalled the artifact rows for Network Usage Buckets (26,131 and 60,684), Radio Log State Lines (7,983 and 5,804) and NFC Driver Log (none and 4,241) (Figure 3). The 295 bug report unit tests of the stack so far pass, and the changed files score 10.00 of 10 on pylint.

Missing and large data are handled in the open. One large Samsung Wi-Fi section is read to a cap of 20,000 lines and the cut is logged. A list of what the reports print but no artifact reads is in the pull request: two NFC vendor dumps, the GATT scanner map, the telephony registry registrations and lsusb.

The value

For an examiner this turns several questions into table lookups. Which Wi-Fi networks does the phone know, whether it ever connected to each, how many times it associated, and with which key management. Which connection events the Wi-Fi service logged, with duration and result. Which apps have data restrictions in the network policy, and which usage buckets the statistics hold where a build prints them. Which Bluetooth devices are bonded, and when the adapter was enabled or a connection started. Whether NFC was on and which card emulation services exist. When a USB port connected or disconnected, with the vendor and product identifiers where the line prints them. Which SIM subscriptions and carrier settings were active.

The limits are part of the answer. A saved network shows that the phone knows it, not that it was joined at a given time. The private DNS log is older than the dump by an unstated amount. The open sockets table is a snapshot of the moment the command ran. The NFC and USB logs are printed by some Samsung builds only. Nothing here gives network destinations, message bodies or call content; the telephony tables hold state and the radio layer's own log lines. Bluetooth bond events were not on any research report that prints the list, so that reader is tested only on a synthetic fixture.

The tool shows subscriber identifiers such as ICCID, IMSI and phone numbers, and the adapter address, exactly as printed, because it runs on the examiner's own evidence. This page shows none; every value in the figures is invented.

Where this sits in the Lab's research

No Lab report is about the network and radio sections as such, so the method on this page comes from the pull request and its notes. Two 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 and the section index that make an absent section visible. LAB-TR-0041, Attributing Interior Gaps in Phone Logs to Restarts, Log Rotation and Clock Steps, is in preparation and not yet on Zenodo; it treats the event and radio logs of bug reports as event-driven streams, in which a quiet period is normal and is not a hole.

The categories follow Android bug reports, category by category, which also records that per-app network counters were present only in the two Samsung reports of its five-report sample.

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 #1818: accounts, power, processes, location, media, display and input.
• ALEAPP #1819: security, storage, logs, boot, crash and dropbox.