Google Health und Health Connect: eine Brücke für Android

Ein Smartphone mit einer Fitness-App Foto: Kristin Hardwick · StockSnap (CC0 1.0), via Openverse

Die Apple-Welt war für uns die einfachere. Ein Ökosystem, eine Schnittstelle, ein Vertrag über HealthKit. Android ist anders. Hier gibt es nicht die eine Waage, das eine Fitness-Armband, die eine App, die alle Gesundheitsdaten sammelt. Es gibt Samsung Health, es gibt Fitbit, es gibt Google Fit, es gibt Dutzende kleinerer Hersteller-Apps — und alle behaupten von sich, der zentrale Speicher für die Vitalwerte ihrer Nutzer zu sein.

Diese Woche geht es darum, wie Xircuit trotzdem eine einzige, verlässliche Sicht auf Android-Gesundheitsdaten bekommt, ohne für jeden Hersteller einen eigenen Build zu pflegen. Die kurze Antwort besteht aus zwei Teilen: Health Connect für alles, was auf dem Gerät liegt, und einem serverseitigen Poller für alles, was in der Cloud lebt. Die längere Antwort ist der Rest dieses Beitrags.

Health Connect als gemeinsamer Nenner

Google hat mit Health Connect etwas geschaffen, das Apple mit HealthKit schon lange hatte: einen geräteweiten, herstellerübergreifenden Speicher für Gesundheits- und Fitnessdaten. Apps schreiben ihre Messwerte hinein, andere Apps lesen sie mit Einwilligung wieder heraus. Für uns ist das die entscheidende Abstraktion. Wir müssen nicht mehr wissen, ob ein Schrittwert von einem Samsung-Armband, einer Drittanbieter-Laufapp oder dem Telefon selbst stammt — er kommt über dieselbe Schnittstelle herein.

Das hat eine angenehme Konsequenz, die ich zu Beginn unterschätzt habe: Samsung Health und viele andere Android-Quellen erreichen uns dadurch ganz ohne dedizierten Build. Wir schreiben keinen Samsung-spezifischen Code, wir integrieren kein proprietäres SDK, wir unterschreiben keinen separaten Partnervertrag. Solange eine App ihre Daten nach Health Connect schreibt und der Nutzer die Freigabe erteilt, sind diese Werte in Xircuit sichtbar. Health Connect ist damit weniger eine Integration als eine Landebahn, auf der das ganze Android-Ökosystem aufsetzen kann.

Was in der Cloud liegt, muss man abholen

Health Connect deckt allerdings nur ab, was tatsächlich auf dem Gerät landet. Zwei wichtige Quellen tun das nicht zuverlässig: Fitbit und die Pixel-Uhren. Ihre Daten leben primär in Googles Cloud, und der Weg über den lokalen Speicher ist entweder lückenhaft oder gar nicht vorgesehen. Sich allein auf das Gerät zu verlassen hätte bedeutet, genau die Nutzer im Stich zu lassen, die eines der populärsten Wearables überhaupt tragen.

Deshalb gibt es für Fitbit und Pixel zusätzlich einen serverseitigen OAuth-Poller, den wir intern schlicht Google Health nennen. Er hält pro Nutzer ein Refresh-Token, meldet sich periodisch bei der jeweiligen Cloud-API an und holt die neuen Messwerte ab. Das läuft als eigener Worker in unserem Aspire-Verbund, entkoppelt von der App, mit den üblichen Bausteinen: Retry mit Backoff, ein Zeitfenster pro Abfrage, damit wir nicht bei jedem Lauf die gesamte Historie neu ziehen, und Idempotenz beim Schreiben, damit ein doppelt abgeholter Datenpunkt keinen doppelten Eintrag erzeugt. Der Nutzer merkt von alledem nichts — er verbindet sein Konto einmal, danach fließen die Werte im Hintergrund.

Ein Schlüssel, der jetzt die Quelle kennt

Als beide Wege — Gerät und Cloud — dieselben Metriken liefern konnten, stellte sich eine Frage, die vorher keine war: Woher stammt ein bestimmter Stundenwert eigentlich? Wenn dieselbe Schrittzahl über Health Connect und über den Fitbit-Poller hereinkommt, dürfen wir sie nicht zweimal zählen, und wir möchten in der Auswertung nachvollziehen können, welche Quelle sie geliefert hat.

