Runtime Permissions Quiz
ANDROID › System
Which API pair is the recommended modern way to request a single runtime permission?
- ActivityCompat.requestPermissions() paired with the onRequestPermissionsResult() callback
- registerForActivityResult(RequestPermission()) paired with launcher.launch()
- PackageManager.requestPermission() paired with a BroadcastReceiver result callback
- Context.checkCallingPermission() paired with a coroutine-based permission request flow
Answer: registerForActivityResult(RequestPermission()) paired with launcher.launch()
The AndroidX Activity Result APIs (RequestPermission contract registered via registerForActivityResult) are the recommended approach; they auto-manage request codes and survive recreation. The requestPermissions/onRequestPermissionsResult flow is deprecated.
A user denied your camera permission once (without 'don't ask again'). What does shouldShowRequestPermissionRationale() now return?
- false, because a single denial permanently blocks the permission from ever returning
- It throws an exception because the permission has never actually been granted before
- true, indicating you should show a rationale to the user before asking again
- It returns the PERMISSION_DENIED integer constant instead of a plain boolean value
Answer: true, indicating you should show a rationale to the user before asking again
After a single non-permanent denial the method returns true, signaling that the user has seen the dialog before and you should explain why the permission is needed before asking again.
How can your app distinguish a permanently denied permission from one that has never been requested?
- Both states return PERMISSION_GRANTED, so the app can never tell the two apart
- checkSelfPermission returns a distinct constant for each of the two denied states
- shouldShowRequestPermissionRationale by itself returns true only for permanent denial
- Both look denied with rationale false, so persist your own "already asked" flag
Answer: Both look denied with rationale false, so persist your own "already asked" flag
shouldShowRequestPermissionRationale returns false both before the first request and after permanent denial, so the app must persist a flag (e.g., in SharedPreferences) recording that it already prompted to tell the two states apart.
On Android 12+, you request ACCESS_FINE_LOCATION. What can the user choose to grant?
- Only fine location, since requesting fine always forces precise access
- Approximate only, using the Precise/Approximate toggle in the dialog
- Background location too, granted automatically together with fine access
- Nothing at runtime; fine location can’t be requested on Android 12+
Answer: Approximate only, using the Precise/Approximate toggle in the dialog
Since Android 12 the location dialog includes a precise/approximate toggle, so even when you request FINE the user can grant only COARSE; you should request both and handle a coarse-only result.
What is the correct way to handle a permission the user has permanently denied?
- Send the user to the app's Settings page via ACTION_APPLICATION_DETAILS_SETTINGS
- Call launcher.launch() repeatedly in a loop until the system finally shows the dialog
- Call ActivityCompat.requestPermissions with a fresh request code to bypass the block
- Programmatically uninstall and then reinstall the app to reset the permission state
Answer: Send the user to the app's Settings page via ACTION_APPLICATION_DETAILS_SETTINGS
Once permanently denied the system will not show the dialog again, so the only path is to send the user to the app's Settings page; meanwhile the app should keep working with reduced functionality and not nag.
Under scoped storage, which approach lets an app let the user pick a photo with NO storage permission at all?
- Requesting the WRITE_EXTERNAL_STORAGE dangerous permission at runtime
- Requesting the broad MANAGE_EXTERNAL_STORAGE all-files access permission
- The Android Photo Picker (ACTION_PICK_IMAGES / PickVisualMedia)
- Reading directly from /sdcard/DCIM using a raw File path and streams
Answer: The Android Photo Picker (ACTION_PICK_IMAGES / PickVisualMedia)
The Photo Picker (PickVisualMedia / ACTION_PICK_IMAGES) returns user-selected media through a system UI and requires no permission, which is why broad storage permissions are now discouraged under scoped storage.
What happens with a one-time ('Only this time') permission granted on Android 11+ when the app stays in the background?
- It is silently upgraded to a permanent, always-allow grant after just the first use
- It silently converts into a persistent background-location grant without ever asking
- It persists until the next device reboot regardless of the app's foreground state
- The grant is revoked after a while in the background, so the next use re-prompts
Answer: The grant is revoked after a while in the background, so the next use re-prompts
One-time grants last only while the app is in active use; after the app spends time in the background the permission is auto-revoked and re-launching the feature triggers a fresh prompt. Explicit user revocation also kills the process.
Which statement about the POST_NOTIFICATIONS permission is correct?
- An install-time normal permission granted automatically at install with no prompt shown
- A runtime permission added in Android 13 that API 33+ apps must hold to post notifications
- It only governs notifications posted by foreground services, not ordinary app notifications
- It belongs to the location permission group and is granted alongside ACCESS_FINE_LOCATION
Answer: A runtime permission added in Android 13 that API 33+ apps must hold to post notifications
POST_NOTIFICATIONS is a runtime (dangerous) permission added in Android 13; apps targeting API 33+ must be granted it before any notification is displayed, otherwise the system silently drops their notifications.
How must an app obtain ACCESS_BACKGROUND_LOCATION on Android 11+?
- Request both at once in the same dialog with foreground location.
- Declare it in the manifest with maxSdkVersion so it's granted at install.
- Request foreground first, then request background separately in Settings.
- It can't be obtained on Android 11+, because background location was removed.
Answer: Request foreground first, then request background separately in Settings.
From Android 11 you must request location incrementally: foreground first, then background as a separate request, and that background request takes the user to the Settings page to choose 'Allow all the time' rather than showing an in-app dialog.
On Android 11+, what happens to an app's granted runtime permissions if the user does not use the app for a few months?
- Nothing; runtime grants stay until the user manually uninstalls the app.
- The app is automatically uninstalled by the system to reclaim device space.
- Only install-time permissions are revoked; runtime grants remain intact.
- The system auto-resets runtime permissions and hibernates the app.
Answer: The system auto-resets runtime permissions and hibernates the app.
Permission auto-reset (and app hibernation) revokes the runtime permissions of apps that go unused for an extended period, so you must always re-check with checkSelfPermission on launch and be ready to request again.
Which of the following is a normal (install-time) permission that requires no runtime prompt?
- android.permission.INTERNET
- android.permission.CAMERA
- android.permission.READ_CONTACTS
- android.permission.RECORD_AUDIO
Answer: android.permission.INTERNET
INTERNET has the normal protection level and is granted automatically at install without any user prompt, whereas CAMERA, READ_CONTACTS, and RECORD_AUDIO are dangerous permissions that must be requested at runtime.
When you launch an ActivityResultContracts.RequestMultiplePermissions() contract, what does the result callback receive?
- A single Boolean that is true only if every requested permission was granted
- A Map<String, Boolean> mapping each requested permission to its granted result
- An Int request code you must manually match against the one you passed in earlier
- An Intent whose extras bundle lists the individual permissions the user approved
Answer: A Map<String, Boolean> mapping each requested permission to its granted result
RequestMultiplePermissions delivers a Map<String, Boolean> keyed by each permission string, letting you inspect partial outcomes such as coarse-granted-but-fine-denied individually.
How does an app obtain a special app-access permission such as SYSTEM_ALERT_WINDOW (draw over other apps) or MANAGE_EXTERNAL_STORAGE?
- Through the normal runtime prompt by calling launcher.launch() on a permission contract
- They are granted automatically at install time because they are normal protection-level permissions
- Only by signing the app with the platform certificate so Android trusts it as system-level
- By opening the matching Settings page with a special intent, then checking the grant afterward
Answer: By opening the matching Settings page with a special intent, then checking the grant afterward
Special permissions are not granted through the runtime permission dialog; the app must route the user to a specific Settings page via an intent like ACTION_MANAGE_OVERLAY_PERMISSION (or ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION) and verify the result afterward.
On Android 14, when an app requests READ_MEDIA_IMAGES, what new choice can the user make in the dialog?
- Pick only specific photos, granting READ_MEDIA_VISUAL_USER_SELECTED
- Nothing changed since Android 13; media access remains strictly all-or-nothing
- Automatically upgrade the app to MANAGE_EXTERNAL_STORAGE for full file access
- Grant an 'approximate media' access tier, much like coarse location does for GPS
Answer: Pick only specific photos, granting READ_MEDIA_VISUAL_USER_SELECTED
Android 14 added partial (selected) photo and video access: the user can pick specific items, in which case READ_MEDIA_VISUAL_USER_SELECTED is granted instead of full READ_MEDIA_IMAGES/VIDEO, and the app sees only the chosen media.