Fix alarm sound session activation failures in background

[bjorkert]

Fixes #590 — Unable to play alarm: Session activation failed.

In background without Silent Tune holding the audio session alive, iOS denies AVAudioSession.setActive(true) with the legacy non-mixable options: [] (cannotInterruptOthers, 560557684). The alarm goes silent.

Result

AlarmSound now picks its session options from a fallback ladder and logs each attempt:

1. [] — non-mixable, dominates other audio (preferred)
2. .duckOthers — mixable, ducks other audio
3. .mixWithOthers — mixable, no ducking (last resort)

When the app is in background without Silent Tune, step 1 is skipped (iOS will always deny it there) and the ladder starts at .duckOthers.

Each session activation logs its outcome with the iOS error code, so future regressions or unexpected denials are diagnosable from a user's log.

[bjorkert]

Changed it to draft, needs more testing.

[marionbarker]

Test

✅ successful test

Demonstrate the problem

Build using dev: 6.0.9, c9f74f4

• configured LoopFollow phone with a RileyLink for background refresh
• enable high and low alerts configured so I should get an alert and lock the phone
• wait after CGM update - no alert sound
• unlock phone, check alert status - see an alert but did not hear one
• wait while app is open - alarm sounds

Demonstrate this PR fixes the problem

Build using fix/alarm-audio-session-activation, 54c2a5d

• enable high and low alerts configured so I should get an alert and lock the phone
• wait after CGM update - ✅ alert sounds even though phone is locked.

[marionbarker]

approve by test

[dnzxy]

The .duckOthers gating is a reasonable fix for cannotInterruptOthers, but I don’t think the notification path is safe as written. Since the notification with custom sound is scheduled before in-app playback is attempted, it can double-play when .duckOthers succeeds.

I'd suggest to please either make the notification sound truly conditional on playback failure, or intentionally make the background/no-Silent-Tune path notification-only.

We could also consider using applicationState == .background instead of != .active, and centralize the duplicated policy logic.

[dnzxy]

Isn't something like potentially safer to avoid unintended duplicate plays?

let playbackStarted = AlarmSound.play(...)

if !playbackStarted && inBackgroundWithoutSilentTune {
    AlarmManager.shared.sendNotification(
        title: type.rawValue,
        actionTitle: ...,
        soundFile: soundFile
    )
} else {
    AlarmManager.shared.sendNotification(
        title: type.rawValue,
        actionTitle: ...,
        soundFile: nil
    )
}

[bjorkert]

Thanks for testing and feedback. Code and PR description updated. Tested successfully with RileyLink and SilentTune.