Android Studio手机权限全链路：运行时权限申请与版本适配实战

做 Android 开发的这几年，被问得最多的一类问题不是架构、不是性能，而是“我在 Android Studio 里跑起来，为什么一调相机就闪退”。这个问题看着像配置问题，实际上八成是手机权限没走对流程。Android Studio 打开手机权限这件事，说穿了不是点一个按钮，而是把“声明、申请、判断、兜底”这四步串成一条完整的链路。链路中间任何一环断了，表现就是闪退、白屏、功能静默失效，而且往往在模拟器上跑得好好的，一装到真机就出事。

这篇东西写给三类人：刚学 Android、第一次写权限申请的新手；被 targetSdkVersion 升级折磨过的中级开发；以及想把手头项目权限逻辑推倒重写、做成一套可复用方案的从业者。我会从权限到底是什么讲起，把版本差异、代码骨架、状态判断、实战场景、调试手段和踩过的坑一次讲透，代码全部用 Kotlin，直接抄回去改包名就能跑。

1. 先把“打开手机权限”这件事掰开揉碎

1.1 权限不是开关，是三层关卡

很多人脑子里的模型是“权限 = 开或关”，所以在 Android Studio 里找不到那个开关就慌了。真实模型是三层关卡，缺一不可：

第一层是清单声明。应用要在 AndroidManifest.xml 里写明“我需要相机”，系统安装时才知道你要什么。没声明就申请，申请永远失败，而且失败得悄无声息。

第二层是运行时授予。从 Android 6.0（API 23）开始，危险权限不能靠安装时一次性拿到，必须在用户真正要用的时候弹窗问。用户点了“允许”，这一层才通过。

第三层是使用时的校验。就算你拿到了权限，系统也可能在任何时候收回——用户在设置里手动关掉、系统长时间未使用应用自动重置、用户在权限弹窗里选了“仅本次允许”然后退出应用。所以每次调用相机前都得 check 一次，不能凭“我刚才申请过了”就想当然。

三层关卡的设计逻辑其实很朴素：安装时一次问完，用户根本不知道自己同意了什么；使用时再问，用户才知道“哦，原来现在要拍照了”。这套设计对用户友好，对开发者就是负担，但负担是必须扛的。

提示：只要你写的功能涉及相机、麦克风、位置、通讯录、短信、通话记录、身体传感器、后台位置、通知、媒体文件读取，就必须走完这三层。少一层，功能就是“看起来正常，实际必挂”。

1.2 六个高频权限分别是管什么的

新手最容易混的是“我到底该申请哪一个”。下面这张表是我日常查得最频繁的对照表，把最常用的权限、所属权限组、触发弹窗的时机和常见误用列清楚：

有几个点必须单独拎出来说。系统相机 Intent 不需要 CAMERA 权限，这是最经典的误判。你调ACTION_IMAGE_CAPTURE，实际是另一个应用（相机 App）在干活，它自己去拿权限，你的应用只需要一个 FileProvider 输出 URI。很多项目在清单里多声明一个 CAMERA，结果用户在设置页看到“相机权限”以为你要偷拍，反而降低信任。

定位权限是成对的。Android 12 起，只声明ACCESS_FINE_LOCATION而不声明ACCESS_COARSE_LOCATION，系统会直接忽略你的精确权限申请，弹窗都不给你。这条规则坑过很多人，表现是“代码没错，就是不弹窗”。

通知权限是“隐形杀手”。targetSdk 升到 33 之后，POST_NOTIFICATIONS变成运行时权限，不申请的话，NotificationManager.notify()调用不报错、不崩溃，通知就是不出现。这种静默失败排查起来最费时间，因为 Logcat 里干干净净。

1.3 为什么在 Android Studio 里“点不出”权限

经常有人问：Android Studio 里有没有一个按钮能直接打开手机权限。答案是：没有，也不该有。IDE 的职责是编译、部署、调试，权限授予是操作系统和用户之间的交互，IDE 无权代劳。

