微信小程序蓝牙连接失败？安卓14附近设备权限避坑指南

微信小程序蓝牙连接在安卓14上“哑火”？深入解析“附近设备”权限新规与实战修复

最近不少同行在群里吐槽，说自家跑得好好的微信小程序蓝牙功能，在部分安卓14设备上突然“罢工”了。用户点击连接，界面转两圈就没了下文，后台日志干干净净，仿佛什么都没发生过。起初以为是蓝牙模块出了问题，或是微信基础库版本不兼容，一通排查下来，最终矛头都指向了一个在安卓14上新增的、且微信小程序框架处理得颇为“含蓄”的权限——“附近设备”权限。这个问题隐蔽性极强，因为传统的蓝牙授权检测API依然会返回“已授权”，给人一种一切正常的错觉，实则通往硬件的路已经被一道隐形的门给堵上了。今天，我们就来彻底拆解这个“坑”，并提供一套从检测、引导到修复的完整实战方案。

1. 理解安卓14的“附近设备”权限：它为何让蓝牙“失联”

在安卓14之前，应用使用蓝牙功能，主要涉及两个经典权限：BLUETOOTH（允许蓝牙通信）和 BLUETOOTH_ADMIN（允许发现和配对设备）。开发者通常通过检查这些权限的授予状态来控制流程。然而，从安卓14（API级别34）开始，谷歌引入了更细粒度的隐私控制。对于需要扫描附近蓝牙、Wi-Fi等设备以进行连接或交互的应用，必须额外申请并获取 NEARBY_WIFI_DEVICES 运行时权限。

这个权限的官方描述是允许应用“发现并连接到附近的设备”。关键在于，它是一个运行时权限，意味着用户可以在应用使用过程中动态地允许或拒绝。对于微信小程序而言，其蓝牙API运行在微信这个“宿主”应用内。当小程序调用 wx.startBluetoothDevicesDiscovery 时，实际发起系统级蓝牙扫描请求的是微信客户端。因此，用户必须向微信授予“附近设备”权限，小程序才能通过微信间接地发现蓝牙设备。

最棘手的地方在于微信小程序API的现状：wx.getSetting 或 wx.authorize 中并没有直接对应“附近设备”权限的scope。更令人困惑的是，即使此权限未授予，wx.getBluetoothAdapterState 或通过 wx.getAppAuthorizeSetting 查询蓝牙授权状态，返回的结果可能依然是 authorized: true。这是因为系统只检查了经典的蓝牙权限，而微信没有将新的“附近设备”权限状态通过现有API暴露出来，导致开发者无法通过标准途径进行准确判断。

核心矛盾点：

• 系统要求：安卓14+上，进行蓝牙设备扫描必须拥有 NEARBY_WIFI_DEVICES 权限。
• 小程序API盲区：现有API无法直接检测微信是否已获此权限。
• 错误反馈：传统权限检测返回“已授权”，掩盖了真实问题。

这就导致了文章开头描述的现象：代码逻辑看似正确，权限检测也通过了，但就是搜不到任何设备。

2. 实战检测：如何判断“附近设备”权限是否真的开启

既然没有直接的API，我们就需要采用一种间接但可靠的“探针”策略。核心思路是：发起一次短暂的蓝牙设备发现，通过是否有设备被扫描到来反推权限状态。如果在一个合理的扫描周期内，连一个公共的、非目标蓝牙设备（如别人的耳机、手环）都扫描不到，那么极大概率是“附近设备”权限未被允许。

下面是一个增强版的检测函数示例，它包含了更健壮的错误处理和状态管理：

/**
 * 检测安卓14附近设备权限状态的间接方法
 * @returns {Promise<{hasPermission: boolean, deviceList: Array, error: any}>}
 */
const checkNearbyDevicePermission = () => {
  return new Promise((resolve) => {
    // 仅针对安卓14及以上版本进行此检测
    const systemInfo = wx.getSystemInfoSync();
    const isAndroid = systemInfo.platform === 'android';
    const sdkVersion = s