Why Is Google Health Connect Returning No Data?

Your Android app calls HealthConnectClient.readRecords(...), gets no error worth acting on, and the list comes back empty. The first suspect is not your code at all: no source app is writing that record type into Health Connect, so there is genuinely nothing to read. Health Connect is an on-device store, not a data source — something has to populate it first: another app, or for steps, distance and active calories burned, Health Connect's own on-device tracking. The quick check: open Health Connect, go to Data and access, and confirm the exact type you are reading has entries; App permissions shows which apps are connected.

If a writer exists and reads are still empty, work down the ranked causes below. The other frequent culprits are a per-type read permission you never actually got granted (which can surface as a SecurityException), Health Connect not being available on the device (getSdkStatus is not SDK_AVAILABLE), and the default 30-day history window hiding older data. For the iOS equivalent of this problem, see HealthKit returns no data; to re-check your setup end to end, use the Google Health Connect integration guide.

Version note. API names below (HealthConnectClient, getSdkStatus, getGrantedPermissions, TimeRangeFilter, PERMISSION_READ_HEALTH_DATA_HISTORY) match Android's Health Connect Jetpack reference as checked on October 2, 2026; Google announces the 1.1.0 library as stable. Play Console policy specifics change more often than the API — re-check them against Google's publishing guide before you ship.

Most likely causes (ranked)#

1. No source/provider app is writing that record type. Health Connect is empty until an app writes into it. Perfect code plus perfect permissions still returns nothing if no writer exists for that type.
2. The per-type read permission was never granted. Permissions are granular per record type and per direction (read vs write). Google lists SecurityException as the exception for a request that needs a permission you were not granted — easy to miss if a broad catch swallows it.
3. Health Connect is not available (getSdkStatus is not SDK_AVAILABLE). If the SDK reports unavailable or "provider update required," you cannot read anything.
4. The default history window. Without PERMISSION_READ_HEALTH_DATA_HISTORY you see data from up to 30 days before your first permission grant onward — not a rolling last 30 days — so older records simply do not come back.
5. A missing Play Console Health apps declaration. Google says a Play-published app that never declared its Health Connect data types can't get access: its users see an error dialog when they try to link it with Health Connect.
6. A work profile. Google says Health Connect is not supported in work profiles: permissions may appear grantable, but the APIs are not usable and no data is written there.

Step 1: Confirm an app is actually writing that record type#

Before debugging code, rule out the boring answer. On the device, open Health Connect. On Android 14 and later it is part of the system and opens from Settings (under Security & privacy; searching Settings for "Health Connect" is the reliable route, since the menu path varies); on Android 13 and lower it is Settings → Apps → Health Connect. Then choose Data and access, the category (steps, heart rate, sleep, etc.), the data type, and See all entries. If no entries appear there, no reader can ever return data.

Fix: install or enable an app that writes that type, and confirm data lands in the Health Connect data browser before you touch your app again. Health Connect generates steps, distance and active calories burned itself from device sensors — but Google says it starts tracking a type only once some app has been granted read permission for it, and users can switch built-in tracking off per type in Health Connect settings. Native step counting needs Android 14 with SDK extension 20 or later, and Google says those steps are batched to the database no more often than once a minute. Since the June 2026 Health Connect update, those on-device steps are attributed to a device-specific synthetic package name rather than android, so a dataOriginFilter on android alone misses recent ones; Google's read-data guide shows how to get the current device's name with getCurrentDeviceDataSource(). This is the same class of bug as an empty HealthKit store on iOS (HealthKit no data): the platform is a store first, and its built-in tracking covers only steps, distance and active calories.

Step 2: Verify Health Connect is available with getSdkStatus#

Every Health Connect call assumes the platform is present and usable. Call HealthConnectClient.getSdkStatus(context) first and branch on the result — anything other than SDK_AVAILABLE means you cannot read.

when (HealthConnectClient.getSdkStatus(context)) {
    HealthConnectClient.SDK_AVAILABLE -> {
        val client = HealthConnectClient.getOrCreate(context)
        // proceed with reads
    }
    HealthConnectClient.SDK_UNAVAILABLE_PROVIDER_UPDATE_REQUIRED -> {
        // send the user to update Health Connect
    }
    else -> {
        // SDK_UNAVAILABLE — Health Connect not usable on this device
    }
}

