How to Test Permission Dialogs on Android (Complete Guide)

Permission dialogs are the gatekeepers between an app’s functionality and the device’s protected resources. When a dialog fails—whether it never appears, is dismissed incorrectly, or blocks the user f

Why Permission Dialogs Matter on Android

Permission dialogs are the gatekeepers between an app’s functionality and the device’s protected resources. When a dialog fails—whether it never appears, is dismissed incorrectly, or blocks the user from proceeding—core features break, user trust erodes, and the app may be flagged by Play Store reviewers for misleading behavior. In production, a missing permission can cause silent crashes (e.g., trying to read contacts without READ_CONTACTS), lead to ANRs when the app waits for a result that never arrives, or expose data if the app incorrectly assumes a permission was granted. Conversely, over‑granting permissions (e.g., always allowing location) creates privacy risks and can trigger rejection during the store’s privacy review. Testing these dialogs therefore touches reliability, security, compliance, and user experience—all critical dimensions for any Android release.

Comprehensive Test Matrix for Permission Dialogs

A systematic matrix helps ensure that every dimension of permission handling is exercised. Below is a detailed breakdown that can be copied into a test‑case management tool or used as a checklist for exploratory sessions.

Happy Path Scenarios

When testing the happy path, focus on the *exact* moment the system presents the dialog. Use a clean device state (no prior grants) and observe that the dialog’s title matches the permission’s label, the description explains why the app needs it, and the two action buttons are present. After granting, immediately invoke the protected API (e.g., Camera.open()) and assert that no SecurityException is thrown. Additionally, verify that the permission appears as granted in the system UI and that a subsequent request for the same permission does not trigger another dialog (the system remembers the choice).

Error Path Scenarios

Error paths reveal how the app behaves when the user refuses access. A robust app should degrade gracefully: hide the feature, show an inline explanation, or offer a retry button that re‑triggers the request after the user has changed their mind in Settings. Test the “Don’t ask again” flow by denying, checking the checkbox, and then attempting to re‑request the permission; the system should skip the dialog and return PERMISSION_DENIED directly to the callback. Confirm that your app does not treat this as a fatal error but instead presents a UI that guides the user to Settings.

Edge Cases

Edge cases often surface only under specific device states or OS versions. For example, on Android 12 (API 31) the system introduced *approximate location*; if your app requests ACCESS_FINE_LOCATION while the user has only granted coarse, the system shows a separate dialog for the precise location upgrade. Similarly, Android 13’s POST_NOTIFICATIONS permission requires a distinct runtime request even if the app previously sent notifications via notification channels. Test each OS version you support, using emulator system images or real devices, to confirm that the dialog flow matches the platform’s expectations.

Accessibility Considerations

Permission dialogs are system‑provided UI, but they still must be usable by people who rely on assistive technologies. When TalkBack is active, swipe left/right should move focus between the permission explanation, the “Allow” button, and the “Deny” button, with each element announcing its role and state. Verify that the dialog does not trap focus (i.e., the user can swipe out to the underlying app) and that the announcement includes the permission group (e.g., “Location, fine location”). For Switch Control, ensure that a single switch press can highlight each button and that a second press activates it. Finally, test with the largest font size and bold text enabled to confirm that no text is truncated and that touch targets remain at least 48 dp.

Security & Privacy Implications

A permission dialog that is bypassed or mishandled can lead to data leakage or privilege escalation. Ensure that your app never reads protected data before the callback returns PERMISSION_GRANTED. Use strict mode or a custom SecurityException listener to catch any premature access. Additionally, audit your logging: never log the raw grantResults array or any data obtained via the permission (e.g., GPS coordinates) unless you have explicitly masked PII. Finally, confirm that your app’s manifest declares only the permissions it truly needs; excess declarations increase the attack surface and may trigger store warnings.

Manual Testing Approach

Manual testing remains valuable for catching subtle UI glitches, OEM‑specific quirks, and accessibility problems that automated scripts may overlook. Below is a repeatable, step‑by‑step process you can follow on a physical device or emulator.

Preparing the Device/Emulator

1. Start with a clean state – Either factory‑reset the emulator or use adb shell pm clear to remove app data and revoke all runtime permissions.
2. Install the test build – adb install -r app-debug.apk. Ensure the build is *debuggable* if you intend to use adb shell pm grant for pre‑granting; otherwise, keep it non‑debuggable to mimic production.
3. Enable developer options – On the device, go to Settings → About phone → tap Build number seven times, then toggle USB debugging.
4. Grant necessary ADB permissions – On Windows/macOS/Linux, verify adb devices shows your device.
5. Set up accessibility tools – Turn on TalkBack, Switch Control, or font scaling via Settings → Accessibility → Display size to validate the dialog under those conditions.
6. Prepare a test script – Have a simple note‑taking app or a test harness that triggers the permission request via a button press. This makes it easy to repeat the flow without navigating through the app each time.

