Snooze glucose alerts from anywhere: over other apps, on the lock screen, and with volume buttons

[petervanrijt]

What this PR does

What this PR does

Snoozing a glucose alert no longer requires opening xDrip first:

• Snooze screen over the app in use — when an alert fires while you are using another app, the snooze screen floats on top of it; after snoozing you are returned to that app automatically. Opt-in via Settings → Alarms and Alerts → Glucose alerts settings, requires the Android permission Display over other apps (xDrip asks for it at startup).
• Snooze screen on the lock screen — with Override silent mode (per alert) or Wake Screen enabled, an alert wakes the display and shows the snooze screen above the lock screen, without unlocking. Closing it returns to the lock screen.
• Volume-button snooze, also from the lock screen — press the same volume button twice within 1.5 seconds to snooze. While an alert is sounding, the volume buttons no longer change the phone volume. A held button does not count as a double press.
• Snoozed-alert status — the ongoing notification (and optionally the Extra Status Line) shows "Alert <name> snoozed until HH:mm" while an alert is snoozed, and hides it when glucose recovers.
• Test alert with a 5-second delay — time to switch apps or turn the screen off, so the new screens can be tested from Edit Alert → Test alert.
• Robustness fixes — crash when disabling alerts while the alert type is missing; REMOVE ALERT leaving an orphaned active alert (and its sound) behind; test alerts not being snoozable; full-screen intents silently ignored due to notification channel importance (fixed with a migration that only runs for users who need it).

The alert sound itself is never reduced or suppressed by any of this: every failure direction is "more conspicuous" or "convenience unavailable", never "quieter or missed".

What existing users need to change

After updating, xDrip asks once per start to grant Display over other apps; without it everything keeps working except the pop-up over other apps. Note two behaviour changes: snoozing with a volume button now takes a double press (was a single press), and alerts with Override silent mode now wake up into the snooze screen instead of the main screen. Users of xDrip notification channels who use Wake Screen or override-silent alerts get a fresh high-importance alert channel; re-apply any custom channel settings there if desired.

Documentation (included in this PR)

Design, decisions, safety review and per-change test plans:

• CHG1-snooze-over-other-apps.md
• CHG2-fullscreen-snooze-on-lockscreen.md
• CHG3-volume-key-snooze.md
• CHG4-volume-key-double-press.md
• CHG5-statusline-snoozed-alert.md
• CHG6-review-chg1-chg5.md
• CHG7-pr4510-adoptions.md
• CHG8-notification-snooze-line.md
• CHG9-delayed-test-alert.md
• CHG11-buttons-silence-alarms-dependencies.md
• CHG12-consistent-snooze-text-and-prompt-refresh.md
• CHG13-final-review.md
• CHG14-adopt-upstream-notificationchannels.md
• CHG15-remove-string-resources.md
• file_overview.md

Notes for reviewers

• Supersedes draft Snooze glucose alerts with volume buttons, also from lock screen #4510: scope cleaned up per the feedback there (no extra wake switch — the existing Wake Screen setting is reused; single shared key handler; documented test plans per change).
• The robustness fixes (CHG7/A1) are preconditions for the new snooze paths (consistent ActiveBgAlert state, snoozable test alerts), not standalone refactoring.
• No new string resources: per review feedback the new user-facing texts are plain English literals for now; a dedicated follow-up PR will move them into translatable resources once the wording is agreed. Existing translated strings are untouched.
• Phone app only; the Wear module is untouched.

Full disclosure

This pull request is accelerated using Claude Code (model Opus 5 with effort setting on high or maximum).

[Navid200]

Thanks

It will take a while to make the strings perfect. I suggest removing all the strings from this PR.

[petervanrijt]

Ok. Will do tonight or tomorrow. Just synced with xDrip-master. I will review it before sending it to dev team for the final review. When curious you can already build it yourself :) Op ma 13 jul 2026, 20:10 schreef Navid ***@***.***>:

…

