📚 课程目录第2章权限超时概述

权限超时概述：权限请求流程与超时机制

说实话，权限超时这个事儿，刚入行的时候我真没当回事。那时候觉得用户点个允许就行，能有多复杂？直到有一次看到一个授权弹窗卡了20秒才消失，紧接着日志里就蹦出来一个ANR——嗯，那个夜晚我印象特别深。后面我花了整整一周，把权限请求流程从头到尾捋了一遍，才搞清楚这背后的一整套超时机制。

你想想看，权限请求本质上是一个跨进程交互。应用发起请求，系统服务收到后弹出对话框，然后眼巴巴等着用户点「允许」或「拒绝」。如果用户不理它，或者系统因为某些原因迟迟没收到响应，那就得有个兜底策略——超时。这个超时阈值是多少？不同版本有啥差异？处理不好会怎样？这些都是我们今天要聊的核心。

权限请求的标准流程

在很多初学者眼里，权限请求就是调个requestPermissions()，然后等回调。其实背后的链路比这个长得多。我个人习惯把这个流程拆成四个阶段：

应用发起请求：调用系统API，把权限列表和回调一起发给ActivityManagerService（AMS）。
系统服务分发：AMS往PackageManagerService（PMS）发一个检查请求，看这个权限是普通权限还是危险权限。如果是危险权限，就走弹窗。
弹窗等待用户操作：系统弹出一个授权对话框，应用进程挂起等待。这时候如果用户一直不操作，计时器就开始跑了。
回调或者超时：用户点了按钮，系统把结果丢给应用；或者超时了，系统强制取消，给应用一个拒绝的结果。

这里面最容易出问题的就是第三步。我记得在Android 8.0之前，弹窗是直接由应用进程管理的——也就是说如果应用进程挂掉了，弹窗也跟着消失。后来改成了系统进程管理，弹窗变成了对话框形式的Activity，这就引入了弹窗生命周期和超时的概念。

用户响应超时：到底超了谁的时间？

所谓「用户响应超时」，说白了就是系统给用户留的思考时间。系统并不知道你在犹豫，它只知道对话框发出去之后，过了一定时间没收到点击事件。那它就默认用户不想给了，或者用户已经不在屏幕前了。

具体到代码层面，超时是靠一个Handler的延迟消息实现的。大致逻辑是这样的：

// 伪代码，仅示意
void showPermissionDialog() {
    // 弹出对话框
    startActivityForResult(intent, PERMISSION_REQUEST_CODE);
    // 启动超时计时器，默认10秒
    mHandler.postDelayed(mTimeoutRunnable, PERMISSION_TIMEOUT_MS);
}

private Runnable mTimeoutRunnable = () -> {
    // 超时后强制返回拒绝结果
    onPermissionResult(PERMISSION_DENIED);
    dismissDialog();
};

这个PERMISSION_TIMEOUT_MS的值，就是我们要重点关心的系统默认超时阈值。

系统默认超时阈值：不同版本不一样

我查过AOSP源码，也自己在不同版本的真机上实测过。这里我把主要版本的默认超时阈值整理成了表格，方便你对照：

Android版本	默认超时阈值	备注
Android 6.0 ~ 8.1	10 秒	由应用进程的Handler控制，容易受应用主线程卡顿影响
Android 9.0	15 秒	改由system_server进程管理，阈值增大
Android 10 ~ 11	10 秒	又调回了10秒，但改成由ActivityManager线程控制
Android 12+	20 秒	Google增加了兜底机制，阈值提升到了20秒

注意：第三方ROM（比如MIUI、Flyme、EMUI）往往会修改这个阈值。我曾经遇到过一台某品牌手机，权限弹窗超时长达40秒——不是它良心，而是他们的定时器代码有bug。所以不要只依赖官方阈值，一定要在目标机型上做授权测试。

不同Android版本的差异：不仅仅是时间数字

除了超时阈值的数值变化，版本之间还有一些架构上的差异，直接影响了ANR的概率。我觉得最有价值的几个点：

Android 6.0 引入了运行时权限：之前权限直接在安装时授予，没有弹窗超时这个概念。从6.0开始，系统有了超时机制，但实现很简陋——应用进程的UI线程如果卡了，超时回调也可能跟着卡。
Android 9.0 把权限管理移到系统侧：弹窗变成了一个系统级的Activity，不依赖应用进程。这样一来，即使应用主线程卡顿，超时计时还是正常走的——反而更容易触发ANR。我遇到过一种情况：应用在主线程做了一个耗时操作，弹窗已经弹出来了，但点击事件的回调迟迟没发出去，结果超时了。
Android 12+ 引入了权限超时自动撤销：如果用户长时间不授权（超时），系统不仅返回拒绝，还会把这个权限标记为「已超时」，后续再申请时会直接拒绝，不再弹窗。这个改动影响很大——如果你的应用需要反复申请某个权限，超时一次后就不能再弹了，只能引导用户去设置页面手动开启。

一个典型ANR案例：权限超时导致的系统ANR

我印象很深的一次项目经历是这样的：我们有一个视频录制应用，在Android 11设备上运行时，只要网络稍差就ANR。一开始以为是网络模块的问题，排查了一周没结果。后来我抓了几份trace文件，发现主线程卡在了onRequestPermissionsResult的回调里。仔细一看，原来权限弹窗超时后，系统已经回调了onRequestPermissionsResult，但这个回调里我们做了网络请求——而且是在主线程做的。网上之前有文章说权限回调不会卡主线程，这就是个大误解。

权限超时的SVG流程概览

下面这张图把权限请求到超时的完整路径画了出来。你可以看到整个流程中，哪个环节可能引发ANR，哪个环节是我们可以干预的。

避坑指南：权限超时测试要点

基于上面的分析，我在实际项目中总结了几条经验，分享给你：

想复现权限超时ANR？ 很简单：在授权弹窗弹出来之后，让应用主线程卡住10秒以上，然后点击「允许」，大概率触发ANR。因为主线程卡住会导致回调无法及时被处理，而超时计时却不会等你。

我曾经踩过的一个坑：在一款Android 9的设备上，权限弹窗超时后系统强制回调了DENIED，但我们的应用没有处理onRequestPermissionsResult中的UI操作（比如隐藏加载动画），导致用户以为还在授权中，疯狂点击屏幕，最后应用无响应。后来我加了一个超时监听器，超时后主动取消加载状态。

最后说一点：不同厂商对权限超时阈值的修改非常隐蔽。我建议在测试计划中至少包含以下三个测试用例：

无操作超时：弹出弹窗后不点任何按钮，等待30秒，检查是否ANR。
点击后卡顿：在onRequestPermissionsResult回调中故意sleep 5秒，看系统会不会二次超时。
连续多次申请：快速重复申请同一权限（超时一次后再次申请），观察系统行为是否一致。

把这些测试做透了，权限相关的ANR基本上就能防住百分之八十。剩下的那百分之二十，往往跟系统定制有关，那就需要拉上你们厂商对接的同学一起看了。