第2章：前置条件检查清单

在编写任何 Runtime 权限申请代码之前，团队必须完成四项前置条件的逐一确认。本章提供标准化的检查清单与操作流程，确保权限申请方案在正确的应用类型、目标版本、权限等级和隐私政策基础上展开，避免因前置条件遗漏导致的兼容性 crash 或合规风险。

2.1 适用场景

本章流程适用于以下项目节点：

场景	说明
新应用立项	首次开发 Android 应用，需从零完成权限方案设计
旧应用适配	现有应用 targetSdk 升级至 33+，需补充 Runtime 权限流程
合规审计	因隐私政策或应用商店要求，重新梳理权限申请逻辑
模块重构	权限相关模块进行架构重构，需重新评估前置条件

2.2 前置条件（本章的前置条件）

在开始本章检查清单操作之前，团队应已具备以下基础：

• 产品需求文档（PRD）已明确应用的核心功能与所需权限的对应关系。
• 项目已创建 Android 工程，build.gradle 文件可编辑。
• 法务或合规团队已提供隐私政策初稿或模板。
• 开发环境已配置 Android Studio 及目标 SDK 的 platform 资源。

2.3 操作步骤

四项检查按顺序执行，每一步完成后在《前置条件检查清单》中记录结果。

步骤 2.3.1：应用类型识别

1. 查阅项目配置：从 AndroidManifest.xml 和产品文档确认应用是否为系统预装应用、普通商店应用或企业签名的特殊权限应用。
2. 判断 sharedUserId：若存在 android:sharedUserId="android.uid.system"，则属于系统级应用，部分权限可通过签名授权。
3. 记录结果：在检查清单中填写应用类型（三选一：普通应用 / 系统预装 / 企业签名）。

步骤 2.3.2：目标平台版本确认

1. 读取 build.gradle：定位 minSdk、targetSdk、compileSdk 三个参数。
2. 校验版本阈值：targetSdk 必须 ≥ 33（Android 13）才支持 POST_NOTIFICATIONS 等新版 Runtime 权限；若 targetSdk < 33，需先升级。
3. 填写版本矩阵：将三个版本号写入清单。

步骤 2.3.3：权限等级分类

1. 枚举所有声明权限：收集 AndroidManifest.xml 中所有 <uses-permission> 标签。
2. 对照官方分级：使用下方表格对每个权限进行分类。
3. 标记动态申请项：危险权限和特殊权限（如 MANAGE_EXTERNAL_STORAGE）需走 Runtime 申请流程。

权限等级	申请方式	典型示例	备注
普通 (Normal)	安装时自动授予	INTERNET、ACCESS_NETWORK_STATE	无需动态申请
危险 (Dangerous)	运行时动态申请	CAMERA、RECORD_AUDIO、ACCESS_FINE_LOCATION	必须弹窗 + 回调处理
签名 (Signature)	系统签名自动授权	BIND_ACCESSIBILITY_SERVICE	普通应用无法声明
特殊 (Special)	系统设置页面跳转授权	SYSTEM_ALERT_WINDOW、MANAGE_EXTERNAL_STORAGE	需 ACTION_MANAGE_..._SETTINGS

步骤 2.3.4：用户隐私政策准备

1. 拟定隐私政策文案：明确列出将申请的权限及其对应业务功能。示例片段：

本应用需要以下权限提供服务：
- 相机权限：用于扫描二维码、拍摄照片上传头像。
- 位置权限：用于在地图上标记您的当前位置。
- 通知权限：用于发送订单状态更新提醒。

您拒绝授权不影响其他功能的使用，可随时在系统设置中关闭。

2. 确定弹窗时机：在首次申请权限之前弹出隐私政策说明弹窗（Android 13+ 推荐使用系统自带的 shouldShowRequestPermissionRationale 前置对话框）。
3. 准备拒绝处理逻辑：当用户拒绝权限时，提供功能降级体验文案，而非直接崩溃。
4. 合规存档：将隐私政策页面 URL 或本地 HTML 文件路径记录在清单中。

2.4 输入 / 输出物

类型	名称	来源 / 去向
输入	产品需求文档（PRD）	产品经理提供
输入	AndroidManifest.xml	项目源码仓库
输入	build.gradle（Module 级）	项目源码仓库
输出	《前置条件检查清单》（已签署）	归档至项目文档目录
输出	《权限分级总表》	交付开发与测试团队
输出	《隐私政策摘要说明》	提交法务审核

2.5 责任边界

角色	职责
产品经理	提供功能-权限映射表；确认隐私政策中功能描述准确。
开发工程师	执行应用类型识别、版本确认、权限分类；编写检查清单。
法务 / 合规	审核隐私政策文案是否符合 GDPR、CCPA 及目标商店（Google Play / 国内）要求。
测试工程师	验证检查清单中的版本号和权限声明与工程一致，回归权限弹窗流程。
技术负责人	审批《前置条件检查清单》，签字确认后方可进入编码阶段。

2.6 记录材料

本章需产出并归档以下记录材料：

• 《前置条件检查清单》（模板示例）：

| 检查项               | 结果       | 检查人   | 日期       |
|----------------------|------------|----------|------------|
| 应用类型识别         | 普通应用   | 张三     | 2025-04-01 |
| targetSdk ≥ 33       | 34         | 张三     | 2025-04-01 |
| 权限等级分类完成     | 8项已分类  | 李四     | 2025-04-01 |
| 隐私政策文案备妥     | v2.1 已审核| 王五     | 2025-04-01 |
| 技术负责人签字       | 已批准     | 赵六     | 2025-04-02 |

• 《权限分级总表》：列出所有声明的权限、等级、申请方式、备注说明。
• 《隐私政策摘要说明》：包含权限列表、业务目的、拒绝后果的文字截图或 HTML 文件。

2.7 异常处理

异常情况	处理措施	责任人
targetSdk < 33 无法升级	评估业务影响，若必须保留旧版，则放弃新版 Runtime 权限特性；记录为技术债务。	技术负责人
应用类型为系统预装	部分权限可通过签名自动授权，但仍需按 Runtime 流程兜底，避免在非预装设备上崩溃。	开发工程师
权限等级判断争议	以 Android 官方文档 Protection level 字段为准；特殊权限对照 PackageManager API 确认。	开发工程师 + 技术负责人
隐私政策未通过法务审核	暂停权限申请编码，等待法务反馈修改后重新审核；检查清单不可提前签字。	产品经理 + 法务
清单中版本号与实际工程不一致	立即修正清单或工程，保持二者严格同步；重新执行检查步骤。	开发工程师

2.8 验收标准

本章工作完成需同时满足以下验收条件：

• AC-1：《前置条件检查清单》四项检查结果全部为“通过”，且技术负责人已签字。
• AC-2：《权限分级总表》与实际 AndroidManifest.xml 声明的权限列表完全一致，等级分类正确。
• AC-3：隐私政策文案已获法务合规批准，并通过邮件或文档系统存档。
• AC-4：工程中 targetSdk 已设置为 ≥ 33（或已记录例外债项）。
• AC-5：所有异常情况（如有）均已记录在《前置条件检查清单》备注栏，并有明确的处理方案。