Health Connect Phase 1 ist inzwischen abgeschlossen und auf echten Geräten verifiziert. Der wichtigste strukturelle Eingriff dabei war eine Migration, die die Quellenangabe in den Stunden-Schlüssel der Metriken eingezogen hat. Vorher war eine stündliche Kennzahl allein über Nutzer, Metrikart und Zeitstempel identifiziert; jetzt ist die Herkunft Teil desselben Schlüssels. Das klingt nach einer kleinen Änderung, hatte aber angenehme Folgen: Dieselbe Stunde kann parallel einen Wert vom Gerät und einen aus der Cloud tragen, ohne dass der eine den anderen überschreibt, und die Deduplizierung wird zu einer sauberen Entscheidung auf Schlüsselebene statt zu nachgelagerter Rätselei.

Vernetzte Datenpunkte als Sinnbild für Synchronisation Foto: Rawpixel (CC0 1.0), via Openverse

Die Hürde vor dem Release: Googles Gesundheits-Deklaration

Technik ist bei Gesundheitsdaten selten der schwierigste Teil. Google Play verlangt für alle Berechtigungen aus dem health.*-Namensraum eine einmalige Gesundheits-Deklaration, bevor überhaupt ein Android-Release freigegeben wird. Das ist kein Formular, das man nebenbei ausfüllt: Man erklärt, welche Datentypen die App liest, wozu sie das tut und wie die Verarbeitung mit den Play-Richtlinien für sensible Daten zusammenpasst. Solange diese Deklaration nicht als abgeschlossen gilt, blockiert Google die Veröffentlichung der betreffenden Version.

Ich erwähne das so ausdrücklich, weil es die Art von Gate ist, die einen Zeitplan lautlos kippt. Der Code kann fertig, getestet und geräteverifiziert sein — und trotzdem geht nichts live, bis die Deklaration steht. Wer eine Android-Gesundheitsintegration plant, sollte diesen Schritt früh eintakten und nicht als Formalität ans Ende schieben.

Was noch offen ist, bevor wir breit ausrollen

Der Poller-Teil, also Google Health für Fitbit und Pixel, steht bei uns bewusst noch hinter einem Flag. Bevor wir ihn breit freigeben, sind mehrere Dinge zu erledigen, die nichts mit unserem Code zu tun haben und trotzdem verbindlich sind. Die OAuth-Zustimmung muss mit den korrekten Scopes auf dem Consent-Screen konfiguriert sein, die Redirect-URIs müssen registriert und der komplette Ablauf muss von Google verifiziert werden. Das ist der Standardweg, den jede App geht, die im Namen eines Nutzers auf dessen Cloud-Gesundheitsdaten zugreift.

Ein weiterer Punkt greift erst bei Skalierung: Sobald mehr als hundert Nutzer die Integration verwenden, verlangt Google ein CASA-Assessment, also eine Sicherheitsprüfung nach einem festgelegten Katalog. Das ist kein Grund, klein anzufangen — aber ein Grund, die Prüfung nicht erst dann anzustoßen, wenn die Schwelle schon erreicht ist. Bis all das steht, bleibt der Poller im Beta-Zustand hinter dem Flag, während Health Connect als geräteseitiger Weg bereits nutzbar ist. Diese Trennung erlaubt uns, den einfacheren, geräteverifizierten Teil auszuliefern, ohne auf die längeren Freigabeschleifen der Cloud-Integration zu warten.

Warum dieser Zweiweg-Ansatz die richtige Wahl war

Rückblickend war die wichtigste Entscheidung, Android nicht als ein einziges Problem zu behandeln. Der Reflex wäre gewesen, für jeden großen Hersteller eine eigene Anbindung zu bauen — teuer, fragil und endlos in der Pflege. Stattdessen nutzen wir das, was das Ökosystem selbst schon bereitstellt: Health Connect bündelt die Gerätequellen, der Poller ergänzt gezielt die zwei wichtigen Cloud-Quellen, und der um die Herkunft erweiterte Stundenschlüssel hält beide Ströme sauber auseinander. Zwei Mechanismen, klar getrennte Zuständigkeiten, ein gemeinsames Datenmodell dahinter.