但 Android Studio 提供了几条合法的辅助路径，很多人不知道：

第一条是模拟器自带的权限面板。在模拟器里打开设置，进入应用详情页，就能看到权限列表并手动切换。这条路适合快速验证“权限被拒绝后界面是否正常”。

第二条是Logcat 里的权限相关日志。过滤Permission、grantResults、SecurityException这几个关键词，能看到系统返回的真实结果，比你自己在代码里打 Log 更权威。

第三条是Device Explorer / App Inspection。虽然它不能改权限，但能让你看到应用私有目录里是否真的写入了文件，用来验证存储权限是否真的生效。

真正批量控制权限的入口是 ADB，这部分我在第 6 节单独展开讲，那才是提效的关键。

2. 版本差异：同一段代码在不同系统上的不同命运

2.1 一条清晰的分界线：API 23

Android 6.0 是分水岭。API 23 之前，危险权限在安装时一次性授予，用户要么全同意要么不装；API 23 之后改成运行时申请。这意味着你如果在维护一个老项目，可能会同时存在两套逻辑，实际判断方式是：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { // 走运行时申请流程 } else { // 老系统直接认为已授权 }

现在 API 23 以下的设备基本绝迹，这段兼容代码可以删了，但判断 targetSdkVersion 的逻辑不能删。因为系统会根据你声明的 targetSdk 决定用哪套规则对待你，这跟设备系统版本是两回事。

举个具体例子：你的应用 targetSdk 是 32，装在 Android 13 的手机上，系统会按 32 的规则处理你——不会强制你申请POST_NOTIFICATIONS，而是在你第一次创建通知渠道时自动弹一次窗。你的应用 targetSdk 是 33，装在 Android 13 上，就必须自己主动申请，不申请就没通知。

所以排查权限问题时，第一个要问的不是“用户手机什么系统”，而是“这个包的 targetSdk 是多少”。这两者组合出来的行为矩阵，比很多人想象的要复杂。

2.2 存储、定位、通知三块重灾区的变化对照

存储是最乱的。我按版本拉一条线：

• API ≤ 28：READ_EXTERNAL_STORAGE/WRITE_EXTERNAL_STORAGE直接读写外部存储，简单粗暴。
• API 29（Android 10）：分区存储引入，应用只能直接访问自己的沙盒目录和公共媒体目录（通过 MediaStore）。可以申请requestLegacyExternalStorage临时豁免，但这个后门在 API 30 被关掉。
• API 30（Android 11）：分区存储强制生效。应用无需任何权限就能向 MediaStore 写入自己创建的媒体文件；读取其他应用创建的媒体文件仍需READ_EXTERNAL_STORAGE。
• API 33（Android 13）：READ_EXTERNAL_STORAGE对媒体文件失效，拆成READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIO三个。
• API 34（Android 14）：新增READ_MEDIA_VISUAL_USER_SELECTED，支持“仅选择部分照片”授权，用户只给你看那几张。

定位的变化同样值得记：

• API 31（Android 12）起：精确与模糊定位分离，申请精确权限必须先声明模糊权限，且弹窗里用户可以选择“仅大致位置”。
• API 29 起：后台定位ACCESS_BACKGROUND_LOCATION独立成权限，不能和前台定位一起申请，必须等前台授权后再单独引导用户去设置页开启，否则系统直接拒绝。

通知的变化简单但致命：API 33 起POST_NOTIFICATIONS是运行时权限，且属于“用户可以随时撤销”的类型。另外从 API 31 开始，PendingIntent必须显式指定FLAG_IMMUTABLE或FLAG_MUTABLE，否则直接抛异常，这个坑和权限无关但经常一起出现，顺手记一下。

提示：升级 targetSdk 前，先把这张版本对照表贴到需求文档里，逐条过一遍。我见过太多项目把 targetSdk 从 30 跳到 33，结果相册打不开、通知不显示、定位拿不到，一次性冒出三个“线上事故”。

3. 声明与请求：一套能直接抄的代码骨架

3.1 AndroidManifest 里的写法与三个隐藏坑

声明本身很简单，难点全在细节：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"> <!-- 相机：只有真正调用硬件时才需要 --> <uses-permission android:name="android.permission.CAMERA" /> <uses-feature android:name="android.hardware.camera" android:required="false" /> <!-- 麦克风 --> <uses-permission android:name="android.permission.RECORD_AUDIO" /> <!-- 定位：精确和模糊必须成对声明 --> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <!-- 通知：targetSdk >= 33 必须声明 --> <uses-permission android:name="android.permission.POST_NOTIFICATIONS" /> <!-- 相册读取：targetSdk >= 33 用这个 --> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> </manifest>

三个坑：

第一个坑是uses-feature的required属性。声明了 CAMERA 权限却不声明uses-feature，部分应用市场会推断你的应用必须依赖相机硬件，把没有摄像头的设备过滤掉。加一行required="false"能避免这个问题。

第二个坑是权限名写错不报错。android.permission.CAMREA这种拼写错误，编译期完全不报，运行时申请直接返回拒绝。我现在的习惯是把权限常量全部收进一个object PermissionConst，用常量引用，杜绝手写字符串。

第三个坑是清单合并（manifest merger）。引入的第三方 SDK 会往你的清单里塞权限，你能在build/intermediates/merged_manifests/目录下看到最终合并结果。有些 SDK 偷偷加了位置、电话这类高敏感权限，用户看到权限列表会直接放弃安装。定期检查合并后的清单，是上线前必做的一步。

3.2 用 ActivityResultContracts 替换掉过时的回调

onRequestPermissionsResult这套老 API 现在还在用的人不少，但它有硬伤：请求码要自己管理、Fragment 里要层层转发、结果和请求的对应关系靠 if-else 硬匹配，代码一多就乱。

现在的标准做法是registerForActivityResult，注册时机必须在onCreate之前或者onCreate里（也就是生命周期进入 STARTED 之前），不能在按钮点击回调里临时注册，否则会抛LifecycleOwner is attempting to register while current state is RESUMED。

单权限请求的骨架：

class CameraActivity : AppCompatActivity() { private val requestCamera = registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted -> if (granted) { openCamera() } else { handleCameraDenied() } } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_camera) findViewById<Button>(R.id.btnTakePhoto).setOnClickListener { if (hasPermission(Manifest.permission.CAMERA)) { openCamera() } else { requestCamera.launch(Manifest.permission.CAMERA) } } } private fun hasPermission(permission: String): Boolean = ContextCompat.checkSelfPermission(this, permission) == PackageManager.PERMISSION_GRANTED private fun openCamera() { /* 启动相机 */ } private fun handleCameraDenied() { if (!shouldShowRequestPermissionRationale(Manifest.permission.CAMERA)) { // 永久拒绝：引导去设置页 showGoSettingsDialog() } else { toast("需要相机权限才能拍照") } } }

这段代码有几个细节值得说。hasPermission这个判断不能省，因为用户可能在设置里手动授予过，此时直接启动相机比弹窗体验更好。shouldShowRequestPermissionRationale的返回值含义要记牢：首次请求前返回 false，用户拒绝过一次返回 true，用户勾选“不再询问”后又返回 false。所以它单独用是有歧义的，必须配合一个“是否已经请求过”的标记才能准确区分“从没问过”和“永久拒绝”。

3.3 一次请求多个权限的批量处理

RequestMultiplePermissions返回的是Map<String, Boolean>，键是权限名，值是是否授予。写法：

private val requestMulti = registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { result -> val allGranted = result.values.all { it } if (allGranted) { startRecord() } else { val denied = result.filterValues { !it }.keys when { denied.contains(Manifest.permission.CAMERA) -> { toast("缺少相机权限，无法录像") guideToSettingsIfPermanent(Manifest.permission.CAMERA) } denied.contains(Manifest.permission.RECORD_AUDIO) -> { toast("缺少麦克风权限，将只录画面") startRecordWithoutAudio() } } } } // 调用处 requestMulti.launch(arrayOf( Manifest.permission.CAMERA, Manifest.permission.RECORD_AUDIO ))

批量请求有两个必须知道的行为。

行为一：系统会按权限组依次弹窗，用户拒绝一个，后面的还会继续弹。所以你不能假设“用户点了拒绝就全拒了”，必须逐个判断。

行为二：同一权限组内的权限会被合并。比如你同时申请READ_MEDIA_IMAGES和READ_MEDIA_VIDEO，系统只弹一次窗。这在体验上是好事，但也意味着你的resultmap 里两个键的值会同时变化，别以为是系统给错了。

还有一个我自己的习惯：能分批就别批量。比如“打开相机 + 录音”这两个权限，我会在用户点击“录像”按钮时才一次性申请，而不是进页面就申请。进页面就弹一堆权限窗，用户连你要干什么都不知道，拒绝率极高。权限申请的时机应该和用户的操作意图严格对齐，这是产品层面的设计，和技术实现同样重要。

4. 授权状态的四种形态与控制流设计

4.1 用两个布尔量把状态拆干净

checkSelfPermission和shouldShowRequestPermissionRationale两个方法组合起来，能得到权限状态的完整画像。但真正写起来会发现缺一个维度：这个权限到底有没有被请求过。所以要在SharedPreferences里存一个标记：

这张表是我这几年反复验证过的最稳的判断逻辑，代码落地成这样：

enum class PermissionState { GRANTED, NEVER_ASKED, DENIED_ONCE, DENIED_FOREVER } fun getPermissionState(activity: Activity, permission: String): PermissionState { val granted = ContextCompat.checkSelfPermission(activity, permission) == PackageManager.PERMISSION_GRANTED if (granted) return PermissionState.GRANTED val asked = prefs.getBoolean("asked_$permission", false) val rationale = ActivityCompat.shouldShowRequestPermissionRationale(activity, permission) return when { !asked -> PermissionState.NEVER_ASKED rationale -> PermissionState.DENIED_ONCE else -> PermissionState.DENIED_FOREVER } } fun markAsked(permission: String) { prefs.edit().putBoolean("asked_$permission", true).apply() }

注意markAsked要在launch()之后立刻调用，不能等回调回来再调，因为回调可能不触发（比如用户直接按返回键关掉弹窗）。

4.2 “拒绝过一次”是挽留用户的最佳窗口

DENIED_ONCE这个状态下，系统还会给你一次弹窗机会，但这可能是最后一次。Android 11 之后有个规则：用户连续拒绝两次同一个权限，系统就不再弹窗，等同于永久拒绝。所以第二次弹窗之前，必须给用户一个解释，否则你等于把最后的机会浪费掉了。

解释的文案不是随便写的。我踩过的坑是写“为了给您更好的体验，请允许相机权限”——这种话用户看了毫无感觉，拒绝率极高。有效的写法是具体说清楚功能关联：“扫描二维码需要使用相机，我们不会保存任何画面”。把用途、边界、承诺三件事说清楚，通过率能明显提升。

弹解释对话框的实现不需要多复杂，一个AlertDialog就够：

private fun showRationaleDialog(onConfirm: () -> Unit) { AlertDialog.Builder(this) .setTitle("需要相机权限") .setMessage("扫描二维码时要调用相机取景，画面只在本地处理，不会上传或保存。") .setPositiveButton("去授权") { _, _ -> onConfirm() } .setNegativeButton("暂不") { _, _ -> } .show() }

4.3 永久拒绝之后，跳设置页是唯一出路

DENIED_FOREVER状态下再调launch()，系统什么都不会发生，回调也不会来，用户会以为你的按钮坏了。这时候只能引导用户去系统设置页手动开启：

fun openAppSettings(activity: Activity) { val intent = Intent( Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.fromParts("package", activity.packageName, null) ) intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) activity.startActivity(intent) }

这里有三个经验点。

第一，不要直接跳转，要先弹窗说明。裸跳设置页会让用户一脸茫然，不知道要改什么。弹窗里明确写“请在设置页找到【权限】-【相机】，选择【仅在使用中允许】”，路径写清楚。

第二，跳转前加FLAG_ACTIVITY_NEW_TASK。如果你的调用发生在非 Activity 的 Context（比如 Service、Application），不加这个 flag 直接崩。

第三，跳转回来后要重新校验。用户可能开了权限，也可能什么都没做就返回。在onResume里重新 check 一次，状态变了就执行功能，没变就保持当前 UI。很多项目的“跳转设置页后功能还是不能用”，就是漏了这一步。

提示：部分定制系统会把“应用详情页”改成自己的界面，甚至有些机型上ACTION_APPLICATION_DETAILS_SETTINGS会被拦截。做一个 try-catch 兜底，跳转失败时提示用户手动去系统设置找应用。

5. 几个高频场景的正确写法

5.1 相册选图：最省事的方案是不申请权限

如果你的需求只是“让用户选一张图”，那最正确的做法是用系统照片选择器，一个权限都不申请：

private val pickImage = registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri -> if (uri != null) { // 拿到 uri，可以直接加载或上传 imageView.setImageURI(uri) } } // 调用，只筛图片 pickImage.launch( PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly) )

这套 API 从 API 33 起是系统原生，API 19 以上有兼容实现（依赖androidx.activity的新版本）。它的好处是用户选择过程完全在系统 UI 内完成，应用只拿到用户主动选中的那一张 URI 的临时读取权限，不需要READ_MEDIA_IMAGES，也不需要担心 Android 14 的“部分照片”授权逻辑。

只有当你需要批量扫描相册、做图片列表、自己做相册 UI时，才需要申请读取媒体权限。这时要按版本分支：

fun getMediaPermission(): String = when { Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU -> Manifest.permission.READ_MEDIA_IMAGES else -> Manifest.permission.READ_EXTERNAL_STORAGE }

Android 14 还要额外处理“用户只选了部分照片”的情况：此时READ_MEDIA_IMAGES和READ_MEDIA_VISUAL_USER_SELECTED都会返回已授予。判断逻辑要写成“只要READ_MEDIA_VISUAL_USER_SELECTED已授予，就认为用户给了一部分，界面上要提供一个‘管理可访问照片’的入口，引导用户重新选择”。

5.2 拍照存文件：FileProvider 与分区存储的配合

用系统相机拍照，完整流程是三步：先生成一个目标文件的 URI，再把 URI 通过 Intent 传给相机应用，最后在回调里读取。关键是那个 URI 必须通过 FileProvider 生成，不能是裸的file://：

<provider android:name="androidx.core.content.FileProvider" android:authorities="${applicationId}.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" /> </provider>

res/xml/file_paths.xml里指定可共享的目录：

<paths> <cache-path name="camera_cache" path="images/" /> </paths>

代码部分：

private lateinit var pendingPhotoUri: Uri private fun takePhoto() { val dir = File(cacheDir, "images").apply { mkdirs() } val file = File(dir, "photo_${System.currentTimeMillis()}.jpg") pendingPhotoUri = FileProvider.getUriForFile( this, "$packageName.fileprovider", file ) val intent = Intent(MediaStore.ACTION_IMAGE_CAPTURE).apply { putExtra(MediaStore.EXTRA_OUTPUT, pendingPhotoUri) addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION) } launcher.launch(intent) }

这一段有三个容易翻车的点。一是FLAG_GRANT_WRITE_URI_PERMISSION必须加，否则相机应用拿不到写权限，拍完照片是空的。二是临时目录要放在cacheDir而不是外部存储，分区存储下写外部公共目录反而更麻烦。三是 Android 11 的包可见性，如果你的应用要查询哪些应用能响应拍照 Intent，需要在清单里加<queries>，不过单纯用launch()启动不需要。

5.3 定位：精确和模糊的取舍不是技术问题

定位权限的处理上，我的建议是先想清楚业务到底需不需要精确位置。天气、城市推荐这类功能，模糊定位足够，申请ACCESS_COARSE_LOCATION就行。需要精确位置的场景（导航、打卡、轨迹记录），才走完整流程。

精确位置的请求要分两步，第二步是等用户主动：

// 第一步：申请前台定位（精确 + 模糊一起） requestMulti.launch(arrayOf( Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION )) // 第二步：只有在用户明确开启了“后台定位”的功能后， // 才引导去设置页申请 ACCESS_BACKGROUND_LOCATION fun guideToBackgroundLocation(activity: Activity) { AlertDialog.Builder(activity) .setTitle("开启后台定位") .setMessage("开启后，锁屏状态下也能持续记录轨迹。请在设置页选择【始终允许】。") .setPositiveButton("去设置") { _, _ -> val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.fromParts("package", activity.packageName, null)) activity.startActivity(intent) } .setNegativeButton("取消", null) .show() }

为什么后台定位不能和前台一起申请？因为系统会直接拒绝，而且 Android 11 之后，从设置页返回时系统可能连弹窗都不给。这个权限的体验设计本身就是“高门槛”，业务上要接受“大部分用户不会开”这个现实，做好降级方案。

另外还有一个常被忽略的判断：权限给了，不代表定位服务开着。用户可能全局关了定位开关。所以要额外检查LocationManager.isProviderEnabled()，两者都满足才能真正定位。

5.4 通知权限：不申请就是静默失败

private val requestNotification = registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted -> if (!granted) { toast("未开启通知，可能收不到消息提醒") } } // 在合适的时机（比如用户开启消息订阅时）调用 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { if (!hasPermission(Manifest.permission.POST_NOTIFICATIONS)) { requestNotification.launch(Manifest.permission.POST_NOTIFICATIONS) } }

