Runtime Permissions Interview Questions
ANDROID › System
Walk me through the full decision tree your app should follow the first time a feature needs camera access, from checking whether it already has permission through to the user denying it twice.
What a strong answer covers: Start with checkSelfPermission to avoid an unnecessary prompt if already granted; if not granted, consult shouldShowRequestPermissionRationale to decide whether to show explanatory UI before the system dialog; launch the request via registerForActivityResult(RequestPermission()); on denial, check shouldShowRequestPermissionRationale again, and if it now returns false, treat that as permanent denial since the system won't show its own dialog again, and route the user to the app's Settings screen via ACTION_APPLICATION_DETAILS_SETTINGS instead of re-prompting.
A PM wants the app to request location permission the moment the user opens the app so it's 'out of the way.' How would you push back, and what's the actual best practice?
What a strong answer covers: Best practice is contextual, just-in-time requesting right before the feature that needs it, paired with rationale UI explaining the benefit, because grant rates are far higher when users understand why in the moment, and Play policy expects permissions to be justified by immediate use. There's also a technical reason to avoid front-loading: Android 11+ auto-resets permissions the user hasn't exercised, so asking at launch for a feature they haven't touched yet risks the grant being revoked before it's ever used.
Design the UX for a photo-editing feature across three outcomes on Android 14: the user grants full photo access, grants only 'Selected photos' partial access, or denies outright. What are the engineering implications of each path?
What a strong answer covers: Full access proceeds normally; partial access (READ_MEDIA_VISUAL_USER_SELECTED) means the app can only see the specific photos the user picked, so if they need a different one later the app should re-invoke the system picker to let them add more rather than assuming visibility into the whole library, and should track this as tri-state rather than a boolean granted/denied. Denied outright should fall back to the Photo Picker API or SAF's per-item selection, which need no runtime permission at all; a well-designed feature might avoid requesting READ_MEDIA_IMAGES entirely by defaulting to the picker.