Skip to content

fix: dismiss the overheat notification once the battery cools - #261

Open
almothafar wants to merge 1 commit into
masterfrom
claude/overheat-notification-persistence-qungp5
Open

fix: dismiss the overheat notification once the battery cools#261
almothafar wants to merge 1 commit into
masterfrom
claude/overheat-notification-persistence-qungp5

Conversation

@almothafar

Copy link
Copy Markdown
Owner

Closes #259

The problem

The high-temperature alert had hysteresis on firing but none on clearing:

  • decideTemperature re-arms the persisted _temperature_alert_sent flag once the battery cools
    to threshold − TEMPERATURE_HYSTERESIS_C (3 °C).
  • handleTemperature used that decision only to rewrite the boolean — it ignored the
    true → false transition.
  • TEMPERATURE_NOTIFICATION_ID was never passed to NotificationManager.cancel() anywhere in the
    app, and the shared alertBuilder never sets setAutoCancel(true).

So the warning outlived the hot spell and sat in the shade until the user swiped it, reading as
"still overheating" on a phone that had long since cooled.

The change

Act on the true → false transition handleTemperature already computes and call the new
NotificationService.clearTemperatureAlert — the same "don't leave a stale alert alive" cleanup
FastDrainDetector already does for its own warning. No extra prefs read, no new state.

This covers both re-arm paths in decideTemperature:

  • the battery cooled past the hysteresis point (the reported bug), and
  • the user switched the high-temperature alert off in Settings while one was showing.

Staying inside the hysteresis band still holds the alert, so the notification cannot flap.

Deliberately out of scope: adding setAutoCancel(true) to the shared alertBuilder — that
would change tap-behaviour for every quiet-hours-aware alert, not just temperature.

Tests

Three cases added to BatteryLevelReceiverTest, which already mocks the NotificationService
statics:

  • temperature_cooledBelowHysteresis_dismissesStaleAlert — hot tick then a cool tick, asserts
    clearTemperatureAlert called once.
  • temperature_withinHysteresisBand_keepsAlertShown — negative case at 43 °C, asserts never().
  • temperature_alertDisabledWhileShown_dismissesStaleAlert.

testDebugUnitTest, lintDebug and assembleDebug all pass on this branch.

Manual verification

Not run — no device available in this environment. Worth checking on hardware:

  1. Lower the high-temperature threshold to 40 °C and heat the battery until the alert fires.
  2. Let it cool; past 37 °C the notification should disappear on its own, no swipe.
  3. Fire it again, then toggle "Notify on high temperature" off — it should clear immediately.

Generated by Claude Code

The high-temperature alert had hysteresis on firing but none on clearing.
decideTemperature re-arms the persisted flag once the battery cools past
threshold - 3 C, but handleTemperature used that decision only to rewrite
the boolean; TEMPERATURE_NOTIFICATION_ID was never cancelled anywhere and
the shared alert builder never sets setAutoCancel. The warning therefore
outlived the hot spell and sat in the shade until the user swiped it.

Act on the true -> false transition the method already computes and call
the new NotificationService.clearTemperatureAlert, the same "don't leave a
stale alert alive" cleanup FastDrainDetector does for its own warning. This
also covers switching the alert off in Settings while one is showing, since
decideTemperature re-arms there too. Staying inside the hysteresis band
still holds, so the notification cannot flap.

Closes #259

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P8Rjarp53XHQEaZYX4SwTD
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix: overheat notification stays after the battery cools down

2 participants