Alright, let's break this down clearly: Yes, it's absolutely possible for non-system apps to unpair Bluetooth devices on Android 9.0+, and it doesn't have to rely solely on tricks from the smartwatch side. Based on your scenario (a companion app for smartwatches, works on AOSP 10, no special signing/root), here are the most likely ways this is being done:

1. Trigger the watch to initiate unpairing via Bluetooth protocol commands #

This is probably the most fitting solution for your use case:

• Since your app pairs with the watch's audio chip (using protocols like A2DP or HFP), it can send specific Bluetooth protocol commands over a GATT connection to the watch, instructing it to initiate an unpair request.
• When the watch sends this request to the Android system, the system automatically handles removing the pairing relationship. No restricted system APIs like BluetoothDevice#removeBond() are called directly from your app.
• This aligns perfectly with your details: the app initiates the action, no excessive permissions are required, and it works on stock AOSP without relying on vendor-specific libraries.

2. Reflective calls to bypass @SystemApi restrictions (context-dependent) #

Even though BluetoothDevice#removeBond() is marked as @SystemApi, there are edge cases where regular apps can still call it via reflection:

• Note: Strict stock AOSP 9+ systems restrict reflective access to @SystemApi methods, but some loopholes or compatibility handling exist:
  • You can try fetching the method using getDeclaredMethod() (instead of getMethod()) and calling setAccessible(true) to bypass visibility checks.
  • Early Android 10 AOSP builds may not have fully enforced this restriction, allowing regular apps to successfully invoke the method via reflection.
• This approach has compatibility risks (future system updates may patch the loophole), but it's plausible given your app works on AOSP 10.

3. Accessibility Service to simulate user actions (less likely here) #

If the app requires user authorization for accessibility permissions, it could automate unpairing by simulating taps in the system Bluetooth settings:

• An AccessibilityService can listen for the Bluetooth settings UI and mimic the user's tap on the "Unpair" button.
• However, this requires explicit user permission to enable accessibility services, which doesn't match your description of "automatic" unpairing without extra steps, so this is a lower-probability option.

How to verify if it's app-side or watch-side #

You can test this easily:

• Power off the watch completely, then try using the app to unpair the already paired device. If it succeeds, the app is directly interacting with the system's Bluetooth stack.
• If unpairing only works when the watch is powered on and reachable, the app is almost certainly sending protocol commands to trigger the watch to initiate the unpair request.

内容的提问来源于stack exchange，提问作者Daniel Lee