Android 12蓝牙权限大改，你的App连不上设备了吗？手把手教你适配新API

Android 12蓝牙权限适配实战从崩溃日志到完美兼容上周三凌晨我被一连串紧急报警短信惊醒——线上监控显示我们的健康监测App在Android 12设备上的崩溃率突然飙升37%。快速查看Firebase日志后发现清一色都是SecurityException: Need BLUETOOTH_SCAN permission...。这就像一场突如其来的技术风暴让原本稳定的蓝牙连接功能在新型设备上全面瘫痪。如果你也正面对类似的困境不妨跟着我的排查路线走一遍。1. 崩溃背后的权限革命Android 12的蓝牙权限体系进行了堪称颠覆性的改革。原先简单的BLUETOOTH和BLUETOOTH_ADMIN权限被拆解为三个精细化的运行时权限新权限适用场景旧版本对应关系BLUETOOTH_SCAN扫描周边蓝牙设备BLUETOOTH_ADMIN部分功能BLUETOOTH_CONNECT连接已配对设备BLUETOOTH核心功能BLUETOOTH_ADVERTISE允许本机被其他设备发现BLUETOOTH_ADMIN部分功能这种变化带来的直接影响是所有涉及蓝牙操作的App在Android 12设备上都需要重新适配。我在测试机上复现问题时发现即使用户在安装时授予了所有权限App仍然会在尝试连接智能手环时闪退——因为系统根本不会自动映射旧权限到新权限体系。关键发现新权限都是dangerous级别的运行时权限必须通过弹窗显式获取用户同意2. 兼容性适配双保险策略2.1 Manifest声明技巧在AndroidManifest.xml中需要同时处理新旧权限的兼容问题。以下是经过生产验证的声明方案!-- 旧权限仅适用于Android 11及以下 -- uses-permission android:nameandroid.permission.BLUETOOTH android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_ADMIN android:maxSdkVersion30/ uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION android:maxSdkVersion30/ !-- 新权限从Android 12开始生效 -- uses-permission android:nameandroid.permission.BLUETOOTH_SCAN / uses-permission android:nameandroid.permission.BLUETOOTH_ADVERTISE / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT / !-- 可选声明后台扫描需求 -- uses-permission android:nameandroid.permission.BLUETOOTH_SCAN android:usesPermissionFlagsneverForLocation /特别注意那个神奇的neverForLocation标志——它可以让你在不需要定位时避免声明ACCESS_FINE_LOCATION权限这对提升商店过审率很有帮助。2.2 运行时权限动态申请权限请求代码需要处理Android 6.0以来的运行时权限体系和12的特殊要求private fun checkBluetoothPermissions() { val permissionsToRequest mutableListOfString() // 基础蓝牙权限检查 if (Build.VERSION.SDK_INT Build.VERSION_CODES.S) { if (!checkSelfPermission(BLUETOOTH_SCAN) PERMISSION_GRANTED) { permissionsToRequest.add(BLUETOOTH_SCAN) } if (!checkSelfPermission(BLUETOOTH_CONNECT) PERMISSION_GRANTED) { permissionsToRequest.add(BLUETOOTH_CONNECT) } } else { // 旧版本处理 if (!checkSelfPermission(BLUETOOTH) PERMISSION_GRANTED) { permissionsToRequest.add(BLUETOOTH) } if (!checkSelfPermission(ACCESS_FINE_LOCATION) PERMISSION_GRANTED) { permissionsToRequest.add(ACCESS_FINE_LOCATION) } } if (permissionsToRequest.isNotEmpty()) { requestPermissions(permissionsToRequest.toTypedArray(), BLUETOOTH_PERMISSION_REQUEST_CODE) } }实用技巧三个新权限属于同一权限组实际测试发现只要用户授予了BLUETOOTH_SCAN系统会自动授予同组的其他权限。但为保险起见建议还是全部声明。3. 那些容易踩的坑在灰度发布过程中我们收集到一些典型问题场景场景1用户拒绝权限后再次触发请求解决方案添加权限解释对话框shouldShowRequestPermissionRationale(BLUETOOTH_SCAN).takeIf { it }?.let { showRationaleDialog(需要蓝牙权限来发现您的健康设备) }场景2后台扫描被系统限制必须添加前台服务声明service android:name.BluetoothScanService android:foregroundServiceTypeconnectedDevice /场景3华为HarmonyOS 3.0的特殊表现实测发现需要额外检查ohos.permission.LOCATION权限建议使用反射判断系统类型后特殊处理4. 全流程测试方案为确保适配质量我设计了一套分层测试方案单元测试层Test public void testPermissionCompat() { // 模拟Android 11环境 Shadows.shadowOf(Build.VERSION).setSdkInt(30); assertTrue(PermissionHelper.needsLegacyPermissions()); // 模拟Android 12环境 Shadows.shadowOf(Build.VERSION).setSdkInt(31); assertTrue(PermissionHelper.needsNewPermissions()); }UI自动化测试def test_ble_connection(): # 模拟权限弹窗操作 device connect_to_device() if device.sdk_version 12: device.click_allow_button(BLUETOOTH_SCAN) assert device.get_connected_devices().count 0真机覆盖测试矩阵系统版本厂商ROM测试重点Android 10小米旧权限是否正常工作Android 12三星新权限弹窗流程HarmonyOS 3华为特殊权限要求Android 13Pixel后台扫描限制经过三天的紧急修复和A/B测试我们的崩溃率降回了0.2%以下。这次事件给我的深刻教训是每次Android大版本更新都要仔细检查权限模型的变更。现在我的CI流程中已经加入了权限变更检查项确保不会再次掉入同样的陷阱。