BluetoothLeScanner的ScanFilter按Service UUID过滤BLE设备不生效问题

问题原因 #

这是安卓BLE扫描非常常见的底层兼容坑，核心原因有两个：

• 安卓系统的ScanFilter走硬件过滤逻辑，只会解析BLE主广播包（Advertising Data）中的字段，不会解析扫描响应包（Scan Response）的内容。你用nRF Connect看到的完整服务UUID，大概率是放在ESP32的扫描响应包里的，硬件过滤层拿不到这个数据自然匹配失败；而你手动过滤时调用的result.getScanRecord().getServiceUuids()已经默认合并了主广播包和扫描响应包的所有数据，所以能正常匹配到。
• 部分老旧/定制安卓系统的蓝牙栈，对128位自定义UUID的硬件过滤支持存在缺陷，仅能正常匹配蓝牙标准定义的16位短UUID，128位UUID的过滤规则不会被硬件层正确加载。

可行的解决方案 #

可以根据需求任选一种：

方案1：修改ESP32的广播配置 #

把自定义128位服务UUID从扫描响应包移到主广播包中，硬件过滤就能正常识别。参考ESP32 Arduino的广播配置代码示例：

BLEAdvertising *pAdvertising = BLEDevice::getAdvertising();
pAdvertising->addServiceUUID(SERVICE_UUID); // 直接添加到主广播包，不要放在扫描响应里
pAdvertising->start();

方案2：给ScanFilter补充128位UUID匹配掩码 #

如果没法修改ESP32的广播逻辑，构造过滤规则的时候额外传入全F的UUID掩码，强制让系统正确匹配128位UUID：

// 构造全F的128位UUID掩码
ParcelUuid uuidMask = ParcelUuid.fromString("FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF");
ScanFilter filter = new ScanFilter.Builder()
        .setServiceUuid(mServiceUuidFilter, uuidMask)
        .build();

方案3：继续使用手动过滤逻辑 #

如果上面两种方案都存在兼容问题，直接保留你现有的无过滤扫描+手动校验UUID的逻辑即可，这个逻辑的系统兼容性最好，仅在扫描设备特别多的场景下会有可忽略的性能损耗，普通使用完全感知不到差异。

内容的提问来源于stack exchange，提问作者Jeff L