三星Note 10系列BLE扫描过滤功能异常问题咨询

Hey there, let's break down this device-specific BLE issue you're facing. It sounds like Samsung's Note 10/Plus has a quirk in its BLE stack that's interfering with scan filters when combining a service UUID and manufacturer data—something that works flawlessly on stock Android devices like Pixels.

Problem Recap #

When you include .setServiceUuid(ParcelUuid("someUuid")) in your ScanFilter alongside manufacturer data filters, the ScanCallback stops receiving results on the Note 10/Plus. But remove that service UUID line, and everything works as expected across all devices.

Code Examples to Reproduce #

Non-Working (Note 10/Plus Only) #

internal class Scanner {
    private val scanFilter = ScanFilter.Builder()
        .setServiceUuid(ParcelUuid("someUuid"))
        .setManufacturerData(someIntId, someByteArray, someMask)
        .build()
    private fun startScan(scanSettings: ScanSettings, scanCallback: ScanCallback) {
        bleAdapter.bluetoothLeScanner.startScan(listOf(scanFilter), scanSettings, scanCallback)
    }
}

Working (All Devices) #

internal class Scanner {
    private val scanFilter = ScanFilter.Builder()
        //.setServiceUuid(ParcelUuid("someUuid")) // Disabled to fix the issue
        .setManufacturerData(someIntId, someByteArray, someMask)
        .build()
    private fun startScan(scanSettings: ScanSettings, scanCallback: ScanCallback) {
        bleAdapter.bluetoothLeScanner.startScan(listOf(scanFilter), scanSettings, scanCallback)
    }
}

What's Likely Going On & How to Fix It #

Samsung has a history of customizing their BLE stack, which can lead to inconsistencies with stock Android behavior. Here are some actionable steps to resolve this:

• Check UUID Precision: Ensure the ParcelUuid string matches the advertised UUID exactly—including hyphen placement and case. Some Samsung devices are stricter about parsing UUID strings than other handsets.
• Reorder Filter Builder Calls: Try setting the manufacturer data first, then the service UUID in the ScanFilter.Builder. Sometimes the order of operations can trigger or avoid stack quirks.
• Isolate the Filter: Test using only the service UUID filter (remove manufacturer data) to see if that works. If it does, the problem is with how Samsung's stack combines multiple filter criteria.
• Update the Device: Make sure the Note 10/Plus is running the latest One UI and Android updates. This could be a known bug that Samsung has patched in newer releases.

Reliable Workaround #

If none of the above fixes work, you can bypass the system-level filter entirely by handling the filtering in your app:

1. Remove the service UUID from the ScanFilter (use the working code example).
2. Manually check for the target service UUID in your ScanCallback implementation:

override fun onScanResult(callbackType: Int, result: ScanResult) {
    super.onScanResult(callbackType, result)
    val targetServiceUuid = ParcelUuid.fromString("someUuid")
    
    // Check if the scanned device advertises our target UUID
    result.scanRecord?.serviceUuids?.let { advertisedUuids ->
        if (advertisedUuids.contains(targetServiceUuid)) {
            // Process this valid scan result
        }
    }
}

This shifts the filtering logic to your app, avoiding the Samsung-specific stack issue entirely while maintaining the same functionality.

内容的提问来源于stack exchange，提问作者Keith Leow