A permission dialog is part of the application workflow. Handle it as a visible decision, then verify what changed. An Android agent that blindly taps the first Allow-looking label will eventually grant the wrong permission, miss a denial path, or continue behind a dialog it never dismissed.

For a test, decide the permission policy before launching the app. Are you checking first-run consent, testing graceful denial, or deliberately pre-granting runtime permissions so a different feature can be exercised? Those are different cases and should produce different evidence.

Observe before choosing the permission action

Open the app, read the current screen, identify the requesting app and permission, then choose the permitted response. Text and resource identifiers can change with Android version, language and app implementation. Use the latest observation rather than reusing an old element reference.

Android’s runtime permission guide distinguishes runtime permissions from special permissions and recommends asking in context and handling denial gracefully. An automation test should preserve that distinction instead of treating every Settings screen as the same dialog.

A compact REST action can express the specific choice you have already observed:

json
{
  "actions": [
    { "type": "tap", "target": { "text": "Don't allow" } }
  ]
}

That label is illustrative, not a universal selector. Read the real screen, including locale-specific capitalization and punctuation. After the action, inspect the returned screen and test the behavior you intended to exercise. “Permission dialog dismissed” is not equivalent to “feature works”.

Use pre-granting only when it matches the test

The install endpoint supports grant_permissions for runtime permissions. For local APK bytes, it can be requested explicitly:

bash
curl --fail-with-body -X POST "$MSB/v1/phones/$ID/apps?grant_permissions=true" \
  -H "Authorization: Bearer $MOBILESANDBOX_API_KEY" \
  -H 'Content-Type: application/octet-stream' --data-binary @app.apk

Leave that option off when you are testing first-run permission UX or a denied state. Pre-granting changes the starting conditions, so it can make a test pass while skipping the behavior you meant to validate. It also does not manufacture a camera, physical sensor or external account capability.

Special permissions need their own path

An app may direct the user to a Settings page for a permission with a separate approval mechanism. Treat that as a new foreground screen: observe, identify the correct app/setting, act, return to the app and verify the effect. Do not claim grant_permissions automatically grants every Android access category.

A useful failure trace records the app package, the screen before the choice, the selected action and the app’s next screen. Avoid storing unrelated account data from a broad screenshot. The screen observation guide explains when a text trace is enough.

Cover denial and returning-user state

For an owned app, run at least one clean-install consent case and one denial case. Then decide whether a returning user should see the dialog again. A parked sandbox retains saved app state; it is therefore different from a fresh permission test. A repeat run on an old phone can silently skip the first-run experience.

Use a fresh disposable sandbox when you need known starting conditions, and preserve a sandbox only when retention is part of the scenario. See fresh versus persistent sandboxes, installation details and the error reference before encoding a long permission-handling batch.

Put it to work.

Open the quickstartRead the API reference