[BUG] Permission request is swallowed on app restart on Android

[rlnt]

Bug Description

After implementing a camera permission request via Grant, I noticed that the first request is swallowed when invoked.

Expected Behavior

I would expect that the rationale dialog shows up when requesting permission.

Actual Behavior

Nothing happens.

Steps to Reproduce

Here is a minimal reproduction project. I am personally using Compose Multiplatform, but it's reproducible in Android-only.
grant-permission-repro.zip

1. Import the minimal project.
2. Start the app.
3. When started, deny the camera permission.
4. Click the button again to see the rationale.
5. Cancel the rationale.
6. Restart the app.
7. When the app starts, press the button to request permission.
8. See, nothing happens.
9. Press again to see the rationale dialog.

Video

Sorry for the washed colors, I forgot to disable HDR. But I am sure you get the idea. This is the restart of the app. The first button click does nothing, but the state is updated. Only the second click brings up the dialog.
https://github.com/user-attachments/assets/93f92360-2fb7-45f4-adb7-1bc85d3f1450

Environment

Grant Version:
2.2.1

Platform:

• Android
• iOS

Platform Details:

• Android API Level: 37
• iOS Version: /
• Device/Emulator: Android Emulator

Dependencies:

• Kotlin: 2.4.0
• Compose: 2.4.0
• Koin (if applicable): 4.2.2

Workaround

I thought about checking the new state after the first request and checking that to immediately start a second request, but this is rather ugly.

Checklist

• I have searched existing issues
• I am using the latest version of Grant
• I have enabled GrantLogger and included logs
• I have provided a minimal code sample
• I have tested on a real device (if applicable)

[rlnt]

I may have misunderstood the guidelines and the general flow of requesting permissions. If you could enlighten me on how to request the camera permission properly, that would be great.

My use case is that I have a screen that should be used for scanning QR codes. That obviously requires camera permissions. When installing the app for the first time, the screen only shows a simple label saying something like "QR scanner requires camera permission" and a button underneath to request the permission. I think that's the correct way of doing it because if the system prompt were to show up directly, the user wouldn't see any text explaining why the permission is required, right?

