fix: request notification permission on enable

[jvsena42]

Closes #566

This PR stops the Android notification permission system dialog from appearing automatically on the home screen, requesting it only when the user taps "Enable" on the background payments prompt.

Description

The home screen previously asked RequestNotificationPermissions to launch the POST_NOTIFICATIONS system dialog on every entry while notifications were ungranted, so a user who dismissed it kept getting re-prompted on each app open. Issue #566 asked to gate how often this appears; this aligns Android with the iOS flow, where the dialog is only triggered from the background payments intro sheet's "Enable" button (NotificationsSheet → requestPermission()).

• The home-screen RequestNotificationPermissions now runs with showPermissionDialog = false, so it only keeps the granted/denied state in sync (including when the user changes it in system settings); it no longer launches the dialog.
• Tapping "Enable" on the background payments prompt requests the OS notification permission in place and dismisses the sheet; "Later" just dismisses it. "Enable" no longer navigates to the Background Payments settings screen, matching iOS.
• The runtime request is guarded behind Android 13+ (TIRAMISU); on older versions, where there is no runtime notification permission, "Enable" simply dismisses.

The background payments prompt itself is unchanged: it still appears only when notifications are not yet granted and the wallet has a Lightning spending balance.

Preview

before.webm

allow-flow.webm

deny-flow.webm

suggestion-intro.webm

android-11-enable-flow.webm

QA Notes

Manual Tests

• 1. LN spending balance + notifications not granted → open app to Home: no system permission dialog appears automatically.
• 2. Background payments prompt → tap Enable: OS permission dialog appears and the sheet dismisses with no navigation.
• 3. OS dialog → tap Allow: notifications enabled and the node keeps running in the background.
• 4. regression: Background payments prompt → tap Later: sheet dismisses, no OS dialog.
• 5. regression: Android 12 or below → tap Enable: navigate to payment settings (no runtime permission).

OBS: On Android 12 or bellow, the notifications are enabled by default

Automated Checks

• N/A — UI wiring change in ContentView only; no business logic added. just compile and just lint pass.
• CI: standard compile, unit test, and detekt checks run by the PR bot.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e1d1ae8cce

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[greptile-apps]

Greptile Summary

This PR fixes the Android notification permission prompt appearing automatically on every app open, aligning with the iOS behavior where the OS dialog is only shown when the user explicitly taps "Enable" on the background payments intro sheet.

• RequestNotificationPermissions on the home screen is changed to showPermissionDialog = false, keeping the granted/denied state in sync via lifecycle observation without launching the OS dialog automatically.
• The onEnable callback for TimedSheetType.NOTIFICATIONS now directly launches POST_NOTIFICATIONS via a rememberLauncherForActivityResult registered at the ContentView level (Android 13+), while pre-13 devices fall back to navigating to the Background Payments settings screen as before.

Confidence Score: 5/5

The change is a clean, focused UX fix with no business logic changes — it only rewires where the OS permission dialog is triggered.

Both changed paths behave correctly. The launcher is registered at the right Compose scope, the Android 13+ guard is in place, and the pre-13 fallback matches documented QA test cases. The RequestNotificationPermissions lifecycle observer continues to keep granted state in sync when users change settings externally.

No files require special attention.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/ui/ContentView.kt	Registers a new notification permission launcher at ContentView scope, moves OS dialog trigger from home-screen auto-prompt to the explicit Enable button, and sets showPermissionDialog=false on RequestNotificationPermissions. Logic is correct and handles pre-API 33 fallback.
changelog.d/next/1004.fixed.md	Changelog entry accurately describes the UX change.

Sequence Diagram

sequenceDiagram
    participant User
    participant HomeScreen
    participant RequestNotificationPermissions
    participant BackgroundPaymentsIntroSheet
    participant ContentView
    participant OS as Android OS

    Note over HomeScreen,RequestNotificationPermissions: Before PR - dialog auto-prompted
    HomeScreen->>RequestNotificationPermissions: "showPermissionDialog=true (old)"
    RequestNotificationPermissions->>OS: launch POST_NOTIFICATIONS dialog
    OS-->>User: Permission dialog shown on every open

    Note over HomeScreen,OS: After PR - dialog only on explicit Enable
    HomeScreen->>RequestNotificationPermissions: "showPermissionDialog=false"
    RequestNotificationPermissions->>RequestNotificationPermissions: Sync granted/denied state only (ON_RESUME)

    User->>BackgroundPaymentsIntroSheet: Tap Enable
    BackgroundPaymentsIntroSheet->>ContentView: onEnable()
    ContentView->>ContentView: dismissTimedSheet() + setBgPaymentsIntroSeen(true)
    alt Android 13+
        ContentView->>OS: notificationPermissionLauncher.launch(POST_NOTIFICATIONS)
        OS-->>User: Permission dialog shown once
        OS-->>ContentView: granted: Boolean
        ContentView->>ContentView: settingsViewModel.setNotificationPreference(granted)
    else Android less than 13
        ContentView->>HomeScreen: navController.navigateTo(BackgroundPaymentsSettings)
    end

Loading

_{Reviews (1): Last reviewed commit: "fix: navigate to payment settings on and..." | Re-trigger Greptile}

[jvsena42]

I prioritized matching the iOS flow, because the current behavior is really annoying for a user that don't want to enable notifications.

Some UX improvements could be addressed in follow-up PRs:

• Request permission once even without LN balance because of CJIT and channel opening, or at least in these specific flows
• Make the FG service optional, since it became less vital after ldk-node caching improvements
  • Could be an option in background payments settings. Would need some design work

[ovitrif]

this aligns Android with the iOS flow, where the dialog is only triggered from the background payments intro sheet's "Enable" button

Should've been this way from native v1 🤝 , it's part of how Google suggests to implement these in their Android guidelines

[ovitrif]

tAck

I would expect this to work in same way also in:

• Transfer to Spending > Toggle BG Payments ON
• CJIT Flow > same Toggle ON

Any specific reasons why it doesn't? Even If iOS doesn't do the same, I kinda still think Android should.

Rec - Transfer to Spending

transfer.mp4

[ovitrif]

nit: this belongs to a reusable top level fn, not inline in a handler, especially because other entrypoints should be handled the same way…