Repository navigation
Reference Health Connect Matchmaking
Status: External Health Connect API reference. This is background material, not OpenVitals implementation policy.
A guide to the Health Connect Matchmaking API.
The Matchmaking API allows your app to discover other apps and devices that can write health data that your app has permission to read. This helps users connect their favorite data sources to your app with less friction.
The Matchmaking screen discovers Health Connect-compatible apps and devices. It then cross-references your app's required read permissions with the write capabilities of those apps and devices. The screen displays apps and devices that have declared, but not yet granted, write permissions for at least one of the specified record types that your app is permitted to read.
Important
Important: Your app must already have read permissions granted for the record types you want to match.
This guide assumes you have already
configured Health Connect in your app
and have an instance of HealthConnectClient available.
Important
Important: All Matchmaking APIs are experimental. You must opt in to use these APIs by annotating any usage with @ExperimentalMatchmakingApi.
Before attempting to use Health Connect, your app should verify that Health Connect is available on the user's device. Health Connect may not be installed on the user's device, or it could be disabled.
Use HealthConnectClient.getSdkStatus() to check for
availability. If Health Connect is not available, prompt the user to
install or update Health Connect from the Google Play Store.
To determine whether a user's device supports matchmaking on Health Connect,
check for the availability of FEATURE_MATCHMAKING:
if (healthConnectClient
.features
.getFeatureStatus(
HealthConnectFeatures.FEATURE_MATCHMAKING
) == HealthConnectFeatures.FEATURE_STATUS_AVAILABLE) {
// Feature is available
} else {
// Feature isn't available
}
The matchmaking flow is launched using a MatchmakingRequest. This request
defines which record types you want your app to collect, and lets you include or
exclude specific data sources such as apps or devices:
-
recordTypes: A set ofRecordclasses such asStepsRecord::class. If empty, the flow considers all record types your app has read permissions for. -
includedDataSources: A set ofDataOriginobjects to exclusively include. -
excludedDataSources: A set ofDataOriginobjects to exclude.
Note
Note: includedDataSources and excludedDataSources cannot both be set in the same request.
Follow these steps to integrate the Matchmaking API into your application.
Before showing a matchmaking entry point, use
checkIfMatchmakingIsPossible() to determine if there are any relevant
matching apps or devices for the requested record types:
suspend fun checkMatchmakingPossible(healthConnectClient: HealthConnectClient) {
val request = MatchmakingRequest(recordTypes = setOf(StepsRecord::class))
val response = healthConnectClient.checkIfMatchmakingIsPossible(request)
if (response.isMatchmakingPossible) {
// Relevant apps or devices found. Show entry point to launch flow.
} else {
// Handle case where no new data sources are available
}
}
We recommend checking if matchmaking is possible on an ongoing basis.
Users might later install additional apps or connect devices with mutually
compatible data types. A common approach is to check each time your app
starts. If it returns true, show an entry point to launch the matchmaking
flow.
If matchmaking is possible, use createMatchmakingIntent() to get an Intent
to launch the Health Connect flow, then launch it using the Activity Result
API:
// Create the matchmaking launcher
val matchmakingLauncher = registerForActivityResult(
ActivityResultContracts.StartActivityForResult()
) { result ->
if (result.resultCode == Activity.RESULT_OK) {
// Matchmaking finished successfully.
// User successfully granted at least one permission.
} else {
// User canceled flow or didn't grant permissions.
}
}
fun launchMatchmaking(healthConnectClient: HealthConnectClient) {
val request = MatchmakingRequest(recordTypes = setOf(StepsRecord::class))
val intent = healthConnectClient.createMatchmakingIntent(request)
matchmakingLauncher.launch(intent)
}
By launching this intent, Health Connect displays a screen where users can see
compatible apps and devices, and choose to connect them to share data with
your app.



