Mobile App Permission Testing: Consent and Revocation

Camera access granted during onboarding may be revoked later in system settings. A location feature can also ask for access before explaining its purpose. Permission testing covers both product behavior and the transitions controlled by Android and iOS: first request, denial, a later grant, restricted access and revocation while the app is open.

List the user action that needs each capability. Scanning a document can request camera access when the scan starts; a static help screen has no reason to ask. If a feature can use a system file picker without broad photo-library access, test that path separately. The goal is a working task with the least access the task requires, not the largest collection of granted permissions.

For every permission, document what the screen displays before the OS prompt, what it does after a grant and what it offers after a denial. A denied microphone request can leave text input available. A denied notification request should not block an unrelated account setup unless that dependency is real and explained.

Availability and wording of permission choices depend on OS version and API. Build the matrix from the actual target versions, not from a screenshot of one device. A system picker and a broad library permission are different routes and may need different tests.

A tester who already granted access may never see the failure a new user sees. Reset permission state or reinstall a test build as appropriate to the platform, then verify the first request. Cover grant, deny and dismissal if the OS presents that route. Relaunch the feature after each decision. Some platforms change prompt behavior after repeated denial, so verify the app's fallback when no new system dialog appears.

Test a request triggered twice in quick succession. Two screens may race to ask for the same permission; after the OS response, the app should have one coherent feature state. Record the route to the prompt, not merely the final permission value. Asking at startup and asking at the moment of use can produce different user expectations.

Do not simulate a grant by changing an app-local preference only. The OS owns access. Read the actual permission state at the point of use and handle a mismatch between cached UI and current system settings.

On supported systems, photo selection can be limited to a user-chosen subset. Select two images, attach one, then change the permitted selection. The app must not assume that every thumbnail in an old cache is still readable. For location, test approximate access where supported and verify that a feature requiring exact coordinates explains its limitation without inventing a precise value.

Permission to use a sensor does not mean the sensor is available at every moment. Test a camera already occupied by another app, an interrupted microphone session and a location response that times out. Handle “granted but resource unavailable” separately from “denied.” The UI should never claim that an upload or recording succeeded solely because permission was granted.

For background location or other expanded access, test the specific supported OS flow and product justification. Do not assume an earlier foreground grant automatically extends to background use. Capture whether users can complete the core task without granting the expanded scope.

Open the scanning feature, background the app, revoke camera access in settings and return. Depending on the system, the process may be restarted. Recreate the screen from durable state and show an actionable result. Do not leave the previous “camera ready” badge visible over a failed preview.

Repeat for a queued upload of a locally selected file. If the app retained a file handle or a copy that is still valid, verify the behavior against the platform storage rules. If access is lost, stop cleanly and ask the user to choose a file again. A generic “network failure” message hides the real reason and leads to useless retries.

Test a privacy toggle inside the app as well as the OS permission. Turning off location sharing in the app should stop the feature's data flow even if OS-level location access remains granted. Check outgoing requests, queued events and visible history, not just the switch position.

A permission test is incomplete if the UI behaves correctly while a bundled analytics or crash SDK still sends sensitive values. Capture requests during first launch, grant, denial, use and revocation. Compare what the app sends with its stated purpose. Remove photo paths, precise coordinates and recorded audio from diagnostic logs unless a narrowly justified test environment requires them.

Use test accounts and synthetic content. When recording is denied, verify that no audio file was created and no “recording complete” event was sent. When camera access is revoked, verify that the app no longer produces image data. Review local caches and pending uploads after sign-out if the feature handles personal material.

For each failure, include starting permission, action, resulting OS state, app route and observed result. “Camera denied” is less useful than “camera granted on build 305, revoked in settings while scan screen is backgrounded, return shows a black preview and a live shutter button.” Record the OS version and whether the device restarted the process.

Fixes should be checked with the original first-use path as well as the revocation path. A new explanatory screen can improve denial behavior while accidentally preventing a user who already granted access from reaching the camera.

Upgrade from a build that did not use a capability to a build that adds it. Launch the updated app without touching that feature, then inspect whether a new prompt appears unexpectedly. Use the feature and verify the explanatory context, prompt and denial path. A change to a manifest or entitlement does not by itself prove that the app will ask at the right moment.

Next update from a build where access was already granted. Confirm that the new app reads the current system state and does not display an obsolete explanation or assume a broader scope than was granted. Repeat with permission denied before the update. The two origins can produce different screens even when the new binary is identical.

Where a feature can work with selected media from a picker, compare the experience with broad library access enabled and disabled. Test an empty selection and an item removed after the app first displayed it. If the app caches a preview, ensure a preview is not mistaken for ongoing authorization to upload the underlying original.

Record four routes for each capability: new user grants it, new user denies it, returning user revokes it in settings and an already granted user updates the app. A camera, microphone or location feature should explain why it cannot run without the required access while keeping unrelated tasks usable. The operating system owns the actual access state; an app preference must not be treated as a grant.

For limited photo access, select two items, remove one from the allowed set and reopen the attachment screen. A cached thumbnail does not guarantee that the underlying file remains readable. For a denied notification permission, verify that essential information is still available inside the app. Finally inspect network and local logs before and after revocation to ensure the permission flow matches the data flow.