Why Your BLE Scan Returns No Results on Android

You’ve set up your BLE scanner. You’ve written the code. You’ve deployed to your device. You hit “scan” and… nothing. An empty list stares back at you after hours spent implementing what should be a straightforward feature.

It’s one of the more frustrating problems in Android BLE development and one of the most common.

BLE scanning on Android has a lot of moving parts, and any one of them can silently fail without giving you a helpful error message. Maybe it’s a permission you didn’t know you needed. Maybe it’s an Android version quirk. Maybe it’s a filter that’s accidentally filtering out everything. The problem is, Android won’t always tell you which one it is.

The good news? Most of the time, the fix is simpler than you think. This article walks you through a systematic debugging process, starting with the quick wins and moving into the deeper Android-specific quirks that trip people up. Let’s get your scan working.

What to Check Before You Touch Code

Before you dive into code, let’s rule out the most common culprits. These account for the majority of “empty scan” issues we see, and you can check them in just a few minutes.

1. Confirm the Basics

It sounds almost too simple, but start here: toggle Bluetooth off and back on. Android’s Bluetooth stack can get into weird states, especially during development when you’re repeatedly starting and stopping scans. A quick toggle often clears it. If that doesn’t help, restart your device entirely. Some Bluetooth state issues are sticky and require a full restart to resolve.

Another quick way to narrow your issue down is to use LightBlue to verify that devices are actually advertising. It’s a free BLE scanner app that shows you what’s broadcasting nearby.

Install it, open it, and check what you see:

• If LightBlue detects devices but your app doesn’t → the problem is in your app’s code or configuration
• If LightBlue sees nothing → you’re dealing with a hardware issue, your target device isn’t advertising, or there’s genuinely nothing nearby

Either way, you’ve just narrowed down your debugging scope considerably.

2. Check Your Permissions

Android requires specific permissions for BLE scanning because scanning can expose location data. BLE beacons can be tied to physical locations, which is why the OS treats this as location-sensitive. If you don’t have the right permissions, your scan will silently return nothing.

What you need depends on your target Android version:

Android 6–11:

• Declare ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION in your manifest
• Request and obtain runtime permission from the user

Android 12+:

• Declare BLUETOOTH_SCAN and BLUETOOTH_CONNECT in your manifest
• If you’re scanning without using location data, add android:usesPermissionFlags="neverForLocation" to avoid needing location permissions

Declaring permissions in your manifest only gets you halfway there. You still need to request them at runtime and actually get the user to grant them. Before you scan, use ContextCompat.checkSelfPermission() to verify permissions are actually granted. And if a user has selected “Don’t ask again” and denied permission, your app can no longer prompt them. You’ll need to direct them to system settings to manually enable the permission.

If you’re not 100% confident your permissions are correct, this is where to focus your attention. Double-check both the manifest declarations and the runtime grant status.

3. Enable Location Services

Even if you’ve granted location permissions, the system-wide location toggle must be enabled for BLE scans to work on Android 6 through 11.

Go to Settings → Location and make sure it’s turned on. If it’s off, your scan will return zero results regardless.

On Android 12+, if you’ve declared BLUETOOTH_SCAN with the neverForLocation flag, you can bypass this requirement. But if you’re targeting older versions or didn’t use that flag, location services must be enabled.

Debugging Your Scanning Code

If you’ve confirmed Bluetooth is on, LightBlue sees devices, permissions are granted, and location services are enabled, but your app still shows nothing, it’s time to look at your scanning code.

Filters That Filter Out Everything

ScanFilter is incredibly useful for narrowing down results to just the devices you care about. It’s also incredibly easy to misconfigure in a way that silently excludes everything. Common mistakes include filtering by a service UUID that doesn’t match what your device advertises, filtering by device name with exact matching when the actual name has extra whitespace or capitalization differences, or combining multiple filters in ways that create impossibly narrow criteria.

Test it by starting with no filters at all. Pass null as your filter parameter when you call startScan(). If devices suddenly appear, you know your filter was the problem. Once you confirm unfiltered scanning works, add your filters back one at a time and verify results after each addition. This helps you pinpoint exactly which filter configuration is causing the issue.

Scan Settings and the Power Mode Trap

ScanSettings controls how aggressively Android scans for devices. During troubleshooting, you want the most aggressive setting to rule out timing issues.

