If your Android app pairs with a companion device, a smartwatch, a fitness band, a piece of hardware, the old way meant requesting broad permissions like fine location just to scan for Bluetooth devices, which is more access than the task warrants. The CompanionDeviceManager offers a better path: a system pairing dialog where the user picks the specific device, after which your app is associated with that one device without needing those broad permissions. It is both a usability and a privacy improvement. It does not, however, secure the actual data you exchange with the device, which remains your responsibility. Here is what the CompanionDeviceManager does and how to use it securely.
Short answer
The Android CompanionDeviceManager lets your app pair with a companion device through a system dialog where the user selects the device, associating your app with that specific device without requiring broad permissions like fine location for scanning. Per Android, this is a privacy improvement: instead of requesting location to scan for nearby Bluetooth devices, you get a user-mediated association scoped to the chosen device, and it grants companion capabilities like running when the device is nearby. It does not secure the communication with the device, though, so you must still treat data from the device as untrusted input and protect the link at the application layer. Use it to pair with least privilege, and secure the device communication separately.
What you should know
- CompanionDeviceManager pairs via a system dialog: the user picks the device.
- It scopes access to the chosen device: a user-mediated association.
- It avoids broad permissions: no fine location just to scan for devices.
- It grants companion capabilities: like running when the device is nearby.
- It does not secure the device communication: that is still your responsibility.
What does CompanionDeviceManager do?
It associates your app with a specific companion device, with the user choosing it. The table summarizes.
| Aspect | Detail |
|---|---|
| Pairing flow | A system dialog where the user selects the device |
| Association | Your app is associated with that specific device |
| Permission benefit | Avoids broad permissions like fine location for scanning |
| Companion capabilities | Such as running when the associated device is nearby |
| Communication | Not secured by the association; up to your app |
Rather than your app scanning for nearby devices itself, which historically required location permission, the CompanionDeviceManager presents a system dialog that finds candidate devices and lets the user pick the one to pair with. Once the user chooses, your app is associated with that specific device, and that association is what grants access and companion capabilities, like the ability to run in the background when the associated device is nearby, scoped to that device. The headline benefit is the permission model: because the system handles the discovery and the user explicitly selects the device, your app does not need broad permissions such as fine location merely to scan, which is least privilege applied to companion pairing. What the association does not do is secure the data you then exchange with the device; the association establishes the relationship, but the security of the communication over Bluetooth or another transport is a separate matter you handle.
What is the privacy benefit, and the communication caveat?
The benefit is avoiding over-permissioning; the caveat is that pairing is not protection. The privacy improvement is real: scanning for Bluetooth devices the traditional way pulled in location permission, because nearby-device scanning can reveal location, so an app that just wanted to connect to the user's own watch ended up requesting access far beyond its need. The CompanionDeviceManager removes that, the user selects their device in a system dialog, and your app is associated with just that device, so you pair with least privilege and avoid requesting location you do not need, which is better for users and cleaner for review. The caveat is that this association is about discovery and access scoping, not about the security of the data exchanged afterward. Communication with the device, typically over Bluetooth, has its own security considerations: data coming from the device is untrusted input that should be validated, and a sensitive link should be protected at the application layer with encryption and, where appropriate, authentication, rather than assuming the pairing made the channel safe. So the CompanionDeviceManager solves the permission-and-discovery problem cleanly while leaving the communication security to you.
How do you use it securely?
Pair through the manager, request only the companion capabilities you need, and secure the link. Use the CompanionDeviceManager for companion pairing so you avoid requesting broad permissions like fine location merely to scan, letting the user select their device through the system dialog and associating your app with just that device. Request only the companion capabilities your feature genuinely needs, applying least privilege to what the association grants. Then secure the actual communication separately: treat data received from the companion device as untrusted input and validate it, do not assume a paired device is benign or its data well-formed, and for sensitive exchanges protect the link at the application layer with encryption and appropriate authentication rather than relying on the transport or the pairing. Handle any data from the device with your normal storage and privacy practices. The principle is to use the CompanionDeviceManager to pair with least privilege and a clean permission model, and to remember that securing what flows over the resulting connection is a separate job you still have to do.
What to watch out for
The first trap is requesting broad permissions like fine location to scan for a companion device when the CompanionDeviceManager would let you pair without them; use the manager for least-privilege pairing. The second is assuming the pairing secures the communication, when data from the device is untrusted input and a sensitive link needs application-layer protection. The third is requesting more companion capabilities than the feature needs. Pairing and device communication are implemented in your app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled APK or AAB against OWASP MASVS, surfaces your permissions and assesses input handling, while using the manager and securing the link are yours to implement.
What to take away
- The CompanionDeviceManager pairs your app with a companion device through a system dialog where the user selects it, scoping access to that device without broad permissions like fine location for scanning.
- The privacy benefit is least-privilege pairing with a clean permission model, avoiding location access an app does not need just to connect to the user's own device.
- It does not secure the communication, so treat data from the device as untrusted input, validate it, and protect a sensitive link at the application layer.
- Use a pre-submission scan such as PTKD.com to surface your permissions and input handling, and secure the companion-device communication in your app.
