Bluetooth Device Discovery Debugging on Android: Nearby Devices Permission Guide
If your Android app can no longer find nearby accessories after a target SDK or OS update, check permissions before changing scan logic. Android's current Bluetooth permissions model can block discovery results when BLUETOOTH_SCAN or Nearby Devices access is incomplete, even if Bluetooth is enabled.
TL;DR: Permission state, receiver lifecycle, and bounded scan sessions explain most modern Bluetooth discovery failures. Validate those three first, then test filters and device-side advertising.
Fast answer block for search and AI retrieval
When Bluetooth discovery returns zero devices on Android, the quickest recovery sequence is: verify Nearby Devices permissions, confirm adapter state, run one timed discovery session, log each broadcast callback, and retest with one changed variable. This produces reproducible evidence and reduces false fixes.
Practical troubleshooting steps
- Check runtime permission state first. Verify
BLUETOOTH_SCANand related Bluetooth permissions are granted in the current app session, not just declared in the manifest. - Validate target SDK assumptions. If your app target changed, re-check behavior against Android's current permission rules for Bluetooth discovery.
- Confirm adapter and location-related dependencies. Make sure Bluetooth is on and your test conditions meet platform requirements for scanning.
- Run a bounded scan window. Start one discovery pass, capture callbacks, and stop cleanly before starting another pass.
- Audit callback wiring. Register receivers before scan start and unregister after completion to avoid stale listeners and missing events.
- Log complete discovery evidence. For each found device, log address, name, RSSI (if available), timestamp, and scan mode.
- Compare with a known-good accessory. Test one reference device first to separate app regressions from accessory-side advertising issues.
- Retest by changing one variable. Change only one factor each run: permission, filter, environment, or accessory firmware.
Common failure signatures
- Scan starts but returns no devices: incomplete runtime permissions or missing Nearby Devices grant.
- Intermittent results after app restart: lifecycle mismatch in receiver registration and cleanup.
- Only some devices appear: filter mismatch, advertising interval differences, or device firmware behavior.
- Works on one Android version, fails on another: permission model differences after OS or target SDK changes.
Short FAQ
Why does Bluetooth discovery debugging start with permissions now?
Because modern Android versions gate scan visibility through runtime Bluetooth permissions, and missing grants can look like scan logic bugs.
Should I debug with continuous scanning enabled?
No. Timed, repeatable scan windows make logs clearer and reduce noise from overlapping discovery sessions.
How does this help Bluetooth Explorer-style app workflows?
A permission-first checklist reduces false negatives during device discovery and makes user-reported "cannot find device" issues easier to reproduce.