这个问题我在带新人的时候被问过不下二十次，问法几乎都一样：“Android Studio 怎么打开手机权限？”听起来像一句操作指令，真上手就会发现它其实横跨了三个完全不同的层面——最外层是设备和开发工具之间的调试授权，中间层是操作系统对已安装应用的能力开放，最内层才是代码里那套运行时权限的申请流程。三层里任何一层没打通，现象都长得很像：功能点不动、弹窗不出现、日志里甩一句 SecurityException，然后人就开始怀疑人生。这篇东西我按自己平时排查的顺序捋一遍，从设备开关一直写到 adb 一行命令直接授予权限，中间夹着 Manifest 声明、targetSdk 的版本行为差异、被拒绝后的二次引导，以及那些文档里基本不会提、但每次换机型都会撞上的坑。适合刚接触 Android 应用开发、被权限卡住的同学，也适合已经写了半年代码但一直是“复制粘贴权限模板”的同行——把每一行为什么这么写搞清楚，后面换任何权限类型都能自己推出来。
1. 先分清“打开权限”到底指哪几件事
1.1 设备侧：让开发工具能碰到这台手机
最外层这件事，本质是“授权一台电脑去调试一台手机”。手机默认把所有 USB 连接都当成充电线，只有你在开发者选项里打开 USB 调试，并且在手机弹出的“允许 USB 调试吗”对话框上点了允许，这台电脑才会被记录进手机的调试授权列表。这时候adb devices才会从unauthorized变成device。
这一步很多人会忽略一个细节：授权是按“电脑的 RSA 密钥”记的，不是按“Android Studio 这个软件”记的。所以你换了电脑、重装了系统、换了 USB 口背后的另一台机器，都会重新弹一次授权框。反过来，如果你在同一台电脑上用命令行 adb 授权过，Android Studio 直接就能用，因为它调用的就是同一个 adb 可执行文件。理解这一点，后面很多“为什么 Studio 认不到设备但命令行能认到”的怪现象就自动有答案了。
还有一层更隐蔽的：部分定制系统在“USB 调试”之外，额外挂了一个“USB 调试（安全设置）”之类的开关，专门管控“通过 USB 修改权限或模拟点击”这类高危操作，通常还要求登录账号才能打开。你的pm grant命令如果报Operation not allowed或者SecurityException，八成就是卡在这个开关上，而不是命令写错了。
1.2 系统侧：让已安装的应用能拿到某项能力
中间这层是普通用户视角里最熟悉的：设置 → 应用 → 某个应用 → 权限，里面那一排开关。对开发者来说，这一排开关的意义在于——它是权限状态的“最终事实来源”，代码里checkSelfPermission查的、pm grant改的，都是这块数据。
开发调试期最省事的做法当然是手动点，但手动点有个致命缺陷：只要重新安装应用（尤其是带android:debuggable变更或者卸载重装），权限状态就会重置。一天装二十次包，就要点二十次相机、二十次定位，时间全耗在这上面。所以成熟的团队基本都会把常用权限写进一个脚本，靠 adb 批量灌进去。
1.3 代码侧：让应用自己会“要”权限
最内层才是真正写进产品里的东西。从 Android 6.0 开始，危险权限不再是安装即授予，而是必须在运行时由代码主动发起申请，系统弹出对话框，用户点允许。这是产品必须实现的能力，不能指望用户自己跑到设置页去点——事实上 90% 的用户根本不知道那个页面在哪。
这三层的关系可以这么理解：设备侧授权是“你能进这栋楼”，系统侧授权是“你能进这间屋”，代码侧申请是“你自己知道该找谁要钥匙”。任何一层断了，最终表现都是功能不可用。
| 层级 | 作用对象 | 典型操作 | 失败表现 |
|---|---|---|---|
| 设备调试授权 | 电脑 ↔ 手机 | 开发者选项、USB 调试、RSA 授权 | adb devices 显示 unauthorized 或空列表 |
| 系统权限授予 | 手机系统 ↔ 已安装应用 | 设置页开关、pm grant、appops | 代码申请被拒、SecurityException |
| 代码运行时申请 | 应用自身逻辑 | requestPermission、回调处理 | 弹窗不出现、功能静默失效 |
2. 环境准备：先把调试通道打通再谈权限
2.1 手机端必须打开的开关清单
不同定制系统的菜单位置差异很大，但逻辑是一致的，我按必须程度排一下。
必开项：开发者选项（在“关于手机”里连点版本号七次解锁）、USB 调试。这两项不开，后面全免谈。
强烈建议开：USB 安装（部分系统默认关闭，会导致INSTALL_FAILED_USER_RESTRICTED）、USB 调试（安全设置）。后面这个开关在通过 adb 直接改权限、模拟点击时会用到，通常需要登录账号，验证一次之后长期有效。
容易漏的：连接模式。很多手机插上 USB 默认是“仅充电”，某些系统在仅充电模式下仍然允许 adb，但有些不允许，表现就是设备列表时有时无。我一般直接在开发者选项里把“默认 USB 配置”设成文件传输，省得每次插线都要下拉通知栏点一下。
还有两个隐性坑：一是“USB 调试自动断开”，部分系统在息屏或长时间无操作后会主动断开 adb，调试长任务时莫名其妙断连，要去电池优化里把这个应用排除掉；二是“后台弹出界面”权限，如果你调试的功能涉及从后台拉起 Activity，系统会直接拦掉，表现是代码逻辑全对但界面不出现。
提示：每换一台测试机，我会先花两分钟把上面这套开关过一遍，存成一张便签贴在显示器边上。这比事后对着日志猜“为什么 adb 又不认设备了”省时间得多。
2.2 开发工具这边的准备：adb 从哪来、怎么确认它是通的
Android Studio 本身并不内置一个独立的 adb，它用的是 SDK 里platform-tools目录下的那一份。所以第一步是在 SDK Manager 里确认 Platform-Tools 已安装，然后记住它的绝对路径，后面写脚本、配 External Tools 都要用到。
验证顺序我习惯这样走：终端里敲adb version确认可执行文件在 PATH 里；adb devices看设备列表；如果列表为空但手机明明插着，先adb kill-server再adb start-server，这一步能解决大概三成的识别问题；还是不行就换线、换口，尤其是那些只能充电不能传数据的劣质线，坑过太多次。
Android 11 之后还有个很实用的能力：无线调试。手机和电脑在同一网络下，开发者选项里打开“无线调试”，点“使用配对码配对设备”，会给你一个 IP 端口和六位配对码，电脑上执行adb pair 192.168.1.100:37123，输入配对码，然后再adb connect 192.168.1.100:5555。配对成功后，Android Studio 的设备列表里会直接出现这台机器，插线都省了。做需要反复走动测试的场景（比如定位、传感器）时特别香。
# 常规有线连接 adb devices adb kill-server && adb start-server # 无线调试（Android 11 及以上） adb pair 192.168.1.100:37123 adb connect 192.168.1.100:5555 adb devices2.3 Manifest 声明与 targetSdk：决定权限行为的两个源头
Manifest 里的<uses-permission>是“申请意向书”，运行时申请才是“实际动作”。没写声明的权限，运行时申请一定失败，日志里会提示权限未在清单中声明。
真正容易踩的是targetSdkVersion。它决定了系统用哪一套规则来对待你的应用，跟手机系统版本是两回事。我在项目里见过太多次“代码照抄教程但就是不弹窗”，最后发现 targetSdk 还停在 22——那种情况下系统会在安装时就把危险权限全授予，requestPermissions直接回调成功，自然看不到弹窗，看着像 bug，其实是旧规则在生效。
| targetSdk | 权限相关行为变化 |
|---|---|
| ≤ 22 | 危险权限安装即授予，运行时申请不弹窗 |
| ≥ 23 | 危险权限必须运行时申请，用户可随时撤销 |
| ≥ 28 | 前台服务需声明类型，部分权限收紧 |
| ≥ 29 | 分区存储，位置权限分前台/后台 |
| ≥ 30 | 存储访问框架调整，需要 MANAGE_EXTERNAL_STORAGE 才能全盘读写 |
| ≥ 31 | 精确位置与大致位置分离，需同时声明两个定位权限 |
| ≥ 33 | 通知需要 POST_NOTIFICATIONS 运行时申请，媒体权限拆成 READ_MEDIA_IMAGES / VIDEO / AUDIO |
这张表建议打印出来贴在工位上，每次升级 targetSdk 之前对着过一遍，能省掉大量“升级完功能就坏了”的排查时间。我自己的经验是：升级 targetSdk 那次迭代，至少要留出半天专门跑权限回归，别指望它无痛。
3. 代码层怎么“打开权限”：运行时申请的完整落地
3.1 声明 + 静态检查：申请之前先问一句
先看清单写法。以相机和定位为例：
<manifest xmlns:android="http://schemas.android.com/apk/res/android"> <uses-permission android:name="android.permission.CAMERA" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> <!-- Android 13 及以上改用媒体细分权限，旧权限不再生效 --> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32" /> </manifest>maxSdkVersion这个属性很关键。Android 13 之后READ_EXTERNAL_STORAGE对图片视频基本失效，但你如果不加限制地留着它，部分设备在审核或运行时行为上会出现奇怪的兼容表现。用maxSdkVersion="32"明确告诉系统“这条只在 12 及以下有效”，是干净的做法。
代码侧，申请前必须先查当前状态，绝不能上来就 request：
// Kotlin private fun hasCameraPermission(): Boolean { return ContextCompat.checkSelfPermission( this, Manifest.permission.CAMERA ) == PackageManager.PERMISSION_GRANTED }// Java private boolean hasCameraPermission() { return ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) == PackageManager.PERMISSION_GRANTED; }为什么要先查？两个原因。第一，用户可能在设置里已经手动给过了，这时候再弹一次属于骚扰；第二，某些系统在权限已授予时调用 request 会直接同步回调 granted，逻辑上看着没问题，但用户会看到界面闪一下，体验很怪。先查再加分支，是最省心的写法。
3.2 申请：用 ActivityResultContracts 替代过时的写法
老的requestPermissions()+onRequestPermissionsResult()那套还在用，但我不推荐新项目继续写。问题出在回调是全局的，一个 Activity 里申请了五处权限，五处回调全挤在同一个方法里靠 requestCode 分支，代码很快就变成一坨。
现在的标准做法是ActivityResultContracts.RequestPermission，回调跟着调用点走：
private val cameraLauncher = registerForActivityResult( ActivityResultContracts.RequestPermission() ) { granted: Boolean -> if (granted) { openCamera() } else { handleCameraDenied() } } private fun requestCamera() { if (hasCameraPermission()) { openCamera() return } cameraLauncher.launch(Manifest.permission.CAMERA) }多权限一起申请用RequestMultiplePermissions，回调返回一个Map<String, Boolean>：
private val multiLauncher = registerForActivityResult( ActivityResultContracts.RequestMultiplePermissions() ) { result -> val cameraOk = result[Manifest.permission.CAMERA] == true val locationOk = result[Manifest.permission.ACCESS_FINE_LOCATION] == true if (cameraOk && locationOk) { startScan() } else { showMissingPermissionTip(cameraOk, locationOk) } } private fun requestScanPermissions() { multiLauncher.launch( arrayOf( Manifest.permission.CAMERA, Manifest.permission.ACCESS_FINE_LOCATION ) ) }Java 项目如果暂时不想引入这套，至少把 requestCode 定义成常量，别用魔法数字，将来加权限的时候你会感谢自己。
注意：
registerForActivityResult必须在 Activity/Fragment 创建阶段（比如成员变量初始化或 onCreate 里）调用，放在点击事件里注册会抛 IllegalStateException。这是我从崩溃日志里见过最多的一条。
3.3 被拒绝之后：三种状态必须区分对待
用户点“拒绝”和用户点“拒绝且不再询问”，系统给的信号是完全不同的，处理方式也必须不同，否则就会出现“点了没反应”的死循环。
用shouldShowRequestPermissionRationale判断，会出现三种组合：
| checkSelfPermission | shouldShowRationale | 含义 | 正确做法 |
|---|---|---|---|
| 已授予 | - | 有权限 | 直接执行业务 |
| 未授予 | true | 拒绝过一次，还能再问 | 展示解释文案后再申请 |
| 未授予 | false | 首次申请，或被永久拒绝 | 首次直接申请；否则引导去设置页 |
难点在于第二行和第三行是同一个返回值 false 的两种情况，代码没法直接区分。常见的工程解法是自己在 SharedPreferences 里记一个“是否已经申请过”的标记：
private fun handleCameraDenied() { val firstAsk = prefs.getBoolean(KEY_CAMERA_ASKED, false) if (!firstAsk) { // 首次被拒，正常提示，下次还能弹 prefs.edit().putBoolean(KEY_CAMERA_ASKED, true).apply() toast("需要相机权限才能扫码") return } val canAskAgain = ActivityCompat.shouldShowRequestPermissionRationale( this, Manifest.permission.CAMERA ) if (canAskAgain) { // 还能弹，说明是普通拒绝，展示说明后再申请 showRationaleDialog { cameraLauncher.launch(Manifest.permission.CAMERA) } } else { // 永久拒绝，只能引导去设置页 showGoSettingsDialog() } }跳设置页的写法：
val intent = Intent( Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.fromParts("package", packageName, null) ) startActivity(intent)有个变化必须记住：Android 11 起，用户连续拒绝两次（或点一次“拒绝”后再次申请再拒）就会被系统判定为“不再询问”，之后shouldShowRequestPermissionRationale一直返回 false，你的申请也不会再弹窗，只会立刻回调 denied。这意味着不能无限循环弹窗骚扰用户，产品设计上必须有一条“去设置页手动开”的兜底路径。
3.4 特殊权限：不走运行时弹窗，只能跳页面或走 appops
有一类权限不属于运行时权限体系，requestPermissions对它们无效，必须跳系统设置页：
| 能力 | Manifest 声明 | 跳转 Action |
|---|---|---|
| 悬浮窗 | SYSTEM_ALERT_WINDOW | Settings.ACTION_MANAGE_OVERLAY_PERMISSION |
| 修改系统设置 | WRITE_SETTINGS | Settings.ACTION_MANAGE_WRITE_SETTINGS |
| 所有文件访问 | MANAGE_EXTERNAL_STORAGE | Settings.ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION |
| 精确闹钟（12+） | SCHEDULE_EXACT_ALARM | Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM |
| 无障碍服务 | BIND_ACCESSIBILITY_SERVICE | Settings.ACTION_ACCESSIBILITY_SETTINGS |
| 通知监听 | BIND_NOTIFICATION_LISTENER_SERVICE | Settings.ACTION_NOTIFICATION_LISTENER_SETTINGS |
这些页面跳过去之后，用户操作完返回，你的 onResume 里要重新检查一次状态，因为跳转类权限没有回调。这是新手最容易漏的一步：跳完设置页以为完事了，回来一查还是没授予，用户明明点了允许——其实是他点完没返回，或者返回了但你没刷新 UI。
4. 调试期提效：用 adb 一行命令直接授予权限
4.1 pm grant / revoke：运行时权限的直通车
这是我调试期用得最多的两条命令，比在设置页点快了不止十倍：
PKG=com.example.demo # 授予 adb shell pm grant $PKG android.permission.CAMERA adb shell pm grant $PKG android.permission.ACCESS_FINE_LOCATION adb shell pm grant $PKG android.permission.POST_NOTIFICATIONS # 撤销 adb shell pm revoke $PKG android.permission.CAMERA几个实际约束得说清楚。第一，只能用于运行时权限（dangerous 级别），像INTERNET这种普通权限装了就有，grant 会报错也不需要。第二，包名必须是当前真实安装的包名，改包名后缀调试的记得同步改脚本。第三，mainfest 里没声明的权限，grant 会返回Unknown permission或者直接失败。第四，pm grant对 appop 类权限（悬浮窗、精确闹钟、所有文件访问）无效，得走下一节的 appops。
我习惯把它写成一个脚本，放在项目根目录，换设备换包名只改一行变量：
#!/usr/bin/env bash set -e PKG=${1:-com.example.demo} echo ">> target package: $PKG" adb shell pm grant "$PKG" android.permission.CAMERA || true adb shell pm grant "$PKG" android.permission.RECORD_AUDIO || true adb shell pm grant "$PKG" android.permission.ACCESS_FINE_LOCATION || true adb shell pm grant "$PKG" android.permission.ACCESS_COARSE_LOCATION || true adb shell pm grant "$PKG" android.permission.READ_MEDIA_IMAGES || true adb shell pm grant "$PKG" android.permission.POST_NOTIFICATIONS || true echo ">> done" adb shell dumpsys package "$PKG" | grep -A 30 "runtime permissions"|| true是为了让某一条失败不中断整个脚本，比如在老系统上POST_NOTIFICATIONS根本不存在，报错很正常。最后那句dumpsys是用来确认结果的，比盲信命令返回值靠谱。
4.2 appops：那些 pm grant 管不了的特殊权限
appops是更底层的一套权限开关，覆盖范围比运行时权限广。常用的几条：
PKG=com.example.demo # 悬浮窗 adb shell appops set $PKG SYSTEM_ALERT_WINDOW allow # 所有文件访问 adb shell appops set $PKG MANAGE_EXTERNAL_STORAGE allow # 精确闹钟 adb shell appops set $PKG SCHEDULE_EXACT_ALARM allow # 修改系统设置 adb shell appops set $PKG WRITE_SETTINGS allow # 查看某应用的相关 op 状态 adb shell appops get $PKGappops get的输出信息量很大，会列出每个 op 当前的模式（allow / deny / ignore / default），排查“明明给过了为什么还是不行”时，先看这里的状态是不是 allow，能排掉一半的误判。
提示：后台定位没法直接
pm grant，系统要求先有前台定位。稳妥顺序是先 grant 精确定位，再 grant 后台定位，否则部分系统会直接拒绝。这个顺序问题我在至少三台不同定制系统上踩过。
4.3 把命令塞进开发工具：External Tools 与运行配置
每天开终端敲命令也烦，Android Studio 支持把外部命令挂成菜单项。路径是 Settings → Tools → External Tools → 加号，Program 填 adb 的绝对路径，Arguments 填shell pm grant $Prompt$:$Prompt$ ...之类，用$Prompt$让人工输入包名和权限名。配置好之后在菜单里一键触发，比切终端快。
更省事的做法是挂在 Run Configuration 的 Before launch 里，加一个 External Tool，每次跑应用前自动把权限灌一遍。代价是每次启动都多等一两秒，看个人取舍。我自己是没挂自动的——偶尔需要验证“未授权状态下应用的表现”，自动灌权限反而会掩盖问题，所以做成手动菜单更合适。
4.4 权限状态被改了但应用没反应
这是调试期的高频疑问：用 adb 授予了权限，代码里checkSelfPermission也返回 GRANTED，但应用的行为还是旧的。原因通常是应用在启动时把权限状态缓存进了内存，或者相机、定位这类资源已经在无权限状态下初始化失败并进入了降级分支。
解决办法很土但有效：授予权限后，用adb shell am force-stop $PKG强杀一次再重启，或者干脆在应用里监听onResume重新检查。前者适合调试，后者才是产品该有的健壮性。
5. 常见问题与排查实录
5.1 设备连不上：按这个顺序排
| 现象 | 可能原因 | 处理 |
|---|---|---|
| adb devices 列表为空 | 线只供电、驱动缺失、USB 调试未开 | 换线换口，重开调试，重启 adb 服务 |
| 显示 unauthorized | 手机端授权框没点或点了拒绝 | 撤销授权后重新插线，重新点允许 |
| 显示 offline | adb 服务与设备版本不匹配 | adb kill-server 后重连，必要时升级 platform-tools |
| 安装报 USER_RESTRICTED | 系统的 USB 安装开关没开 | 开发者选项里打开对应开关 |
| 连接一会就断 | 系统省电策略或自动断开调试 | 关闭电池优化，保持屏幕常亮 |
5.2 权限给了但不生效：三个常见误判
第一种，给的是旧权限名。Android 13 之后READ_EXTERNAL_STORAGE对媒体文件基本无用，必须用READ_MEDIA_IMAGES这一组，脚本里还留着旧权限的话，grant 成功了但功能依然读不到文件。
第二种，给的是 A 权限，代码查的是 B 权限。比如定位，前台和后台是两个独立权限，只给了前台，代码里查后台自然是拒绝。
第三种，应用进程没有重新走权限检查。前面说过，强杀重启最快。我通常会顺手在 Logcat 里过滤Permission关键字，系统的权限拒绝日志一般都带这个词，比翻自己的日志快。
5.3 存储权限的几个版本坑
WRITE_EXTERNAL_STORAGE在 Android 10 之后基本废弃，11 之后连读都受限。如果你的应用确实需要全盘文件管理（比如文件管理器类），得走MANAGE_EXTERNAL_STORAGE加appops，而且这个权限在应用商店审核里属于高敏感，用之前想清楚是不是真的需要——绝大多数场景用 Storage Access Framework 或媒体库接口就够了，没必要去碰这个。
还有一条经常被忽略：应用卸载重装后，MANAGE_EXTERNAL_STORAGE的 appop 状态会重置为 default，脚本要重新跑。
5.4 通知不弹、后台定位拿不到
通知这块，Android 13 起POST_NOTIFICATIONS是货真价实的运行时权限，不申请就是静默丢弃，代码不报错，只是用户什么也看不到。排查时先确认清单里声明了，再确认代码里申请了，最后用pm grant补一刀验证是不是权限问题——三步走完基本能定位。
后台定位的坑更细。系统要求先有前台定位，才能申请后台定位；而且后台定位申请弹出来的对话框跟普通权限不一样，是一个跳转式的说明页，很多用户看到就直接返回了，回来状态还是没变。产品上必须接受“后台定位可能永远拿不到”这个现实，做降级方案。
5.5 几条比较私人的避坑习惯
我给自己定了三条规矩，用下来省了很多事。
第一条：任何新接入的权限，先在 Manifest 里加上，再在代码里包一层统一的权限工具类，所有申请走同一个入口。这样将来要加“申请前弹说明”“统计拒绝率”这类需求，改一处就行，不至于散落在二十个 Activity 里。
第二条：调试脚本和 Manifest 保持同步更新。脚本里少一条权限，下次换机器调试就要多点一次设置页，一次两次无所谓，一天二十次就是灾难。
第三条：每次升级 targetSdk，专门跑一遍“权限回归清单”——相机、定位、存储、通知、蓝牙、后台任务各点一次，看有没有静默失败。这个清单我存在项目 wiki 里，五年了还在用，是最划算的一份文档。
5.6 编译期的权限告警别无视
在调用需要权限的 API 时，如果没加@RequiresPermission注解，Lint 会报MissingPermission。这个警告我很建议开着当错误处理，因为它拦住的往往不是“忘了申请”，而是“在错误的时机调用了需要权限的 API”——后者才是真正难查的那类问题。加注解的写法：
@RequiresPermission(Manifest.permission.CAMERA) private fun openCameraInternal() { // 这里可以放心调用相机 API }加上之后，所有调用点都会被 Lint 检查，编译器会替你记住“这个函数调用前必须有相机权限”，比人脑可靠。
6. 我自己的固化流程
折腾了这么多年，现在我的做法已经比较固定了：新项目初始化的时候，先把权限工具类、调试脚本、External Tools 配置这三样东西一次性搭好，后面所有权限相关的需求都往里塞。权限工具类负责“检查—申请—拒绝分支—跳设置页”这条完整链路，脚本负责调试期批量灌权限，External Tools 负责让我不用切终端。这三样加起来大概两百行代码加一个 shell 文件，但能省掉后续无数次重复劳动。
另外有个小技巧值得单独说：调试权限相关问题时，我习惯先手动在设置页把所有权限关掉，然后完整走一遍首次申请流程，观察弹窗文案、拒绝后的提示、二次申请的合理性。这一步能发现很多“只在干净设备上才出现”的问题，比如首次申请时没有前置说明、拒绝后没有兜底路径、二次申请弹窗文案和第一次重复等等。这些问题在已经授权过的开发机上永远测不出来，但真实用户第一眼就会撞上。
最后提一句心态上的事。权限这块的复杂度不在于代码难写，而在于版本碎片化——同一段逻辑在不同系统版本、不同定制系统上的表现都可能不一样。所以遇到“明明按文档写了却不行”的情况，先别怀疑自己的代码，去看 targetSdk、看系统版本、看那个权限是不是被归到了 appop。把这篇文章里的三层模型记住，再配合dumpsys和appops get两个诊断命令，绝大多数问题都能自己定位到根因，不用再漫无目的地搜索。