Step‑by‑Step Manual Test Procedure

Documenting Results

Use a simple spreadsheet with columns for *Permission*, *Scenario* (grant, deny, don’t ask again, etc.), *Observed Behavior*, *Expected*, *Status*, and *Notes*. Attach screenshots or screen recordings for any failures. This documentation becomes a regression baseline for future releases.

Automated Testing Strategies

While manual testing catches UI nuances, automated tests provide repeatability and coverage for regression suites. Android offers several layers for permission testing, ranging from fast unit tests to full‑system UI automations.

Unit and Instrumentation Tests with Espresso

Espresso excels at validating that your app reacts correctly to permission callbacks, but it cannot interact with the system permission dialog directly (the dialog runs in a separate system process). Instead, you mock the permission result and verify UI changes.

// PermissionFragmentTest.kt
@RunWith(AndroidJUnit4::class)
class PermissionFragmentTest {

    @get:Rule
    val grantRule = GrantPermissionRule.grant(
        Manifest.permission.CAMERA,
        Manifest.permission.RECORD_AUDIO
    )

    @Test
    fun cameraPermissionGranted_showsPreview() {
        // Launch the fragment that requests camera
        launchFragmentInContainer<CameraFragment>(Bundle.EMPTY)

        // Espresso can see the UI that appears after permission is granted
        onView(withId(R.id.camera_preview))
            .check(matches(isDisplayed()))
    }

    @Test
    fun cameraPermissionDenied_showsRationale() {
        // Revoke the permission to simulate a deny scenario
        InstrumentationRegistry.getInstrumentation()
            .getTargetContext()
            .revokePermission(Manifest.permission.CAMERA, PackageManager.PERMISSION_DENIED)

        launchFragmentInContainer<CameraFragment>(Bundle.EMPTY)

        // Assuming the fragment shows a TextView with id R.id.permission_rationale
        onView(withId(R.id.permission_rationale))
            .check(matches(isDisplayed()))
    }
}

The GrantPermissionRule automatically grants the listed permissions before each test method runs, letting you test the *granted* path without invoking the system dialog. To test the denied path, manually revoke the permission after the rule has run (as shown) or use a custom ActivityTestRule that calls Context#revokePermission.

UI Automator Tests for System Dialogs

UI Automator can cross‑process boundaries, making it suitable for clicking the Allow or Deny buttons on the system permission dialog. Note that UI Automator requires the test to be instrumented with android.permission.INTERACT_ACROSS_USERS_FULL (granted automatically for instrumentation tests on Android 9+).

// PermissionDialogTest.java
@RunWith(AndroidJUnit4::class)
public class PermissionDialogTest {

    private static final String CAMERA_PERMISSION = Manifest.permission.CAMERA;
    private static final int REQUEST_CODE = 101;

    @Before
    public void revokeCameraPermission() {
        Context ctx = InstrumentationRegistry.getInstrumentation()
                .getTargetContext();
        ctx.revokePermission(CAMERA_PERMISSION, PackageManager.PERMISSION_DENIED);
    }

    @Test
    public void grantCameraViaUiAutomator() {
        // Launch the activity that triggers the permission request
        Intent intent = new Intent(InstrumentationRegistry.getTargetContext(),
                MainActivity.class);
        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        InstrumentationRegistry.getInstrumentation()
                .startActivitySync(intent);

        // Wait for the system dialog to appear (max 2 seconds)
        UiDevice device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
        UiObject allowBtn = device.findObject(new UiSelector()
                .textContains("Allow")
                .className("android.widget.Button"));

        assertTrue("Allow button not found", allowBtn.waitForExists(2000));

        // Click Allow
        allowBtn.clickAndWaitForNewWindow(2000);

        // Verify that the permission is now granted
        PackageManager pm = InstrumentationRegistry.getInstrumentation()
                .getTargetContext()
                .getPackageManager();
        int granted = pm.checkPermission(CAMERA_PERMISSION,
                InstrumentationRegistry.getTargetContext().getPackageName());
        assertEquals(PackageManager.PERMISSION_GRANTED, granted);
    }
}

Key points:

