Bluetooth file transfers from btopp.db

Summary

This contribution adds Bluetooth File Transfers, an artifact that reads the btopp table of the Android Bluetooth app's btopp.db. It looks under either Bluetooth package name, reads one database per Android user, and adds a Source File column. Direction, status, visibility, confirmation and scanned are shown as stored, and the notes give what the Android source says each code means.

The honest part comes first. On the four Android 16 images the pull request was written against, btopp.db exists with its full table and holds no rows. The artifact notes in the merged change later widen the count: 40 research images carry the database, 100 copies counting storage views, second users and one rollback copy, and two copies held one row each. So the code has been run on three synthetic cases and on two real rows.

The issue

A familiar question in an examination is whether a phone handed a file to another device nearby. Bluetooth object push is one route. The Android Bluetooth app keeps a table with one row per transfer, and until now an ALEAPP report had no entry for it. An examiner who wanted the answer opened the database by hand, or did not look.

Two traps sit in the way. The first is the path. The database lives under com.android.bluetooth on some builds and com.google.android.bluetooth on others, 14 and 26 of the 40 research images that carry it. A reader that checks one folder finds nothing on the other and says nothing. The second is that the table is usually empty. On all four Android 16 images it was present, complete and empty. An empty table is consistent with no transfer by this route, but it does not show that no file was ever sent, because Quick Share, Nearby Share and messaging apps do not write here.

Figure 1 separates what this table records from what it cannot.

The essence

Bluetooth File Transfers reports one row per row of the btopp table, in each btopp.db found. Timestamp is converted to UTC with the core's unit detection; every other column is reported as stored, with the integers left as integers. The notes record what the AOSP source says the codes mean and say plainly that a device maker's build may differ, which was not examined.

Our methodology

We began with the schema. We listed the columns of btopp in every copy we could find and found three variants: 14 columns with user version 1 in 29 images, the same 14 plus device_name and reserved with user version 2 in 10 images, and the 14 plus carrier_name in one image. The artifact reads the columns common to the variants and leaves Device Name blank where the column is absent; carrier_name is not read.

Meaning came from the Android source. The notes cite the AOSP Bluetooth module for the direction, visibility, confirm and status codes, and for how the provider fills the timestamp when the inserting code gives none. We did not translate the codes in the report, because whether a device maker's build uses the same values was not examined. The timestamp is read with the core's magnitude-based unit detection; on the two real rows it was a 13-digit value, read as milliseconds, which is an inference from the digit count and nothing more.

For checking we leaned on invented data and on independent counts. Three synthetic cases with invented values cover an empty table, a database under the Google module path, and two Android users. The storage-view test mode passes: a duplicate view of one copy is unchanged, and a second user exactly doubles the rows. On the four Android 16 images an independent count(*) returned 0 in each, so no real row was parsed in the original work. The suite passed 135 cases with no failure, three more than before. The tool's output checker had no table to read on the real reports, so it was not applicable.

Figure 2 shows the steps. Figure 3 shows the shape of the research images.

The value

The value today is a place to look and a decoded structure, not a stream of findings. An examiner now gets, in the report, any Bluetooth object-push record the phone kept: when the transfer was initialized, the destination address, the file name and type, the byte counts, and the direction and status codes, with the AOSP meaning in the notes. Where the table is empty the report says so, and the notes say what an empty table does not show.

The limits are firm. A row is a record in the Bluetooth app's table and is not by itself proof that a file reached the other device. Whether a device maker's build updates the timestamp later was not examined. Transfers by Quick Share, Nearby Share or messaging apps are not expected here. The pull request asks for one thing from other examiners: a populated btopp.db, from a device that has sent or received a file over Bluetooth, would close the remaining gap. Figure 4 shows how a populated row would read, with invented values.

Where this sits in the Lab's research

No Lab report is devoted to this store; the method above comes from the pull request. It appears as one of the case studies in Lab Technical Report LAB-TR-0006, Section 7.1 and Table 8, which records the Bluetooth transfer table as present and empty on all four images, with row content and timestamp unit not verified. That is the same boundary stated here, before the later corpus count.

Cite as: Addai, D. (2026). Empty Is Not Absent: Silent Failure Modes in Open-Source Mobile Forensic Parsers on iOS 26 and Android 16. LAB-TR-0006, version 1.0, preprint. doi:10.5281/zenodo.23717929.

Sources

Every number and claim on this page, and where it comes from. Figures marked synthetic example use invented values.

Related posts