Android Permissions Activity Results

When To Use

Use this skill when the request is about: android permission request flow, activity result api android, camera permission in android app.
Primary outcome: Use modern permission requests, Activity Result APIs, and capability-gated UX in Android flows.
Read references/patterns.md when you need the picker-vs-permission matrix or API-level behavior checklist.
Read references/scenarios.md for photo picker, notification permission, and limited media access examples.
Handoff skills when the scope expands:
android-media-files-sharing
android-testing-ui

Start with the capability the user needs, not the permission name: photo picker, document picker, camera capture, or notification opt-in often avoids broader runtime permissions.
Choose the right Activity Result contract and keep the launcher in a stable lifecycle owner such as an activity, fragment, or remembered Compose launcher.
Model the full permission state space explicitly: granted, denied, permanently denied, limited/selected access, one-time access, and settings-based recovery.
Account for API-level differences such as POST_NOTIFICATIONS on Android 13+, approximate vs precise location, background location as a separate flow, and Android 14 selected-photos access.
Re-check capability on return from settings or picker flows, then validate rotation, process death, and denial recovery instead of assuming the happy path.

Treat loading, empty, error, offline, and permission-denied states as first-class UI states.
Do not launch permission or picker contracts directly from composition without a user action or explicit side effect.
Prefer the narrowest capability surface available, such as Photo Picker or SAF, over broad storage permissions.
Keep permission recovery testable: rationale, settings redirect, denied state, and post-return revalidation.

Assuming the happy path is enough for product flows.
Repeatedly re-prompting after denial instead of offering a clear settings or alternate-path recovery.
Requesting media or storage access when the Photo Picker or document contracts are enough.
Treating Android 14 selected-photos access as full media-library access.

Can the feature use a picker or contract instead of a runtime permission?
Does the flow handle denial, limited access, and return-from-settings correctly?
Are permission launches owned by the right lifecycle scope and initiated at the right time?
Are platform-specific behaviors called out for Android 13+ and Android 14+ where relevant?

Scenario: Find the repo's Activity Result and permission surfaces before proposing a flow change.
Command: rg -n "rememberLauncherForActivityResult|RequestPermission|RequestMultiplePermissions|PickVisualMedia|OpenDocument|TakePicture" examples

Scenario: Review notification and media access paths for API-level-specific behavior.
Command: rg -n "POSTNOTIFICATIONS|READMEDIA|READEXTERNAL_STORAGE|PickVisualMedia" examples

Scenario: Differentiate permission prompts from media-sharing and testing requests.
Command: python3 scripts/eval_triggers.py --skill android-permissions-activity-results

The chosen contract or picker is narrower than a broad permission where possible.
Denied, permanently denied, limited, and settings-return states are all modeled.
API-level differences are called out for the affected Android versions.
Recovery UI and observability are explicit instead of implied.