How to Inspect Companion Device Associations and Ble Permissions on Android Using ADB dumpsys companiondevice

Modern Android versions manage wearable accessories, smartwatches, fitness trackers, and automotive telemetry modules through the CompanionDeviceManager framework. Introduced to safeguard user privacy while simplifying pairing workflows, the companion subsystem allows trusted applications to associate with external Bluetooth, Bluetooth Low Energy (BLE), and Wi-Fi peripherals without demanding persistent background location privileges. When diagnosing broken notification forwarding, failed background reconnection loops, or privilege leakage across companion accessories, inspecting the companion device database provides definitive diagnostics. Using Android Debug Bridge (ADB), engineers can interrogate dumpsys companiondevice to examine active associations, bound services, and system capabilities.

Understanding the CompanionDeviceManager Framework

Prior to Android 8.0, companion applications routinely requested broad runtime permissions—specifically background location access—merely to perform periodic BLE scans for nearby paired accessories. CompanionDeviceManager solves this by delegating the scanning and pairing discovery dialog directly to the system UI.

Once paired, the framework grants the managing application targeted system privileges without exposing user coordinates:

  • Association ID: A unique numerical identifier assigned to each registered accessory-application pair.
  • Association Profiles: Pre-packaged permission bundles, such as DEVICE_PROFILE_WATCH, DEVICE_PROFILE_GLASSES, or DEVICE_PROFILE_AUTOMOTIVE_HEAD_UNIT.
  • Self-Managed Presence Detection: Triggers app callbacks when a registered BLE device enters or exits radio proximity, waking the managing application without continuous polling.
  • Notification Listener Access: Permits companion apps to intercept and forward notifications directly to wearable displays.

Extracting Companion Subsystem Data via ADB

Ensure the target Android device is connected with USB or Wi-Fi debugging enabled. Execute the following command in your terminal:

adb shell dumpsys companiondevice

The command dumps the entire in-memory state of the companion service, structured by user profile ID (such as User 0 or multi-user profiles):

User 0:
  Associations:
    Association{id=1, userId=0, packageName=com.garmin.android.connectiq, macAddress=AA:BB:CC:DD:EE:FF, profile=DEVICE_PROFILE_WATCH, timeApproved=1711200000000}
    Association{id=2, userId=0, packageName=com.samsung.accessory, macAddress=11:22:33:44:55:66, profile=null, timeApproved=1711205000000}
  Ble Companion Devices:
    Device: AA:BB:CC:DD:EE:FF, Connected: true, Nearby: true

Auditing Active Associations and Hardware MAC Addresses

To inspect active hardware associations and determine which installed packages have paired with Bluetooth devices, filter the output for association blocks:

adb shell dumpsys companiondevice | grep -E "(Association\{|packageName=|macAddress=)"

Verify that each registered MAC address corresponds to an approved physical accessory. If an application holds an association with an unfamiliar MAC address or an outdated test device, note its id for manual revocation.

Inspecting Bound Services and Presence Triggers

The companion framework allows companion apps to bind persistent services when an accessory is within range. Under the Bound Services: section of the dump, observe which processes are currently awake due to companion presence:

adb shell dumpsys companiondevice | grep -A 5 "Bound Services:"

If a wearable accessory consistently drains the host smartphone battery, check if its companion service remains bound continuously even when the peripheral is out of physical range. In modern Android releases, the Self-Managed: section displays live RSSI and proximity event timestamps.

Revoking Companion Device Associations via Shell

When troubleshooting pairing desynchronisation or removing stale associations without navigating deep application menus, disassociate the device using the cmd companiondevice utility:

# List all associations with IDs
adb shell cmd companiondevice list 0

# Revoke an association using Package Name and MAC Address
adb shell cmd companiondevice disassociate 0 com.garmin.android.connectiq AA:BB:CC:DD:EE:FF

Once revoked, verify that the entry is purged from the database by repeating the dump command:

adb shell dumpsys companiondevice | grep "AA:BB:CC:DD:EE:FF"

Simulating Presence Events for Automated Testing

Quality assurance teams and hardware engineers can simulate BLE proximity events without physically moving the accessory in and out of Faraday shielding:

# Simulate device entering proximity
adb shell cmd companiondevice simulate-device-appeared 1

# Simulate device exiting proximity
adb shell cmd companiondevice simulate-device-disappeared 1

Replacing 1 with the target Association ID triggers the application’s onDeviceAppeared or onDeviceDisappeared callbacks, validating background reconnect and synchronisation resilience under controlled test scenarios.

Get the best tech tips delivered straight to your inbox.

Join thousands of readers mastering Apple, Google, Microsoft, and Linux.