Recover the Silent Tune keep-alive after audio interruptions - #745
Open
bjorkert wants to merge 4 commits into
Open
Recover the Silent Tune keep-alive after audio interruptions#745bjorkert wants to merge 4 commits into
bjorkert wants to merge 4 commits into
Conversation
The silent audio session is the only background execution claim Silent Tune has, so when another app interrupts it the process is suspended within seconds and no app code runs again until iOS resumes it. Reactivation now happens inside a UIApplication background task assertion, which grants runtime independently of the audio claim, so the retry attempts actually run instead of being frozen by suspension. Attempts are spread over about 18 seconds, which fits inside both the assertion and a BGAppRefreshTask window, and playAudio confirms the player is really playing rather than assuming play() worked. The BGAppRefreshTask stays open until the restart resolves, so a failed first attempt is retried within the same window. It also queues its successor before doing any work, asks for the earliest possible window when a restart fails, and cancels itself when the user is no longer on Silent Tune. scheduleRefresh leaves a pending request alone when it would run at least as soon, so repeated background transitions no longer push the check further out. Logging follows the same shape: quiet when the keep-alive is healthy, and detailed once it is struggling. A first attempt success stays behind debug logging, while recovery after a failure reports the attempts and elapsed time, repeated failures with an unchanged error code are suppressed so a long ladder cannot bury the log, and session errors are named instead of being printed as raw four character codes. The task scheduler records one line per lost runtime window with its length and which background alerts fired, and the background and foreground transitions record the refresh mode, Low Power Mode and Background App Refresh status.
Device logs show isPlaying still reporting true at the moment an interruption is delivered, so the recovery entered on interruption began was skipped before it took its background task assertion, leaving the app dependent on iOS delivering interruption ended after all. Recovery no longer consults isPlaying to decide whether to run. Reattempting against a player that is genuinely playing is harmless, because the session is activated before the player is replaced, so a failed attempt leaves a working player untouched. Recovery on interruption began now waits a second before its first attempt. A brief interrupter's interruption ended lands inside that window and supersedes the work, so momentary blips stay as quiet as before, and work that does run means the claim is really gone whatever isPlaying says. The immediate background refresh request moved to that point as well, so it is made once per real interruption instead of once per blip, and the assertion expiring now arms it unconditionally since reaching expiration means the claim was never re-established.
Silent audio also stops when the audio route disappears and when media services reset, and neither posts an interruption notification, so nothing noticed. A day of device logs shows three silent deaths with zero interruptions while the phone moved in and out of CarPlay. Route changes and media services resets are now observed and recover through the same ladder. Recovery runs for a route appearing or disappearing; a category change never recovers, because playAudio sets the category itself and an alarm takes over the session that way. Other reasons are logged so a later log can earn them a recovery. A process launched into the background by BGAppRefreshTask never runs the backgrounding transition, so it had no interruption, route or media services observers and no background alerts armed. Observers are now attached whenever audio is restarted, and a background recovery arms the alerts, which also clears any delivered notification the recovery has just made obsolete. The task scheduler is kicked on recovery so the alerts are re-armed from the moment runtime returns. Alerts are only armed while backgrounded, since the task's work lands on the main queue and the app may have been opened in between. The runtime gap is measured against a monotonic clock, so a wall clock correction cannot hide a stall, and a material difference between the two is reported. A scheduler park that outlives the moment between a task firing and its action rescheduling it is now reported with its duration.
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.
Silent Tune's looping silent audio is the app's only background claim. When it stops, iOS suspends the app within seconds and it cannot recover on its own, which is what produces the "App inactive for N minutes" notification.
Reactivation now runs inside a UIApplication background task assertion so the retries get runtime even without the audio claim, keeps trying for about 18 seconds, and no longer trusts player.isPlaying, which keeps reporting true after the session is taken. The BGAppRefreshTask stays open until the restart resolves, and scheduleRefresh no longer pushes a pending request further out.
Three other things stop the audio and none were handled. A route disappearing, such as leaving CarPlay, pauses the player with no interruption notification. A media services reset invalidates the session and player. And a process launched into the background by BGAppRefreshTask never runs the backgrounding transition, so it had no observers attached and no background alerts armed. All three are covered now, and a background recovery clears any delivered notification it has made obsolete.
This does not make Silent Tune reliable, since an interruption that outlasts the assertion still suspends the app. Logging is quiet while healthy and detailed once struggling, including one line per lost runtime window measured against a monotonic clock.