Use SCAN_MODE_LOW_LATENCY while debugging. This mode scans continuously and gives you the best chance of seeing results quickly. SCAN_MODE_LOW_POWER is great for battery life in production, but it scans much less frequently and can cause you to miss devices during debugging, especially if they’re advertising intermittently or you’re testing in a noisy RF environment. Start with SCAN_MODE_LOW_LATENCY to maximize your chances of seeing results, then optimize for power once everything’s working.

Android’s Silent Scan Limit

Android has an internal limit of 5 scan starts within 30 seconds per app, and it comes up more often than you’d expect.

If you exceed this limit, your scans will still appear to have started normally. The startScan() won’t throw an error, but it will return zero results. The only sign that something’s wrong is a vague warning buried in Logcat that’s easy to miss if you’re not specifically looking for it.

This happens most often when:

• You’re rapidly toggling scans on and off during testing
• Your app automatically restarts scans in quick succession after errors or connection attempts
• You’re calling startScan() multiple times without properly stopping previous scans

Space out your scan start/stop calls to avoid hitting this limit. If you’re debugging and keep running into it, just wait 30 seconds before trying again. For production code, you’ll want to track your scan state carefully and make sure you’re not starting scans more frequently than you need to.

What to Do If Your Scan Still Not Working

You’ve checked the basics, verified your permissions, tested with no filters, used SCAN_MODE_LOW_LATENCY, and you’re still getting nothing. Let’s dig deeper into some of Android’s more obscure behaviors.

Device-Specific Fragmentation

Android’s BLE implementation varies across manufacturers. Samsung devices behave slightly differently than Pixels, which behave differently from OnePlus devices, and so on. Sometimes an issue only appears on specific hardware. 

On some Samsung phones, scans don’t start working reliably until Bluetooth has been toggled off and back on, sometimes even twice. A few Xiaomi devices also seem to need a short delay between checking permissions and starting a scan to avoid silent failures. These issues aren’t documented anywhere official, but they’ve shown up often enough in our testing (and in developer forums) that they’re worth mentioning.

If you have access to multiple Android devices, we recommend testing on at least two or three different models from different manufacturers. If the issue only happens on one device or manufacturer, you may need device-specific workarounds. Check manufacturer-specific forums or issue trackers for known BLE problems with your device model. The Android BLE community has documented many of these quirks over the years.

Background Scan Limitations

Android aggressively restricts background activity to preserve battery life, and BLE scanning is no exception. If your app moves to the background, Android may pause or throttle your scans. You might get dramatically fewer results, delayed results, or no results at all. The exact behavior varies by Android version and manufacturer.

The solution:

• Keep your app in the foreground during scanning when possible
• If you need background scanning, implement a foreground service with a persistent notification
• Be aware that even with a foreground service, scan frequency may be reduced compared to foreground scanning

Known Error Codes and Odd Behaviors

SCAN_FAILED_APPLICATION_REGISTRATION_FAILED

This error indicates that Android’s Bluetooth stack couldn’t register your app as a scanner client. It’s usually a temporary system state issue.

Fix attempts in order:

1. Toggle Bluetooth off and back on
2. If that doesn’t work, restart the device
3. In rare cases, clear the Bluetooth app cache (Settings → Apps → Bluetooth → Storage → Clear Cache)

Rotating MAC Addresses

Modern BLE devices often rotate their MAC addresses for privacy. If you’re filtering or caching results based on MAC address, you might be seeing the same device with a different address and not recognizing it. This doesn’t cause “empty” results per se, but it can make it seem like your target device isn’t showing up when it actually is.

To fix this, filter by service UUID or device name instead of MAC address when possible.

If You’re Still Stuck

If you’ve worked through everything in this article and you’re still getting nothing, the issue is likely device-specific, related to your peripheral’s firmware or advertising configuration, or buried in a deeper Android compatibility problem. These are the kinds of issues that require experience across hundreds of device models and deep knowledge of both the Android stack and BLE peripherals. If your project is hitting some serious roadblocks, we can help.

For those building production BLE apps, our Ultimate Guide to Android BLE Development walks through everything from scanning basics to architecture patterns that actually hold up at scales. Or if you’re looking for more debugging specifics, we recommend our articles on permissions across Android versions and handling common BLE scan errors.