fix: dismiss the full-battery alert when the charger comes out - #266
Open
almothafar wants to merge 1 commit into
Open
fix: dismiss the full-battery alert when the charger comes out#266almothafar wants to merge 1 commit into
almothafar wants to merge 1 commit into
Conversation
The "Battery fully charged" alert kept coming back after unplugging. The level-alert decision treated BATTERY_STATUS_FULL as the whole trigger, but plenty of devices keep reporting that status while sitting at 100% with the cable already out. So on unplug PowerConnectionReceiver cleared the alert and re-armed the episode, and the very next ACTION_BATTERY_CHANGED — still reporting FULL — posted it straight back. With the sticky-notification preference on it could not even be swiped away. The alert is now bounded by the charger rather than by the status: it only fires while plugged in, and a shown one is dismissed as soon as the plugged state says the charger is out. That dismissal is state-driven rather than tied to the unplug broadcast alone, so a transition missed while the process was dead (doze, OEM task killers) still resolves on the next broadcast instead of stranding the notification until the following charge. Dismissal happens before dispatch in the receiver: level alerts share one notification ID, so an alert decided on the same broadcast (a critical one on a battery that unplugged full and then drained) must replace the stale notification, not be cancelled after it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016VvXe4CxGMYwGSC3UgUDru
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
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.
The "Battery fully charged" notification stayed on screen after unplugging.
The bug
decideChargingOrFulltreatedBATTERY_STATUS_FULLas the whole trigger, never asking whether a charger was actually connected. Plenty of devices keep reporting that status while sitting at 100% with the cable already out, so on unplug:PowerConnectionReceiver.handleChargerDisconnectedcancels the notification and clearsfullNotifiedto re-arm the next charge session.ACTION_BATTERY_CHANGED— still reportingFULL, now against a freshly cleared flag — posts the alert straight back.The alert is cleared and immediately re-posted, which reads as a notification that refuses to go away. With the sticky-notification preference on it carries
FLAG_NO_CLEAR, so it can't be swiped either.A second path reached the same symptom: when the process is killed mid-charge (doze, OEM task killers) nobody sees the unplug broadcast, so nothing ever clears the alert.
The fix
The full alert is now bounded by the charger, not by the status.
BatteryLevelReceiverreadsEXTRA_PLUGGEDand passes it into the decision core; the alert fires only onfull && plugged, so off the charger it cannot re-post itself.PowerConnectionReceiveralready does on the transition it does see.onReceive: level alerts share one notification ID, so an alert decided on the same broadcast (a critical one, on a battery unplugged at full that then drained) must replace the stale notification rather than be cancelled after it.Unchanged: the once-per-charge behaviour, the
(warning, FULL_PERCENTAGE]re-arm band, and re-firing when a charger is connected at an already-full battery — each pinned by a test.Tests
Five new cases in
BatteryLevelReceiverDecisionTestcovering the regression itself (unplugged while still reportingFULL), the dismissal of a stale alert on both the charging-or-full and the discharge branch, the critical-alert-survives-the-dismissal ordering, and the re-plug case.testDebugUnitTestandlintDebugboth pass.Also drops an unused constant (
FRESH) in the test file.Generated by Claude Code