Conversation
Play reviews for this app are slow, so meeting Google's target-API deadline rather than staying ahead of it risks a mandatory bump colliding with a long review. Bump compileSdk/targetSdk to 37 now that Android 17 is stable, and write the "adopt the newest stable API level as soon as it ships" rule down as a maintenance policy in AGENTS.md, summarised in CLAUDE.md, with a check step added to the /release command so it actually gets looked at every release. The app declares no orientation lock, no local-network access and no audio playback, so none of the API 37 behaviour changes apply to it; assembleDebug, testDebugUnitTest and lintDebug all pass against the new level. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alerts only ever appeared while AutoSugar was the visible car app, which is exactly when they are useless — the driver can already see the reading. Polling ran on AutoSugarSession's lifecycleScope, and a Session's lifecycle tracks car-screen visibility: the host stops it the moment Maps or any other car app takes the screen and destroys it thereafter, taking the alert loop with it. Move polling into GlucoseMonitorService, a started dataSync foreground service whose lifetime is the car connection rather than the car screen. It observes CarConnection and stops itself once the head unit is gone; the session only starts it, idempotently, and falls back to the old in-session loop if the platform refuses the foreground-service start. Android 15+ caps dataSync at six hours per 24h, so onTimeout posts a "monitoring stopped" alert to the car screen before stopping rather than going quiet unannounced. dataSync is the only type whose Android 14 prerequisites the app meets without declaring a permission it has no use for; ADR 003 records that trade-off along with the lifecycle change, and TESTING.md gets the DHU steps that actually exercise the backgrounded case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alerting is opt-in per profile, so the notification permission is requested at the point a profile's alerts toggle is switched on. Only the edit screen did that: the same toggle on each card in the source list called setAlertsEnabled straight through, so a profile enabled from the list was left marked "alerts on" with the permission never requested and nothing anywhere saying alerts could not arrive. Route both toggles through the same request. Permission state also drifts after the fact. Denying twice makes the permission unpromptable — launch() returns "denied" without showing a dialog, so the toggle just flicked back off for no visible reason — and Android revokes permissions on its own for an app not opened in months, which is a plausible fate for one used only while driving. The alert channel can be blocked by hand independently of the app-level switch, too. Any of these silently swallowed every alert. Add GlucoseAlertManager.alertsDeliverable() as the one place that answers "would an alert posted now actually reach the driver", check it on every resume, and show a banner in settings — with a route into the system notification settings, the only way back once a permission is unpromptable — whenever a profile has alerts enabled but nothing could be delivered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The switch on each card toggled that source's glucose alerts, which put two different meanings of "on" in the same list: a source could be configured and visible in the car while its switch read off. Alerts belong to the source's own screen, next to the thresholds they act on, and that is where the notification permission is requested. The list switch now enables or disables the source. A disabled source keeps its configuration on the phone but is invisible to the car and never polled: every car screen and the alert monitor read a new enabledProfilesFlow instead of profilesFlow, so the filter cannot be forgotten at one call site, and disabling the selected source clears activeProfileId rather than stranding the next session on a source missing from its own list. Settings keeps reading the full list, or a source switched off could never be switched back on. Alert state stays visible through a bell on cards whose alerts are on, and disabled cards are dimmed. NightscoutProfile.enabled defaults to true, in the model and in the JSON DTO, so sources written before this field existed stay visible after the update instead of silently vanishing from the car. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.