这里有个额外的判断要做：权限 granted 不等于通知真的能弹。用户可能只在系统设置里关掉了“通知”总开关，此时权限状态还是 granted。所以发送通知前要双重判断：

fun canNotify(context: Context): Boolean = NotificationManagerCompat.from(context).areNotificationsEnabled() && (Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU || ContextCompat.checkSelfPermission(context, Manifest.permission.POST_NOTIFICATIONS) == PackageManager.PERMISSION_GRANTED)

还有通知渠道（NotificationChannel）的问题。API 26 起，不创建渠道的通知会被系统直接丢弃。渠道一旦创建，重要级别就不能再改，只能引导用户去设置页调。渠道的 id 和名称要在设计阶段就定好，上线后改名等于新建渠道，用户会看到重复的通知分类。

6. 调试：不用手点也能把权限场景跑一遍

6.1 ADB 命令是提效的核心

手动点权限弹窗的效率极低，一轮测试要点十几次。用 ADB 能把最常见的场景一条命令搞定：

# 查看应用已授予和已拒绝的权限 adb shell dumpsys package com.example.demo | grep -A 30 "runtime permissions" # 授予某个权限 adb shell pm grant com.example.demo android.permission.CAMERA # 撤销某个权限 adb shell pm revoke com.example.demo android.permission.CAMERA # 撤销全部运行时权限（模拟新装） adb shell pm reset-permissions com.example.demo

