企业官网建设流程全解析

• 文档
• 教程
• 知识库

本文以 在Android M中权限被拒绝时该如何处理 为核心，结合仓库中 权限 - 第一篇、权限 - 第二篇、权限 - 第三篇、权限 - 第四篇 系列译文展开，讲解 Android M（Android 6.0）运行时权限模型下，如何正确判断用户拒绝权限的意图、何时该展示解释理由，以及如何处理"不再提示"导致的永久拒绝场景。

导读

从 Android M（API 23）开始，危险权限不再于安装时一次性授予，而需要在运行时由用户逐个确认。开发者必须面对"权限被拒绝"这一常态：是用户第一次拒绝、还是勾选了"不再提示"永久拒绝？Android 官方为此在 SDK 中提供了shouldShowRequestPermissionRationale()方法，本文围绕该方法的返回值语义、三种拒绝场景的判断逻辑、Fragment 中的已知 Bug 与绕行方案，并结合仓库内权限系列译文给出完整的可落地代码实践，帮助你构建稳定、不崩溃且对用户友好的运行时权限处理流程。

一、背景：Android M 为何要引入"运行时权限"

在 Android M 之前（API 1.0 起），权限的声明方式非常简单——在AndroidManifest.xml中使用<uses-permission>声明即可，用户在安装时统一授权。Android M 改变了这一模型：

• 正常权限（Normal Permission）：如MODIFY_AUDIO_SETTINGS，对用户隐私基本没有风险，安装时由系统自动授权；
• 危险权限（Dangerous Permission）：如RECORD_AUDIO、CAMERA、定位等，可能影响用户安全或隐私，必须在运行时由用户明确授权。

这里有一个关键前提：只有将targetSdkVersion设置为23 或更高，应用才会触发运行时权限请求机制。正如 权限 - 第一篇 所强调的，当时已有不少开发者无意中将targetSdkVersion升到最新版本，却未实现运行时请求权限的代码，导致应用正常运行中直接崩溃。因此处理权限被拒绝，是升级到 API 23 后绕不开的必修课。

二、shouldShowRequestPermissionRationale()：判定"是否该解释"的核心方法

Android M Preview 2 的 SDK 引入了Activity.shouldShowRequestPermissionRationale()方法，用于告知 App：在调用需要权限的功能之前，是否应该向用户展示"为什么需要该权限"的理由。

该方法的返回值取决于权限当前的"历史状态"，具体语义如下：

简而言之：返回值true是"需要向用户解释"的明确信号；而返回值false则可能对应两种截然不同的状态——"从没问过"或"永远不会再给"。这一点决定了我们无法仅凭返回值区分首次安装与永久拒绝，需要在业务层自行记录请求历史（详见下文第五节）。

三、三种场景的完整处理流程（可复用的代码模式）

要将shouldShowRequestPermissionRationale()用好，必须把它嵌入标准的"检查 → 请求 → 回调"流程中。下面这套代码模式综合了 权限 - 第一篇 的权限检查封装与 权限 - 第三篇 的请求回调逻辑，并在其中补入理由展示环节。

3.1 第一步：检查权限是否已被授予

在 API 23 的Context中可使用checkSelfPermission()检测授权状态，但为了兼容 M 之前的系统，更稳妥的做法是使用ContextCompat.checkSelfPermission()——在 Marshmallow 之前的设备上，该调用总是返回PERMISSION_GRANTED（旧系统在 Manifest 声明后即默认授予），因此同一份代码在所有 OS 层级都能工作，无需手写 API 级别判断：

// PermissionsChecker.java —— 参考 issue-40 权限系列第一篇 class PermissionsChecker { private final Context context; public PermissionsChecker(Context context) { this.context = context; } // 只要有一个权限缺失，即返回 true public boolean lacksPermissions(String... permissions) { for (String permission : permissions) { if (lacksPermission(permission)) { return true; } } return false; } private boolean lacksPermission(String permission) { return ContextCompat.checkSelfPermission(context, permission) == PackageManager.PERMISSION_DENIED; } }

