Google Health and Health Connect: a bridge for Android

A smartphone with a fitness app Photo: Kristin Hardwick · StockSnap (CC0 1.0), via Openverse

The Apple world was the easier one for us. One ecosystem, one interface, one contract via HealthKit. Android is different. There isn't the one scale, the one fitness band, the one app that collects all health data. There's Samsung Health, there's Fitbit, there's Google Fit, there are dozens of smaller manufacturer apps — and every one of them claims to be the central store for its users' vitals.

This week is about how Xircuit still gets a single, reliable view of Android health data, without maintaining a separate build for every manufacturer. The short answer has two parts: Health Connect for everything that lives on the device, and a server-side poller for everything that lives in the cloud. The longer answer is the rest of this post.

Health Connect as the common denominator

Google built something with Health Connect that Apple has had with HealthKit for a long time: a device-wide, cross-manufacturer store for health and fitness data. Apps write their measurements into it, other apps read them back out with consent. For us, that's the decisive abstraction. We no longer need to know whether a step value came from a Samsung band, a third-party running app, or the phone itself — it arrives through the same interface.

That has a pleasant consequence I underestimated at the start: Samsung Health and many other Android sources reach us this way with no dedicated build at all. We write no Samsung-specific code, we integrate no proprietary SDK, we sign no separate partner agreement. As long as an app writes its data to Health Connect and the user grants consent, those values are visible in Xircuit. Health Connect is thus less an integration and more a landing strip that the entire Android ecosystem can touch down on.

What lives in the cloud has to be fetched

Health Connect, however, only covers what actually lands on the device. Two important sources don't do that reliably: Fitbit and the Pixel watches. Their data lives primarily in Google's cloud, and the path through local storage is either patchy or not provided for at all. Relying on the device alone would have meant leaving behind exactly the users who wear one of the most popular wearables around.

That's why there's an additional server-side OAuth poller for Fitbit and Pixel, which we internally just call Google Health. It holds a refresh token per user, periodically logs in to the respective cloud API, and fetches the new measurements. This runs as its own worker in our Aspire setup, decoupled from the app, with the usual building blocks: retry with backoff, a time window per query so we don't re-pull the entire history on every run, and idempotency on write, so a data point fetched twice doesn't produce a duplicate entry. The user notices none of this — they connect their account once, and after that the values flow in the background.

A key that now knows the source

Once both paths — device and cloud — could deliver the same metrics, a question came up that hadn't existed before: where does a particular hourly value actually come from? If the same step count comes in via Health Connect and via the Fitbit poller, we mustn't count it twice, and in reporting we want to be able to trace which source delivered it.

Health Connect Phase 1 is now complete and verified on real devices. The most important structural change involved was a migration that pulled the source designation into the hourly key of the metrics. Previously, an hourly figure was identified solely by user, metric type, and timestamp; now the origin is part of that same key. That sounds like a small change, but it had pleasant consequences: the same hour can now carry a value from the device and one from the cloud in parallel, without one overwriting the other, and deduplication becomes a clean decision at the key level instead of downstream guesswork.

Connected data points as a symbol for synchronization Photo: Rawpixel (CC0 1.0), via Openverse

The hurdle before release: Google's health declaration

With health data, technology is rarely the hardest part. Google Play requires a one-time health declaration for all permissions from the health.* namespace before any Android release can be approved at all. This isn't a form you fill out on the side: you have to declare which data types the app reads, what for, and how the processing fits with Play's policies for sensitive data. As long as this declaration isn't considered complete, Google blocks publication of the affected version.

I mention this explicitly because it's the kind of gate that silently tips over a schedule. The code can be finished, tested, and device-verified — and still nothing goes live until the declaration is in place. Anyone planning an Android health integration should schedule this step early rather than push it to the end as a formality.

What's still open before we roll out broadly

The poller part — Google Health for Fitbit and Pixel — is deliberately still sitting behind a flag on our end. Before we release it broadly, several things need to be settled that have nothing to do with our code and are nonetheless mandatory. The OAuth consent screen must be configured with the correct scopes, the redirect URIs must be registered, and the complete flow must be verified by Google. That's the standard path every app takes when it accesses a user's cloud health data on their behalf.

Another point only kicks in at scale: once more than a hundred users are using the integration, Google requires a CASA assessment — a security review following a defined catalog. That's not a reason to start small, but it is a reason not to trigger the review only once the threshold has already been reached. Until all of that is in place, the poller stays in beta behind the flag, while Health Connect is already usable as the device-side path. This separation lets us ship the simpler, device-verified part without waiting on the longer approval loops of the cloud integration.

Why this two-track approach was the right call

In hindsight, the most important decision was not to treat Android as a single problem. The reflex would have been to build a dedicated connection for every major manufacturer — expensive, fragile, and endless to maintain. Instead, we use what the ecosystem already provides: Health Connect bundles the device sources, the poller specifically fills in the two important cloud sources, and the hourly key extended with origin keeps both streams cleanly apart. Two mechanisms, clearly separated responsibilities, one shared data model underneath.