*Navid200* left a comment (NightscoutFoundation/xDrip#4623) <#4623 (comment)> Thanks It will take a while to make the strings perfect. I suggest removing all the strings from this PR. — Reply to this email directly, view it on GitHub <#4623?email_source=notifications&email_token=ADH3DDEUJDEEV7WHZZ6IGX35EUQZZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJWGEYTCNJTGE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4961115319>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADH3DDGTUXTEOCEVJFGYM235EUQZZAVCNFSNUABEKJSXA33TNF2G64TZHM3DSMBSG43DKMJ3JFZXG5LFHM2DQNRZGE3TKMBYGKQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ADH3DDHXJN53IALGEN4W7DL5EUQZZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJWGEYTCNJTGE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/ADH3DDH76PWYNAXUMV2XZZL5EUQZZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJWGEYTCNJTGE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[Navid200]

If you prefer to keep the strings, we can work on them. It is just that it will only delay the PR in going through.
The reason I suggest keeping them as text in English is that then they will not be show stoppers as long as they get the point across.
We will then be able to open another PR later and spend as much time on it to agree on the strings without delaying the functionality. That's the only reason I have suggested that. I will work with you to get this done any way you prefer.
My suggestion is to expedite this PR by making it contain as little as possible that requires a review. Strings are very critical and can take a long time to review and come to agreement on.

[jamorham]

I don't really like the look of what looks like changes to the alerting logic. To snooze an alert you should just be able to call AlertPlayer.getPlayer().OpportunisticSnooze(); which is what is done for incoming alert snoozing from other sources. As far as I know this function works very well and doesn't need any changes to the alert code.

From what I understand this PR should be UI changes only to support the lock screen snoozing.

[Navid200]

I would like us to work on this and make it do what it needs without doing anything else.
Your original PR changed 9 files. This one changes 31.
We should be able to accomplish our common intent with a simpler PR.

I could be wrong about all your intentions. My hope is for the user to be able to snooze an alert without having to look at the screen.

The existing mechanism in xDrip requires xDrip to be in foreground. This is why the existing mechanism is not adequate. I always think of someone who gets an alert in an inconvenient situation for example while driving. The intent is to be able to silence the alert without having to take your eyes off the road.

I understood from your original PR that you had found a way to force Android to bring up an xDrip page on screen when you pressed the volume button. Now that xDrip is in foreground, pressing the button a second time should snooze it because we already have the mechanism.
Am I misunderstanding your intent or your findings?
If not, we should be able to accomplish this still with changing only 9 or even less files.

I am more than happy to work on this to assist you if you are OK with that.

[jamorham]

The documentation looks like it probably should be attached to the PR rather than added to the source tree as it seems to relate to the changes only.

[petervanrijt]

Thank you!

Processed

• ✅ merged NightscoutFoundation:master into alarm-snooze-v2 — local merge 13 July 2026 13:44, pushed 14 July 2026.
• ✅ Comment 4961115319 @Navid200: "It will take a while to make the strings perfect. I suggest removing all the strings from this PR."
• ✅ Comment 5014902562 @jamorham: "The documentation looks like it probably should be attached to the PR rather than added to the source tree as it seems to relate to the changes only."

Help

In response of comment 5008280148 @Navid200: Ofcourse your help is more than welcome, please do. With a (third) newborn my time is somewhat limited 😅.

To answer the other questions

Snoozing itself uses the existing path: the snooze screen and the volume keys both end up in AlertPlayer.Snooze() — the same call OpportunisticSnooze() wraps. I deliberately didn't call OpportunisticSnooze() itself, because its internal 3-second rate limit would swallow the second press of the double-press confirmation, and it shows its own toast.

Why UI alone doesn't get there: volume keys need a foreground activity to receive key events, and the lock-screen UI needs the notification's full-screen intent — which Android silently drops on upgraded installs whose alert channel importance is below HIGH. That is the only reason for the small channel migration; it enables the screen, nothing else. A MediaSession-based approach could intercept volume keys without any UI, but it competes with other media apps for the keys and behaviour varies per OEM — for a glucose alarm I preferred the predictable failure mode (if no screen shows, the alarm simply keeps sounding).

Beyond the UI there are, deliberately, a few small non-UI changes:

1. After a snooze from any source (snooze screen, notification, watch, broadcast), the pop-up snooze screens close and the ongoing notification refreshes right away — small hooks in Snooze()/stopAlert(). Reason: a snooze screen must never stay up, and the notification must never show a sounding alert, for an alert that has already been handled elsewhere; the UI has to reflect the true alert state at all times.
2. GuessDefaultSnoozeTime() falls back to the per-type default when an alert has no snooze time set. Reason: the volume-key and lock-screen paths snooze without showing a picker, so the default they apply must always be a sane value.
3. The orphaned-alert fixes — ActiveBgAlert.alertTypegetOnly() no longer deletes the active alert record as a side effect when the alert type is missing, and REMOVE ALERT now clears its active alert. Reason: the double-press path relies on ActiveBgAlert.getOnly() returning consistent state; without these fixes a double press can show success while the alert state is inconsistent — apparent success without effect, the worst failure mode for a glucose alarm — and test alerts, exactly how users will try the new snooze paths, cannot be snoozed at all.

Over the coming week I'll retest everything against the documentation. If all tests pass, I'll mark this PR as Ready for review.