React Native BLE Manager 中 Beacon 扫描权限问题的分析与解决

问题背景

在 React Native BLE Manager v11.5.6 版本中，开发者报告了一个关于 Beacon 扫描功能无法正常工作的问题。经过排查，发现这与 Android 权限配置中的 android:usesPermissionFlags="neverForLocation" 标志有关。

技术分析

权限标志的影响

在 Android 12 (API 级别 31) 及更高版本中，BLUETOOTH_SCAN 权限引入了一个重要的标志 neverForLocation。这个标志的设计初衷是：

1. 隐私保护：当设置为 true 时，表明应用不会使用蓝牙扫描结果来推断设备位置
2. 权限简化：可以免除应用请求位置权限的要求

然而，对于 Beacon 扫描场景，这个标志会产生负面影响：

• Beacon 技术本身通常用于基于位置的场景
• 设置 neverForLocation 标志会导致系统过滤掉 Beacon 广播包
• 即使应用已经声明了位置权限，该标志仍会阻止 Beacon 的发现

解决方案对比

开发者提出了两种解决方案：

1. 直接移除标志：

   <uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
   

2. 使用工具属性移除（在多模块项目中更可靠）：

   <uses-permission 
     android:name="android.permission.BLUETOOTH_SCAN" 
     tools:remove="android:usesPermissionFlags" />
   

第二种方法在以下场景更为适用：

• 项目依赖了其他BLE库（如react-native-ble-plx）
• 这些库可能在自己的清单文件中设置了该标志
• 使用tools:remove可以确保最终合并的清单中移除了该标志

完整权限配置建议

对于需要扫描 Beacon 的应用，推荐以下 Android 权限配置：

<!-- 基础蓝牙权限 -->
<uses-permission android:name="android.permission.BLUETOOTH"/>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>

<!-- Android 12+ 新权限 -->
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT"/>
<uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
<uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE"/>
<uses-permission android:name="android.permission.NEARBY_DEVICES"/>

<!-- 位置权限（Beacon扫描必需） -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION"/>

最佳实践建议

1. 明确用途声明：如果应用确实需要基于 Beacon 的位置服务，应该正大光明地请求位置权限，而不是试图绕过系统保护机制

2. 多模块项目处理：在包含多个BLE相关库的项目中，使用tools:remove是更可靠的解决方案

3. 权限最小化：只在确实需要后台位置访问时才声明ACCESS_BACKGROUND_LOCATION

4. 兼容性考虑：确保在旧版Android上也能回退到传统权限模型

总结

这个案例很好地展示了Android权限系统的演进对BLE开发的影响。随着Android对隐私保护的加强，开发者需要更精确地声明应用的能力和意图。对于Beacon相关应用，明确的位置权限声明比试图绕过系统限制更为可取，这既符合平台设计理念，也能确保功能的可靠运行。