Android BLE Scan Stops on Screen Off: Bluetooth Explorer Debugging Guide (2026)
If your Android BLE scanner works while the app is active but misses devices after the screen locks, the problem may be expected platform behavior rather than random instability. This guide turns that symptom into a concrete Bluetooth debugging workflow you can use during QA, bug triage, and release hardening.
TL;DR: Default unfiltered BLE scans can pause on screen off. Use meaningful scan filters, verify BLUETOOTH_SCAN and location assumptions, and switch to PendingIntent-based delivery when your process cannot stay alive.
Fast answer for search intent
To fix Android BLE discovery that stops on screen off, do not rely on a plain unfiltered foreground scan. Move to filtered scanning, confirm your permission model, log exactly when the display state changes, and use a background-safe PendingIntent flow if results must wake your app later.
What the recent Android guidance changes for debugging
The current Android Developers BluetoothLeScanner reference documents several details that are easy to miss in older tutorials. Unfiltered scans can be paused when the screen turns off, while filtered scans are the recommended path if you need to avoid that behavior. The same reference also points teams toward PendingIntent-based scan delivery for cases where the process is not always running, and it notes that using FLAG_CANCEL_CURRENT when building the matching PendingIntent can break stopScan().
That combination matters because many “BLE scan randomly stopped” bugs are really design mismatches between foreground assumptions and background requirements.
Practical troubleshooting steps
- Reproduce with timestamps and screen state. Log scan start, first result, last result, screen off, screen on, app background, and app foreground transitions in one timeline.
- Separate unfiltered from filtered behavior. Run one test with your current default scan and one test with explicit
ScanFiltervalues for the target device family or service UUID. - Confirm permission reality on your target SDK. Check
BLUETOOTH_SCANfor Android 12+ and verify that your location strategy matches the platform rules for receiving scan results. - Review any
neverForLocationassertion carefully. If you declared it, test whether it narrows the Bluetooth devices your app can interact with on affected builds. - Choose the right delivery model. If your process may be suspended or killed, test
startScan(List, ScanSettings, PendingIntent)instead of assuming a live callback will always remain attached. - Keep the
PendingIntentstable. If you use the background scan path, verify that the exact same logicalPendingIntentis used for start and stop, and avoid flags that can invalidate stop behavior. - Inspect result batching and callback extras. Capture callback type, error code, and scan result lists so you can tell the difference between no matches, delayed delivery, and configuration failure.
- Retest with one variable changed per run. Change only filters, screen state, permission mode, or delivery model at a time so the root cause stays visible.
Recommended debug sequence for Bluetooth Explorer style workflows
For teams building a Bluetooth Explorer style app, the fastest path is:
- Start with a filtered foreground scan and verify device visibility while the screen stays on.
- Repeat the same run with screen lock events and compare the exact last callback timestamp.
- Move the same target filter into a
PendingIntentscan when background discovery is a product requirement. - Only after those runs should you adjust batching, callback type, or broader scan settings.
This sequence keeps you from conflating radio behavior, lifecycle behavior, and permission behavior into one noisy test case.
FAQ
Why does my Android BLE scan find devices only while the screen is on?
The platform may pause default unfiltered scans on screen off. Test with explicit filters and compare screen-on versus screen-off timelines before assuming radio instability.
When should I use a PendingIntent scan instead of ScanCallback?
Use the PendingIntent path when your process may not stay running and you need scan results to relaunch or notify your app.
Can a permission declaration change which devices I see?
Yes. On newer Android versions, scan permissions and location-related assertions can affect whether results are delivered and which devices are eligible.