How to Integrate Google Health Connect (2026)

If you also need iOS, Health Connect is the Android half of a two-platform job — see Apple HealthKit vs. Google Health Connect for how the two compare, because you integrate each SDK natively and there is no shared endpoint between them. Health Connect's Play Console gate, and every page on this site that covers it, are collected in the Health Connect API overview. Coming from Google Fit? The reading path for getting off Google Fit orders this guide with the shutdown timeline, the migration plan and the empty-read fix.

What you'll need#

• An Android app targeting a reasonably recent SDK. Google's guide says the SDK supports Android 8 (API 26) and up, but Health Connect itself needs Android 9 (API 28) or later: on Android 14 and later it is part of the platform, and on Android 13 and lower it is a separate app the user installs from the Play Store.
• Health Connect available on the device. Your code should check availability and route the user to install or update it if it is missing or out of date.
• The connect-client Jetpack dependency (add it to your module's build.gradle).
• A Play Console Health apps declaration listing every data type you read or write. This is a publishing requirement — plan for it, and note Google says the declaration may be reviewed again when you submit a new app version.

Verify the library version. The Jetpack library updates frequently. Pin whatever the current stable (or intended alpha) release is from the official docs rather than copying a version string from any tutorial, including this one. When this page was checked on October 2, 2026, Google announced 1.1.0 as the stable release and its get-started guide pinned 1.2.0-alpha06.

// build.gradle (module) — check the docs for the current version
dependencies {
    implementation "androidx.health.connect:connect-client:<latest-version>"
}

The strings you will paste#

These are the manifest permissions for the data this guide reads and writes. Each description is copied verbatim from Android's HealthPermissions reference, and the pairing of record type to permission comes from Android's Health Connect data types list; both were fetched on October 2, 2026.

In Kotlin you request the same four as HealthPermission.getReadPermission(StepsRecord::class), HealthPermission.getWritePermission(StepsRecord::class), HealthPermission.PERMISSION_READ_HEALTH_DATA_HISTORY and HealthPermission.PERMISSION_READ_HEALTH_DATA_IN_BACKGROUND. Android's Jetpack HealthPermission reference adds that the history and background permissions depend on the version of Health Connect installed on the device, so check getFeatureStatus (on healthConnectClient.features) with HealthConnectFeatures.FEATURE_READ_HEALTH_DATA_HISTORY or HealthConnectFeatures.FEATURE_READ_HEALTH_DATA_IN_BACKGROUND before requesting either.

Step 1: Declare your permissions in the manifest#

Every health data type you touch is its own permission. Declare each one in AndroidManifest.xml. If you need history older than the default window (covered in Step 5), declare that permission too.

<!-- AndroidManifest.xml -->
<uses-permission android:name="android.permission.health.READ_STEPS"/>
<uses-permission android:name="android.permission.health.WRITE_STEPS"/>
<!-- Only if you need data older than ~30 days: -->
<uses-permission android:name="android.permission.health.READ_HEALTH_DATA_HISTORY"/>

At runtime you refer to these same permissions as typed strings derived from the record class, not raw manifest names — for example HealthPermission.getReadPermission(StepsRecord::class). Keep the manifest list and your runtime set in sync: Google's get-started guide says every permission in your request set must be declared in the manifest first, and that the manifest list should match the data types you declare in the Play Console.

Step 2: Check availability and get the client#

Never assume Health Connect is installed. Call HealthConnectClient.getSdkStatus(context) and compare it against HealthConnectClient.SDK_AVAILABLE. Only then create the client with HealthConnectClient.getOrCreate(context). If the SDK is unavailable, send the user to install or update the Health Connect app.

import androidx.health.connect.client.HealthConnectClient

val status = HealthConnectClient.getSdkStatus(context)
val healthConnectClient =
    if (status == HealthConnectClient.SDK_AVAILABLE) {
        HealthConnectClient.getOrCreate(context)
    } else {
        // SDK_UNAVAILABLE or SDK_UNAVAILABLE_PROVIDER_UPDATE_REQUIRED —
        // prompt the user to install or update Health Connect, then stop.
        null
    }

Step 3: Request permissions at runtime#

Build the set of permissions you need as typed strings, then request them through the Health Connect permission contract. The health permissions carry Android's "dangerous" protection level, but you don't request them with the generic runtime-permission API: Google's guide uses PermissionController.createRequestPermissionResultContract() with an Activity Result launcher (or rememberLauncherForActivityResult in Compose), which displays the Health Connect permissions screen. The callback hands you the set of granted permissions, so you check whether it contains everything you asked for.

import androidx.health.connect.client.PermissionController
import androidx.health.connect.client.permission.HealthPermission
import androidx.health.connect.client.records.StepsRecord

val permissions = setOf(
    HealthPermission.getReadPermission(StepsRecord::class),
    HealthPermission.getWritePermission(StepsRecord::class)
)

// Compose example
val requestPermissions = rememberLauncherForActivityResult(
    contract = PermissionController.createRequestPermissionResultContract()
) { granted ->
    if (granted.containsAll(permissions)) {
        // Proceed — every requested permission was granted.
    } else {
        // User denied one or more. Degrade gracefully; do not re-prompt in a loop.
    }
}

// Launch when the user taps "Connect":
// requestPermissions.launch(permissions)

Note the difference from HealthKit here: Health Connect does tell you which permissions were granted, so you can branch on the actual result instead of guessing.

Step 4: Read the user's data#

With permission granted, read records inside a coroutine using readRecords(ReadRecordsRequest(...)), scoped by a TimeRangeFilter. Every read returns a list of typed record objects.

import androidx.health.connect.client.request.ReadRecordsRequest
import androidx.health.connect.client.time.TimeRangeFilter
import java.time.Instant

suspend fun readSteps(start: Instant, end: Instant): List<StepsRecord> {
    val client = healthConnectClient ?: return emptyList()
    val response = client.readRecords(
        ReadRecordsRequest(
            StepsRecord::class,
            timeRangeFilter = TimeRangeFilter.between(start, end)
        )
    )
    return response.records
}

For a step total, prefer aggregate() with StepsRecord.COUNT_TOTAL over summing raw records yourself. Multiple apps can write steps for the same window, and summing raw reads counts overlapping sources twice; Google says the aggregation API "contains logic to handle duplicate records."

import androidx.health.connect.client.request.AggregateRequest

suspend fun readStepTotal(start: Instant, end: Instant): Long {
    val client = healthConnectClient ?: return 0L
    val response = client.aggregate(
        AggregateRequest(
            metrics = setOf(StepsRecord.COUNT_TOTAL),
            timeRangeFilter = TimeRangeFilter.between(start, end)
        )
    )
    return response[StepsRecord.COUNT_TOTAL] ?: 0L
}

Step 5: Handle the 30-day history limit#

By default, a freshly granted app can read only data from up to 30 days before the first permission grant. Android's Jetpack reference spells out what happens past that line: reading a single older record by ID (readRecord) throws, while readRecords, aggregate and the other reads simply leave the older data points out. To read older history you must request the dedicated history permission: HealthPermission.PERMISSION_READ_HEALTH_DATA_HISTORY in Kotlin, android.permission.health.READ_HEALTH_DATA_HISTORY in the manifest (both from the table above, checked against Android's reference on October 2, 2026). This is separate from the background-read permission, which controls whether you can read while your app is backgrounded.

