---
title: "HealthConnectFeatures.getFeatureStatus: checking what the user's Health Connect supports"
canonical: "https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability"
cluster: "Health Connect API"
primary_query: "HealthConnectFeatures getFeatureStatus"
last_reviewed: "2026-10-04"
description: "How getFeatureStatus works in Health Connect, per Google's reference: FEATURE_STATUS_AVAILABLE, all ten FEATURE_ flags, and what to do when one is missing."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"HealthConnectFeatures.getFeatureStatus: checking what the user's Health Connect supports\", AIFitnessAPI, https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability"
---

# HealthConnectFeatures.getFeatureStatus: checking what the user's Health Connect supports

> HealthConnectFeatures.getFeatureStatus(feature) tells you whether one Health Connect capability works on the user's device, returning FEATURE_STATUS_AVAILABLE (2) or FEATURE_STATUS_UNAVAILABLE (1). You call it through healthConnectClient.features with one of the FEATURE_ constants, such as FEATURE_READ_HEALTH_DATA_IN_BACKGROUND, FEATURE_READ_HEALTH_DATA_HISTORY or FEATURE_PLANNED_EXERCISE. Google's reference lists ten flags, one more than its availability guide. When a feature is unavailable, Google says to ask the user to update Health Connect, noting that features tied to the system module stay unavailable on Android 13 and lower even with the APK.

- Canonical: https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability
- Last reviewed: 2026-10-04
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "HealthConnectFeatures.getFeatureStatus: checking what the user's Health Connect supports", AIFitnessAPI, https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability

---

Health Connect ships on two tracks: a framework module from Android 14 and an app from the Play Store on Android 13 and lower, and users do not always update either. So a Jetpack API that compiles in your app may not work on the user's phone. `HealthConnectFeatures.getFeatureStatus()` is how you find out before calling it. This page covers the call, every flag the reference lists, and what Google says to do when the answer is no.

## What Google says it is for

Google's availability guide: "When new features are added to Health Connect, users may not always update their version of Health Connect. The Feature Availability API is a way to check if a feature in Health Connect is available on your user's device and decide what action to take." It also states the consequence of skipping it: "Functionality behind a feature flag won't be available for use if the user's device doesn't support the feature."

The guide says the API "shares the same dependency as the Health Connect SDK" and asks for at least `androidx.health.connect:connect-client:1.1.0-alpha08`.

## The interface and the call

`HealthConnectFeatures` is an "Interface for checking availability of features in `HealthConnectClient`", added in 1.1.0. You reach it through the client's `features` property, which the reference describes as giving "Access operations related to feature availability."

```kotlin
fun getFeatureStatus(feature: Int): Int
```

The parameter is "One of the "FEATURE_" constants in this class", and the return is "one of `FEATURE_STATUS_UNAVAILABLE` or `FEATURE_STATUS_AVAILABLE`":

| Constant | Value | Reference |
| --- | --- | --- |
| `FEATURE_STATUS_UNAVAILABLE` | 1 | "Indicates that a feature is unavailable and the corresponding APIs cannot be used at runtime." |
| `FEATURE_STATUS_AVAILABLE` | 2 | "Indicates that a feature is available and the corresponding APIs can be used at runtime." |

## Every feature flag the reference lists

| Constant | Value | Added in | What it gates |
| --- | --- | --- | --- |
| `FEATURE_READ_HEALTH_DATA_IN_BACKGROUND` | 1 | 1.1.0 | Background reads; see [READ_HEALTH_DATA_IN_BACKGROUND](/health-connect-api/read-health-data-in-background) |
| `FEATURE_SKIN_TEMPERATURE` | 2 | 1.1.0 | Skin temperature data |
| `FEATURE_PLANNED_EXERCISE` | 3 | 1.1.0 | Planned exercise sessions; see [training plans](/health-connect-api/planned-exercise-session-training-plans) |
| `FEATURE_READ_HEALTH_DATA_HISTORY` | 4 | 1.1.0 | Reads older than 30 days; see [READ_HEALTH_DATA_HISTORY](/health-connect-api/read-health-data-history) |
| `FEATURE_MINDFULNESS_SESSION` | 5 | 1.1.0 | Mindfulness sessions |
| `FEATURE_PERSONAL_HEALTH_RECORD` | 6 | 1.1.0 | Personal Health Records APIs; annotated `@ExperimentalPersonalHealthRecordApi` |
| `FEATURE_ACTIVITY_INTENSITY` | 7 | 1.2.0-alpha06 | Activity Intensity APIs |
| `FEATURE_EXTENDED_DEVICE_TYPES` | 8 | 1.2.0-alpha06 | Seven newer `Device` types; see [Metadata and recordingMethod](/health-connect-api/metadata-recording-method) |
| `FEATURE_EXERCISE_SESSION_IMPROVEMENTS` | 9 | 1.2.0-alpha06 | `ExerciseSessionRecord.rateOfPerceivedExertion`, `ExerciseSegment.weight`, `ExerciseSegment.setIndex` and `ExerciseSegment.rateOfPerceivedExertion` |
| `FEATURE_MATCHMAKING` | 10 | 1.2.0-alpha06 | Matchmaking APIs; annotated `@ExperimentalMatchmakingApi` |

Google's availability guide has its own table of flags, and it lists nine of these: `FEATURE_EXERCISE_SESSION_IMPROVEMENTS` appears only in the reference. The reference is the complete list, and the guide itself sends you there: "For a list of all available feature flags, see the `HealthConnectFeatures` reference page."

