pm grant, pm revoke and pm set-permission-flags, then read the state back, because pm can exit 0 without changing anything. On iOS, reset the camera with resetAuthorizationStatus(for:) and seed the other states through a debug-only seam. Assert the app's recovery UI in every state. Keep exactly one test per platform that taps the real system prompt, and run it before release.A scanner app's UI suite has a test that taps the scan button and expects the camera prompt. On a fresh emulator it passes. In CI it waits ten seconds for an Allow button and fails. Earlier in the same run, a denial test tapped Deny. A previous run on the same emulator tapped Deny too, and since Android 11 a second denial means the system stops showing the dialog for that app. On the iOS side the prompt does appear, but the locator was written against button copy that belongs to the operating system, and that copy is not yours to pin.
\n\nNeither failure says anything about the app. What would say something, what the app shows a user who refused the camera twice, is what most suites never reach, because getting there by tapping takes two app runs and a device nobody else touched. This part of the series turns permission state into test setup. The first part left the system prompt itself for this article; it is still here, confined to one test per platform.
\n\nrules 1.7.0 and UI Automator 2.4.0 (Google Maven). Xcode 27 (27A266a) is the current release, with 27.1 at release candidate; iOS is at 27.0.1. Android permission behaviour is quoted from developer.android.com pages last updated 2026-10-01 and from AOSP source on the main branch. The Swift mapping below was compiled and run with Swift 6.4 from the macOS command-line tools; the Android and XCUITest snippets were not executed on a device for this article.Start from what the app can read. The two platforms disagree on how many states exist, so a matrix copied from one onto the other contains states that cannot happen.
\n\n| What happened | Android: what the app reads | iOS: what the app reads | Screen to assert |
|---|---|---|---|
| Never asked | Denied; rationale false; no user flags | .notDetermined | Explain, then request |
| Allowed | Granted | .authorized | Viewfinder |
| Denied once | Denied; rationale true (USER_SET) | .denied | Android: rationale, then ask again. iOS: settings link |
| Denied twice | Denied; rationale false (USER_FIXED) | No separate state | Settings link |
| Not the user's decision | Denied; rationale false (POLICY_FIXED) | .restricted | Explain the limitation |
The Android column comes from the platform source rather than the reference page, which only says the method returns \"whether you should show permission rationale UI.\" In AOSP, shouldShowRequestPermissionRationale returns false if any of USER_FIXED, POLICY_FIXED or SYSTEM_FIXED is set, and otherwise returns whether USER_SET is. So a permission the app never requested and a permission the user blocked give the app the same two answers: denied, no rationale. The platform does not tell them apart for you. The app has to remember that it asked.
Android's permission guide names both flags: a permission denied once is flagged USER_SET, and one \"denied permanently by selecting Deny twice\" is flagged USER_FIXED. The policy row exists because a device owner or profile owner can call DevicePolicyManager.setPermissionGrantState to deny a permission so that \"the user cannot manage it through the UI.\" To your app that looks like a user block, but sending the user to Settings will not help them.
iOS has fewer states and one hard edge. After the first answer, \"the system saves the user's selection so that it doesn't have to prompt the user again,\" so there is no denied-but-askable state to test. .restricted is the case where \"a user can't change the authorization status, possibly due to the system imposing restrictions like parental controls.\" A Settings button on that screen leads nowhere, which makes it a bug a test can catch.
On Android, \"granted\" is not always permanent. Since Android 11, camera, microphone and location prompts offer Only this time. The app keeps access while it is visible and for a short period after it goes to the background, and the user is asked again next time.
\n\nOne constraint shapes the settings screen. Android's own sample code, in the branch that handles a denial, says: \"Don't link to system settings in an effort to convince the user to change their decision.\" The settings link therefore belongs on the screen a user reaches by tapping the blocked feature again, not on launch. That is assertable: in the blocked state, the link should be absent until the user taps scan.
\n\nEvery row of that table is a branch in the app. Pull the branch out into a function that takes the platform's answer as input, and every row becomes a host test that runs in milliseconds. On iOS the input is the authorization status, behind a protocol so a test can supply it:
\n\nimport AVFoundation\n\npublic enum CameraScreen: Equatable, Sendable {\n case capture // authorized\n case explainThenAsk // notDetermined: in-app explainer, then requestAccess\n case openSettings // denied: the system will not prompt again\n case explainLimitation // restricted: the user cannot change it either\n}\n\npublic protocol CameraAuthorizing: Sendable {\n func status() -> AVAuthorizationStatus\n}\n\npublic struct SystemCamera: CameraAuthorizing {\n public init() {}\n public func status() -> AVAuthorizationStatus {\n AVCaptureDevice.authorizationStatus(for: .video)\n }\n}\n\npublic func cameraScreen(_ camera: some CameraAuthorizing) -> CameraScreen {\n switch camera.status() {\n case .authorized: return .capture\n case .notDetermined: return .explainThenAsk\n case .denied: return .openSettings\n case .restricted: return .explainLimitation\n @unknown default: return .explainLimitation\n }\n}import AVFoundation\nimport Testing\n\nstruct FixedCamera: CameraAuthorizing {\n let value: AVAuthorizationStatus\n func status() -> AVAuthorizationStatus { value }\n}\n\n@Test(arguments: [\n (AVAuthorizationStatus.authorized, CameraScreen.capture),\n (.notDetermined, .explainThenAsk),\n (.denied, .openSettings),\n (.restricted, .explainLimitation),\n])\nfunc screenFollowsAuthorization(status: AVAuthorizationStatus, expected: CameraScreen) {\n #expect(cameraScreen(FixedCamera(value: status)) == expected)\n}AVAuthorizationStatus exists on macOS from 10.14, so this mapping runs on a Mac with no simulator. Driven through a plain executable with the same four cases, it printed each raw value, the screen and a check:
3 capture ok\n0 explainThenAsk ok\n2 openSettings ok\n1 explainLimitation okOn Android the mistake is in the branch order. This version reads naturally and ships a dead button:
\n\n// Wrong: treats \"no rationale\" as \"safe to ask\".\nfun onScanTapped() {\n when {\n hasCameraPermission() -> openViewfinder()\n shouldShowRequestPermissionRationale(CAMERA) -> showRationale()\n else -> requestCamera.launch(CAMERA) // blocked: no dialog, callback gets false\n }\n}In the blocked state the user taps scan, the system shows nothing, the callback reports a denial, and the screen does not change. The fix is the remembered flag from the previous section, written when the app launches the request:
\n\nenum class CameraScreen { VIEWFINDER, EXPLAIN_THEN_ASK, RATIONALE, OPEN_SETTINGS }\n\nfun cameraScreen(granted: Boolean, rationale: Boolean, askedBefore: Boolean): CameraScreen =\n when {\n granted -> CameraScreen.VIEWFINDER\n rationale -> CameraScreen.RATIONALE // USER_SET, nothing fixed\n !askedBefore -> CameraScreen.EXPLAIN_THEN_ASK // no flags yet\n else -> CameraScreen.OPEN_SETTINGS // USER_FIXED or POLICY_FIXED\n }\n\nclass CameraScreenTest {\n @Test\n fun blockedIsNotNeverAsked() {\n assertEquals(CameraScreen.EXPLAIN_THEN_ASK, cameraScreen(false, false, askedBefore = false))\n assertEquals(CameraScreen.OPEN_SETTINGS, cameraScreen(false, false, askedBefore = true))\n }\n}A user block and a policy lock both land on OPEN_SETTINGS, so write that screen's copy to hold when Settings will not let the user change anything either. The cost of this design is one persisted boolean whose value must agree with the platform's flags. Seeding has to set both, or the test runs a state no user can reach.
Device tests still need real platform state, because the instrumented build calls the real checkSelfPermission. The shell's package manager reaches every user-controlled row in the table. grant and revoke are documented on the adb page, and the guide documents clear-permission-flags. set-permission-flags appears in the pm help text in AOSP, which limits the flags it accepts to review-required, revoked-compat, revoke-when-requested, user-fixed and user-set.
#!/usr/bin/env bash\n# Seed one camera permission state before the app starts.\n# Usage: seed-camera.sh granted|not-asked|denied-once|blocked\nset -euo pipefail\nPKG=com.example.scanner\nPERM=android.permission.CAMERA\nSTATE=${1:?state required}\n\nadb shell am force-stop \"$PKG\" # revoking kills the process anyway\n\ncase \"$STATE\" in\n granted)\n adb shell pm grant \"$PKG\" \"$PERM\" ;;\n not-asked)\n adb shell pm revoke \"$PKG\" \"$PERM\"\n adb shell pm clear-permission-flags \"$PKG\" \"$PERM\" user-set user-fixed ;;\n denied-once)\n adb shell pm revoke \"$PKG\" \"$PERM\"\n adb shell pm clear-permission-flags \"$PKG\" \"$PERM\" user-fixed\n adb shell pm set-permission-flags \"$PKG\" \"$PERM\" user-set ;;\n blocked)\n adb shell pm revoke \"$PKG\" \"$PERM\"\n adb shell pm set-permission-flags \"$PKG\" \"$PERM\" user-set user-fixed ;;\n *)\n echo \"unknown state: $STATE\" >&2; exit 2 ;;\nesac\n\n# pm can exit 0 without changing anything, so read the state back.\ndump=$(adb shell dumpsys package \"$PKG\")\nline=$(grep -m1 \"$PERM: granted=\" <<<\"$dump\")\necho \"$line\"\nhas() { grep -q \"$1\" <<<\"$line\"; }\ncase \"$STATE\" in\n granted) has 'granted=true' ;;\n not-asked) has 'granted=false' && ! has 'USER_SET' && ! has 'USER_FIXED' ;;\n denied-once) has 'granted=false' && has 'USER_SET' && ! has 'USER_FIXED' ;;\n blocked) has 'granted=false' && has 'USER_FIXED' ;;\nesac || { echo \"seed did not take: wanted $STATE\" >&2; exit 1; }The read-back is there for a reason found in the source. When a permission is POLICY_FIXED, the grant path logs \"Cannot grant policy fixed permission\" and returns, and the shell command still exits 0. On a managed test device, a \"granted\" seed can silently stay denied. The read-back logic was exercised against a stubbed adb printing canned dumpsys blocks: it accepted each correct state and exited 1 for a blocked seed missing USER_FIXED and for a grant that a policy lock had ignored.
Four other details decide whether this setup stays honest:
\n\ndenied-once and blocked, launch with a debug-only extra such as adb shell am start -n com.example.scanner/.ScanActivity --ez seed_camera_asked true, so the remembered flag agrees with the platform flags.pm reset-permissions takes no package argument. Its help text reads \"Revert all runtime permissions to their default state\", and the implementation resets runtime permissions across the device. On a shared device it also resets every other app's grants.adb install -g grants every manifest permission at install. That suits suites that are not about permissions, but under it the never-asked path never runs.The AndroidX rule many suites start with has a sharper edge. GrantPermissionRule's reference says a granted permission \"will apply for all tests running in the current Instrumentation\", that \"there is no way of revoking a permission after it was granted\", and that trying \"will crash the Instrumentation process.\" One test class using it can make every later denial test in the same run test the granted state instead:
// Wrong: grants CAMERA for the whole instrumentation run, not this class.\n@get:Rule\nval camera: GrantPermissionRule = GrantPermissionRule.grant(Manifest.permission.CAMERA)\n\n// Right for permission-state tests: no rule. The runner seeds the state\n// with seed-camera.sh before launching this class, one state per invocation.\n@Test\nfun blockedCameraShowsSettingsLinkOnlyAfterTap() {\n launchActivity<ScanActivity>().use {\n onView(withId(R.id.open_settings)).check(doesNotExist())\n onView(withId(R.id.scan_start)).perform(click())\n onView(withId(R.id.open_settings)).check(matches(isDisplayed()))\n }\n}If the suite runs through Appium, the UiAutomator2 driver's mobile: changePermissions covers grant and revoke for the pm target, and mobile: getPermissions reads back granted or denied lists. Neither touches flags, so the denied-once and blocked rows need mobile: shell, which the driver enables only with the uiautomator2:adb_shell server feature. That belongs in the reviewed server config described in the Appium extensions part of this series. This helper type-checks against WebdriverIO 10.0.2 with TypeScript 7.0.2 under --strict:
import type { Browser } from 'webdriverio';\n\ntype CameraState = 'granted' | 'not-asked' | 'denied-once' | 'blocked';\n\nconst PKG = 'com.example.scanner';\nconst CAMERA = 'android.permission.CAMERA';\nconst FLAGS: Record<Exclude<CameraState, 'granted'>, string[]> = {\n 'not-asked': [],\n 'denied-once': ['user-set'],\n blocked: ['user-set', 'user-fixed'],\n};\n\nconst pm = (driver: Browser, ...args: string[]) =>\n driver.execute('mobile: shell', { command: 'pm', args });\n\nexport async function seedCamera(driver: Browser, state: CameraState): Promise<void> {\n // Revoking a runtime permission kills the process, so stop it first and seed cold.\n await driver.execute('mobile: terminateApp', { appId: PKG });\n\n if (state === 'granted') {\n await driver.execute('mobile: changePermissions', {\n permissions: CAMERA, appPackage: PKG, action: 'grant',\n });\n } else {\n await driver.execute('mobile: changePermissions', {\n permissions: CAMERA, appPackage: PKG, action: 'revoke',\n });\n // changePermissions cannot touch flags; this needs uiautomator2:adb_shell.\n await pm(driver, 'clear-permission-flags', PKG, CAMERA, 'user-set', 'user-fixed');\n const flags = FLAGS[state];\n if (flags.length > 0) {\n await pm(driver, 'set-permission-flags', PKG, CAMERA, ...flags);\n }\n }\n\n const granted = (await driver.execute('mobile: getPermissions', {\n type: 'granted', appPackage: PKG,\n })) as string[];\n if (granted.includes(CAMERA) !== (state === 'granted')) {\n throw new Error(`camera seed failed: wanted ${state}, granted=${granted.includes(CAMERA)}`);\n }\n\n await driver.execute('mobile: activateApp', { appId: PKG });\n}The policy row cannot be seeded this way at all: policy-fixed is not in the flag list pm accepts, and setting it takes a device or profile owner. Cover it with the host test, and on a managed device only if enterprise customers make it matter.
Simulators have had xcrun simctl privacy <device> grant|revoke|reset <service> <bundle id> since Xcode 11.4, whose release notes present it as a way to \"create known states for testing purposes.\" The service list, as documented by Appium's simctl wrapper and the XCUITest driver, covers calendar, contacts, location, photos, media library, microphone, motion, reminders and Siri. It has no camera entry. Run xcrun simctl help privacy on your own Xcode before relying on that, since the list belongs to the tool version.
# Works for the services simctl knows; camera is not one of them.\nxcrun simctl privacy booted grant microphone com.example.scanner\nxcrun simctl privacy booted reset all com.example.scannerFor the camera, the documented switch is XCUIApplication.resetAuthorizationStatus(for:) with XCUIProtectedResource.camera, available from iOS 13.4. It returns the app to .notDetermined, and the XCUITest driver's mobile: resetPermission, which takes a protected-resource name, is documented for simulators and real devices. Nothing in XCTest sets camera access to authorized, denied or restricted. Those states come from tapping the prompt or from device restrictions, so UI tests reach them through the protocol from the previous section, chosen by a launch argument in debug builds only:
// App target\n#if DEBUG\nstruct SeededCamera: CameraAuthorizing {\n let value: AVAuthorizationStatus\n func status() -> AVAuthorizationStatus { value }\n}\n\nfunc makeCameraAuthorizer(\n arguments: [String] = ProcessInfo.processInfo.arguments\n) -> any CameraAuthorizing {\n guard let flag = arguments.firstIndex(of: \"-seedCamera\"),\n arguments.indices.contains(flag + 1) else { return SystemCamera() }\n switch arguments[flag + 1] {\n case \"authorized\": return SeededCamera(value: .authorized)\n case \"denied\": return SeededCamera(value: .denied)\n case \"restricted\": return SeededCamera(value: .restricted)\n default: return SystemCamera() // \"notDetermined\" uses the real API after a reset\n }\n}\n#else\nfunc makeCameraAuthorizer() -> any CameraAuthorizing { SystemCamera() }\n#endif// UI test target\nimport XCTest\n\nfinal class CameraStateScreenTests: XCTestCase {\n private func launch(seeding state: String) -> XCUIApplication {\n let app = XCUIApplication()\n app.launchArguments += [\"-seedCamera\", state]\n app.launch()\n return app\n }\n\n func testDeniedOffersSettingsAfterTap() {\n let app = launch(seeding: \"denied\")\n XCTAssertFalse(app.buttons[\"camera.openSettings\"].exists)\n app.buttons[\"scan.start\"].tap()\n XCTAssertTrue(app.buttons[\"camera.openSettings\"].waitForExistence(timeout: 5))\n }\n\n func testRestrictedExplainsWithoutSettingsLink() {\n let app = launch(seeding: \"restricted\")\n app.buttons[\"scan.start\"].tap()\n XCTAssertTrue(app.staticTexts[\"camera.restrictedExplanation\"].waitForExistence(timeout: 5))\n XCTAssertFalse(app.buttons[\"camera.openSettings\"].exists)\n }\n}The seeding factory compiled with -D DEBUG and returned the expected screen for each launch argument; the UI test needs Xcode and a simulator, and was not run here. Since Xcode 16.3 the UI classes live in XCUIAutomation, and import XCTest re-exports it, so the test file needs no extra import.
The trade is a test seam in shipping code, kept out of release builds by #if DEBUG. It also limits what these tests prove: they show your UI given a status, not that iOS reports that status. For the settings link itself, UIApplication.openSettingsURLString is the documented deep link to your app's page in Settings. Assert that the button opens it, and leave what Settings shows to the OS.
Something still has to prove that the real prompt appears, that it carries your purpose string, and that the app reacts to the answer. On iOS the purpose string is the one piece of that dialog you own. Apple requires NSCameraUsageDescription, and calling requestAccess or starting a capture session without it \"raises an exception.\" That makes it worth one test, started from a reset state:
final class CameraPromptReceiptTests: XCTestCase {\n // OS-owned copy. The only place the suite depends on it.\n private let allowLabel = \"Allow\"\n\n func testFirstScanShowsSystemPromptWithOurPurpose() {\n let app = XCUIApplication()\n app.resetAuthorizationStatus(for: .camera)\n app.launch()\n app.buttons[\"scan.start\"].tap()\n app.buttons[\"camera.explainer.continue\"].tap()\n\n let springboard = XCUIApplication(bundleIdentifier: \"com.apple.springboard\")\n let alert = springboard.alerts.firstMatch\n XCTAssertTrue(alert.waitForExistence(timeout: 10))\n let purpose = alert.staticTexts.matching(\n NSPredicate(format: \"label CONTAINS %@\", \"scan shelf labels\")).firstMatch\n XCTAssertTrue(purpose.exists, \"purpose string missing from the prompt\")\n\n alert.buttons[allowLabel].tap()\n XCTAssertTrue(app.otherElements[\"camera.viewfinder\"].waitForExistence(timeout: 5))\n }\n}The test queries the alert directly rather than registering an interruption monitor. Apple's guidance is explicit: \"When an alert or other modal UI is an expected part of the test workflow, don't write a UI interruption monitor,\" because monitors only fire when an unrelated interruption blocks an element. Reaching the alert through SpringBoard's bundle identifier is common practice, but Apple's documentation for init(bundleIdentifier:) does not promise which process hosts system alerts. That uncertainty is another reason to keep it to one test.
On Android, the dialog's buttons are defined in the PermissionController module's layout in AOSP, with ids such as permission_allow_button, permission_allow_foreground_only_button, permission_allow_one_time_button and permission_deny_button. Matching on the id suffix with a pattern avoids depending on button copy and on which package hosts the dialog on a given build:
@Test\nfun firstScanShowsSystemDialog() {\n // Runner seeded \"not-asked\" before this test.\n val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())\n launchActivity<ScanActivity>().use {\n onView(withId(R.id.scan_start)).perform(click())\n onView(withId(R.id.explainer_continue)).perform(click())\n\n val allow = device.wait(\n Until.findObject(By.res(Pattern.compile(\".*:id/permission_allow(_foreground_only)?_button\"))),\n 10_000,\n )\n assertNotNull(\"system camera dialog did not appear\", allow)\n allow.click()\n onView(withId(R.id.viewfinder)).check(matches(isDisplayed()))\n }\n}Those ids come from AOSP; a vendor build can change them, which is exactly why this check runs on the release devices from the device matrix before a release, not on every pull request. The receipts cover the joint between your app and the OS; everything else covers behaviour.
\n\nThe Android dialog never appears. The cause is usually a USER_FIXED flag left by an earlier test or run, which turns the request into an immediate denial. The check: adb shell dumpsys package com.example.scanner and read the camera line's flags. The fix is the seed script at the start of every test that cares, never a reinstall in the middle of a run.
The app vanishes right after setup. A revoke ran while the app was alive, and the process was terminated as the guide describes. It shows as a test that fails on its first interaction with no crash report. The check is whether the seed step ran after launch. The fix is ordering: stop, seed, launch.
\n\nA granted permission disappears after the app is backgrounded. A receipt test, or a person at the device, picked Only this time, and the grant expired once the app left the foreground. Android's flag names include ONE_TIME alongside USER_SET and USER_FIXED, so the same dumpsys line tells this case apart from the first. Seed granted with pm grant rather than inheriting whatever the receipt left.
The iOS receipt waits for an alert that never comes. A previous run on the same simulator already answered, and the status is no longer .notDetermined. The check is whether resetAuthorizationStatus(for: .camera) runs before launch(). Without the reset, the test passes only on fresh simulators.
Pick the one permission your most-used feature depends on. On Android, run the seed script with blocked, launch, tap the feature, and check that the screen offers a way forward rather than a button that does nothing. On iOS, launch with -seedCamera denied and then restricted, and check that only the first offers Settings. If either check fails on the shipped build, that is a production bug, found without touching a system dialog.
Keep three pieces of evidence: the dumpsys line the seed script printed, a screenshot of the recovery screen for each state, and one passing receipt per platform from the release device run. Together they show the app handles every reachable state and that the real prompt still connects to it.
For suites whose subject is not permissions, do. UiAutomator2's appium:autoGrantPermissions grants every requested permission when the session starts, and the XCUITest driver's appium:autoAcceptAlerts accepts every alert, privacy prompts included. Both remove the denial paths from that suite entirely, so they cannot be the only place permissions are tested.
Not unchanged. Photo access has a fifth state on both platforms: PHAuthorizationStatus.limited on iOS 14 and later, and partial access through READ_MEDIA_VISUAL_USER_SELECTED on Android 14 and later, where the user picks individual items. Add a row for it, with its own screen and its own way to reselect.
It can enumerate combinations quickly, and it will also produce rows the platform cannot reach, such as an iOS camera that was denied but can still be asked. Which states exist is decided by the platform documentation, the AOSP rationale logic and a real device. Use generated rows as a checklist, then delete every row you cannot seed or reach.
\n\nUSER_SET and USER_FIXED flags in dumpsys, pm clear-permission-flags, one-time permissions and process termination on revoke, the sample comment against linking to settings, and install -g.pm grant and pm revoke commands and the -g install option.set-permission-flags help text and its accepted flag list, and reset-permissions taking no package.shouldShowRequestPermissionRationale logic over the fixed flags and USER_SET, and the grant path that logs and returns for a policy-fixed permission.ONE_TIME and POLICY_FIXED.setPermissionGrantState, the denied state where \"the user cannot manage it through the UI\", and which callers may use it.By.res(Pattern) selector used to match the dialog's resource ids.READ_MEDIA_VISUAL_USER_SELECTED and reselection.appium:autoGrantPermissions, mobile: changePermissions, mobile: getPermissions, and mobile: shell behind the uiautomator2:adb_shell feature.mobile: setPermission services and mobile: resetPermission on simulators and real devices.appium:autoAcceptAlerts including privacy alerts, and the simulator-only appium:permissions capability.simctl privacy service names, with no camera entry.simctl privacy for creating known permission states.restricted.camera case.