</>KiehnOnline

Programming

Android marshmallow request permission

27 September 2026 · 7 min read

Android marshmallow request permission

Navigating the complexities of Android permissions can be a significant hurdle for both app developers and users. With the release of Android 6.0 Marshmallow (API level 23), Google introduced a groundbreaking change to how applications request and manage permissions: runtime permissions. This pivotal update shifted the control from installation time to when the app actually needs access to sensitive data or features, fundamentally altering the user experience and enhancing security. Understanding the nuances of an Android Marshmallow request permission is crucial for ensuring your applications function smoothly while respecting user privacy and adhering to modern security standards.

Understanding Runtime Permissions in Android Marshmallow

Before Android Marshmallow, users granted all necessary permissions during app installation. This “all or nothing” approach often led to users unknowingly granting extensive permissions that weren’t immediately obvious or even necessary for core app functionality, posing significant privacy and security risks. Android Marshmallow revolutionized this model by introducing runtime permissions, also known as “dangerous permissions.” These are permissions that could potentially affect the user’s privacy or the device’s operation, such as accessing contacts, location, camera, or microphone.

Instead of granting these permissions at install, apps must now explicitly ask the user for permission at the time the feature requiring it is used. For instance, a messaging app might only request camera access when the user tries to send a photo, not immediately upon installation. This granular control empowers users to make informed decisions about what data they share and when, significantly improving transparency. It also encourages developers to design apps that only request permissions when truly needed, fostering a more secure and trustworthy app ecosystem. According to Google’s Android Developers documentation, this change was primarily driven by the need to give users more control over their data. For more details, refer to the official Android 6.0 behavior changes documentation.

The system automatically grants “normal permissions” (those that don’t pose a privacy risk, like accessing the internet) at installation. However, “dangerous permissions” require user approval at runtime. Apps targeting API level 23 or higher must be designed to handle permission requests gracefully, including situations where the user denies a request. This ensures a robust and user-friendly experience, preventing crashes and offering clear alternatives.

Why Runtime Permissions Matter: Security and User Control

The introduction of runtime permissions in Android Marshmallow was a monumental step forward for user security and privacy. Previously, malicious apps could request a broad range of permissions during installation, often hidden within lengthy terms and conditions that users rarely read. Once installed, these apps could then exploit those permissions without any further user interaction, potentially accessing sensitive data like contacts, call logs, or even location data in the background.

With the new permission model, users have direct control over what an app can access and when. This means that if an app wants to use the microphone, a clear permission dialog appears, giving the user the option to grant or deny. This significantly reduces the attack surface for privacy-invasive apps and increases user confidence. A study by NortonLifeLock highlighted that runtime permissions were a crucial improvement in mitigating mobile malware threats, providing users with a clearer understanding of an app’s capabilities and intentions. This enhanced transparency is not just about security; it’s also about building trust between users and app developers.

What are Android Marshmallow runtime permissions? Android Marshmallow runtime permissions are a security feature introduced in Android 6.0 (API level 23) that requires apps to explicitly ask users for permission to access sensitive resources (like camera, microphone, or contacts) at the time they are needed, rather than granting all permissions during app installation. This empowers users with more control over their data and enhances device privacy.

For developers, understanding this shift means moving beyond simply declaring permissions in the manifest. It requires implementing logic to check for permissions, request them when necessary, and handle user responses appropriately. This involves checking the app’s current permissions status, presenting system-generated permission dialogs, and reacting to the user’s choice. Failing to implement this correctly can lead to app crashes or a poor user experience, as the app might try to access a protected resource without the necessary authorization. Developers must also consider edge cases, such as users revoking permissions later via device settings.

How to Implement Android Marshmallow Request Permission in Your App

Implementing runtime permissions involves a structured approach to ensure your app behaves predictably and respectfully. The process typically includes checking if a permission has already been granted, requesting it if not, and then handling the user’s response. This proactive method prevents crashes and ensures your app adheres to the Android security model.

Here’s a step-by-step guide for requesting a dangerous permission:

  1. Check if you have the permission: Before performing an operation that requires a dangerous permission, you must check if your app already has that permission. Use ContextCompat.checkSelfPermission() from the AndroidX library for this.
  2. Request the permission (if necessary): If the permission is not granted, you must request it from the user. Use ActivityCompat.requestPermissions(). This method asynchronously requests the permissions and calls back to your activity’s onRequestPermissionsResult() method.
  3. Provide context (optional but recommended): If your app needs a permission that the user might not immediately understand, or if the user previously denied the permission, you should provide an explanation using ActivityCompat.shouldShowRequestPermissionRationale(). This helps users understand why the permission is necessary, improving the chances of them granting it.
  4. Handle the user’s response: After the user responds to the permission dialog, the system invokes your app’s onRequestPermissionsResult() callback. This is where you determine if the permission was granted or denied and proceed accordingly. If granted, perform the operation. If denied, gracefully inform the user about the feature’s limited functionality without the permission.

A common pitfall is requesting all dangerous permissions at once without providing context. Users are more likely to grant permissions when they understand the immediate benefit. For example, a photo editing app shouldn’t ask for camera access on launch if the user isn’t about to take a photo. Instead, it should request it when the user taps the “Take Photo” button. For practical code examples and best practices, developers often consult resources like GeeksforGeeks on Android Runtime Permissions, which provides clear snippets and explanations.

Best Practices for Handling Permission Requests

Effective management of runtime permissions goes beyond mere implementation; it involves strategic design choices that enhance user experience and trust. A well-designed permission flow can significantly reduce permission denials and improve app adoption. Prioritize user education and transparency in your approach.

  • Request permissions in context: Only ask for a permission when it’s immediately relevant to the user’s current action. For example, request location access when the user taps a “Find Nearby Stores” button, not when the app first launches. This direct association helps users understand the “why.”

  • Explain why you need the permission: If shouldShowRequestPermissionRationale() returns true, display a user-friendly explanation. A simple dialog or a brief in-app message can clarify the benefit of granting the permission. Avoid technical jargon and focus on how the permission improves the user’s experience.

  • Handle denials gracefully: Users might deny a permission. Your app should not crash. Instead, disable the feature that requires the permission, offer an alternative, or gently remind the user that the feature won’t work without it. Do not repeatedly badger users with permission requests Question & Answer :
    I am currently working on an application that requires several “dangerous” permissions. So I tried adding “ask for permission” as required in Android Marshmallow(API Level 23), but couldn’t find how to do it.

    How can I ask for permission using new permission model in my app?

    Request runtime permissions from the docs has code examples you can use.

    The code snippets in this answer are taken from that document.

    Open a Dialog using the code below:

    ActivityCompat.requestPermissions(MainActivity.this, new String[]{Manifest.permission.READ_EXTERNAL_STORAGE}, 1);

    Get the Activity result as below:

    @Override public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) { switch (requestCode) { case 1: { // If request is cancelled, the result arrays are empty. if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) { // permission was granted, yay! Do the // contacts-related task you need to do. } else { // permission denied, boo! Disable the // functionality that depends on this permission. Toast.makeText(MainActivity.this, "Permission denied to read your External storage", Toast.LENGTH_SHORT).show(); } return; } // other 'case' lines to check for other // permissions this app might request } }

    More info: https://developer.android.com/training/permissions/requesting.html