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

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."

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":

Every feature flag the reference lists#

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:

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.

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.
• 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.