Generated from docs/reference/design/matchmaking.md. Edit it there; changes made here are overwritten.
This wiki mirrors the Markdown in Hale-MTU/OpenVitals on every push to main.
Features
- Features
- Achievements
- Activity And Training Plans
- Activity Metrics
- Apple Health Import
- Beverage Logging And Caffeine
- Bluetooth LE Sensors
- Body Energy
- Body Metrics
- CoMaps Navigation Context
- CSV Import
- Cycle Tracking
- Daily Readiness
- Elevation Correction
- Feature Map
- FIT Files Import
- Food Logging
- GPX/KML/KMZ/TCX Route Import
- Health Connect Metrics Dashboard
- Health Report Export
- Heart And Vitals
- Heart Rate Recovery
- Home Screen Widgets
- Hydration
- Manual Entry Of Metrics
- Medical Records
- Metric Detail Customization
- Mindfulness
- Non Health Connect Metrics Dashboard
- Nutrition
- Offline Maps Support
- Onboarding And Permissions
- Preloaded Beverage Nutrition Reference
- Privacy, Support, And Diagnostics
- Recording Of Activity
- Reminders
- Settings And Preferences
- Sleep Score And Recovery
- Sleep Tracking
- Statistics
- Sync With Another Phone
How-to
App
- App Guide
- FAQ
- Getting Started
- Health Connect
- Install
- Local And Connected Editions
- Permissions
- Privacy
- Screenshots
- Support
Reference
- Design Reference
- Reference
- Design Guidelines for Offline & Sync
- OpenVitals UI Notes
- Reference: Data Capture
- Reference: Data Display
- Reference: Health Connect Matchmaking
- Reference: Health Connect Onboarding
- Reference: Health Connect Permissions
- Reference: Health Connect UX
- Reference: Promoting Health Connect
Engineering
- Code Analysis
- Engineering
- Flutter ↔ Kotlin test-parity matrix
- apple-health-import
- Architecture
- body-cycle-recovery
- Design system conformance
- Development
- Feature Playbook
- Flutter -> Kotlin test parity: domain/data/core/contract/state/navigation/di/bootstrap/l10n/widget_test
- Flutter → Kotlin test-parity matrix: features section
- Flutter → Kotlin test-parity matrix: ui / goldens / integration / fixtures
- Flutter-to-Kotlin test-parity matrix — dashboard + devicesync
- manual-entry
- Translations
Proposals
- Proposals
- Activity Start Flow Analysis
- Activity Start Flow Simplification Proposals
- Caffeine Detail And Future Sleep Insights
- Cycle Tracking: Design and Status
- Medical Records Through Health Connect
- Medical Records: What Is Left
Releases
- OpenVitals 2.16.0
- OpenVitals 2.15.2
- OpenVitals 2.15.1
- OpenVitals 2.15.0
- OpenVitals 2.14.5
- OpenVitals 2.14.4
- OpenVitals 2.14.3
- OpenVitals 2.14.2
- OpenVitals 2.14.1
- OpenVitals 2.14.0
- OpenVitals 2.13.0
- OpenVitals 2.12.0
- OpenVitals 2.11.2
- OpenVitals 2.11.1
- OpenVitals 2.11.0
- OpenVitals 2.10.1
- OpenVitals 2.10.0
- OpenVitals 2.9.1
- OpenVitals 2.9.0
- OpenVitals 2.8.0
- OpenVitals 2.7.3
- OpenVitals 2.7.2
- OpenVitals 2.7.1
- OpenVitals 2.7.0
- OpenVitals 2.6.6
- OpenVitals 2.6.5
- OpenVitals 2.6.4
- OpenVitals 2.6.3
- OpenVitals 2.6.2
- OpenVitals 2.6.1
- OpenVitals 2.6.0
- OpenVitals 2.5.0
- OpenVitals 2.4.1
- OpenVitals 2.4.0
- OpenVitals 2.3.2
- OpenVitals 2.3.1
- OpenVitals 2.3.0
- OpenVitals 2.2.8
- OpenVitals 2.2.7
- OpenVitals 2.2.6
- OpenVitals 2.2.5
- OpenVitals 2.2.4
- OpenVitals 2.2.3
- OpenVitals 2.2.2
- OpenVitals 2.2.1
- OpenVitals 2.2.0
- OpenVitals 2.1.0
- OpenVitals 2.0.4
- OpenVitals 2.0.3
- OpenVitals 2.0.2
- OpenVitals 2.0.1
- OpenVitals 1.9.0
- OpenVitals 1.8.0
- OpenVitals 1.7.7
- OpenVitals 1.7.6
- OpenVitals 1.7.5
- OpenVitals 1.7.4
- OpenVitals 1.7.3
- OpenVitals 1.7.2
- OpenVitals 1.7.1
- OpenVitals 1.7.0
- OpenVitals 1.6.3
- OpenVitals 1.6.2
- OpenVitals 1.6.1
- OpenVitals 1.6.0
- OpenVitals 1.5.1
- OpenVitals 1.5.0
Project