Google Health Connect integration for Android developers

Key Takeaways

• Google Health Connect is a local, on-device platform, not a cloud API. Integration requires an Android SDK installed in the user's app.
• Open Wearables Android SDK handles the full google health connect integration lifecycle: permissions, WorkManager background sync, token refresh, and encrypted credential storage.
• Health Connect covers 30+ data types across all Android 10+ devices, including HRV, VO2 max, multi-stage sleep, blood glucose, blood pressure, and hydration.
• Your backend never touches Health Connect directly. After sync, data is available through standard REST endpoints in canonical units.
• On Android 14+, Health Connect comes pre-installed. On Android 10-13, users need to install it from the Play Store.
• Open Wearables is MIT-licensed with no per-user fees.
• You do not embed credentials in the mobile app. The SDK authenticates against your backend using tokens generated server-side.

Why Google Health Connect Integration Is Not Like Other OAuth Flows

Most health and fitness APIs follow a familiar pattern: redirect the user to a consent screen, receive an authorization code, exchange it for tokens, and start making API calls from your backend. Google Health Connect does not work this way.

Health Connect is a local data platform that lives on the Android device. It was designed with on-device privacy in mind: data never leaves the device through Health Connect's own mechanisms. If you want it in your backend, your code must run on the device and push it there explicitly.

Practical consequences: there is no server-to-server API, permissions are granted on the device (not in a browser), background sync needs to survive app restarts using WorkManager, and you handle all of this before your backend sees a single data point.

Open Wearables handles that entire layer for google health connect integration.

Health Connect vs Samsung Health: When to Use Which

Health Connect: Works on all Android 10+ devices, 30+ data types, pre-installed on Android 14+. Provider ID: "google".

Samsung Health: Limited to Samsung devices, 20+ data types. Provider ID: "samsung".

For most apps targeting a general Android audience, Health Connect is the right choice. Open Wearables supports both through a unified interface, and you query the same REST endpoints regardless of which provider the user connected.

What Open Wearables Android SDK Does for You

Without Open Wearables, google health connect integration involves: adding the Health Connect SDK, building a permission request flow for each data type, writing WorkManager sync jobs with resume support, normalizing Health Connect formats, managing token refresh, and storing credentials securely.

With Open Wearables, you add one dependency and call three SDK methods.

The SDK internally: maps Open Wearables type IDs to Health Connect data type constants, runs background sync through WorkManager with resumable sessions, stores credentials in EncryptedSharedPreferences, handles 401 responses with automatic token refresh, and converts all data to canonical units (bpm, meters, Celsius, UTC).

Backend Setup: Generating Tokens

            POST /api/v1/users/{user_id}/token
          

Returns access_token and refresh_token. Pass these to the Android client. Never embed app_id or app_secret in the mobile app.

Android SDK: Installation and Setup

Add the dependency:

            // settings.gradle.kts
maven { url = uri("https://jitpack.io") }

// build.gradle.kts
implementation("com.github.the-momentum:open-wearables-android-sdk:0.5.0")
          

Requirements: minSdk = 29, compileSdk = 36, Kotlin 2.1.0+.

Initialize in your Application class:

            OpenWearables.init(context = this, baseUrl = "https://your-backend.example.com")
          

Sign in and select the Health Connect provider:

            sdk.signIn(accessToken = accessToken, refreshToken = refreshToken)
sdk.selectProvider("google")

sdk.requestAuthorization(
    types = listOf("steps", "heartRate", "sleep", "oxygenSaturation", "vo2Max", "bloodGlucose")
)
          

Start background sync:

            sdk.startBackgroundSync(syncDaysBack = 30)
          

Reading Data After Sync

            GET /api/v1/users/{user_id}/timeseries
GET /api/v1/users/{user_id}/events/workouts
GET /api/v1/users/{user_id}/events/sleep
          

These endpoints return data in the canonical normalized format regardless of source provider.

Android Version Considerations

Android 14+: Health Connect is pre-installed. The permissions dialog appears as part of your app's normal flow.

Android 10-13: Health Connect must be installed from the Play Store. Detect availability and prompt users to install it if not present using HealthConnectClient.getSdkStatus().

Quickstart

            git clone https://github.com/the-momentum/open-wearables
cd open-wearables
docker compose up -d
          

API at http://localhost:8000. Auth via X-Open-Wearables-API-Key. MIT license, $0 per user.

See Related Articles

• How to access Google Health Connect data in your backend
• Google Health Connect integration: Android health data for developers
• How to integrate Apple Health data into your app
• How to sync wearable data from multiple devices
• How to normalize wearable data across providers

FAQ

Does Health Connect require an internet connection or a Google account?

No. Health Connect is an on-device platform. It does not require a Google account, and health data does not pass through Google's servers.

Do I need to handle Health Connect permission changes after initial setup?

Yes. Users can revoke individual permissions at any time. You should handle cases where sync fails due to missing permissions and present the requestAuthorization() flow again when appropriate.

What happens if the user does not have Health Connect installed on Android 10-13?

Health Connect will not be available. Use HealthConnectClient.getSdkStatus() to detect availability and deep-link to the Play Store listing.

Is the data synced in real time or on a schedule?

Sync runs on a schedule managed by WorkManager. It is not real-time. WorkManager respects Android's battery optimization policies. For most health use cases, periodic batch sync is appropriate.

Can I request only specific data types instead of all 30+?

Yes. The requestAuthorization() call takes an explicit list of type IDs. Request only the types your app actually uses to minimize friction and avoid Play Store review issues.