把检测逻辑独立成类，是为了让 App 中所有 Activity 复用，避免重复代码、提升可维护性。

3.2 第二步：请求权限并接收回调

requestPermissions()的运作方式与startActivityForResult()类似：系统弹出授权对话框，用户在对话框中的选择最终通过onRequestPermissionsResult()回调返回：

// PermissionsActivity.java —— 参考 issue-40 权限系列第三篇 public class PermissionsActivity extends AppCompatActivity { private static final int PERMISSION_REQUEST_CODE = 0; private PermissionsChecker checker; private boolean requiresCheck; @Override protected void onResume() { super.onResume(); if (requiresCheck) { String[] permissions = getIntent().getStringArrayExtra(EXTRA_PERMISSIONS); if (checker.lacksPermissions(permissions)) { // 调用系统的运行时权限请求 ActivityCompat.requestPermissions(this, permissions, PERMISSION_REQUEST_CODE); } else { allPermissionsGranted(); } } else { requiresCheck = true; } } @Override public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) { if (requestCode == PERMISSION_REQUEST_CODE && hasAllPermissionsGranted(grantResults)) { requiresCheck = true; allPermissionsGranted(); } else { requiresCheck = false; // 权限被拒绝：进入"解释或引导"分支，详见下一节 handlePermissionDenied(); } } private boolean hasAllPermissionsGranted(@NonNull int[] grantResults) { for (int grantResult : grantResults) { if (grantResult == PackageManager.PERMISSION_DENIED) { return false; } } return true; } }

3.3 第三步：在回调中利用shouldShowRequestPermissionRationale()分流

用户拒绝权限后，onRequestPermissionsResult()收到的grantResults并不能告诉你"用户是第一次拒绝"还是"勾选了不再提示"。此时就轮到shouldShowRequestPermissionRationale()登场：

