Repository navigation
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 2 potential issues.
2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)
| public var isAutomaticActivationEnabled: Bool { | ||
| get { _state.isAutomaticActivationEnabled } | ||
| set { _state.mutate { $0.isAutomaticActivationEnabled = newValue } } |
There was a problem hiding this comment.
🟡 Active calls cannot regain SDK activation
When an app restores isAutomaticActivationEnabled during an active call, the SDK does not activate the session after CallKit releases it. The activation gate runs only when requirements change from empty to nonempty, so audio stays silent until they fully reset.
Learn more
Session requirements describe whether the SDK's audio engine needs an active session. The activation gate in configureAudioSession runs only on a transition from no requirements to some. Changing the public flag while requirements persist changes the stored value but does not invoke configuration or activate the session. If an app transfers an ongoing call from CallKit-managed activation to SDK-managed activation, CallKit can deactivate the session while the SDK still has requirements, leaving the engine without audio.
Example: A call starts with isAutomaticActivationEnabled = false; its playback requirement remains held. The app sets the flag to true to continue playback after ending the CallKit call. CallKit deactivates the session, but the SDK never calls setActive(true) for that requirement.
Recommended fix: Decide and document whether activation ownership can change while requirements are held. If supported, track actual activation ownership and handle the handoff explicitly; a setter alone cannot reactivate after a later external deactivation without a handoff signal.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
On activation during a call: like isAutomaticConfigurationEnabled, this is meant to be set before connecting, and handing activation over in the middle of a call is not supported. Documented in cc7f717.
On Objective-C: AudioSessionEngineObserver is not exposed to Objective-C today, including the existing isAutomaticConfigurationEnabled and isAutomaticDeactivationEnabled, so this follows the same pattern. Happy to look at an Objective-C entry point separately if that is wanted.
| public var isAutomaticActivationEnabled: Bool { | ||
| get { _state.isAutomaticActivationEnabled } | ||
| set { _state.mutate { $0.isAutomaticActivationEnabled = newValue } } |
There was a problem hiding this comment.
🟡 Objective-C apps cannot configure activation ownership
Objective-C CallKit apps cannot set isAutomaticActivationEnabled, because its containing class is not exposed to Objective-C. The new public switch has no Objective-C-accessible alternative.
Learn more
The repository's public API rule calls for Objective-C support. This property is declared on AudioSessionEngineObserver, a Swift-only class, and AudioManager.audioSession also belongs to a Swift-only class. Merely adding @objc to the property cannot expose the containing object to Objective-C.
Example: An Objective-C app using CXProviderDelegate cannot obtain AudioManager.shared.audioSession to disable automatic activation, although a Swift app can.
Recommended fix: Expose a small Objective-C-compatible facade for the audio session switches and make it reachable from Objective-C, or document an approved exception to the public API rule.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Device test results: Tested on an iPhone 17 Pro running iOS 27.0.1 with three outgoing CallKit calls per version, using the default |
|
@hiroshihorie deferring that as you're working on this API part. |
2 participants
isAutomaticConfigurationEnabledcontrols two things at once: configuring the audio session (category, mode, options, IO buffer duration) and activating it. Deactivation already has its own switch,isAutomaticDeactivationEnabled. Activation does not.With CallKit or LiveCommunicationKit the system activates and deactivates the session (
provider(_:didActivate:),conversationManager(_:didActivate:)). Today the only option for these apps is to turn off automatic configuration completely and set the category themselves indidActivate, as the README shows with.playAndRecord/.voiceChat.That hard-coded configuration can't follow what the SDK selects internally. Since #1072 the SDK uses the media-tuned presets when software voice processing is used, and the selection depends on internal state (
isPlatformVoiceProcessingExpected,hasRecorded) that is not public (see the discussion in #1086). So CallKit apps can end up with a different mode than the SDK expects, for example quiet remote audio with software voice processing.Changes
AudioSessionEngineObserver.isAutomaticActivationEnabled, defaulttrue. Whenfalse, the SDK still configures category, mode, options and IO buffer duration, but does not callsetActive(true). The skip is logged the same way as the existing deactivation skip.Docs/audio.md: keep automatic configuration on, setisAutomaticActivationEnabled = falseandisAutomaticDeactivationEnabled = false, and only callsetEngineAvailabilityfrom the activation callbacks. Mention that the same setup works with LiveCommunicationKit.isAutomaticConfigurationEnabled = falsestays documented for apps that want full manual control.The default is
true, so nothing changes for existing apps. This only adds API.Making activation a separate switch, rather than exposing the voice processing state, keeps the configuration logic internal, and it mirrors the existing deactivation switch.
Test
AudioSessionCategorySelectionTestsand the newAudioSessionAutomaticActivationTestspass on the iOS Simulator.