Fix alarm sound session activation failures in background#596
Draft
Fix alarm sound session activation failures in background#596
Conversation
Use .duckOthers instead of empty options when configuring the audio session for alarm playback. The empty options created a non-mixable session that conflicted with the background silent audio player (which uses .mixWithOthers), causing setActive(true) to fail with "Session activation failed" when the app was in the background.
Member
Author
|
Changed it to draft, needs more testing. |
Limit the .duckOthers option to the only state where legacy options: [] fails: background without Silent Tune holding a mixable session alive. In foreground or with Silent Tune, restore options: [] so the alarm continues to dominate other audio with no behavioral change for those users. In that same fail-prone state, plumb the alarm's soundFile through AlarmManager.sendNotification so the system-delivered notification carries the user's configured alarm sound as an audible fallback. In other states the notification keeps .default to avoid an echo with the in-app AVAudioPlayer loop.
bjorkert
added a commit
that referenced
this pull request
Apr 29, 2026
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.
Fixes #590 — Unable to play alarm: Session activation failed.
Background activation of a non-mixable
.playbackaudio session is denied by iOS withcannotInterruptOthers(560557684) unless the app is already actively playing audio. With Silent Tune the silent loop holds a mixable session alive, so activation succeeds. With a Bluetooth-heartbeat refresh (Dexcom / RileyLink / Omnipod Dash) there's no warm session at the moment of alarm, sosetActive(true)fails and the alarm is silent.Changes
AlarmSound.swift— at the fivesetCategorycall sites, chooseoptions:based on app state:backgroundRefreshType == .silentTune→[](legacy aggressive interrupt — no behavioral change for those users).duckOthers(mixable; permits activation)Centralized in a new
sessionCategoryOptions()helper.AlarmManager.sendNotification— accepts an optionalsoundFile: SoundFile?. When provided, the notification usesUNNotificationSound(named: "<soundFile>.caf")instead of.default.Alarm.trigger()— passes the alarm'ssoundFileto the notification only when bothplaySoundis true AND we're in the fail-prone state (background + no Silent Tune). The system-delivered notification then carries the user's configured alarm sound as an audible fallback in case the in-app player can't activate. In foreground / Silent Tune the notification keeps.defaultso it doesn't echo the in-app loop.