Android Oreo中上下文注册BroadcastReceiver——应用后台时的问题

兄弟，我太懂这种尴尬了——之前做蓝牙相关的应用也遇到过一模一样的问题，Pre-Oreo时代的后台玩法到了Oreo直接被砍，前台Service又要挂通知，用户看着烦，产品也不让加。下面给你几个实测有效的方案，按需选：

1. 前台Service的“静默通知”技巧（最接近你的原有逻辑） #

Oreo要求前台Service必须显示通知，但我们可以把通知做得“几乎不可见”：

• 针对Android 8.0+，创建一个低优先级的通知渠道，把importance设为NotificationManager.IMPORTANCE_MIN，同时设置setShowBadge(false)，这样通知不会在状态栏显示图标，只会被折叠到通知栏的“其他通知”分组里，用户不特意找根本看不到。
• 通知内容可以写得隐晦一点，比如“应用正在后台维护”，或者用透明图标（注意不要违反Google Play政策，不能完全隐藏到用户找不到的地步）。

示例代码：

// 创建通知渠道（Android 8.0+）
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    val channel = NotificationChannel(
        "silent_service_channel",
        "后台服务",
        NotificationManager.IMPORTANCE_MIN
    ).apply {
        setShowBadge(false)
        description = "应用后台运行所需"
    }
    val notificationManager = getSystemService(NotificationManager::class.java)
    notificationManager.createNotificationChannel(channel)
}

// 创建静默通知
val notification = NotificationCompat.Builder(this, "silent_service_channel")
    .setSmallIcon(R.drawable.ic_transparent) // 透明图标
    .setContentTitle("")
    .setContentText("")
    .setPriority(NotificationCompat.PRIORITY_MIN)
    .setCategory(NotificationCompat.CATEGORY_SERVICE)
    .build()

// 启动前台Service
startForeground(1, notification)

注意：Android 12+对前台Service的通知有更严格的要求，但IMPORTANCE_MIN的渠道依然可以保持低存在感，不会打扰用户。

2. 改用WorkManager替代后台Service（推荐的现代方案） #

如果你的核心需求是“收到蓝牙断开广播后执行开WiFi操作”，其实完全可以抛弃后台Service，用WorkManager来实现：

• 首先，静态注册android.bluetooth.device.action.ACL_DISCONNECTED广播接收器（这个广播在Oreo+依然允许静态注册，属于系统豁免的隐式广播）。
• 在接收器的onReceive方法里，提交一个OneTimeWorkRequest到WorkManager，由WorkManager在后台执行开WiFi的逻辑。

示例代码：

静态注册广播接收器（AndroidManifest.xml） #

<receiver
    android:name=".BluetoothDisconnectReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.bluetooth.device.action.ACL_DISCONNECTED" />
    </intent-filter>
</receiver>

广播接收器类 #

class BluetoothDisconnectReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        if (intent?.action == BluetoothDevice.ACTION_ACL_DISCONNECTED) {
            // 提交WorkManager任务
            val workRequest = OneTimeWorkRequestBuilder<WifiEnableWorker>()
                .build()
            WorkManager.getInstance(context!!).enqueue(workRequest)
        }
    }
}

Worker类（执行开WiFi操作） #

class WifiEnableWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
        val wifiManager = applicationContext.getSystemService(Context.WIFI_SERVICE) as WifiManager
        // 注意Android 13+需要申请BLUETOOTH_CONNECT和CHANGE_WIFI_STATE权限
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q || !wifiManager.isWifiEnabled) {
            wifiManager.isWifiEnabled = true
        }
        return Result.success()
    }
}

这个方案的优势是完全符合Android的后台规范，不需要前台通知，系统会自动调度任务，即使应用被杀死，只要广播触发，任务依然会被执行。

3. 辅助服务（AccessibilityService）备选方案 #

如果上面两个方案都不符合你的需求，可以考虑用辅助服务——辅助服务的优先级极高，不受后台限制，可以在后台持续监听系统事件（包括蓝牙状态变化）。但缺点是需要用户手动在系统设置里开启权限，体验不太友好，适合一些小众场景。

步骤： #

1. 在AndroidManifest.xml中注册辅助服务，声明权限和配置。
2. 创建AccessibilityService子类，在onAccessibilityEvent中监听蓝牙相关的事件，或者直接注册广播接收器。
3. 引导用户开启辅助服务权限。

这个方案尽量作为最后的备选，因为用户授权门槛较高。

最后提醒一下：不管用哪个方案，都要注意Android版本的权限适配，比如蓝牙相关的BLUETOOTH_CONNECT（Android 13+）、WiFi的CHANGE_WIFI_STATE等权限，都需要动态申请，避免权限不足导致操作失败。

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