Runtime Permissions Flashcards
ANDROID › System
- What is the difference between install-time and runtime permissions?
- Install-time permissions (normal and signature protection levels) are granted automatically at install with no prompt. Runtime ('dangerous') permissions guard sensitive data like location, camera, and contacts, and must be requested at runtime with a user-facing dialog and checked before each use.
- What is the recommended modern API for requesting a runtime permission, and why not the old one?
- Use registerForActivityResult with ActivityResultContracts.RequestPermission (or RequestMultiplePermissions) and call launcher.launch(permission). It manages request codes for you and survives configuration changes. The old ActivityCompat.requestPermissions + onRequestPermissionsResult request-code approach is deprecated and error-prone.
- How do you check whether a permission is currently granted?
- ContextCompat.checkSelfPermission(context, permission) returns PackageManager.PERMISSION_GRANTED or PERMISSION_DENIED. You must call it before every access because the system can revoke permissions at any time (e.g., via auto-reset or the user changing Settings).
- What does shouldShowRequestPermissionRationale return, and what do its true/false values mean?
- It returns true when the user has previously denied the permission once (without 'don't ask again'), signaling you should show an explanatory rationale UI before re-requesting. It returns false both before the first ever request and after permanent denial, so it alone cannot distinguish those two states.
- How do you detect and handle permanent ('don't ask again') denial?
- After two denials the system stops showing the dialog (USER_FIXED). You detect it when the result is denied AND shouldShowRequestPermissionRationale returns false (after a request was already made). Handle it by directing the user to App Settings via an ACTION_APPLICATION_DETAILS_SETTINGS intent, never by re-spamming launch().
- What are approximate vs precise location, and how does a user grant them?
- ACCESS_FINE_LOCATION is precise; ACCESS_COARSE_LOCATION is approximate. On Android 12+ the dialog shows a Precise/Approximate toggle, so even when you request FINE the user can grant only COARSE. Request both together and handle the case where only coarse is granted.
- What is a one-time permission and what happens when the app goes to the background?
- On Android 11+ the dialog offers 'Only this time' for location, camera, and microphone. Access is granted while the app is in use; once the app spends a while in the background the grant is revoked, and re-launching will prompt again. If the user revokes it the process is terminated.
- What is scoped storage and how did it change storage permissions?
- Scoped storage (enforced from Android 10/11) gives each app private access to its own external app-specific directory with no permission needed, plus the MediaStore API for media. Broad READ/WRITE_EXTERNAL_STORAGE is deprecated; on Android 13+ you instead request granular READ_MEDIA_IMAGES/VIDEO/AUDIO, or better, use the Photo Picker which needs no permission at all.
- What are permission groups and why shouldn't you rely on their composition?
- Permission groups bundle logically related permissions (e.g., location) so the system can present a single dialog. Since Android 10 a runtime grant is tracked per individual permission, not per group, and Google warns group membership can change between releases, so never assume granting one permission grants another in the same group.