One more sharp edge: reinstalling your app resets the 30-day window, so a returning user's deep history becomes unavailable again until they re-grant (and you hold the history permission). Design onboarding so a user without the history permission still gets a useful recent view.

Step 6: Complete the Play Console declaration and ship#

Before your app can be published with Health Connect access, you must fill out the Health apps declaration in the Play Console, listing every data type you read and write and justifying each. This is a policy gate, not a formality: Google says not to request types your user-facing features don't need, and an app published without declaring its types leaves users facing an error dialog when they try to connect it to Health Connect. Do this early — Google notes the declaration may be reviewed again when you submit a new app version, and must be refiled whenever your set of data types changes.

Production notes to plan for:

• Availability drift. On Android 13 and lower users can uninstall the Health Connect app (on Android 14 and later it is part of the system and can't be uninstalled), and on any version they can revoke a permission at any time — Google's guide says to check permissions every time before using them. Re-check getSdkStatus and handle empty or error responses on every read, not just at first launch.
• Grant the minimum. Request only the record types your feature needs; Google's publishing guide asks for the minimum data types and a valid use case for each.
• Data types are typed classes. StepsRecord is one of 42 record types in Google's data-types table (HeartRateRecord, SleepSessionRecord, TotalCaloriesBurnedRecord, and more). Each read and write permission is per-class, so scope your request set deliberately.
• Backgrounded reads need their own permission. If you sync in the background, add android.permission.health.READ_HEALTH_DATA_IN_BACKGROUND (in the table above) on top of your data-type permissions, and check the feature status before you request it.

Once step and workout data is flowing, wiring it into a live tracking experience is the next step — add AI workout tracking on Android with Kotlin walks through turning that data (plus on-device pose tracking) into rep counting and form feedback. For the broader landscape of device and health-data sources, see the wearable data APIs overview.