Reading the Android Health Connect store

Summary

This contribution adds healthConnect.py, thirteen artifacts for the Android framework Health Connect store: healthconnect.db under system_ce/<user>/healthconnect on Android 14 and later, and the health-permissions-first-grant-times.xml file beside it. Three artifacts cover the registered apps, the store's preferences and the first time each package was granted health permissions. Ten read the records and logs: activity, measurements, heart rate samples, sleep sessions and stages, exercise sessions and route points, and the access, read-access and change logs.

When the pull request was filed, only the first three had rows on real data: every record table was empty on all four Android 16 images, so the ten record artifacts had been checked against the AOSP schema and a synthetic database. The artifact notes in the merged change later add two research stores from other Android versions, on which the record artifacts matched the table row counts. Both statements are listed in the sources table.

The issue

Health Connect is where Android keeps the steps, heart rate, sleep and exercise that fitness apps write, and where other apps can read them with permission. For an examiner it can answer which health apps were registered, what they recorded and which apps read the data. ALEAPP could not read it.

Without a reader, an examiner who wanted those answers opened a SQLite database with many tables by hand. The store has no single table. It has one table per record type, series and session tables joined to a parent row by a key, and logs of who read and wrote. The schema also changes between versions: the stores we examined were versions 12, 20, 23 and 26, and a column present in one is absent in another.

The empty case needs care too. A store can exist and hold no records, and on all four Android 16 images it did. That is not an uninformative result, because the apps and the permission times still show what was registered, but it is not evidence that the person recorded nothing, and it does not show what an app did before the store was reset or trimmed. Figure 1 shows where the data sits.

The essence

Each artifact reads one part of the store and keeps the values the writing app supplied. Numbers that the Android source names, such as record types, exercise types, sleep stages and recording methods, are shown as the stored number followed by the AOSP name; a number the source does not name is shown as stored. Times are converted from milliseconds to UTC with the zone offset the app supplied, and units follow the AOSP record classes.

Our methodology

We began with the schema. We listed the tables of each store and, independently of the parser, listed the non-empty ones. On the four Android 16 images that showed only the application and preference tables and, on the version 26 stores, device and data-source tables. The parser reads each database's schema at run time and substitutes NULL for any column the version lacks, so older stores read without an error.

Names and units came from the AOSP HealthFitness module, at a commit the notes cite. We did not guess units: distance and elevation are in metres, energy in calories (the unit of the AOSP energy class, not kilocalories), hydration in litres. The notes warn that distance and calorie totals can overlap between apps, and that a value is what the writing app supplied, so manual entry or an import from another source is a possibility the examiner must rule out with the recording method, the app and the device columns.

The checks were layered. For the three artifacts that had data on the four images, row counts equalled independent counts: Apps 2, 2, 3 and 3, Preferences 7, 7, 9 and 9, First Grant Times 1, 2, 2 and 1. A second Android user at system_ce/10, built from the real files, doubled all three exactly. The record artifacts were exercised on a synthetic database built by a fixture script with invented values, including two users. In the merged notes, on two other research stores the activity artifact reported 68,617 and 79,052 rows, equal to the rows of the tables it reads, and for every steps row the start time and count equalled the stored values. Thirteen new test cases brought the suite to 145 with no failure. The storage-view mode skipped 90 cases, because this store sits under system_ce, not data/data, so the harness has nothing to restage.

Not everything is read. Speed records and skin temperature records exist in the research stores and no Health Connect artifact reads them; nor do reproductive health, medical record and the version 26 device tables. Figure 2 shows the steps and Figure 3 shows where each artifact has been seen with data.

One defect found on real data shows why the real stores mattered. On the two version 26 stores the first-grant file holds a shared-user element and no package element, so the first version of the artifact returned no rows and raised no error. It was found by running the artifact on those stores. The artifact now reads both element types and adds an Entry Type column, and a synthetic case and a unit test cover both. Figure 4 shows the mechanism with an invented file.

The value

With the module an examiner can answer, from the report, which apps are registered with Health Connect and when each package was first granted permission, and, where the store holds records, what was recorded, over which intervals, by which app, with which recording method and on which device. The access and change logs add which app read, wrote or deleted which record types and when. These are indicators of what the store holds. They are not evidence of what the person did.

The limits are specific. A session is what the writing app reported, so a sleep session does not establish that the person slept. A route point is a position the app reported and does not by itself show where the device was. A log row records an access the platform logged, but the retention period is not established and the store trims the change log, so a missing row is not evidence that nothing happened. The record artifacts were verified on two research stores and not on a populated Android 16 store, and the pull request asks anyone with a populated store to check the units before relying on them. Health data is among the most sensitive a phone holds; the Lab reports counts and structure only.

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 is one of five case studies in Lab Technical Report LAB-TR-0006, Section 7.1 and Table 8, which records the apps, preferences and first-grant counts, the empty record tables on all four images, and the ten record artifacts as validated on synthetic data only at the time of that report. The report also lists the first-grant defect among the defects that were reproduced with a synthetic file, fixed and covered by a test.

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