Android熄屏状态下检测到附近BLE设备时如何触发后台进程

别再自己开前台服务轮询扫BLE了，这是逆着Android系统后台管理规则做的，被系统杀、碰厂商定制限制都是必然的。你提到的同类产品用的是系统托管式BLE扫描唤醒方案，不需要应用常驻、不需要用户改电池优化，是目前官方唯一认可的稳定实现路径。

核心逻辑 #

你不需要让自己的应用进程一直活着跑扫描，把BLE匹配规则提前注册给系统蓝牙服务，扫描工作完全由系统核心进程托管——这个进程是系统白名单的，永远不会被电池优化策略杀死，哪怕设备熄屏、你的应用已经被系统回收，只要扫到你预设规则的设备，系统会自动唤醒你的应用执行开锁流程，流程跑完系统自动回收资源，完全不需要你做保活。

具体实现步骤 #

• 先配好对应权限
  按系统版本声明必要权限，别多申请没用的权限徒增合规风险：
  • Android 12及以上：声明BLUETOOTH_SCAN、BLUETOOTH_CONNECT权限，如果不需要通过蓝牙扫位置，给BLUETOOTH_SCAN加上android:usesPermissionFlags="neverForLocation"标记，可以完全规避位置权限申请
  • Android 11及更低版本：声明BLUETOOTH、BLUETOOTH_ADMIN、ACCESS_FINE_LOCATION权限
    所有危险权限记得走动态申请流程，拿到用户授权后再注册扫描任务。
• 构造精准的扫描过滤规则
  用ScanFilter.Builder写匹配你家物理锁的规则，支持按设备MAC地址、服务UUID、厂商自定义数据段、设备名匹配，规则越精准功耗越低、误唤醒概率越小，推荐直接绑定锁的专属服务UUID+厂商数据段头，不要用无过滤的全量扫描。
• 构造唤醒用的PendingIntent
  推荐用广播接收器做唤醒入口，轻量不容易出问题：自定义一个继承BroadcastReceiver的类，构造指向这个接收器的PendingIntent，注意Android 12及以上版本必须给PendingIntent加FLAG_IMMUTABLE或者FLAG_MUTABLE标记，否则调用会直接抛异常。
• 注册系统托管扫描任务
  拿到系统BluetoothLeScanner实例后，调用startScan(scanFilters, scanSettings, pendingIntent)方法，把你构造的过滤列表、低功耗扫描配置、唤醒用的PendingIntent传进去就行。调用完成后你可以把自己之前开的前台服务、后台轮询逻辑全关了，剩下的扫描工作全交给系统。
• 实现开锁触发逻辑
  当系统匹配到对应设备，会自动拉起你的应用触发广播接收器的onReceive回调，你在回调里直接走「BLE连接->建立安全会话->传输开锁密钥」的原有逻辑就行，注意这个回调跑在主线程，BLE连接、数据传输这类耗时操作要放到协程或者工作线程里执行，避免触发ANR，流程走完不需要留后台进程，系统会自动回收资源。

方案优势和注意事项 #

这个方案完全规避了你之前碰到的两个问题：

• 扫描逻辑运行在系统核心蓝牙进程，不属于你的应用进程，不会被任何厂商的电池优化策略查杀，熄屏状态下可以长期稳定运行，不需要引导用户手动改电池设置，也不会触发应用商店的合规警告
• 系统会自动调度扫描时机，配合硬件卸载的BLE扫描能力，功耗比你自己开前台服务轮询扫低80%左右，不会造成明显的电量消耗
• 几个需要避坑的点：一是不要在唤醒回调里做长时间驻留的后台逻辑，开锁流程走完就释放连接、结束任务，否则可能被系统判定为后台异常耗电；二是扫描规则尽量精准，不要放宽匹配条件，避免无关设备触发误开锁；三是Android 9及以下的老旧版本（目前市占率不到3%）如果有兼容性问题，可以搭配一个每15分钟触发一次的JobScheduler做兜底注册，不需要高频运行。

你之前踩的坑本质是想用应用层保活的方式绕过系统后台管理，不管怎么优化前台服务、怎么引导用户跳设置，都没法覆盖所有厂商的定制ROM，把扫描能力交给系统托管是目前这类近场自动触发场景下唯一能做到全机型兼容、不需要特殊权限的方案。

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