Android BLE配对后实现STM32WB自定义外设自动重连的方案咨询

核心目标 #

• Android端自动连接STM32WB自研BLE外设，全程无用户手动操作
• 适配外设低频周期性广播特性，保障手机端随时就绪接收外设下发的时间敏感型传感器Indication数据
• 连接效果对标普通智能手表：配对成功后只要处于有效通信范围即可自动回连，无常驻通知等过度用户感知

已验证无效的实现路径 #

• 应用层直接调用connectGatt()时传入autoConnect=true：重连状态无持久化能力，手机重启、系统蓝牙开关重置后，重连逻辑完全失效
• 主动后台扫描实现重连：受Android省电策略、权限限制影响极大，使用前台扫描会带来常驻通知引发用户反感，使用后台扫描在Doze模式下会大幅压缩扫描窗口，极易错过外设的广播包，代码在不同厂商ROM上适配稳定性极差
• 修改外设广播标志使其被系统蓝牙设置发现：系统发起配对时会因外设未开放可配对状态直接配对失败，无法获得系统的连接托管能力

可落地的双向适配方案 #

Android端：借助系统BLE绑定机制托管连接 #

不需要让自研应用在系统蓝牙设置内展示，只要完成系统层的设备绑定，即可获得和智能手表同等的重连能力：

• 首次配对流程：由自研应用主动调用系统BLE配对API createBond() 完成外设与手机的配对绑定，绑定成功后外设会自动存入系统蓝牙的已信任设备列表，系统蓝牙栈会自动为这类设备提供后台被动重连能力——不受Doze模式、应用进程存活状态的限制，只要外设发起带已绑定硬件地址的广播，系统蓝牙控制器会直接捕获广播包，路由到对应应用的Gatt连接回调
• 连接建立：配对完成后调用connectGatt(context, false, TRANSPORT_LE, PHY_LE_1M_MASK)建立连接，后续连接断开的重连动作完全由系统蓝牙栈维护，不需要应用主动开启扫描

此前autoConnect=true失效的核心原因是没有完成系统层的设备绑定，应用层配置的autoConnect仅在应用进程存活时生效，没有被系统蓝牙栈持久化托管

STM32WB外设端：适配系统托管的广播逻辑 #

由于外设软硬件可自主调整，可针对性降低手机端的重连压力：

• 广播策略优化：上电后短时间窗口（如前30秒）开放可配对广播标志用于首次绑定，绑定完成后关闭可配对位，后续仅对已绑定的手机MAC地址开放可连接广播响应，不需要长时间开放全范围可配对广播
• 广播参数设置：将广播间隔调整为100ms-500ms区间，在保证低功耗的前提下，确保系统蓝牙控制器的固定扫描窗口可以稳定捕获广播包
• 连接触发逻辑：外设存储已绑定的手机配对密钥、MAC地址，运行中主动检测已绑定设备的信号强度，一旦在有效连接范围内，由外设主动发起连接请求，不需要手机端主动广播或扫描

应用端：极端场景兜底逻辑 #

仅在系统托管失效的场景下触发临时操作，避免常驻资源消耗：

• 应用启动后先检测系统已绑定设备列表，若存在目标外设的绑定记录，直接监听系统Gatt连接回调即可，不需要主动扫描
• 仅当检测到绑定记录被删除（如用户手动清除应用数据、在系统蓝牙设置中移除设备）时，临时开启5-10秒的短时扫描重新完成配对，不需要常驻前台服务

内容的提问来源于stack exchange，提问作者Youssef Beltagy