When Settings revokes a permission, the app must detect it and degrade

What it is

Someone can turn a permission off in system Settings while the app is elsewhere. On return, the product must notice that the grant is gone and switch into the post-denial fallback: stop calling, switch to typing or files, say it is unavailable now—not spin, crash, or keep showing a stale address book. This entry is about detecting an out-of-band revoke and wiring it to degradation. It is not about whether the main path still works after Don't Allow on the first dialog.

Why it happens

Grant state lives in the OS; caches inside the app process go stale. A toggle flipped in Settings leaves memory, disk, and UI models still saying Allow. The next read comes back empty or as an exception; without an active check, the failure looks like a network fault or a broken feature. Detection has to hook the lifecycle: on foreground, on opening the feature, before resuming a background session, ask the system "is this still allowed." Typical misses: a map still following a now-invalid coordinate, a black camera preview with no reason, an in-app push switch still drawn as on.

Where it stops holding

The system may kill some background sessions (camera especially) at the moment of revoke, before the app can finish its own check. The next foreground still has to degrade; do not wait for a cold start. On managed devices, policy did the revoke; after detection, say "turned off by your organization" instead of sending people to a toggle they cannot flip. Expiry of Allow Once is not "revoked in Settings"; close it as a one-shot ending, not as a fault.

Applying it

• On foreground and on opening a permission-dependent screen, read the system's current grant. If it disagrees with the local cache, change state immediately and stop the related APIs.
• After detecting revoke, use the same fallback UI as a dialog denial. Do not invent a second, unexplained error screen.
• In-app toggles must match system state; when the system is off, the in-app control must not still show on.
• Verify: grant in the foreground, background the app, turn the permission off in Settings, return and enter the feature. Within about a second the fallback copy should appear, with no crash and no infinite spinner. Automate both return-from-background and return-from-kill.

Related

• Within the group: H4.10.1 System in-use indicators and in-app permission entries do different visibility jobs · H4.10.3 A mismatch between shown permission state and actual availability is misdiagnosed as a bug · H4.10.4 Unused permissions after first install should prompt a keep-or-drop review
• Adjacent: H4.03 Degradation after Denial · H4.04 Revocable Permissions · H3.09 Crash and Offline Recovery
• Search terms: permission revoked · settings change · out-of-band revoke