Android Runtime Permission Example with Denial and Retry Handling

Declare only the required capability

For a feature that directly uses the camera, declare android.permission.CAMERA in the manifest. A feature that delegates capture to another application may have a different access model; first choose the API that minimizes your own permission needs.

The official runtime-permission guide recommends requesting access in context rather than presenting a bundle of unrelated requests on launch.

Register the result handler before the action

This Kotlin fragment belongs in an AndroidX activity or fragment. The helper methods represent your application's UI and feature code:

private val cameraRequest = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { granted ->
    if (granted) openCameraFeature()
    else showCameraUnavailableMessage()
}

private fun onScanRequested() {
    if (ContextCompat.checkSelfPermission(
            this, Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED) {
        openCameraFeature()
    } else {
        cameraRequest.launch(Manifest.permission.CAMERA)
    }
}

For a fragment, use the appropriate context and lifecycle setup. Required imports and the camera implementation are intentionally not hidden inside this small example.

Add a rationale without coercion

Use shouldShowRequestPermissionRationale where appropriate to explain why the feature needs access. Do not treat its false result as a universal “permanently denied” flag: it can also be false before the first request and in other states.

Let the user continue with unrelated features. Repeatedly reopening the dialog or blocking the entire app after a declined optional permission undermines the choice.

Handle changed access

Recheck permission when the protected operation starts. A grant can be revoked in settings or expire under platform behavior. Catch and handle the operation's failure appropriately rather than relying on a preference such as cameraPermissionWasGranted=true.

Test the full state table

Test first request, grant, denial, repeated denial, settings grant, settings revocation and app recreation. Check behavior on the oldest supported Android version and a current target/version combination.

APKLint can inspect the declaration and flag suspicious patterns. It cannot click the system dialog or prove that the feature degrades gracefully after denial; those are device or emulator tests.