• Use UiSelector().textContains("Allow") – the exact text may vary by locale; you can also use resource IDs if you know them (android:id/button1 for Allow, android:id/button2 for Deny on many devices).
• After clicking, call waitForNewWindow to ensure the dialog has dismissed before proceeding.
• Verify the grant via PackageManager#checkPermission.

Using adb to Grant/Revoke Permissions

For quick sanity checks or scripted test harnesses, adb provides direct control over permission states.

# Revoke a permission (simulate a deny)
adb shell pm revoke com.example.myapp android.permission.CAMERA

# Grant a permission (simulate an allow)
adb shell pm grant com.example.myapp android.permission.CAMERA

# Check current state
adb shell pm list permissions -g -d | grep CAMERA

You can embed these commands in a shell script that launches your app, performs a UI action via adb shell input tap (coordinates obtained from adb shell uiautomator dump), then checks the permission state. This approach is useful for continuous‑integration pipelines that run on device farms lacking UI Automator support.

Leveraging AndroidX Test Rules (GrantPermissionRule)

The GrantPermissionRule from androidx.test:core simplifies permission handling in instrumentation tests. It automatically grants the requested permissions before each test and revokes them after, ensuring isolation.

@get:Rule
val permissionRule = GrantPermissionRule.grant(
    Manifest.permission.ACCESS_FINE_LOCATION,
    Manifest.permission.ACCESS_COARSE_LOCATION
)

@Test
fun locationRequest_whenGranted_showsMap() {
    launchActivity<MapsActivity>()
    onView(withId(R.id.map_view)).check(matches(isDisplayed()))
}

If you need to test the *denied* path, combine the rule with a manual revoke after the rule’s initialization:

@Before
fun revokeLocation() {
    val ctx = ApplicationProvider.getApplicationContext()
    ctx.revokePermission(Manifest.permission.ACCESS_FINE_LOCATION,
            PackageManager.PERMISSION_DENIED)
}

Mocking Permission Results with Robolectric

Robolectric runs tests on the JVM, making it fast for unit‑level logic. It allows you to stub the Context#checkPermission and Context#requestPermissions calls.

@RunWith(RobolectricTestRunner.class)
@Config(sdk = {Build.VERSION_CODES.Q})
public class PermissionViewModelTest {

    private PermissionViewModel viewModel;

    @Before
    public void setUp() {
        Context ctx = RuntimeEnvironment.application;
        // Pretend the permission is denied
        ShadowContext shadowCtx = shadowOf(ctx);
        shadowCtx.grantPermission(Manifest.permission.CAMERA,
                PackageManager.PERMISSION_DENIED);
        viewModel = new PermissionViewModel(ctx);
    }

    @Test
    public void requestCameraPermission_whenDenied_returnsFalse() {
        boolean granted = viewModel.requestCameraPermission();
        assertFalse(granted);
    }
}

Robolectric is ideal for testing ViewModels, UseCases, or any logic that decides whether to show a rationale or disable a UI component based on permission state.

CI Integration Tips

• Device farm selection – Choose a fleet that offers a range of API levels (21‑34) and at least two OEM skins (e.g., Google Pixel and Samsung Galaxy).
• Parallelization – Split the permission matrix across shards; each shard runs a subset of scenarios (grant, deny, don’t ask again) on a different device.
• Artifact collection – After each test, pull adb logcat and adb shell dumpsys activity to capture any ANRs or crashes. Store them as build artifacts for triage.
• Flaky test mitigation – UI Automator tests that interact with system dialogs can be flaky due to animation timing. Add explicit waits (UiObject.waitForExists) and disable window animations during tests via adb shell settings put global window_animation_scale 0.0.

Tooling Comparison

Choose the combination that matches your test pyramid: unit/logic tests with Robolectric, instrumentation tests with Espresso + GrantPermissionRule for fast feedback, and a smaller set of UI Automator tests to guard against system‑level regressions.

Autonomous, Persona‑Driven Exploration with SUSA

Autonomous testing tools that model real‑world user behaviors can uncover permission‑related defects that scripted tests never consider. SUSA (SUSATest) is an autonomous QA platform that explores an app without predefined scripts, using a set of persona profiles that mimic how different people interact with software.

How SUSA Models Different Personas

SUSA defines behavior patterns for personas such as:

