H4.04.3re-prompt requires a fresh user action设计
重新申请需要新的用户动作
别名: 重新申请 · 再次授权 · fresh user action · re-request permission
概念解释
权限被拒绝或被撤回之后，下一次系统授权弹窗必须跟在一个新的、可识别的用户动作后面：再次点了「拍摄」、再次点了「开启通知」、从设置里点了「去打开」。后台恢复、冷启动、列表刷新、定时器到时，都不能自行把弹窗叫回来。这条是重新申请的触发条件，不是禁止一切再次询问，也不是把同一次拒绝连弹多次的骚扰本身。
机制
平台把无动作的二次弹窗视为绕过「记住拒绝」。应用侧若在 onResume、推送回调或心跳里调权限 API，等于把撤回写成暂时的。要求新动作，是把授权重新接回「人正在要这项功能」：动作提供了新的情境，也提供了可放弃的点（不点就不再问）。没有这道闸，撤回和拒绝都只是推迟下一次打断，可撤回在时间上不成立。
边界
系统自己弹出的设置变更说明、或用户从系统设置打开权限后回到应用，不属于应用发起的重新申请。操作系统在「仅本次」过期后于下一次使用再问，那是平台语义，仍应落在用户再次使用该功能时，而不是应用在空闲时预问。无障碍辅助或车机投屏若由系统代发权限请求，动作归属要按平台计，不能因此在应用里再叠一张。
怎么落地
- 拒绝或撤回之后，把该权限标为「需新动作」；只有明确绑定该能力的控件被激活才调用系统 API。
- 重新申请的控件文案写正在做的事（「拍摄收据」「用位置导航」），不要写「重新授权」。
- 禁止在应用进入前台、网络重连、广告 SDK 初始化时附带权限请求。
- 验证：拒绝一项权限，然后只做浏览、下拉刷新、切后台再回来。不应出现系统弹窗。再点该功能入口，弹窗可以出现一次。把这段操作做成自动化回归，冷启动与推送唤醒必须包含在脚本里。