Asking again needs a fresh user action

What it is

After a permission is denied or revoked, the next system authorization dialog must follow a new, recognizable user action: tapping Capture again, tapping Turn on notifications, tapping Open from Settings. Background resume, cold start, list refresh, and timers must not summon the dialog on their own. This entry is the trigger rule for asking again. It is not a ban on all later asks, and not the harassment pattern of firing the same denial over and over.

Why it happens

Platforms treat a second dialog with no action as bypassing "remembered denial." If the app calls the permission API from onResume, a push callback, or a heartbeat, revocation is implemented as temporary. Requiring a fresh action hooks authorization back to "the person is asking for this feature now": the action supplies new context and a place to walk away (don't tap, don't get asked). Without that gate, both revoke and deny are only delays until the next interruption, and revocability fails in time.

Where it stops holding

A system-owned notice about a settings change, or returning to the app after the person turned the permission on in Settings, is not an app-initiated re-ask. When the OS asks again after "Allow Once" expires, that is platform semantics and should still land on the next use of the feature, not an idle pre-ask by the app. If an assistive service or car projection lets the system send the request, credit the action to the platform; do not stack another sheet in the app.

Applying it

• After denial or revoke, mark the permission "needs a new action." Call the system API only when a control explicitly bound to that capability is activated.
• Label that control with the job in progress ("Photograph the receipt," "Navigate with location"), not "Re-authorize."
• Do not attach a permission request to coming to the foreground, network reconnect, or ad-SDK init.
• Verify by denying a permission, then only browsing, pull-to-refreshing, and backgrounding. No system dialog should appear. Then tap the feature entry; one dialog may appear. Automate this as a regression, including cold start and push wake.

Related

• Within the group: H4.04.1 The app needs an in-app permission status and a jump to Settings · H4.04.2 Revocation has to clean up data already taken
• Adjacent: H4.03 Degradation after Denial · H4.01 Timing of Requests · O2.06 Consent Interface Design and Abuse
• Search terms: fresh user action · permission re-request · revocation