Managing App Permissions on Android 11+

Introduction

With Android 11 and above, Google introduced a suite of refinements to the app permissions model aimed at strengthening user privacy and giving users more granular control over their data. Gone are the days when an app blanket-requested broad access to your device. Today, apps must explicitly request “one-time” permissions, foreground-only access, and justify background operations. For developers and power users alike, understanding these changes is critical. In this guide, we’ll walk through Android’s modern permission categories, best practices for requesting and handling permissions in your code, and hands-on tips to audit and manage app permissions on your own device. By the end, you’ll know how to balance functionality and privacy seamlessly.

1. The Evolved Permission Model in Android 11+

Android 11 refined permissions around three axes: granularity, temporary access, and background control.

1.1 Permission Categories

1. Normal Permissions
   • Low-risk (e.g., INTERNET, VIBRATE)
   • Granted at install time; users aren’t prompted
2. Dangerous Permissions
   • High-risk (e.g., READ_CONTACTS, ACCESS_FINE_LOCATION)
   • Must be requested at runtime
3. Special Permissions
   • Sensitive features (e.g., MANAGE_EXTERNAL_STORAGE, SYSTEM_ALERT_WINDOW)
   • Require navigating users to a system settings page

1.2 One-Time Permissions

• WHAT: Users can grant a single-use permission for camera, microphone, and location.
• WHY: Prevents long-term background surveillance without unneeded friction.
• HOW: Request with the standard runtime API; the system dialog shows “While using the app,” “Only this time,” and “Deny.”

1.3 Background Location Access

• STRONGER CONTROLS: Apps targeting Android 11 can no longer request background location (ACCESS_BACKGROUND_LOCATION) in the same dialog as foreground location.
• TWO-STEP FLOW:
  1. Request ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION.
  2. After granted, prompt the user to grant background access via a separate system settings screen.

2 Best Practices for Developers

2.1 Request Permissions Contextually

• On-Demand: Only request a permission when the user performs the action that needs it. javaCopyEditprivate void openCamera() { if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.CAMERA}, REQUEST_CAMERA); } else { launchCamera(); } }
• Explain the Why: Use shouldShowRequestPermissionRationale() to detect if you should show a custom in-app explanation before the system dialog.

2.2 Handle “Don’t Ask Again”

• Detect: If the user checks “Don’t ask again,” your next requestPermissions call is silently denied.
• Solution:
  1. Check shouldShowRequestPermissionRationale()—it returns false after “Don’t ask again.”
  2. Show a dialog directing the user to your app’s Settings → Permissions page via: javaCopyEditIntent intent = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS); intent.setData(Uri.fromParts("package", getPackageName(), null)); startActivity(intent);

2.3 Use the Jetpack Activity Result APIs

• Why: Simplifies permission callbacks and lifecycle handling.
• Example: kotlinCopyEditprivate val requestPermissionLauncher = registerForActivityResult( ActivityResultContracts.RequestPermission() ) { isGranted: Boolean -> if (isGranted) { launchCamera() } else { showPermissionDeniedMessage() } } fun askCameraPermission() { requestPermissionLauncher.launch(Manifest.permission.CAMERA) }

3. Managing Special Permissions

3.1 All Files Access (MANAGE_EXTERNAL_STORAGE)

• Scope: Grants broad file-system access akin to legacy storage model.
• Google Play Policy: Restricted use; you must justify in your Play Console declaration.
• Settings Flow: javaCopyEditif (!Environment.isExternalStorageManager()) { Intent intent = new Intent(Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION); intent.setData(Uri.fromParts("package", getPackageName(), null)); startActivity(intent); }

3.2 SYSTEM_ALERT_WINDOW and Notification Access

• Overlay Permission: For drawing over other apps.
• Notification Listener: For reading notifications.
• Both Require: Directing users to a system settings screen—no runtime dialog.

4. Auditing and Managing Permissions on Your Device

4.1 Viewing App Permissions

1. Open: Settings → Apps → See all apps
2. Select App → Permissions
3. Grant/ Revoke: Tap each category to change

4.2 One-Time and Auto-Reset Behavior

• One-Time Permissions auto-revoke on app exit.
• Auto-Reset: Unused apps have all dangerous permissions reset after a period of inactivity—revoked next launch.

4.3 Permission Dashboard (Android 12+)

• Central View: Settings → Privacy → Permission Manager
• Filter by Permission: See which apps have access to location, microphone, camera, etc.

5. Handling Permission Denials Gracefully

1. Fallback Functionality
   • If camera is denied, allow image upload from gallery.
2. User Education
   • Show friendly in-app messages explaining why the permission matters.
3. Progressive Enhancement
   • Offer non-permission-based features first, then prompt for extra features when needed.

Conclusion

Android 11+ elevates privacy by giving users deeper control over app permissions—introducing one-time grants, separate flows for background access, and stricter special-permission handling. As a developer, you should request permissions contextually, use modern APIs like ActivityResultContracts, and guide users transparently when advanced permissions are needed. As an Android user, audit your app permissions regularly in Settings or the Permission Dashboard, and leverage one-time grants to safeguard your data. By following these best practices, you’ll deliver both robust functionality and a privacy-first experience on today’s Android platforms.