An app without fitness platform integration loses half its scenarios. Users expect automatic collection of steps, calories, heart rate, but without Google Fit or Health Connect, data must be entered manually. We integrate Google Fit (and Health Connect as a fallback) into your Android app in 4–14 working days — turnkey, with full OAuth handling, deduplication, and Wear OS support. Our team has extensive experience in Android development and more than 40 successful fitness integration projects.
Google Fit API has existed since its inception and currently is in a "works, but better migrate to Health Connect" state. Google officially recommends moving to Health Connect for new projects. Nevertheless, Google Fit remains relevant for devices on Android 8–13 without Health Connect support, for Wear OS apps, and for projects with an existing user base.
Google Fit REST API vs Fitness API
Two fundamentally different entry points:
Android Fitness API (com.google.android.gms:play-services-fitness) — native Java/Kotlin SDK, works via Google Play Services, requires OAuth 2.0 Google account.
Google Fit REST API — HTTP API, suitable for server-side and Flutter/React Native, but requires custom OAuth token management.
For native Android — always the Fitness API. REST only makes sense if data is needed on the backend without mobile device involvement.
How We Integrate Google Fit
We use the stack: Kotlin, Jetpack Compose, Hilt for DI, Google Sign-In for OAuth. At the first stage, we analyze data requirements: which types (steps, heart rate, calories), whether time aggregation is needed, whether subscription to live data is required. Then we design the architecture considering deduplication and error handling. We implement reading historical data via HistoryClient and subscription via SensorsClient (for foreground) or RecordingClient (background tracking). All requests are wrapped in suspend functions with coroutines for asynchronicity.
For example, on a recent health tracking app, we reduced data synchronization from 8 seconds to 1.2 seconds by optimizing HistoryClient queries and implementing caching for frequently accessed buckets.
Why Choose Health Connect for New Projects
Health Connect is a redesigned Google platform for health data exchange between apps. Unlike Google Fit, it is not tied to a Google account, works locally on the device, and gives the user more control over which apps read specific data types. For Android 14+ it is available by default, for older versions — via a separate APK installation.
| Feature | Google Fit | Health Connect |
|---|---|---|
| Google account dependency | Yes | No |
| Minimum Android version | 8.0 | 8.0 (with APK) / 14+ (built-in) |
| Deduplication | Partial | Built-in |
| Wear OS support | Yes | Yes |
| Google recommendation | Fallback | Primary stack |
We guarantee compatibility with both approaches and help clients choose the migration strategy optimal for their audience.
Permissions and OAuth: The Main Source of Problems
Google Fit requires two levels of permissions:
- Android permission:
android.permission.ACTIVITY_RECOGNITION(since Android 10) - OAuth scope:
FITNESS_ACTIVITY_READ,FITNESS_BODY_READ,FITNESS_LOCATION_READ, etc.
If you request the Android permission but do not obtain the OAuth scope, the Fitness API will return empty data without an error. This is a silent failure that is hard to catch.
val fitnessOptions = FitnessOptions.builder() .addDataType(DataType.TYPE_STEP_COUNT_DELTA, FitnessOptions.ACCESS_READ) .addDataType(DataType.TYPE_HEART_RATE_BPM, FitnessOptions.ACCESS_READ) .build() val account = GoogleSignIn.getAccountForExtension(this, fitnessOptions) if (!GoogleSignIn.hasPermissions(account, fitnessOptions)) { GoogleSignIn.requestPermissions( this, GOOGLE_FIT_REQUEST_CODE, account, fitnessOptions ) } If a user revokes permission via Google account settings (not through Android Settings), hasPermissions() will return false on the next launch. This must be handled — without retry logic, the app will simply stop receiving data.
Reading Data: HistoryClient and SensorsClient
Historical Data (Steps, Calories)
val readRequest = DataReadRequest.Builder() .read(DataType.TYPE_STEP_COUNT_DELTA) .aggregate(DataType.AGGREGATE_STEP_COUNT_DELTA) .bucketByTime(1, TimeUnit.DAYS) .setTimeRange(startTime, endTime, TimeUnit.MILLISECONDS) .build() Fitness.getHistoryClient(context, account) .readData(readRequest) .addOnSuccessListener { response -> response.buckets.forEach { bucket -> val steps = bucket.dataSets .flatMap { it.dataPoints } .sumOf { it.getValue(Field.FIELD_STEPS).asInt() } } } bucketByTime is the key method for aggregation. Without it, the request returns each individual step from each source (phone + watch + band), which can be several thousand records per day.
Real-Time Data
SensorsClient for subscribing to live data:
Fitness.getSensorsClient(context, account) .add(SensorRequest.Builder() .setDataType(DataType.TYPE_STEP_COUNT_CUMULATIVE) .setSamplingRate(10, TimeUnit.SECONDS) .build(), onDataPointListener ) This subscriber is active only while the app is in the foreground. For background tracking — RecordingClient.subscribe(), which Google Fit accumulates itself.
Deduplication of Data from Multiple Sources
This is a real pain: if a user has an Apple Watch (via Health) + Google Fit on an Android phone + Samsung Health, steps are doubled and tripled. Google Fit partially solves this via DataSet.getDataSources() — each data point has a source (DataSource). Filtering by DataSource.DEVICE allows taking data only from a specific device.
There is no fully reliable deduplication — this is a known ecosystem problem. We document expected discrepancies for the client and build the UI so that the user can select the priority source.
Migration to Health Connect
For new devices (Android 14+), Google Fit is deprecated at the recommendation level. Strategy: check Health Connect availability; if available, use it; fallback to Google Fit for older devices:
val healthConnectAvailable = HealthConnectClient.getSdkStatus(context) == HealthConnectClient.SDK_AVAILABLE What's Included
- Architectural design: choice of approach (Fitness API / REST / Health Connect)
- Implementation of OAuth authentication and handling of permission revocation
- Development of data read/write code (steps, calories, heart rate, etc.)
- Wear OS support if needed
- Deduplication of data from multiple sources
- Testing on real devices with different Android versions
- API and OAuth configuration documentation
- Support during store publication (App Store Review Guidelines, Google Play Console)
Timelines
Basic Google Fit integration (steps, distance, calories) — 4–7 working days. With Health Connect support, deduplication, and Wear OS — 2–4 weeks. Contact us to assess your project — we will choose the optimal approach.
Google Fit API reference







