Permissions and capabilities

Permissions answer what the product requests. Capabilities answer what the active provider can perform. Check both before enabling an optional feature.

Configure minimum access

Use the Setup Wizard or Edit > Project Settings > HealthBridge. Each permission row has independent read and write toggles.

Request only the types and directions required by a user-visible feature. A read grant does not permit writing.

Short IDs and registry IDs

Gameplay APIs use short IDs such as calories and distance. Permission rows can use more specific registry IDs:

API	Typical permission row
calories	active_calories_burned
distance	distance_walking_running
steps	steps
heart_rate	heart_rate
exercise	exercise

Use HealthDataTypeRegistry metadata instead of deriving platform permissions from an API string.

Gate optional features

IHealthProvider provider = HealthBridgeService.Provider;

if (provider != null && provider.Supports(HealthCapability.WorkoutRoutes))
{
    // Enable route UI.
}

Apply the same pattern to writes, deletes, monitoring, and platform-specific categories.

iOS consent

Apple does not reveal every per-type read decision. Initialization can succeed after the sheet closes even if a read type was declined. Denied reads can appear as successful empty results; write denial can fail without detailed disclosure.

Android consent

Health Connect reports granted and denied permissions through HealthBridgeEvents.OnPermissionsResolved. In the current implementation, READ_EXERCISE and READ_HEART_RATE are core initialization permissions. Denial of either causes initialization to fail; optional-only denial can degrade one feature while initialization succeeds.

Build processing must place every configured permission in the final manifest before Health Connect can offer it.

Safe permission flow

1. Explain the feature before the system prompt.
2. Initialize through the correct platform path.
3. Inspect capabilities and available permission details.
4. Enable only supported access.
5. Provide a settings or retry path after a player action.
6. Keep unrelated gameplay usable.