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

Workflow

1. 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.
2. Choose the right Activity Result contract and keep the launcher in a stable lifecycle owner such as an activity, fragment, or remembered Compose launcher.
3. Model the full permission state space explicitly: granted, denied, permanently denied, limited/selected access, one-time access, and settings-based recovery.
4. 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.
5. Re-check capability on return from settings or picker flows, then validate rotation, process death, and denial recovery instead of assuming the happy path.

Guardrails

• Treat loading, empty, error, offline, and permission-denied states as first-class UI states.