Guide · 9 min read
Google Fit is deprecated: migrating to Health Connect
Google Fit APIs are deprecated in favour of Health Connect. What actually changes — server-pull becomes device-push — and how to migrate without losing history.
Published · Updated · By the WearLink engineering team
If your Android health product reads step counts or workouts from the Google Fit APIs, you are on a deprecation clock. Google has moved Android health data to Health Connect, and Fit is being retired. The migration is not difficult, but it is not a find-and-replace either, because the two are architecturally different in a way that changes your backend, not just your app.
The change that actually matters
Google Fit had a REST API. Your server could hold an OAuth token for a user and pull their step count without the phone being involved at all. That is the part that is going away, and no equivalent replaces it.
Health Connect is an on-device data store. Data can only be read by an app running on the user’s phone, with permissions granted on that phone. There is no endpoint you can call from a server. Your architecture moves from server pulls when it wants to device pushes when it can.
| Google Fit (deprecated) | Health Connect | |
|---|---|---|
| Where it runs | Google's servers | On the user's device |
| Server-side read | Yes, via REST | No, impossible by design |
| Android app required | No | Yes |
| Auth model | OAuth token held by your server | On-device permission grants |
| Data freshness | Whenever you poll | When the app runs and syncs |
| Historical backfill | Query any range | Limited by on-device retention |
The four things that bite people
Historical data does not come with you
Health Connect holds a limited on-device window. If you need years of history you must export it from Fit before the API is gone. This is the only genuinely time-boxed item on the list. Everything else you can do later, but data you did not export is simply lost.
Denied permissions look like empty data
Health Connect does not distinguish between “the user said no to heart rate” and “there is no heart rate data”. Both return nothing. If you show the user an empty chart without checking grant state, your support queue fills with people who think the app is broken.
Health Connect is not always present
Availability depends on Android version and whether the user has it set up. Your app needs a real path for devices where it is missing, not a crash.
Duplicates arrive from every direction
Health Connect aggregates other apps, so a single run can reach you from Health Connect and again from Strava or Fitbit directly. Without a deduplication rule your users’ weekly totals are wrong in a way they will notice.
A migration order that works
- Export historical Fit data first. This is the only irreversible step. Do it before anything else, even if the rest of the migration is months away.
- Add Health Connect reads alongside Fit. Run both, write to the same backend records, and compare. You want to see where the two disagree while you still have both.
- Build the permission-state UI. Check grant state explicitly and tell the user which types are denied. Do not infer it from empty results.
- Add a deduplication rule. Decide which source wins when the same workout arrives twice, and apply it consistently rather than per feature.
- Cut over and remove the Fit path. Once the comparison in step 2 is quiet, drop Fit.
Where an aggregator helps, and where it does not
What it can do is take the on-device records your app reads and normalise them into the same schema as your cloud providers, so a step count from Health Connect and one from Fitbit are the same object in your backend.
WearLink’s Kotlin SDK (in preview) does that read-and-push, and the resulting records land beside Fitbit, Oura and Strava data with provider-priority deduplication applied. If you do not have an Android app at all, skip Health Connect entirely and use the cloud providers, which are readable server-side over OAuth. The Health Connect integration page covers the SDK in detail.