Phase 3: Native Development

Runtime permission requests & graceful denial handling

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're at school, and you're working on a really cool art project. You have your basic pencils, paper, and crayons, but to make something super special, like a pop-up card or a detailed collage, you might need extra tools – like sharp scissors, a specific type of glue, or even a fancy tablet to draw on. It used to be that your teacher would give you all these special supplies at the very start of the school year. Once you had them, you could use them whenever you wanted, no questions asked.

But now, things are a little different. Your teacher wants to make sure that everyone is really using those special supplies only when they absolutely need them, and that you know exactly what you're using them for. So, if you want to cut out a picture for your pop-up card, you have to ask for the scissors right then, just before you need to make the cut. This way, you know exactly why you're asking, and the teacher knows you're not just playing with them when you don't actually need them. It's about being responsible and keeping track of who is using what for important tasks.

Sometimes, when you ask for the scissors, the teacher might pause and say, "Are you really sure you need those right now?" or maybe they remember you once left them open on the desk. This is where you, as the app maker, have to be super polite and clear. You might say, "Yes, I really need them to cut out these tricky shapes for my awesome pop-up card!" If the teacher still says no, you don't just give up on your project completely. Maybe you can offer a different way to do it, like carefully tearing the paper instead, or you can gently remind the teacher that without scissors, the card won't look as neat and detailed. Your job is to make it easy for the teacher to say yes, and if they say no, to have a plan B or gently explain why it’s important.

So, when you're building your own apps, think of it like this: your app might need special "supplies" from the phone, like using its camera for photos or its built-in map for directions. Instead of just grabbing them at the start, you politely ask the phone (and the person using it!) right when you need them. And if the phone or person says "no" at first, you'll have a friendly explanation ready, or a clever alternative, so your app can still be helpful and awesome, even if it can't use all the special tools. This makes your apps much more trustworthy and friendly for everyone using them.

Modern mobile operating systems (Android 6.0+ / API 23+ and iOS) utilize runtime permissions for sensitive features like camera, location, contacts, and storage access. Unlike older models where permissions were granted solely at app installation, runtime permissions require your app to explicitly ask the user for permission while the app is running, typically right before a feature that requires it is used. This gives users greater control and transparency over their data and device resources, but it places the responsibility on developers to manage these requests proactively and gracefully.

Before performing any operation that requires a sensitive permission, your app must first check if that permission has already been granted. If not, you then initiate a system-provided permission request dialog. A crucial best practice is to provide context and rationale to the user before showing the system dialog, especially if shouldShowRequestPermissionRationale() returns true (indicating the user has previously denied the permission). Explaining why a permission is needed improves the chances of it being granted and enhances the user's understanding of your app's functionality.

Graceful denial handling is paramount for a good user experience. Users can grant, deny, or permanently deny a permission (often by checking a "Don't ask again" box or repeatedly denying). Your app must be robust enough to handle all these scenarios. If a permission is denied (but not permanently), you might be able to request it again later. However, if a permission is permanently denied, your app cannot prompt the user again. In such cases, you must guide the user to the device's app settings to manually grant the permission, or gracefully degrade the feature, perhaps by disabling it or offering an alternative experience without that specific functionality. Never crash or block the entire app due to a denied permission.

Key Takeaways

  • Always check permission status before attempting sensitive operations.
  • Request permissions contextually and provide clear rationale using shouldShowRequestPermissionRationale().
  • Implement robust logic to handle both temporary and permanent permission denials.
  • For permanent denials, guide the user to device settings or gracefully degrade functionality.

Code Example

java
import android.Manifest;
import android.content.pm.PackageManager;
import androidx.core.content.ContextCompat;
import androidx.core.app.ActivityCompat;

// Inside your Activity or Fragment
private final int MY_CAMERA_REQUEST_CODE = 123;

private void requestCameraPermission() {
    if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) == PackageManager.PERMISSION_GRANTED) {
        // Permission already granted. Proceed with camera operations.
        // For example: initializeCamera();
    } else {
        // Permission not granted.
        if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA)) {
            // User previously denied, show an explanation before requesting again.
            // A dialog explaining *why* the camera is needed would go here.
            // Example: new AlertDialog.Builder(this).setMessage("Camera is essential for scanning QR codes.").show();
        }
        // Request the permission from the user.
        ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.CAMERA}, MY_CAMERA_REQUEST_CODE);
    }
}
// Note: Handle the result in your Activity's onRequestPermissionsResult method.
// There you'll check if permission was granted or denied and react accordingly.

How this code works

This code's job is to safely ask the user for permission to use the device's camera at runtime, which is a key privacy control in modern mobile operating systems. It gracefully handles different user responses, from immediate approval to repeated denials. The requestCameraPermission method first checks if Manifest.permission.CAMERA is already PackageManager.PERMISSION_GRANTED using ContextCompat.checkSelfPermission. If permission is already in place, the app can proceed directly with camera-related tasks.

If permission isn't granted, the code takes an important step: it checks ActivityCompat.shouldShowRequestPermissionRationale. This is a subtle yet crucial aspect: it returns true specifically when the user has previously denied the permission but has not yet chosen the "Don't ask again" option. In this scenario, the app should provide an explanation (e.g., in an AlertDialog) describing why the camera is needed before requesting it again. Regardless of whether a rationale was shown, the final step is ActivityCompat.requestPermissions, which displays the standard Android system permission dialog to the user, identifying this specific request with MY_CAMERA_REQUEST_CODE. The result of this user interaction is then processed in a separate onRequestPermissionsResult method.

Related Articles

Hand-picked reads to go deeper on permissions & privacy.

Back to Mobile Developer Roadmap