Docs

Android 17 Companion Device Profiles: What to Track

Android 17 adds Medical Device and Fitness Tracker profiles to CompanionDeviceManager — the pairing and session events wearable apps should be logging.

Engagement

Android 17 extends CompanionDeviceManager with two new profiles: a Medical Devices profile that lets a medical device app request every permission it needs in a single system dialog, and a Fitness Trackers profile that lets a companion app explicitly declare it’s managing a wearable. Both replace the older pattern of requesting Bluetooth, location, and notification permissions separately, each with its own prompt and its own drop-off point.

For teams building companion apps, the shift is worth instrumenting carefully because it changes where users abandon the pairing flow. A single combined permission dialog either converts better than a sequence of separate prompts, or it doesn’t — apps that don’t track pairing as a funnel with the old multi-step flow as a baseline will have no way to tell whether the new profile actually improved onboarding or just moved the drop-off point earlier, before the device even gets associated. There’s also a device-management gap: once a user pairs through one of these profiles, the app gets a scoped device association rather than a persistent connection, and sessions where the companion device disconnects mid-use look identical to a user simply closing the app unless disconnect and reconnect are logged as their own events.

Data Points to Track

  • Profile type requested (Medical Devices, Fitness Trackers, or legacy per-permission flow), logged at the start of the pairing attempt
  • Pairing funnel step, from profile selection through device discovery, association, and first successful data sync
  • Permission grant outcome for the combined dialog — full grant, partial grant, or dismissal — since a combined prompt can still be partially declined
  • Device association duration, distinguishing a user-initiated disconnect from the OS revoking the association
  • Reconnection latency after an app restart or Bluetooth toggle, since companion devices don’t auto-reconnect the way a persistent Bluetooth pairing does
  • Data sync success rate per session, tagged by profile type, to catch a profile that pairs successfully but fails to stream data reliably

Setup Steps

  1. Log the CompanionDeviceManager profile type as a property on the pairing-start event, so funnel data can be split by profile.
  2. Instrument each pairing funnel step separately (profile selection, discovery, association, first sync) rather than a single pass/fail pairing event.
  3. Capture the permission grant outcome distinctly from the pairing outcome, since a full grant can still be followed by a failed device association.
  4. Fire explicit connect and disconnect events tied to the companion device association, not just app foreground/background state.
  5. Track first-sync latency after association, since a paired-but-not-syncing device is a silent failure mode that won’t show up in pairing success metrics alone.

Actionable Insights

Compare pairing completion rate for the new combined-permission profiles against your historical baseline from the old sequential-permission flow. A higher completion rate confirms the single dialog reduces drop-off; a similar or lower rate — especially with more dismissals at the permission-grant step — suggests the combined prompt reads as more demanding, not less, and might need in-app framing before the system dialog appears. Separately, a gap between pairing success and first-sync success points to a connectivity or protocol issue worth fixing before it shows up as unexplained low engagement in wearable-linked cohorts.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert