Permissions

Health Connector models data and feature permissions as typed values. Your application chooses the smallest set needed for the current user action.

Data permissions

Each readable or writable HealthDataType exposes the matching permission.

final permissions = [
  HealthDataType.steps.readPermission,
  HealthDataType.steps.writePermission,
  HealthDataType.heartRate.readPermission,
];

final results = await connector.requestPermissions(permissions);

Request permissions close to the feature that needs them. A focused request is easier to explain and gives users meaningful control.

Feature permissions

Platform features such as historical or background access have their own permission values.

final results = await connector.requestPermissions([
  HealthPlatformFeature.readHealthDataInBackground.permission,
]);

Check feature availability before presenting dependent functionality:

final status = await connector.getFeatureStatus(
  HealthPlatformFeature.readHealthDataInBackground,
);

Interpreting results

Status	Meaning
granted	The platform reports access is available.
denied	The platform reports access is unavailable.
unknown	The platform does not disclose the authorization state.

iOS read privacy

HealthKit deliberately does not reveal read authorization. iOS read permissions therefore return unknown, regardless of the user's choice. Attempt the read and handle a valid empty result.

Good permission UX

1. Explain the concrete user benefit before opening the system dialog.
2. Ask only for the record types required by that feature.
3. Keep Android manifest declarations synchronized with runtime requests.
4. Continue gracefully when optional access is not available.
5. Provide a settings route when the platform requires manual re-enablement.