Testing Runtime Permissions in a Closed Test: Grant, Deny and Revoke Flows

Most permission bugs don't show up when you test your own app. You tap Allow every time, because you know what the app needs. Real testers don't. Some tap Don't allow on reflex, some grant access and revoke it later, and some only give the app approximate location. Your 14-day closed test is a good time to find out what happens in each case.

This post gives you a concrete set of permission scenarios to run, how to ask testers to cover them, and what to fix first.

Why permissions deserve their own test pass

A permission problem rarely looks like a permission problem to the user. It looks like a blank screen, a button that does nothing, or a crash after returning from Settings. Testers will report "the app is broken" and never mention that they denied the camera.

Permission behavior also differs between Android versions and manufacturers. Some behaviors you may want to check:

• Notifications: on Android 13 and higher, apps need to request the notification permission at runtime. On older versions it is granted by default, so the same app behaves differently on different phones.
• One-time permissions: on newer versions, users can grant location, camera or microphone access for a single session only. The permission disappears when the app goes to the background for a while.
• Approximate vs precise location: users can give you less than you asked for.
• Partial media access: newer Android versions let users share only selected photos and videos instead of the whole library.
• Automatic reset: the system can reset permissions for apps that haven't been used for a while.

Details change between releases, so check the official runtime permissions guide for the versions you target.

The six scenarios to test

1. First-run deny

The user opens the app, sees the permission dialog, and taps Don't allow. Then what?

• Does the app still open and show something useful?
• Does it explain what is unavailable and why?
• Is there a clear path to try again?

If your app shows a dead end, such as an empty camera preview with no message, that is the first thing to fix.

2. Deny twice ("permanently denied")

After the user denies a request more than once, Android may stop showing the system dialog at all. Calling the request again simply returns "denied" instantly. Many apps keep tapping a button that appears to do nothing.

The correct behavior is usually to detect this state and offer a button that opens the app's system settings page. Ask testers to deny twice on purpose and report what they see.

3. Grant, then revoke in Settings

The user grants a permission, uses the feature, leaves the app, revokes the permission in system Settings, and comes back. Depending on the Android version, the system may restart your process, or it may not. Check that:

• the app doesn't crash on the next feature call,
• cached state doesn't claim the permission is still granted,
• screens that depended on the permission update themselves.

4. Partial grants

Test approximate-only location, selected-photos-only media access, and any other reduced grant your target versions support. Your code should treat "some access" as a valid state, not as either full success or full failure.

5. The notification permission

On Android 13 and higher, test both choices. If a testers denies notifications, does your reminder feature quietly fail or does it tell the user? Also check when you ask. Requesting notifications on the very first launch, before the user has seen any value, tends to produce denials.

6. Upgrade path

If you add a permission in a closed-test update, existing testers go through a different flow than new installs. Ask one tester to stay on the old build, update, and use the new feature. This is where "works on a fresh install" can hide a bug.

How to ask testers to run these scenarios

General instructions like "test the permissions" produce little. Give testers a short script instead. For example:

1. Install the app and deny every permission request. Write down what you see on each screen.
2. Open the feature that needs the camera. Describe what the app tells you.
3. Go to Settings, turn the permission on, return to the app, and use the feature.
4. Turn the permission off again while the app is still open in the background. Come back and use the feature.

Ask for a one-line answer per step, plus the phone model and Android version. That is enough for you to reproduce most issues. If you're collecting feedback in a form, add a dedicated "permissions" question rather than hiding it in a general comments box. Our post on collecting useful feedback from closed testers and the rest of the blog cover how to structure those questions.

Testers on TesterMob use their own Android phones and spend about 20 minutes a day in your app, and they write feedback, so a short scripted task fits inside that time. A different mix of phones also means you see more variation in permission dialogs and Settings screens than you would on your own device. If you want a wider spread of devices, the developer page explains how testing works.

What to do on your own device first

Before testers touch the build, spend ten minutes with it yourself:

1. Uninstall the app and reinstall it.
2. Deny every permission.
3. Walk through every screen that could touch a permission-gated feature.
4. Use Settings > Apps > Your app > Permissions to toggle things while the app is running.

If you have an emulator with a different Android version, repeat it there. This catches the embarrassing issues so testers can spend their time on the subtler ones.

Good patterns to aim for

• Ask in context. Request the camera when the user taps "Scan", not on launch.
• Explain before asking when the reason isn't obvious. One sentence on your own screen, then the system dialog.
• Degrade gracefully. Disable or hide the feature, or offer a manual alternative, such as typing an address instead of using location.
• Link to Settings when the system can no longer show the dialog.
• Request only what you need. Every extra permission is another place for denial and another line in your store disclosures.

Keep your Play Console answers consistent

Permissions you use can affect what you declare elsewhere in Play Console, such as your Data safety answers and, for some sensitive permissions, additional declarations or review. Which ones apply, and how, can change over time, so check Play Console Help for the current rules. A practical habit is to list every permission in your manifest during the closed test and confirm each one has a visible, working reason in the app. If you find a permission you no longer use, remove it before production.

Triage: what to fix first

1. Crashes after deny or revoke. These are the most serious and the easiest for testers to trigger.
2. Silent dead ends. A button that does nothing is worse than a clear "camera access is off" message.
3. Poorly timed requests. Annoying, but usually a quick change.
4. Wording. Improve the explanations once the behavior is right.

Ship the fixes as an update during the test and mention them in your release notes so testers know what to re-check.

A note on expectations

Careful permission handling makes your app better and gives testers real things to report. It won't by itself decide whether Google grants production access. TesterMob isn't affiliated with Google and can't guarantee approval. What a closed test can do is help you find these problems with real people on real phones before your first public users do. If you have questions about how testing works, the FAQ is a good place to start.