pm revoke有一个非常有用的特性：它会把权限状态打回“未请求过”，也就是shouldShowRequestPermissionRationale返回 false，标记也清了。这正好用来反复测试“首次请求”的流程，不用卸载重装。

另外还有几个调试常用命令：

# 清除应用数据（连 SharedPreferences 一起清） adb shell pm clear com.example.demo # 强制停止应用 adb shell am force-stop com.example.demo # 查看当前前台 Activity，排查跳转是否正确 adb shell dumpsys activity activities | grep mResumedActivity # 查看权限相关的 Logcat adb logcat -s PermissionManager:* ActivityManager:E

6.2 测试矩阵怎么排才不漏

权限逻辑的测试点其实不多，但组合起来容易漏。我一般按这个矩阵过一遍：

最后一行最容易被忽略。现在很多团队只测最新系统，结果老设备上直接崩。我现在的做法是准备三台设备或三个模拟器：一台 API 29、一台 API 31、一台 API 34，新功能在这三个环境上各跑一遍，基本能覆盖 90% 的分支。

6.3 模拟器上模拟“永久拒绝”的小技巧

模拟器上反复点拒绝很烦，有个快一点的办法：在系统设置里进入应用详情页，把权限手动关掉，再配合pm revoke清标记。更彻底的办法是在开发者选项里打开“不保留活动”，每次切走再回来 Activity 重建，能顺便测出“状态存在 Activity 里而不是持久化存储里”这类隐藏 bug。