For extended device types the reference spells out the failure mode: "If this feature is not available, these device types will be treated as `Device.TYPE_UNKNOWN`." Most other flags say only what they gate. Where a permission depends on a feature, the permission's reference entry names the flag to check.

## A small helper

Every check in Google's guides has the same shape, so it is worth wrapping once:

```kotlin
fun HealthConnectClient.isAvailable(feature: Int): Boolean =
    features.getFeatureStatus(feature) == HealthConnectFeatures.FEATURE_STATUS_AVAILABLE

// before offering training plans
if (healthConnectClient.isAvailable(HealthConnectFeatures.FEATURE_PLANNED_EXERCISE)) {
    // show the plan screens and request READ/WRITE_PLANNED_EXERCISE
} else {
    // hide them, or explain that a Health Connect update is needed
}
```

Unlike most `HealthConnectClient` calls, the function is not `suspend`; it returns the status directly. The reference lists no exceptions for it.

## getSdkStatus first, getFeatureStatus second

The two answer different questions. `HealthConnectClient.getSdkStatus()` says whether Health Connect is usable at all, returning `SDK_AVAILABLE` (3), `SDK_UNAVAILABLE` (1) or `SDK_UNAVAILABLE_PROVIDER_UPDATE_REQUIRED` (2), and you need `SDK_AVAILABLE` before `getOrCreate()` gives you a client to ask about features. Only then does `getFeatureStatus()` say whether one capability works on that installation. When the SDK itself is the problem, see [Health Connect not available](/fix/health-connect-not-available).

## When the answer is unavailable

Google's get-started guide: "If a feature isn't available, ask the user to update Health Connect. Features tied to the system module remain unavailable on Android 13 and lower, even with the APK." The availability guide says the same in other words, and adds for extended device types: "Provide a sensible fallback in your write and UI logic."

On Android 13 and lower, then, updating the Health Connect app helps only for features that do not live in the system module, and Google does not say on the pages fetched here which flags those are. Whatever the cause, the safe behaviour is the same: hide or disable the feature's UI rather than offering a button that will fail, and check again later, since an update can change the answer.

## Pitfalls

- **Compiling is not availability.** A constant added in 1.2.0-alpha06 compiles once you depend on that SDK version, but the device still decides at runtime. Check before every feature-gated call path, not once at install.
- **Requesting permissions for an unavailable feature.** Google's samples for the history and background permissions only launch the request after `getFeatureStatus` returns available. Google does not document what the permission screen does with a permission whose feature is missing, so do not find out in production.
- **The exercise-routes guide checks the wrong flag.** Its "Feature availability" block checks `FEATURE_PLANNED_EXERCISE`. `HealthConnectFeatures` has no route-specific flag; route access is governed by permissions, covered in [exercise route consent](/health-connect-api/exercise-route-consent).
- **Copying a typo.** Google's metadata upgrade checklist writes `FEATURE_EXTENTED_DEVICE_TYPES`; the constant is `FEATURE_EXTENDED_DEVICE_TYPES`.
- **Experimental flags need opt-in.** `FEATURE_PERSONAL_HEALTH_RECORD` and `FEATURE_MATCHMAKING` carry experimental annotations in the reference, so code that uses them needs the matching opt-in.
- **Treating the guide's table as complete.** It omits `FEATURE_EXERCISE_SESSION_IMPROVEMENTS`. The reference says `rateOfPerceivedExertion` on a session is supported only when that flag is available. New SDK versions are tracked on [Health Connect releases](/health-connect-releases).

## FAQ

### What does getFeatureStatus return in Health Connect?

An integer that is one of two constants on HealthConnectFeatures: FEATURE_STATUS_AVAILABLE, value 2, meaning the corresponding APIs can be used at runtime, or FEATURE_STATUS_UNAVAILABLE, value 1, meaning they cannot. The function takes one of the FEATURE_ constants as its argument, is not a suspend function, and the reference lists no exceptions for it.

[Permalink](https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability#faq-1)

### Which Health Connect features need a getFeatureStatus check?

Those with a FEATURE_ constant in HealthConnectFeatures. Google's reference lists background reads, skin temperature, planned exercise, reading health data history, mindfulness sessions, personal health records, activity intensity, extended device types, exercise session improvements and matchmaking. The availability guide's table omits exercise session improvements, which gates fields such as rateOfPerceivedExertion on exercise sessions.

[Permalink](https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability#faq-2)

### What is the difference between getSdkStatus and getFeatureStatus?

getSdkStatus, a companion function on HealthConnectClient, says whether Health Connect is usable on the device at all, returning SDK_AVAILABLE, SDK_UNAVAILABLE or SDK_UNAVAILABLE_PROVIDER_UPDATE_REQUIRED. getFeatureStatus is called on a client you already have and says whether one specific capability is available on that installation. Check the SDK status first, then individual features.

[Permalink](https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability#faq-3)

### What should an app do when a Health Connect feature is unavailable?

Hide or disable the feature and, where it can help, ask the user to update. Google's get-started guide says to ask the user to update Health Connect if a feature isn't available, but warns that features tied to the system module remain unavailable on Android 13 and lower even with the Health Connect APK. For extended device types Google asks for a sensible fallback in write and UI logic.

[Permalink](https://aifitnessapi.com/health-connect-api/getfeaturestatus-feature-availability#faq-4)