用户拒绝权限后能否再次请求的规则因平台而异
别名: 权限再申请 · Don't Ask Again · 跳转设置
概念解释
人点了「不允许」之后，应用还能不能再弹出系统权限框，由操作系统规定，产品不能按自己的挽留策略来。有的系统在未勾选「不再询问」之前允许再调一次系统对话框；有的系统拒绝后就不再为该应用显示系统框，只能请人自己去设置里打开。把一端的「再问一次」搬到另一端，会变成对已经说不的人反复打断，或变成点了按钮却没有任何系统对话框出现。这条只谈拒绝之后的再请求规则，不谈第一次该在安装时还是使用时问，也不谈同名权限覆盖了哪些能力。
机制
系统用一份按应用、按权限的状态机记住决定：未决定、已允许、已拒绝、拒绝且不再询问、受家长或配置文件限制。再次调用申请 API 时，操作系统按当前状态选择：弹出系统框、静默返回拒绝、或直接当无操作。iOS 一类平台在拒绝后把后续申请变成空操作，应用若仍调用，人看到的是自己的按钮没有反应。Android 一类平台允许有限次数的再次弹出，直到人选了不再询问，此后也只能去设置。厂商层还可能加自己的拦截。应用内「再试一次」如果只是再次调用同一 API，在空操作平台上等于死按钮；正确的下一步是打开该权限在设置里的那一页——而设置路径的深度和名称也因系统而异。反复在允许再弹的平台上调用，会把拒绝训练成习惯性点按，下一次真正需要时也不读。
怎么研究
把「拒绝后的第二次、第三次申请」做成条件，而不是只测第一次对话框。
自变量：平台再请求规则、拒绝后间隔（立刻 / 下一次任务 / 隔日）、第二次是系统框还是「去设置」引导。 因变量：第二次是否真的出现系统框、有多少人改口、有多少人把后续提示当骚扰关掉、到达设置页的成功率。
实验室里主试要求「请拒绝然后再允许」会高估改口率。现场要把拒因拆开：误触、当时不想用该功能、永久不想给。误触在允许再弹的平台上能被第二次框接住；永久拒绝被反复弹会恶化评分。不要把「去设置」的点击率当成授权成功——许多人点了却走丢在设置层级里。
边界
「受限制」（家长控制、企业配置）不是「已拒绝」：再请求和去设置都打不开，界面应说明是设备策略，而不是再给一个拒绝后的按钮。用户在设置里自己打开之后，应用会在下一次调用时拿到新状态，不必也不能再弹一次系统框来确认。通知权限在部分系统上有自己的再请求配额，不能套相机的规则。桌面浏览器可以在站点设置里重置，移动应用没有等价的「重置这个站点」，只能走系统设置。
怎么落地
- 拒绝后先查平台返回的状态：还可弹系统框才弹；已经是永久拒绝或空操作，就改为一步到达该权限的系统设置，并写明在设置里要打开哪一项。
- 不要用自定义对话框仿系统权限框来绕过「不能再弹」的规则，人会以为已经在回答系统。
- 验证：在两个系统上对同一能力点不允许，再立刻点产品里的「重试」。一端应出现系统框或明确的「不再询问」路径，另一端应出现可到达正确设置项的引导且不再出现系统框。若两端表现被写成同一套按钮逻辑，再请求规则没有按平台分开。