Permissions are one of the most sensitive touchpoints between an Android app and its users. Every time a permission dialog appears, the user makes a split-second decision about whether they trust the app enough to grant access. Get this interaction wrong, and you lose users before they ever experience what your app can do.
Android's permission model has evolved significantly over the past several years, and 2026 brings continued refinements that developers need to understand. The days of requesting a blanket list of permissions at install time are long gone. Today, the system expects apps to request permissions contextually, explain their purpose clearly, and function gracefully when access is denied.
The Principle of Minimal Access
The single most important rule for permissions is to request only what your app genuinely needs to function. Every unnecessary permission erodes user trust and increases the likelihood of rejection during review on the Play Store.
Before adding a permission to your manifest, ask yourself whether the feature it enables is core to your app's value proposition. If your app needs to read NFC tags, the NFC permission is clearly justified. If your app is a calculator that requests camera access for a QR code scanner buried three levels deep in the settings, users will rightfully question your intentions.
Audit your permissions regularly. Dependencies and libraries can introduce permissions that you did not explicitly declare. A networking library might add INTERNET permission automatically, which is harmless. But an analytics SDK that adds ACCESS_FINE_LOCATION without your knowledge is a different matter entirely. Review your merged manifest after every dependency update.
Runtime Permissions Done Right
Since Android 6.0, dangerous permissions must be requested at runtime rather than at install time. The key to a good runtime permission flow is context. Users are far more likely to grant a permission when they understand exactly why it is needed at the moment it is requested.
The worst approach is to request all permissions the instant the app launches. The user has no context for why a flashlight app needs microphone access, and the rapid succession of dialogs feels aggressive. Instead, defer each permission request to the moment the user tries to use the feature that requires it.
For example, if your app has a feature that records voice notes, request the microphone permission when the user taps the record button for the first time. At that point, the connection between the permission and the action is obvious. The grant rate for contextual requests is dramatically higher than for upfront requests.
Handling Permission Denials Gracefully
Users will deny permissions, and your app must handle this without crashing, showing error screens, or becoming unusable. A denied permission should degrade the specific feature that requires it, not the entire application.
When a user denies a permission, provide a brief explanation of what they are missing and offer an easy path to change their mind later. Android provides the shouldShowRequestPermissionRationale method to detect when a user has previously denied a request. Use this to show a clear, non-aggressive explanation before requesting again.
If a user selects the permanent denial option, do not repeatedly prompt them or show persistent banners nagging them to visit settings. Instead, quietly disable the feature and include a subtle option in your app's settings screen that links to the system permission settings. Respect the user's decision.
Transparency Builds Trust
Users today are more privacy-conscious than ever. Many will check your app's permission list on the Play Store before installing. Others will review the privacy dashboard on their device to see which apps have accessed sensitive data recently.
Be transparent about what data you access and why. Consider adding a permissions explanation screen that users can access from your app's settings. This screen should list each permission your app uses, explain the specific feature it enables, and confirm what data is or is not transmitted off the device.
Apps that access location, camera, or microphone in the background face additional scrutiny. Android now displays persistent indicators when these sensors are in use, and the system may revoke background permissions for apps that have not been opened recently. Design your features to use foreground access whenever possible, and only request background access when there is a clear, ongoing user benefit.
Scoped Storage and Photo Picker
File access permissions have undergone the most dramatic changes in recent Android versions. Scoped storage, fully enforced since Android 11, means apps can no longer browse the entire filesystem. Instead, each app has access to its own private directory and must use the system file picker or MediaStore API to access shared files.
The photo picker introduced in Android 13 takes this further by allowing users to grant access to specific photos and videos without giving the app permission to read the entire media library. If your app only needs users to select images, use the photo picker instead of requesting READ_MEDIA_IMAGES permission. Users appreciate the granularity, and your app avoids a permission dialog entirely.
Testing Permissions Thoroughly
Permission behavior varies across Android versions and manufacturer customizations. Test your permission flows on multiple API levels, particularly the transitions at Android 6.0, 10, 11, 12, and 13 where significant permission changes were introduced. Verify that your app handles every combination of granted, denied, and permanently denied states without unexpected behavior.
Automated testing tools can help, but manual testing of the permission dialogs themselves is essential. The wording, appearance, and behavior of system dialogs differ between manufacturers, and you want to ensure your rationale messages look appropriate alongside the system UI on Samsung, Pixel, Xiaomi, and other popular devices. For examples of these principles in practice, apps like AdMoola, NFC Emulate, Motion Watch, and TeleSMS demonstrate contextual permission requests, clear rationale messages, and graceful degradation when access is denied.