If you skip this check you may be calling into a client that will never return data. On Android 13 and lower Health Connect is a Google Play app rather than part of the system, and Google says it needs Android 9 or later with Google Play services, so treat "not available" as a real, common state and route the user to install or update it.

Step 3: Check the read permission is granted (not just declared)#

Declaring a permission in the manifest is not the same as having it granted at runtime. Read the currently granted set and confirm the exact per-type read permission is present.

val granted = client.permissionController.getGrantedPermissions()
val stepsRead = HealthPermission.getReadPermission(StepsRecord::class)

if (stepsRead !in granted) {
    // permission not granted — launch your permission request flow.
    // Reading now would throw SecurityException.
}

If getGrantedPermissions() does not contain HealthPermission.getReadPermission(<Record>::class) for the type you are reading, request it. A SecurityException on the read is the tell that the permission is either declared-but-not-granted or not declared at all. Remember: uninstalling your app revokes all its Health Connect permissions, so a fresh install starts from zero.

Step 4: Widen the TimeRangeFilter and rule out the 30-day history cap#

If recent data appears but older data is empty (or errors), you are hitting the history window. By default an app can read data from up to 30 days before any permission was first granted. On Android 14+ there is no historical limit reading your own app's data, but a 30-day limit reading other apps' data; on Android 13 and lower the 30-day limit applies to reading any data.

First widen the filter to prove the query itself is not the problem:

val response = client.readRecords(
    ReadRecordsRequest(
        recordType = StepsRecord::class,
        timeRangeFilter = TimeRangeFilter.between(
            Instant.now().minus(365, ChronoUnit.DAYS), // wide window: does ANY data appear?
            Instant.now()
        )
    )
)

If recent records come back but nothing from earlier than 30 days before your first grant ever does, that is the history window, not a bug. Without PERMISSION_READ_HEALTH_DATA_HISTORY, Android's Jetpack reference says reading a single older record by ID (readRecord) throws, while readRecords, aggregate and the other reads just leave the older data points out — so a wide readRecords query returns the recent data and silently stops at the window instead of failing. Declare and request the permission to read further back. Note the window resets from the reinstall date if the user reinstalls your app.

Step 5: Confirm the Play Console health-data declaration for production#

Google's publishing guide describes one failure that only shows up in production: if your app is published on Google Play and released to the public without declaring its Health Connect data types, its users get an error dialog when they try to link it with Health Connect. Every app that uses Health Connect fills in the Health apps declaration in the Play Console, justifying each data type, and files it again whenever the set of types changes — listing every type still in use, not just the new ones.

Confirm the declaration covers every type your release reads. If a type works in a local build but users of the Play release can't connect, suspect the declaration rather than your code. (Checked against Google's publishing guide, last revised March 10, 2026 — Play policy changes, so re-check before you ship.)

Still stuck? Diagnostic checklist#

Run these in order — each rules out one ranked cause:

1. Is anything writing the type? Health Connect UI → Data and access → the specific category shows samples. If empty, install a writer (Step 1).
2. Is Health Connect available? getSdkStatus(context) returns SDK_AVAILABLE, and the app is not running in a work profile (Step 2).
3. Is the read permission granted? getGrantedPermissions() contains HealthPermission.getReadPermission(<Record>::class); no SecurityException on read (Step 3).
4. Is it just old data? Records stop at 30 days before your first grant, however wide the TimeRangeFilter → request PERMISSION_READ_HEALTH_DATA_HISTORY (Step 4).
5. Is production gated? The type works in a local build but Play users can't connect → check the Health apps declaration (Step 5).

If all five pass and reads are still empty, capture the exact record type, the TimeRangeFilter bounds, the granted-permission set, and any SecurityException stack trace before escalating. For a clean-slate re-check of the whole flow, walk back through the Google Health Connect integration guide; if you also ship on iOS, the HealthKit no-data guide covers the Apple-side equivalents.