Repository navigation
Resolve the WebRTC plugin registered with the calling engine #1212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
37cdea1
98f4b5c
9ef5534
c63ec75
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| patch type="fixed" "iOS/macOS: audio device module and local track calls act on the calling Flutter engine's WebRTC instance when more than one engine initializes WebRTC" |
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🟡 Device updates reach the wrong engine After a second engine registers, (Refers to this code) Learn moreThe shared observer receives callbacks from an audio device module attached to a WebRTC factory. The process-wide singleton can change when another Flutter engine registers, independently of the module that emitted the callback. Forwarding the callback to that singleton updates a different engine's WebRTC device listeners, leaving the owning engine's listeners without the event. Example: Engine A connects Bluetooth audio and has an active peer connection. Engine B registers WebRTC, becoming the singleton. When engine A's module reports a device update, the callback invokes engine B's handler, so engine A's device-change listener receives nothing. Recommended fix: Associate the callback's Was this helpful? React with 👍 or 👎 to provide feedback.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same premise as above. On flutter_webrtc 1.6.3 a second engine registering does not take the singleton, so engine A keeps receiving its own device updates. The remaining case is two engines that both create a factory, where the second engine's updates go to the first factory owner. That is unchanged from main, since this PR leaves the observer on the singleton, and fixing it needs a flutter_webrtc API that maps an audio device module back to its owning instance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔴 CallKit gate misses the active engine
After another Flutter engine registers,
setEngineAvailabilitytargets its singleton instead of the active engine. CallKit gating leaves the original engine running outside its activation window.(Refers to this code)
Learn more
The native static entry point is used by an AppDelegate before or during CallKit activation. WebRTC's singleton changes when another Flutter engine registers, but the first engine's factory can still own the running audio device module. The method stores the requested availability, then checks only the current singleton; it returns false if that engine has no factory, or updates the wrong module if it does. The pending value cannot correct the first engine without another targeted application.
Example: The UI engine is recording with its factory initialized. A background engine registers without initializing WebRTC, and CallKit calls
setEngineAvailability(isInputAvailable: false, isOutputAvailable: false). The call returns false and the UI engine continues recording; the gate was expected to stop it.Recommended fix: Keep a process-level reference or registry of initialized WebRTC factories for native CallKit calls, and apply the gate to the active module instead of the moving singleton. Preserve deferred application before any factory exists.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
flutter_webrtc 1.6.3 no longer moves the singleton when an engine registers. The first registered instance keeps it, and another instance takes it over only by creating a factory while the current one has none. In this example the UI engine keeps the singleton after the background engine registers, so the gate reaches its audio device module and returns true. The reverse order (background engine first, UI engine initializing later) also ends on the UI engine through the takeover. With two engines that both create a factory, the gate targets the first factory owner, which is unchanged from main.