Same artifact, different Android versions

Summary

• A reader built for one layout can return nothing on another Android version, and an empty result looks the same as a feature the person never used.
• Three kinds of change appear in our sample: encoding (settings files became Android Binary XML from Android 12), place (permission and Wi-Fi files moved to a new folder) and shape (one access is stored as an aggregate row, a last-access time and a text dump).
• Older guides still name keys and files that were absent from every current phone we checked, for example a legacy settings database, absent from all 14.
• Our sample has no Android 11 and no Android 15 full file system. Those gaps are part of the result, and the figure below shows them as such.
• A careful reader says why a field is empty, and names the versions it did not test.

When the right file gives the wrong answer

An examiner asks whether USB debugging was on. The reader opens the settings file, looks for the setting and finds nothing. The field is empty. That looks like a setting nobody changed. It can also mean that the reader could not read the file.

Our own sample shows how easily this happens. From Android 12 the platform writes its settings files in Android Binary XML (ABX), a binary encoding of XML. In the sample, 53 of 58 settings files were ABX. A standard XML parser rejected all 53, and a text search for the usual setting pattern found nothing in them. A decoder for the binary format recovered between 69 and 505 settings per file [1]. A reader that catches the parse error and returns an empty list would report every setting on these phones as absent.

We call the cause a layout mismatch: the reader assumes one layout and the phone uses another. Three kinds appear in the Lab's research collection.

• Encoding. The path is the same and the bytes are different.
• Place. The file moved to a new folder, or the key was renamed.
• Shape. The record itself means something different, for example a row that stands for a time window and not for one event.

The examples come from Lab Technical Reports on settings locations, App Ops history and parser failure modes. They cover Android 10 and Android 12 to 16 in full file system extractions, and Android 10, 15 and 16 in bug reports. Android 11 is missing, and there is no Android 15 full file system [9].

Try it: one artifact across versions

Figure 1 lets you pick an artifact, a reader built for one layout, and the Android version of the phone. The version buttons show what that reader returns on every version, so the pattern shows before you open a single result. Start with the default, settings values read by a plain XML parser on Android 12, then switch to the decoder.

Two things to notice. First, the pattern follows a change in layout, not a missing feature: the phone has the same setting before and after the change. Second, "No data" is part of the result. It marks a version our sample did not cover, and it is not a finding that nothing is there.

Same path, different encoding

An ABX file starts with the four bytes 41 42 58 00. The format first appeared on Android 12 test images, mostly in system files [3]. In our sample every settings file on Android 12, 13, 14 and 16 was ABX, and the one Android 10 phone used plain XML (Figure 2).

The change is not uniform. Two files in the same part of the system, the Wi-Fi store and the runtime permission file, were plain XML on every version. A reader that applies the binary decoder to every system XML file fails the other way round. The check is cheap: read the first four bytes and decide [4].

A related trap is the old settings database. Guides describe a settings.db under the settings provider. It was absent from all 14 Android extractions, and files with that name belonged to other apps on 12 of them [5].

Same file, different place

Some artifacts keep their format and move. The runtime permission file and the Wi-Fi configuration store sit under the system folders on Android 10 and under an apexdata folder from Android 12 (Figure 3). A reader with the Android 10 paths finds no file on a later phone and returns no grants and no saved networks [6]. The empty table is the same one a phone with none would give, so a missing path needs a stated reason.

Names move too. In the lock settings store, the key that older guides use for the credential type was present on 2 of 14 extractions, and only on Android 10 and 13 ones. A legacy pattern key was on none. What was on every one is sp-handle, which points to the synthetic-password blob. The credential files that older guides name, gesture.key and password.key, were absent from all 14 [7]. In the same way the build fingerprint property of older guides was in none of 13 system build property files, while its system-prefixed form was in all 13 [5].

A bug report does not repair this. It does not carry the lock settings database at all, and in a reconstruction over seven bug reports 60% of the lock-state facts could not be carried by that evidence [8]. For a lock question on a phone known only through a bug report, the supported answer is "not determinable from this evidence", not "no lock".

Same record, different shape

App Ops records which app used a protected resource, such as the camera, the microphone or the location, and when. On Android 16 in our sample the same access is stored in three forms: two history databases, one XML file, and a text dump in every bug report. They are not copies of one record [10].

• A database row is an aggregate. It covers one window, one minute in the short-interval database and fifteen minutes in the long-interval one. It holds the time of the first access in the window and a count.
• The XML file holds the last access for each key and nothing earlier.
• The dump prints a snapshot at the moment the report was made.

A reader that expects the XML time to equal a database time finds a match for 1,717 of 3,180 times (54.0%). For 1,182 of the other 1,463 (80.8%), the XML time sits inside a window whose row counted more than one access, as the first-versus-last difference predicts. The other 281 are unexplained [12]. The file is read correctly. The comparison rule is the one that has to change: match a time to a window, not to an equal value. Reading the stored rows exactly (328,519 rows on five images) [11] still gives windows, not accesses, and 941 rows on two images differ between the main database file alone and the file with its write-ahead log [13].

None of this holds on every version. The Android 14 image had no history database. It carried an older XML history layout and a folder of discrete operations, which we saw on that one image and did not parse. The file appops_accesses.xml stood beside or instead of appops.xml on Android 14 and 16 [14].

The dump changes as well. Figure 4 compares the five bug reports in the App Ops study.

The two Android 10 reports print few uid-level lines, no attribution-tag lines and no proxy text, where the Android 15 and 16 reports print the proxy text on every such line [15]. Each version in this sample comes with a different manufacturer, so the figure cannot separate a version effect from a vendor effect [18].

Shape also changes with a schema. On Android 16, a Samsung media database no longer had a location table but kept a view over it, so a reader's address join failed. The error went to the log and the report showed an empty table. On four images the unfixed reader returned 0, 0, 0 and 3 rows where the fixed reader returns 5,523, 215, 4,582 and 1,450 [16].

Reading by version

A reader cannot avoid the differences, but it can avoid hiding them. The Lab's reports point to six habits [17].

• Find the format from the first bytes, not from the file name.
• Keep paths and key names per release, and say which release a read assumed.
• Open a database with its write-ahead log file, and state that you did.
• Match a time to a window when one form stores an aggregate.
• Report four states, not two: a value was read; the key is absent from a file that was read; the file is absent; the file could not be read.
• Add a fifth: this version was not tested.

Open-source readers for part of this exist. The bug report App Ops readers are merged in ALEAPP (pull request 1816) and the history database readers are in review (pull request 1786). The media database fix is pull request 1779.

What this does not prove

Reproduce

1. On a test phone you own, take a full file system extraction, or generate a bug report, and write down the Android version.
2. List the settings files under data/system/users/<u>/ and read the first four bytes of each. 41 42 58 00 means ABX.
3. Look for the permission and Wi-Fi files at the paths in Figure 3 for your version.
4. For App Ops, list the history database files and appops_accesses.xml, and look for the App Ops service dump in a bug report. Write down which forms your phone has.
5. Write down what you could not check, and why that does not prove anything.

Sources

Every number and claim above comes from a Lab Technical Report. LAB-TR-0003 is on Zenodo (10.5281/zenodo.23717924, all versions). LAB-TR-0006 is on Zenodo (10.5281/zenodo.23717928, all versions). LAB-TR-0017 and LAB-TR-0019 are available on this site (no DOI yet). Pages: LAB-TR-0003, LAB-TR-0006, LAB-TR-0017, LAB-TR-0019.

Version history and corrections

Corrections log

No corrections have been published for this article. Corrections to any article are listed on Corrections, with the version they apply to.

Related