Open Wearables 0.3: Android support, Google Health Connect, Samsung Health

The most interesting health products being built right now share a pattern: they don't just display wearable data, they reason over it. AI coaching that adjusts training load from last night's HRV. Recovery apps that explain why readiness dropped and what to do about it. Longevity tools that surface correlations across months of sleep, activity, and body metrics. All of them need a reliable, consistent stream of physiological data from wherever users track it.

Open Wearables 0.3 is available on GitHub. This is the first stable release in the 0.3 line, consolidating everything introduced since 0.2.2. The 0.3-alpha shipped the Flutter SDK for Apple Health and the MCP Server. The 0.3-beta matured the Apple Health SDK and added Strava. This release adds Android platform support, simplifies deployment, and addresses longstanding reliability issues in the Garmin integration.

What Is Open Wearables

Open Wearables is an open-source, self-hosted platform that provides a unified data foundation for AI-native health applications. It normalizes wearable data from eight providers into a consistent API, so the application layer can focus on intelligence rather than integration plumbing.

You deploy it on your own infrastructure. Users connect their wearable accounts through OAuth or a mobile SDK. Your application gets back structured, deduplicated data in a consistent format, regardless of device or platform. The priority and deduplication system handles the edge cases that make raw wearable data hard to reason over: when a user's Apple Watch and iPhone both report step counts, or when Garmin and Apple Health have conflicting activity records.

The goal is an AI-ready data layer: clean enough to reason over, complete enough to reflect what users actually track.

Android Platform Support: Google Health Connect and Samsung Health

The two biggest additions in 0.3 are Google Health Connect and Samsung Health. Both are the primary health aggregators on Android, and they've been consistently among the most requested integrations since the project launched.

On iOS, the data model is straightforward: Apple Health aggregates everything. A Garmin watch, an Apple Watch, and third-party apps all route data through a single SDK. On Android, the picture is more fragmented. Google Health Connect and Samsung Health operate as separate systems, and a user with a Galaxy Watch may have data in Samsung Health that isn't reflected in Google Health Connect, depending on their device configuration.

For a developer building a cross-platform health product, that has meant managing three separate integration paths: Apple Health on iOS, plus two Android platforms, plus whatever cloud-based providers (Garmin, Whoop, Strava) you support independently.

0.3 changes that. All three major health aggregators are now supported through the same unified API and data model.

What made both Android integrations possible in one release: we redesigned the SDK payload format into a single consistent structure shared across all SDK-based integrations. Apple HealthKit, Samsung Health, and Google Health Connect now use the same payload. Adding a new SDK-based provider no longer requires building a separate pipeline.

Providers in 0.3 (8 total):

• Cloud-based: Garmin, Polar, Suunto, Whoop, Strava
• SDK-based: Apple Health, Samsung Health, Google Health Connect

Documentation for the Android integrations is being updated at docs.openwearables.io as the release stabilizes.

Current Limitations: The Android integrations are functional and in active use, but worth noting: SDK-connected devices don't yet appear in the provider list in the developer portal, despite data syncing correctly. Sync monitoring is more limited on the SDK path compared to cloud-based providers. Both are tracked.

Android Demo App

To make testing the new integrations faster, we built a sample Android app that handles authentication, data sync, and shows the normalized output from the unified SDK payload. If you want to verify your deployment handles Google Health Connect or Samsung Health data correctly before building your own mobile integration, this is the fastest way to do it.

The app is in beta. Join the Discord community to request access.

Railway Deployment

Docker Compose remains the recommended path for production deployments. But it creates friction when evaluating whether Open Wearables fits your use case: you need a working local environment before you can run a basic test.

Railway one-click deployment removes that step. You deploy directly from the repository to a managed Railway instance and have a running platform in a few minutes. A walkthrough video is included with the setup.

This is the right choice for evaluation, demos, and teams that prefer managed infrastructure over self-hosted. For production deployments with compliance or data residency requirements, Docker Compose on your own infrastructure is still the better option.

