Suppress silent LA notifications and prevent stale foreground-restart#638
Open
Suppress silent LA notifications and prevent stale foreground-restart#638
Conversation
Three independent fixes for Live Activity behaviour exposed by a 6.1.0 report of audible notifications + a gratuitous restart: 1. AppDelegate's UNUserNotificationCenterDelegate willPresent handler returned [.banner, .sound, .badge] for every notification. The Live Activity push-to-start payload is intentionally silent (interruption- level: passive, empty title/body), so anything iOS routes through willPresent while the app is foregrounded would still produce sound. Now bails out for passive notifications and for ones with empty title/body. Intentional alerts (renewal-failed, APNs missing, push- to-start token missing, alarms) all carry non-empty title/body and default .active interruption level, so they continue to surface. 2. pendingForegroundRestart could survive a background renewal: a brief foreground entry while the renewal overlay was up latched the intent, the user backgrounded before didBecomeActive ran, the background renewal then replaced the LA, and the next foreground entry minutes later fired the deferred restart against a freshly-renewed LA. adoptPushToStartActivity now clears the latch on every adoption, and performForegroundRestart re-checks the conditions that triggered the latch and bails if they no longer hold. 3. The deferred-foreground-restart path went through startIfNeeded and was logged as reason="user-start", which made the gratuitous restart look like a user action. Threaded a single-shot reason override so the deferred path tags its push-to-start as reason="deferred-foreground-restart". Also expanded the willPresent log line with interruption level and title/body presence so future reports can confirm whether iOS is routing LA push-to-start payloads through willPresent.
Contributor
|
If you're making fixes to the LA, you may want to take a look at these two quick hits as well, in PR 639. |
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
2 participants
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.
Summary
Three independent fixes for Live Activity behaviour that surfaced together
in a 6.1.0 report (audible notification on LA renewal + a gratuitous LA
restart 37 minutes after a successful background renewal).
willPresentno longer forces banner+sound for every notification.The handler in
AppDelegatereturned[.banner, .sound, .badge]unconditionally, which meant any notification iOS routed through
UNUserNotificationCenterwhile LF was foregrounded would producesound — including the intentionally-silent push-to-start payload
(
interruption-level: passive, empty title/body). The handler nowreturns
[]for passive notifications and for ones with emptytitle/body. The four intentional alerts (
scheduleRenewalFailed…,scheduleApnsCredentialsMissing…,schedulePushToStartTokenMissing…,alarms) all use non-empty title/body and the default
.activeinterruption level, so they continue to surface normally.
pendingForegroundRestartis cleared on every push-to-startadoption (
adoptPushToStartActivity). Without this, a briefforeground entry while the renewal overlay was up could latch the
intent, the user could background again before
didBecomeActiveran,the background renewal could replace the LA, and the next foreground
entry — minutes later — would tear down the freshly-renewed LA and
start another.
performForegroundRestartre-checks the latch conditions. Beltand braces with the previous fix: even if a future code path latches
the intent without going through adoption, the deferred restart will
bail out when
renewalFailed/overlayShowing/pushToStartLooksStuckno longer hold.
Deferred-foreground-restart push-to-start is tagged
reason="deferred-foreground-restart"instead of inheriting the"user-start"label fromstartIfNeeded. The previous tag made thestale-latch event indistinguishable from a real user action in logs.
Threaded through a single-shot
nextStartReasonOverrideso theoverride is consumed exactly once and
startIfNeeded's public surfaceis unchanged.
willPresentlog line expanded withinterruptionLevelandwhether title/body are empty, so future reports can confirm whether
iOS is routing the LA push-to-start payload through
willPresent.