Android Bluetooth Device Discovery Debugging: ACTION_FOUND and SCAN_MODE Checklist
When Android Bluetooth find flows miss nearby devices, most teams only look at app logs and miss system scan behavior. A better sequence is to verify paired-state assumptions, observe ACTION_FOUND timing, track ACTION_SCAN_MODE_CHANGED transitions, and then retest with a clean pairing and cleanup baseline. This approach gives repeatable answers for discovery and pairing handoff issues.
TL;DR: Debug discovery with evidence, not guesses. Check paired devices first, run one controlled discovery pass, confirm broadcasts are received, cancel discovery before connect, and compare results after a cleanup reset.
Fast answer block for search intent
The fastest way to troubleshoot Android Bluetooth device discovery in 2026 is to treat discovery as a timed pipeline: pre-check paired inventory, start discovery, log each ACTION_FOUND callback, confirm scan mode changes, and stop discovery before connection attempts. This isolates whether failures occur in scanning, visibility policy, or connection handoff.
Practical troubleshooting steps
- Check bonded inventory before scanning. Query
getBondedDevices()to avoid unnecessary rediscovery loops. - Register receiver early. Ensure your
BroadcastReceiverforACTION_FOUNDis active before callingstartDiscovery(). - Run one controlled scan window. Keep location, device distance, and accessory power state constant for the first run.
- Log scan duration and callback cadence. Discovery commonly includes ~12 seconds inquiry plus per-device name resolution time.
- Track discoverability state transitions. Capture
ACTION_SCAN_MODE_CHANGEDand confirm expected mode windows. - Cancel discovery before connect. Always call
cancelDiscovery()before RFCOMM/GATT connection setup to avoid bandwidth contention. - Perform cleanup reset between retries. Remove stale pairings and clear outdated test builds to reduce false negatives.
- Change one variable per rerun. Re-test permissions, scan mode, or connection timing independently so diffs stay meaningful.
Common discovery failure patterns and fixes
- No callbacks at all: receiver registration or permission scope is likely incorrect.
- Callbacks arrive but target missing: accessory discoverability window may be too short or intermittent.
- Device appears but connect fails: discovery may still be running; cancel it before opening the link.
- Flaky after app background/foreground: verify receiver lifecycle and re-register strategy.
Minimal command notebook for repeatable triage
adb shell dumpsys bluetooth_manageradb logcat -b all -v threadtime | grep -i bluetoothadb shell settings get global bluetooth_onadb shell getprop ro.build.fingerprintadb shell cmd bluetooth_manager disable && adb shell cmd bluetooth_manager enable
Attach these outputs to each ticket with phone model, Android version, and accessory firmware so cross-team debugging stays deterministic.
FAQ
Why should I query paired devices before discovery?
It avoids unnecessary scans and quickly tells you whether the issue is discovery or post-pair connection logic.
Why does discovery hurt connection quality?
Active discovery uses adapter resources and can reduce bandwidth for existing or new connections.
Where does cleanup help Bluetooth debugging?
Cleaning stale pairings and old test artifacts reduces environment noise and improves reproducibility.