我在一个项目里就踩过这个坑：权限状态存在 Activity 的成员变量里，用户跳设置页授权后返回，Activity 被系统回收重建，成员变量没了，代码还是走“未授权”分支，表现为“授权了但功能不生效”。改成从SharedPreferences或直接checkSelfPermission实时判断之后就好了。

7. 踩坑记录与常见问题速查

7.1 一张表覆盖八成问题

7.2 几条我认为不该商量的原则

第一条：权限申请必须由用户操作触发。进首页就弹权限窗的做法，现在通过率极低，用户已经形成了肌肉记忆——下意识点拒绝。我经手过的项目里，把权限申请从“启动时”改到“点击功能时”，通过率基本都能翻倍。

第二条：任何一个权限的拒绝，都要有可用的降级路径。用户不给相机，你可以让他从相册选图；不给定位，你可以让他手动选城市；不给通知，你可以在应用内用小红点提示。功能不是非黑即白，降级路径设计得好，用户反而更愿意后续授权。

第三条：不要写一个“万能权限工具类”然后到处调。我早期也这么干过，一个PermissionUtils.requestAll()走天下，结果半年后没人搞得清哪个页面申请了哪些权限，用户被弹窗轰炸。权限逻辑应该和业务功能绑在一起，每个功能自己负责自己的权限，边界才清晰。

第四条：每个权限都要写清楚“为什么”，而且这句话要能过产品经理和用户两道关。技术上说“需要相机权限以调用 Camera2 API”是废话，用户要听的是“扫码时打开取景框，画面只在你手机上处理”。

7.3 一个我最近改掉的坏习惯

以前我习惯在申请权限前先checkSelfPermission，如果已授权就直接干活，没授权就申请。这套逻辑看着没问题，但漏了一个情况：权限可能在“检查”和“使用”之间被撤销。概率极低，但确实发生过——用户在前台，切到设置里撤销，再切回来，你手里的“已授权”判断已经过期，一调用就抛SecurityException。

现在的写法是把checkSelfPermission的判断直接嵌到调用点前面，或者干脆用 try-catch 包住核心调用，catch 到SecurityException就走权限流程。多这两行代码，能避免一类几乎无法复现的线上崩溃。

说到底，Android Studio 打开手机权限这件事，工具层面没有捷径，真正的功夫在于把版本差异捋清楚、把状态判断做扎实、把降级路径设计好。这三点做到位，权限相关的 bug 会少掉绝大部分。至于那些定制系统上的各种奇奇怪怪的表现，只能靠真机多跑、日志多看，经验是攒出来的，急不得。