• Curious – taps every visible element, explores deep hierarchies, often triggers permission requests by accident.
• Impatient – quickly dismisses dialogs, may tap outside the dialog or use the back button to escape.
• Novice – reads dialog text carefully, may need multiple attempts to understand what a permission entails.
• Adversarial – tries to bypass security controls, repeatedly denies permissions, or uses accessibility services to click hidden buttons.
• Elderly – prefers larger touch targets, may struggle with small text, often relies on TalkBack.
• Accessibility – enables TalkBack, Switch Control, or high‑contrast mode before launching the app.
• Power user – uses shortcuts, long‑presses, and expects immediate feedback; may force‑stop the app to reset permissions.

Each persona carries a probability distribution for actions like “tap Allow”, “tap Deny”, “check Don’t ask again”, “open Settings from the dialog”, or “ignore the dialog entirely”.

What It Looks For in Permission Flows

During an exploration run, SUSA monitors:

• Whether a permission dialog appears at the expected moment (e.g., after tapping a “Scan QR code” button).
• How each persona reacts to the dialog (grant, deny, dismiss, or navigate to Settings).
• Post‑dialog state: does the app crash, show an error toast, or silently continue?
• Accessibility compliance: does TalkBack read the dialog correctly under the “Accessibility” persona?
• Security signals: does any persona manage to trigger a protected API before the permission result is returned?

Because SUSA does not rely on hard‑coded test cases, it can discover edge cases such as a dialog that appears *after* the user has already navigated away from the triggering screen (a race condition caused by delayed permission requests).

Real‑World Bugs Found Only by Persona‑Driven Runs

In a recent analysis of a popular e‑commerce app, SUSA’s Impatient persona repeatedly tapped the back button while the permission dialog was still visible. This caused the activity to finish before the permission callback was delivered, leaving a fragment in a detached state and resulting in a NullPointerException when the app later tried to use the camera. The bug never appeared in scripted tests because those tests always waited for the dialog to resolve before proceeding.

Another finding came from the Elderly persona, which used the system’s magnification gesture to enlarge the dialog. On a device with a non‑standard font scaling implementation, the “Allow” button’s hit‑target shifted, making it impossible to tap without first panning the magnified view. The app logged a permission denial and showed a generic error, leading to poor conversion rates.

These examples illustrate how persona‑driven exploration surfaces issues rooted in timing, UI layout, and accessibility that deterministic scripts overlook. Integrating SUSA into your nightly regression cycle adds a layer of confidence that permission dialogs behave correctly for the full spectrum of real users.

Checklist for Permission Dialog Testing

Use this concise list before signing off a release. Tick each item only after you have verified it on at least one device representing your minimum supported API level and one OEM skin.

• [ ] Manifest audit – Every requested is justified in the privacy policy; no excess permissions.
• [ ] Dialog appearance – Permission dialog shows correct title, description, and two action buttons for each runtime request.
• [ ] Grant path – After tapping Allow, the protected API returns successfully; no SecurityException.
• [ ] Deny path – After tapping Deny, the app receives PERMISSION_DENIED and does not crash; UI reflects lack of access (e.g., button disabled, toast shown).
• [ ] Don’t ask again – When the checkbox is checked and Deny is selected, subsequent requests skip the dialog and return denied instantly.
• [ ] Settings revisit – Tapping a “Go to Settings” link (if provided) opens the correct App info → Permissions screen; toggling the switch there updates the app’s state without requiring a restart.
• [ ] Background requests – Permission requests originating from a foreground service or background worker do not cause ANRs; the app handles deferral or immediate denial gracefully.
• [ ] Rapid successive requests – Multiple permission dialogs triggered in quick succession are displayed sequentially; each request’s result is tracked correctly.
• [ ] Configuration change – Rotating the device or entering multi‑window mode while a dialog is visible does not dismiss it or lose the request context.
• [ ] Accessibility – With TalkBack, Switch Control, large font, and bold text enabled, the dialog is readable, navigable, and operable.
• [ ] OEM variations – Tested on at least two OEM skins (e.g., Stock Android, Samsung OneUI, Xiaomi MIUI) – dialog appearance and behavior remain consistent.
• [ ] Security audit – No protected data is accessed before the permission callback returns; logs do not contain PII from permission‑related calls.
• [ ] Automated coverage – At least one unit test (Robolectric) validates logic for granted/denied states; one instrumentation test (Espresso + GrantPermissionRule) checks UI after grant; one UI Automator test verifies interaction with the system dialog.
• [ ] CI gate – Permission‑related test suite runs on every pull request; failures block merge.

Key Takeaways

Permission dialogs are a nexus of user trust, platform security, and app functionality. A disciplined testing strategy combines:

1. Clear matrix‑driven test design that covers happy paths, error paths, edge cases, accessibility, and security.

2