Garmin Reliability Overhaul

Garmin integration had accumulated reliability problems across earlier releases. This release addresses them at the source.

Historical backfill was rebuilt. The previous implementation had issues with large historical datasets and could leave sync operations stuck with no clean path to recovery.

User permissions are now handled correctly for all account configurations. Garmin's permission model covers several states, and the previous implementation didn't account for non-standard configurations, causing silent sync failures.

Deregistration webhooks are now handled. When a user disconnects their Garmin account, Garmin sends a deregistration event. The platform now processes this correctly. Previously, disconnected accounts could leave orphaned data in the system.

Error recovery no longer loops on unrecoverable failures. Authentication failures and conflict states are identified and surfaced as errors instead of consuming resources with endless retries.

If you were running Garmin in production and encountering reliability issues in earlier releases, this is the primary reason to upgrade.

Apple Health SDK Maturation

The Flutter SDK (health_bg_sync on pub.dev) shipped in 0.3-alpha and was hardened through 0.3-beta. The stable release includes everything from those cycles.

Invitation code onboarding replaces the SDK token flow. Developers generate an invitation code through the API; users enter it in the mobile app. The SDK handles authentication from there.

Refresh token support keeps sessions active across app restarts without re-authentication. Required for background sync scenarios where the app runs unattended.

Structured logging assigns a batch identifier to each sync operation, making it possible to trace specific data points through the pipeline when debugging production issues.

Request body validation rejects invalid payloads early with clear error messages, rather than allowing failures deeper in the pipeline.

Full Flutter SDK documentation is at docs.openwearables.io.

Other Notable Changes

Strava is a full OAuth provider supporting workout and activity data.

Whoop now supports body measurements, recovery data, and Whoop247 data alongside existing workout and sleep sync.

Data source prioritization lets you configure which value wins when multiple devices report the same metric. Configurable at provider level and device type level.

Python SDK is a community-contributed Python client for the Open Wearables API, enabling server-side integrations outside the mobile SDK path.

Body and activity summary APIs provide daily aggregated body measurement and activity data with semantic metric groupings.

MCP Server supports workout data retrieval, activity listing, and health data presentation prompts for use with Claude, ChatGPT, or any MCP-compatible AI assistant.

Community

915 GitHub stars, 108 forks. 12 contributors worked on this release. The project launched in December 2024 and has grown consistently since.

The Android integrations in this release came directly from community demand. Google Health Connect and Samsung Health were among the top-requested features in GitHub discussions from early in the project. Several contributors on this release are not part of the Momentum team, which is the part of open source that actually compounds: the platform improves based on what developers who build with it actually need.

If you want to contribute, the GitHub repository has labeled issues across different areas and skill levels. The Discord community is active for questions and discussions.

Getting Started

New to Open Wearables:

git clone https://github.com/the-momentum/open-wearables.git
cd open-wearables
cp ./backend/config/.env.example ./backend/config/.env
cp ./frontend/.env.example ./frontend/.env
docker compose up -d
make init

Developer portal at http://localhost:3000. API docs at http://localhost:8000/docs. Full quickstart at docs.openwearables.io/quickstart.

Upgrading from 0.2.x or an earlier 0.3 release: Pull the latest from GitHub and restart your Docker services. If you were running Garmin with custom backfill configuration, review the Garmin sections in the release notes before upgrading.

What's Next

Current development priorities driven by GitHub issues:

• React Native SDK (in progress)
• Oura Ring integration
• Fitbit integration
• Sync monitoring and observability improvements
• Health insights automations
• Webhook events system

0.3 is the current stable release. The platform is deployed and running in production applications, but APIs may change before v1.0. Pin your version and test updates before deploying.

Building an AI-Native Health Application?

If you're building a health product that needs to reason over physiological data, not just display it, reach out to the Momentum team. We built Open Wearables and can help you deploy it, customize it, and build the intelligence layer on top.