Google Health Connect Integration: Android Health Data for Developers

Open Wearables Team · May 5, 2026 · 7 min read

Key Takeaways

Google Health Connect is an on-device data store, not a cloud API. Your Android app must read data on the device and upload it to your backend.
Health Connect aggregates data from multiple Android sources: Wear OS, Samsung Galaxy Watch via Samsung Health, Fitbit on supported devices, Garmin Connect app, and third-party fitness apps.
Permissions are granted per data type at the Android OS level, not via an OAuth consent screen. Users must approve each data type your app requests.
Change tokens enable efficient incremental sync by identifying which records have been added, modified or deleted since your last read.
WorkManager is the recommended approach for reliable background data sync from Health Connect on Android.
Open Wearables supports a companion upload architecture where your Android app syncs Health Connect data to the Open Wearables backend.

Introduction

Google Health Connect is Android's answer to Apple HealthKit: a system-level health data hub that aggregates biometric data from multiple apps and wearables into a single on-device store. Any Android app can write health data to Health Connect, and any app with appropriate permissions can read it.

The practical consequence for developers is significant. A user with a Samsung Galaxy Watch, a Fitbit, and a Garmin watch (used for different activities) can have all their health data aggregated in Health Connect on their phone. Your application can read steps, sleep, heart rate, workouts and other metrics from all these sources through a single local API without managing separate cloud integrations for each wearable.

The architectural catch is that Health Connect has no server-side API. There is no way to query a user's Health Connect data from your backend without an Android app intermediary. Your Android app must read the data locally and upload it to your backend. This is a fundamentally different integration pattern from server-side wearable APIs like Garmin or Polar.

What Health Connect Provides

Health Connect organizes data into record types. Each record type has a defined schema. Available record types include steps, distance, calories (active and basal), heart rate (spot measurements and series), heart rate variability, sleep sessions with sleep stage details, exercise sessions with sport type and segment data, body weight, body fat percentage, oxygen saturation, respiratory rate, blood glucose (if contributed by a connected app), blood pressure, and several dozen others.

Data availability depends on which apps have written to Health Connect on the user's device. A user whose Galaxy Watch syncs through Samsung Health will have Samsung's data in Health Connect. A user with a Garmin watch and the Garmin Connect app may have Garmin workout data in Health Connect if they have enabled the Health Connect integration within the Garmin app.

The source of each record is available in the metadata. Records include a dataOrigin field identifying which app wrote the data. This allows you to filter or prioritize data from specific sources when multiple apps contribute overlapping data for the same time period.

Permissions Architecture

Health Connect uses Android's runtime permission system. Each data type your app reads or writes requires a specific permission declared in your AndroidManifest.xml and requested at runtime. For example, reading heart rate requires android.permission.health.READ_HEART_RATE and reading sleep data requires android.permission.health.READ_SLEEP.

Permission requests are shown to the user as a Health Connect consent dialog that lists each data type your app is requesting. This is separate from the standard Android runtime permissions flow. Only request the data types you actually use: users and app stores scrutinize broad health data permission requests.

Permissions can be revoked by the user at any time through the Health Connect app or Android settings. Check permission status before each read operation rather than assuming previously granted permissions are still valid. Handle PermissionException gracefully by updating your UI to show which data types are unavailable and providing a path to request permissions again.

Change Tokens for Incremental Sync

Health Connect provides a change token mechanism that enables efficient incremental syncing. A change token represents a point in time in the Health Connect data store. When you first sync, you request a change token after your initial data read. On subsequent syncs, you provide the previous change token and Health Connect returns only the records that have been added, modified or deleted since that token was issued.

Change tokens are per data type. Maintain separate change tokens for each record type you sync (steps, heart rate, sleep sessions, exercise sessions, and so on). Store change tokens in your application's local database alongside the last sync timestamp. If a change token expires (Health Connect expires tokens after 30 days), fall back to a time-range query and obtain a fresh change token.

The change token approach is strongly preferred over time-range polling because it avoids re-reading data that has not changed, which reduces battery usage and sync latency on the device.

Background Sync With WorkManager

Health Connect data should be synced to your backend in the background, not only when the user opens your app. WorkManager is the recommended approach for background work on Android. It handles constraints (run only when the device has network connectivity), battery optimization, and retry logic automatically.

Define a PeriodicWorkRequest to run your sync job on a schedule (every 15 minutes is the minimum WorkManager interval; once per hour is practical for most health apps). Your Worker class reads from Health Connect using the stored change tokens, serializes the data, and uploads it to your backend API.

            val syncRequest = PeriodicWorkRequestBuilder<HealthConnectSyncWorker>(
    1, TimeUnit.HOURS
)
    .setConstraints(
        Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .build()
    )
    .setBackoffCriteria(
        BackoffPolicy.EXPONENTIAL,
        WorkRequest.MIN_BACKOFF_MILLIS,
        TimeUnit.MILLISECONDS
    )
    .build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "health_connect_sync",
    ExistingPeriodicWorkPolicy.KEEP,
    syncRequest
)

In the Worker class, call the Health Connect SDK's readRecords method for each record type using the stored change token. Serialize the results as JSON and POST them to your backend endpoint. On a successful upload, store the new change token returned by Health Connect. On failure, let WorkManager retry the work using the exponential backoff policy.

Handling Multiple Data Sources

Health Connect's aggregation of multiple apps creates a data deduplication challenge. If the user has both Samsung Health and a generic step counter app writing step data to Health Connect, you may receive overlapping step records for the same time periods. Use the dataOrigin field to implement source prioritization for your application.

Define a source priority list for each record type. For exercise sessions, prefer the data from the wearable device app (Samsung Health, Garmin Connect) over generic third-party apps. For daily steps, prefer the dedicated wearable source. For sleep, prefer the most detailed sleep staging data source.

Alternatively, use Health Connect's built-in aggregation queries, which aggregate data across sources for compatible record types (total steps, aggregate calories). This is simpler but provides less granular information than reading individual records.

Open Wearables and Health Connect

Open Wearables supports a companion Android app architecture for Health Connect integration. Your Android app reads Health Connect data using the patterns described above and uploads it to the Open Wearables backend API. The backend normalizes the incoming Health Connect data to the same schema used for server-side providers like Garmin, Polar and Whoop.

This means Health Connect users and Garmin users in your application produce normalized health summaries through the same backend pipeline. Self-hosted, MIT licensed, no per-user fees.

FAQ

Does Health Connect work on all Android devices?

Health Connect requires Android 9 (API level 28) or higher. On Android 14 and higher, Health Connect is integrated into the operating system. On Android 9-13, it is available as a standalone app from the Google Play Store. Users on affected older Android versions need to install Health Connect separately. Build a check into your app that verifies Health Connect availability and guides users to install it if needed.

How far back does Health Connect data go?

Health Connect retains data for 30 days by default. Some devices and Android versions may retain data longer. Do not assume historical data beyond 30 days is available. For initial onboarding, query the full available window using a time range from 30 days ago to now and store the results in your backend.

Can I write data back to Health Connect from my app?

Yes. Health Connect supports both read and write operations. Your app can contribute data to Health Connect for the record types where you hold write permissions. Write permissions require separate permission declarations and separate user consent from read permissions.

Does Google Play require special review for Health Connect apps?

Yes. Apps that read health data from Health Connect are subject to Google Play's sensitive data policy. You must complete a Health Connect permissions declaration during app submission, explaining your data usage. Apps that handle health data may require an extended review. Start the submission process early and have your privacy policy clearly address Health Connect data usage.