TG咨询同一个应用在两部手机上表现不同，不一定是代码故障：系统版本、应用目标 SDK，以及厂商对后台运行和权限入口的调整，都可能改变授权流程。要做好Android应用在定制系统上的权限差异验证，不能只看安装时弹窗；还要检查用户能否授权、拒绝后功能如何响应，以及设置变更后应用是否及时更新状态。
先把测试条件固定下来
每次比较至少记录手机型号、系统版本、应用版本、目标 SDK、权限初始状态和网络条件。定制系统可选用 OPPO ColorOS、vivo OriginOS 等作为不同实现样本，并与接近原生的 Android 环境对照；不要把某一品牌的表现直接推广到所有机型。系统更新或应用升级后，应重新核验。
权限清单按功能拆分，而非只抄 manifest：例如定位、通知、照片或视频访问、麦克风、相机，以及后台定位等特殊授权。记录每项权限的申请时机、系统页面名称、授权结果、对应功能和拒绝后的提示。
逐项核验的操作流程
- 恢复基线：卸载重装，或在系统应用信息页清除应用数据；确认权限回到未申请状态。清除数据会删除应用本地状态，先确认测试环境可重置。
- 触发实际功能：从需要权限的功能入口操作，观察系统是否弹窗、应用是否说明用途。若功能尚未触发，不应预先申请无关权限。
- 分别测试结果：对每项权限测试首次允许、拒绝、再次请求，以及在系统设置中撤销后重新打开应用。记录是否继续可用、是否提供替代路径、是否出现误导性提示。
- 核对系统设置：进入应用信息和权限管理页，检查当前授权、仅使用期间授权、精确或大致位置等选项。不同系统的菜单名称和排列可能不同，以实际设备显示为准。
- 检查后台与重启：对需要持续工作的功能，测试锁屏、切后台、强制停止和重启后的行为。把权限拒绝与省电限制分开记录，避免把后台进程被限制误判为权限缺失。
- 保存证据：记录系统版本、操作步骤、结果和截图；连接调试设备时，可用 adb shell dumpsys package 包名 查看包信息，并用 adb shell appops get 包名 辅助检查部分应用操作状态。命令输出会随系统版本变化，不能替代用户界面验证。
容易出现差异的权限场景
| 场景 | 重点核验 | 常见误区 |
|---|---|---|
| 定位 | 前台与后台请求是否分开；用户选择大致位置时功能是否合理降级。 | 把定位权限获批等同于后台持续可用。 |
| 通知 | Android 13 及之后版本中，按应用目标 SDK 和系统流程核对通知授权；检查拒绝后的应用内状态。 | 只检查应用内部开关，忽略系统通知权限。 |
| 照片与视频 | 根据系统版本、目标 SDK 和所用 API，检查完整访问、所选内容访问或系统选择器路径。 | 假设用户拒绝广泛访问后，选择单张照片也必然失败。 |
| 麦克风、相机 | 授权后实际调用设备；撤销权限后确认应用能恢复并给出清楚说明。 | 只验证弹窗出现，没有验证功能调用结果。 |
怎样判断问题来自系统还是应用
同一应用版本、相同权限状态下，在两个系统上重复同一条操作路径。如果差异只出现在后台，优先检查厂商的自启动、省电或后台活动管理；如果系统显示已授权但功能仍失败，再检查应用自身的权限回调、资源占用和错误处理。一次现象不足以定位原因，至少要重置状态后复测，并记录是否稳定复现。
最终报告应逐项写明“系统条件—操作—预期—实际—证据”，并注明差异属于系统行为、应用适配还是测试环境限制。这样形成的Android应用在定制系统上的权限差异验证结果，才能供开发、测试和支持人员复查，而不是停留在“这台手机不行”。
常见问题
只测一台定制系统手机够吗？
适合初步排查，不足以代表其他品牌或版本。关键权限至少覆盖目标用户常见的系统版本和不同厂商实现。
用户拒绝权限后，应用必须退出吗？
不必。应停止依赖该权限的功能，并说明影响；若存在不需要该权限的替代路径，可以继续提供。
权限列表显示已允许，为什么功能仍失败？
还需检查后台限制、系统特殊访问、应用状态及具体 API 调用结果。普通运行时权限的授权状态不等于后台任务一定能执行。
系统更新后需要重测吗？
需要，至少复核权限入口、授权选项和核心功能路径；系统升级可能改变行为或设置位置。