Overview
This guide walks you through the complete integration of the Open Wearables Android SDK into a native Kotlin application, from backend setup to production deployment.1
Set up backend authentication endpoint
2
Initialize and configure the SDK
3
Implement sign-in flow
4
Select health provider
5
Request health permissions
6
Start background sync
Read the Mobile SDK Integration Guide first. It covers what is the same on every platform: authentication, the backend token endpoint, the SDK lifecycle, and the production checklist. This page shows the Kotlin code for each step.
Step 1: Backend Setup
Your backend exchanges your app credentials for user-scoped SDK tokens and forwards them to the app - the app never seesapp_id / app_secret. See Backend Endpoint for the setup and example code.
Step 2: SDK Initialization & Configuration
Initialize the SDK once in yourApplication class or main activity, then configure it with your backend host.
Configuration Options
Provide only the base host URL, e.g.
https://your-domain.com. Do not append /api/v1/ or any other path — the SDK adds the required path prefix automatically.Session Restoration
The SDK automatically restores credentials from EncryptedSharedPreferences:Step 3: Sign In
After getting credentials from your backend, sign in with the SDK.The
userId parameter is the Open Wearables User ID (UUID) — the id returned by the Create User endpoint. Do not pass your own external_user_id here.Token-Based Authentication (Recommended)
API Key Authentication
For simpler setups (e.g. internal tools):Automatic Token Refresh
When you provide arefreshToken, the SDK automatically handles 401 responses by refreshing the access token and retrying the request.
You can also update tokens manually:
Step 4: Select Health Provider
Before requesting permissions, you must select a health data provider:Call
setProvider() before requestAuthorization(). The SDK needs to know which provider to request permissions from.Provider Comparison
Samsung Health SDK dependency
If you target Samsung Health, add Samsung’s own Health Data SDK (distributed as an.aar) to your app module. This is required to use the "samsung" provider at all - including in Developer Mode - not just for production. Download it from the Samsung Health Data SDK page:
Testing Samsung Health: Samsung Health is not available in the Android emulator - test on a physical Samsung device with the Samsung Health app installed. Before Samsung approves your app for production, enable Developer Mode in the Samsung Health app so the permission flow works on your test build. If
setProvider("samsung") returns false, the device, the Samsung Health app, or Developer Mode is not set up.Step 5: Request Permissions
Request access to specific health data types. The type IDs are string-based:Make sure to call
setActivity() on the SDK before requesting authorization, so the SDK can launch the permission dialog from the correct Activity context.Step 6: Start Background Sync
Enable background sync to keep data flowing even when your app is in the background:Controlling Sync History Depth
By default, the SDK syncs all available historical data on the first sync. Use thesyncDaysBack parameter to limit how far back the sync goes:
Background Sync Behavior
Stop Sync
Log Level
Control SDK log output using thelogLevel property. By default, the SDK uses OWLogLevel.DEBUG, which outputs logs only in debuggable builds:
Lifecycle Management
Notify the SDK of app lifecycle changes for optimal sync behavior:Samsung Health Production Requirements
Samsung Health works on your development build with Developer Mode - for read access (what Open Wearables needs) you only need a Samsung account, no partnership request. Production adds a requirement: the same code runs, but the permission flow aborts on release builds until both of these are true:- Your partnership request is approved by Samsung. Submit it through Samsung’s app creation process, providing your app’s package name and release signing key signature.
-
Your release signing key is on Samsung’s allowlist. Samsung matches package name + SHA-256 at runtime. Get the fingerprint from your release keystore - and if you use Play App Signing, register the Play app signing key (Play Console →
Setup → App integrity → App signing), not your upload key:
IllegalStateException: Could not get policy for {package} on a release build means Samsung has not matched your app - the partnership is not approved, or the running build’s package name or signing certificate does not match what Samsung registered (a common Play App Signing pitfall). Confirm all three, then contact Samsung Developer Support.Background sync
Samsung Health does not use theandroid.permission.health.* declarations Health Connect relies on - permissions are granted through Samsung Health’s own dialog, so no extra manifest permissions are needed for the Samsung provider. Background sync uses the same WorkManager and foreground-service mechanism as Health Connect; see Troubleshooting for the battery-optimization and POST_NOTIFICATIONS requirements that affect it.
Complete Integration Example
Here’s a complete ViewModel showing the full integration:Using the ViewModel
Data Sync Endpoint
The SDK sends health data to:provider field ("samsung" or "google") and the SDK version:
Next Steps
Troubleshooting
Common issues and solutions for Android.
Data Types
Available health metrics and data formats.

