Skip to content

fix: allow dismissing an alarm that was deleted while ringing#470

Closed
MiMoHo wants to merge 1 commit into
FossifyOrg:mainfrom
MiMoHo:fix/issue-406
Closed

fix: allow dismissing an alarm that was deleted while ringing#470
MiMoHo wants to merge 1 commit into
FossifyOrg:mainfrom
MiMoHo:fix/issue-406

Conversation

@MiMoHo

@MiMoHo MiMoHo commented Jul 3, 2026

Copy link
Copy Markdown

Type of change(s)

  • Bug fix

What changed and why

AlarmService.onStartCommand looked up the alarm in the database up front and, whenever the record was missing, bailed out via stopSelfIfIdle() and returned START_NOT_STICKY. When an alarm is deleted while it is ringing (AlarmsAdapter.deleteItems() calls dbHelper.deleteAlarms(...) and posts AlarmEvent.Refresh but never stops the service), that lookup returns null. Every dismiss / snooze / silence path funnels through AlarmController -> ACTION_STOP_ALARM -> onStartCommand, so the null guard swallowed the stop request: stopActiveAlarm(alarmId) was never reached and stopSelfIfIdle() did nothing because activeAlarm was still set. The result was an alarm that keeps sounding with no way to dismiss or snooze it.

Only the START path actually needs the alarm object; the STOP path merely compares the id against the currently active alarm. This moves the DB lookup and its null guard into the ACTION_START_ALARM branch, leaving ACTION_STOP_ALARM able to stop a ringing alarm by id even after its DB row is gone. Behavior for the start path is unchanged.

Tests performed

  • detekt, lint, unit tests and the build all pass locally (CI-equivalent).
  • Source-verified: AlarmService now null-guards getAlarmWithId(alarmId) inside the ACTION_START_ALARM branch so a still-ringing alarm that was deleted from the DB can be dismissed instead of leaving the service stuck. This is a defensive null check with a clear, contained effect.
  • Note: staging a ringing alarm that is then deleted mid-ring is impractical on a stock emulator, so verification is via CI + code review.

Closes the following issue(s)

Checklist

  • I read the contribution guidelines.
  • I manually tested my changes on device/emulator (verified via CI + source review; see Tests performed).
  • I updated the "Unreleased" section in CHANGELOG.md (if applicable).
  • I have self-reviewed my pull request (no typos, formatting errors, etc.).
  • I understand every change in this pull request.

Coded with Opus 4.8 ultracode.

AlarmService.onStartCommand looked up the alarm in the DB up front and bailed out via stopSelfIfIdle() whenever it was missing. When an alarm is deleted while ringing, that lookup returns null, so ACTION_STOP_ALARM never reached stopActiveAlarm() and the alarm kept sounding with no way to dismiss or snooze it.

Only the START path needs the alarm object; the STOP path only compares the id against the active alarm. Move the DB lookup (and null guard) into the ACTION_START_ALARM branch so a deleted alarm can still be stopped by id.

Fixes FossifyOrg#406.
@MiMoHo
MiMoHo requested a review from naveensingh as a code owner July 3, 2026 21:44
@MiMoHo MiMoHo closed this Jul 3, 2026
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.

Not possible to stop an alarm that was deleted

1 participant