If the user denies the permission, the rationale will be shown, and if the user denies again, the settings dialog will show up. But what if the app restarts and the permission is not granted? In that case, you would disable the feature and give the user the option to request it again (that's what I tried in my sample project). It should then open the settings dialog, if I am not mistaken.

Please correct me if I am wrong.

[vietnguyentuan2019]

Thanks for the detailed repro and video, @rlnt — this is a real bug and I tracked down the root cause.

Root cause

checkStatus() in PlatformGrantDelegate.android.kt (Android actual impl) determines whether a permission is NOT_DETERMINED vs DENIED by checking an in-memory flag (store.isRequestedBefore(grant)) before checking shouldShowRequestPermissionRationale():

val storedStatus = store.getStatus(appGrant)
if (storedStatus == GrantStatus.DENIED || storedStatus == GrantStatus.DENIED_ALWAYS) {
    storedStatus
} else if (store.isRequestedBefore(appGrant)) {   // <-- in-memory only, lost on process death
    val anyCanShowRationale = androidGrants.any { activity.shouldShowRequestPermissionRationale(it) }
    if (anyCanShowRationale) GrantStatus.DENIED else GrantStatus.DENIED_ALWAYS
} else GrantStatus.NOT_DETERMINED

The default GrantStore (InMemoryGrantStore) really is in-memory only — it doesn't survive a process restart. So after killing and reopening the app:

1. store.isRequestedBefore() comes back false (fresh process), so checkStatus() incorrectly reports NOT_DETERMINED, even though Android itself still remembers the earlier denial.
2. GrantHandler sees NOT_DETERMINED and fires the real system dialog again. Android auto-resolves it to DENIED almost instantly (since it was already denied once) — that's the "flash" you're seeing, not a fresh dialog the user can meaningfully interact with.
3. Because this is treated as the first-ever denial (isFirstRequest=true) and the handler's own hasShownRationaleDialog flag was also reset on restart, it takes the "first denial" branch, which just fires onDenied() and exits — no rationale shown. That's the "click does nothing" symptom.
4. By now store.isRequestedBefore() has been set (from step 2's request call), so the second click correctly resolves to DENIED and takes the right branch, showing the rationale.

So the bug is an ordering issue: shouldShowRequestPermissionRationale() is a signal the OS persists across restarts, but the code only consults it after an in-memory-only flag that doesn't. The fix is to check the OS rationale flag first, and only fall back to the in-memory store to disambiguate NOT_DETERMINED vs DENIED_ALWAYS (the two cases where the OS flag is false). The same ordering bug exists in the RawPermission and LOCATION_ALWAYS branches of the same function.

I'll put up a fix for this shortly.

Re: your usage question

Your flow is correct — show an explainer + button before the first system prompt (so the user has context the OS dialog itself can't provide), then let GrantHandler's state machine drive rationale → settings-guide on subsequent denials. The only thing breaking that flow is this bug: on a cold start with a prior soft-denial, the first tap should immediately show the rationale (no need to re-trigger the system dialog at all) — that's what the fix above restores.

[rlnt]

Thanks for the detailed explanation. I really appreciate that.

Even with that fix applied, one question remains. How do you skip the permission check if it has been granted in the past? Let's say you start the app and grant permission for the camera. The next time you open the screen, you would not want to press the button to request permission again. Instead, it should directly open the scanner because permission is already granted. How would you do that? Wouldn't I need to still observe the state myself?

I could work around that by requesting permission in the init {} of the view model, but that would prevent the reasoning from showing up when opening the app for the first time, where you have to press the button to request permission.
I feel like the examples in the repo are missing that point, if I am not mistaken.

[vietnguyentuan2019]

Great question — and you're right that the repo examples don't show this pattern clearly. You do not need to call request() in init {}. GrantHandler already exposes the current status as a read-only flow, so you observe that and only show the button when it isn't granted yet.

handler.status is the flow you want

GrantHandler populates a status: StateFlow<GrantStatus> in its init {} by calling checkStatus() — which is a pure read of the OS state, with no system dialog. So just observing it is side-effect free: it tells you GRANTED / DENIED / DENIED_ALWAYS / NOT_DETERMINED without ever prompting the user.

class QrViewModel(grantManager: GrantManager) : ViewModel() {
    val cameraHandler = GrantHandler(
        grantManager = grantManager,
        grant = AppGrant.CAMERA,
        scope = viewModelScope,
    )

    // Already populated by checkStatus() in init{} — no prompt is shown.
    val cameraStatus: StateFlow<GrantStatus> = cameraHandler.status
}

@Composable
fun QrRoute(vm: QrViewModel) {
    val status by vm.cameraStatus.collectAsState()

    when (status) {
        GrantStatus.GRANTED,
        GrantStatus.PARTIAL_GRANTED -> QrScanner()          // already granted → straight to the scanner, no button

        else -> PermissionPrompt(                            // NOT_DETERMINED / DENIED / DENIED_ALWAYS → explainer + button
            onRequestClick = {
                vm.cameraHandler.request(
                    rationaleMessage = "QR scanning needs the camera.",
                ) { /* onGranted — flow auto-advances the UI via status */ }
            },
        )
    }

    // GrantDialog still drives rationale → settings-guide on denials
    GrantDialog(vm.cameraHandler)
}

This gives you exactly the flow you described:

• First launch (NOT_DETERMINED) → status isn't granted → your explainer + button shows. Tapping it runs the full rationale → settings state machine. The system prompt only appears after the user has seen your explanation.
• Already granted from a previous session → init{}'s checkStatus() returns GRANTED → the when goes straight to QrScanner(). The button never appears, and no prompt is fired.

Returning from Settings

When the user leaves to the system Settings and comes back, call handler.refreshStatus() (e.g. on ON_RESUME) so the flow re-reads the OS state and your when flips to QrScanner() if they enabled it there.

On the bug + docs

The ordering fix from my previous comment is implemented and pushed on fix/issue-55-rationale-after-restart (it also adds a persistent request-history store on Android so a permanently denied permission still routes to Settings on the first tap after a cold restart, not just soft denials). It'll go out in the next release.

And you're right that the demo/docs don't make the "observe status, don't call request() in init{}" pattern obvious — I'll add it. Thanks for pointing it out.

[rlnt]

Thank you, that makes sense. I already implemented this that way.

What confused me a bit was the cameraHandler.request {} has the onGranted lambda callback argument. If you have to observe the GrantStatus flow to control the UI, the lambda is rather pointless, isn't it? And because I thought it must have its use, I was questioning if observing the GrantStatus flow is the right decision.

I guess the onGranted callback has its use cases that I don't know right now. But the rest is solved for me. Thanks for the fix, I appreciate the responsiveness.

[vietnguyentuan2019]

Good instinct, and you are right. For the QR case, observing status is the correct way and onGranted is indeed redundant there, because rendering the scanner is a declarative UI state (so it is recomposition-safe).

The two things are different by design though:

• status is level-triggered: it always holds the current state and re-emit on every collection. Good for "should I show the scanner or the button?".
• onGranted is edge-triggered: it fire exactly once at the moment the permission become granted, then it is cleared to avoid memory leak. It also fires on the return-from-Settings path, not only on the in-dialog grant.

So onGranted has its use for one-shot imperative side effect that you want to run once when the user grant the permission — for example navigate to the next screen, start a single download, capture one frame, or send the location one time. If you drive those off the status flow instead, they would re-trigger on every recomposition, which is not what you want.

But for a persistent screen where the content depend on the status (your scanner), the flow is the right choice. So your decision was correct.

I will make this distinction more clear in the docs too. Thanks again for the nice discussion!

[vietnguyentuan2019]

@rlnt,

I also added this status vs onGranted explanation into the docs (in the "Skip the prompt when a permission is already granted" recipe), so it is easier to learn for the next person.

If everything is ok on your side now, please feel free to close this issue. Thanks again for the great feedback! 🙏

[rlnt]

It works, but it's not perfect yet.

If you deny the permission 2 times, it should be permanently blocked, and the settings dialog should show up. However, the rationale still displays. After an app restart, only the settings dialog is shown as intended. It seems like the permanent denial is not properly tracked in the initial flow.

To make this clear. What should happen:

1. User visits the feature screen for the first time
2. Screen shows reasoning and a button to request permission
3. User presses the button
4. System prompt for permission
5. User denies
6. User clicks the request button again
7. Rationale is shown and user requests permission
8. User denies
9. User clicks the request button again (at this point permission is permanently denied)
10. Settings dialog is shown

What happens instead:

1. User visits the feature screen for the first time
2. Screen shows reasoning and a button to request permission
3. User presses the button
4. System prompt for permission
5. User denies
6. User clicks the request button again
7. Rationale is shown and user requests permission
8. User denies
9. User clicks the request button again (at this point permission is permanently denied)
10. Rationale is shown
11. After requesting permission from there, the settings dialog is shown

After an app restart, the expected flow is established.