private void handlePermissionDenied() { // 从 Intent 中取出本次请求的权限列表 String[] permissions = getPendingPermissions(); // 只要仍有权限允许"再次询问"，就应当展示解释理由 boolean shouldExplain = false; for (String permission : permissions) { if (ActivityCompat.shouldShowRequestPermissionRationale(this, permission)) { shouldExplain = true; break; } } if (shouldExplain) { // 场景 A：用户拒绝过，但尚未勾选"不再提示" // 展示为什么需要该权限的理由，然后重新请求 showRationaleDialog(permissions); } else { // 场景 B：全部权限均被永久拒绝（勾选了"不再提示"） // 返回 false，继续请求会被自动拒绝，应引导用户前往系统设置页 openAppSettings(); } }

说明：在旧系统或支持库场景中，也可使用ActivityCompat.shouldShowRequestPermissionRationale(Activity, String)（对应 support-v4 中的实现），它会在低版本系统上返回合适的默认值，使同一套逻辑保持兼容。

四、"不再提示"与永久拒绝：false背后的陷阱

当用户勾选了"不再提示"（部分文档中亦称"不再询问"）并再次拒绝后，shouldShowRequestPermissionRationale()会返回false——此时系统对后续权限请求一律自动拒绝，任何再次requestPermissions()的尝试都注定失败。

正如 权限 - 第三篇 所指出：开发者无法得知用户是否勾选了"不再提示"，因此要按最坏情况做预案。对于 App 运行所必需的核心权限，如果被永久拒绝，正确做法是弹窗明确告知用户原因，并提供"前往设置"的入口，指引用户在系统设置页手动授权：

// 引导用户前往系统应用详情页手动授权 private void startAppSettings() { Intent intent = new Intent(android.provider.Settings.ACTION_APPLICATION_DETAILS_SETTINGS); intent.setData(Uri.parse("package:" + getPackageName())); startActivity(intent); }

同时注意，从用户的视角看，还存在另一条改变授权状态的路径：用户随时可以进入系统设置的应用详情页手动撤销某个权限。因此不应只在启动时检查一次权限，而应在 Activity 恢复时（onResume()）重新检测——权限 - 第二篇 正是这样做的：用户在设置页撤销权限后返回 App，onResume()检测到权限缺失，即可立即转入请求流程，防止后续调用权限功能时崩溃。

五、Fragment 中的已知 Bug 与绕行方案

本文主题方法在 Android M Preview 2 的 SDK 中存在一个已知 Bug：

Fragment.shouldShowRequestPermissionRationale()会一直返回false。

也就是说，在 Fragment 中直接调用该方法，即使权限曾被用户拒绝过，也拿不到true，导致"解释理由"分支永远无法触发。该问题在后续版本中修复，但在 Preview 2 阶段，官方给出的绕行方案是在 Fragment 中调用宿主 Activity 的方法：

// Fragment 中绕行 Bug 的正确写法 getActivity().shouldShowRequestPermissionRationale(permission);

结合上一节的完整流程，当权限处理逻辑写在 Fragment 内时，onRequestPermissionsResult()中判断"是否需要解释"也应统一走getActivity()的路径，确保判断结果与系统真实状态一致。

六、最佳实践：什么时候才该解释与请求

shouldShowRequestPermissionRationale()提供了"是否该解释"的判断能力，但用好它还需要配合正确的权限请求策略。综合 权限 - 第四篇 的总结，以下几点值得在工程中落实：

1. 把权限分为"核心必需"与"非必需"两类。核心权限（如相机 App 的CAMERA）缺失时 App 无法工作，可启动即请求、拒绝后引导设置页；非必需权限（如地理标签所需的定位权限）应在功能真正被触发的时机请求，而非启动时一股脑弹窗。
2. 避免启动时轰炸式请求。用户对 App 的第一印象若是一连串权限弹窗，很可能会直接卸载。仅在需要时请求，既帮助用户理解每个权限的用途（提高授予率），也让用户更快体验 App 价值。
3. 只请求真正需要的权限。随着业务演进，曾经的必需权限可能已失去用途，应定期审查 Manifest 并清理多余的<uses-permission>声明。
4. 警惕"清除数据"会重置权限。用户清除应用数据时，不仅清空业务数据，还会重置所有权限状态——此前已授权的权限全部回到未授予状态，shouldShowRequestPermissionRationale()的判断历史也随之归零。这既是测试权限流程的便捷手段，也是客服应对"为什么已同意还要再问"问题的标准答案。
5. 结合业务记录做兜底。由于false无法区分"从未请求"与"永久拒绝"，建议自行持久化记录"是否已请求过某权限"。若返回false且历史记录显示已请求过，即可判定为永久拒绝，直接走"设置页引导"分支，避免让用户反复看到无意义的请求弹窗。

七、总结

处理 Android M 运行时权限被拒绝，核心在于准确识别用户的拒绝意图。shouldShowRequestPermissionRationale()提供了三态语义：首次安装返回false（直接请求即可）、用户拒绝后返回true（应展示理由）、永久拒绝后返回false（应引导设置页）。配合ContextCompat.checkSelfPermission()检查、requestPermissions()请求与onRequestPermissionsResult()回调，即可搭建一套完整的权限生命周期管理。

同时不要忘记两个关键细节：M Preview 2 中Fragment.shouldShowRequestPermissionRationale()的 Bug 需通过getActivity()绕行；权限状态可能随时被系统设置或"清除数据"改变，因此要在onResume()中反复校验，而不是只在启动时检查一次。需要进一步深入时，可继续阅读仓库内的 权限 - 第一篇 至 权限 - 第四篇 完整系列，其中包含从权限声明、检查封装到请求回调、设置页引导的逐步演进代码。

• 文档
• 教程
• 知识库