[davidliu]

Summary

Merges upstream react-native-webrtc up to 155.0.1. That brings in the 30 upstream commits made since our last sync (#73).

We stay on our libwebrtc 150 builds (android-prefixed 150.7871.04 and LiveKitWebRTC 150.7871.04). Upstream's switch to Jitsi's M155 build is not taken. The package version is unchanged at 150.1.1; the release bump will be a separate change.

This PR also includes an Android fix for a ConcurrentModificationException (see "Also in this PR").

⚠️ Merge with "Create a merge commit", not squash

Our earlier upstream syncs (#16, #24, #42, #73) were squash-merged. Git never recorded upstream as a parent, so every sync had to redo all conflict resolution since July 2024.

This branch fixes that. 8f25154 is a real merge commit whose second parent is upstream fb662c9 (155.0.1). Squashing this PR would lose that link, and the next sync would start from scratch again.

As a side effect, the commit list shows 78 upstream commits:

• 48 already synced: already brought in by the squashed syncs; they appear only because the history is now linked.
• 30 new: e36ddec..fb662c9. List them with git log e36ddec..8f25154^2.

The merge used e36ddec (the upstream commit #73 synced to) as its base, so earlier resolutions were not redone.

New from upstream

Features

• RTCCertificate support: RTCPeerConnection.generateCertificate() and certificates in RTCConfiguration (Android and iOS).
• getDisplayMedia(constraints) (Android only): android.createConfigForDefaultDisplay and android.resolutionScale.

Fixes

• Android:
  • Race condition in getDisplayMedia.
  • getDisplayMedia crash on API < 31.
  • Crash when the host delivers onActivityResult twice, e.g. with react-native-navigation.
  • Leaked intermediate video-effect frames.
• iOS:
  • Broadcast picker on the new architecture.
  • On the simulator, camera capture now starts when a camera is available at runtime.
• Peer connection close: connections are now disposed when signalingState becomes closed instead of connectionState, so the final signalingstatechange event is delivered.
• Codec preferences: setCodecPreferences uses the error-reporting API on both platforms and logs failures.
• applyConstraints: keeps the current facingMode when none is given. This doesn't change which camera is used here, since we already ignore camera changes in applyConstraints (android,ios: disallow changing cameras through apply constraints #34).
• Build: the vendored event-target-shim type declarations now ship in lib/typescript (tools/postbuild.mjs).

No net change: Center Stage (added, then reverted upstream); a duplicate RTCRtpSender global assignment removed (a later line already overwrote it); dependency bumps.

Conflict resolution

Kept ours

• Package name and version, the libwebrtc 150 dependencies, README.
• iOS 12.0 minimum in the podspec and install docs. Upstream moved to 14.0 only because M155 requires it. The example apps take upstream's 14.0.

Adapted upstream code to our prefixed SDK

• Android: explicit livekit.org.webrtc imports for RtcCertificatePem and RtcError.
• iOS: LKRTCCertificate and LKRTCCameraVideoCapturer, plus <LiveKitWebRTC/RTCCertificate.h> imports.
• ProGuard rules (consumer-rules.pro):
  • Upstream's -dontwarn rule is ported as -dontwarn livekit.org.jni_zero.**.
  • Upstream's -keep class J.N is skipped; that class doesn't exist in the prefixed artifact.

Combined

• ScreenCaptureController: upstream's resolutionScale, plus our check that skips the format change when the size hasn't changed (android: only change capture format for screen if dimen actually changed #8).

Replaced

• Our scripts/copy-vendor-types.js (added in Merge upstream #73) is replaced by upstream's tools/postbuild.mjs. It fixes the same problem and also deletes the empty .d.js files. The build script name is kept.
• package-lock.json: ours, plus the two upstream bumps we didn't have: brace-expansion → 1.1.21, picomatch → 2.3.2.

Also in this PR

• 3d3a0c9 android: fix ConcurrentModificationException from off-executor createStream.
  • The entry points that other native modules call (createVideoTrack, registerTrack, createStream) now run on the WebRTC executor, the only thread where the local stream and track maps are safe to touch.
  • createVideoTrack blocks until the track is created.
• tmp/ added to .gitignore and .npmignore.

Testing

Done (on the merge commit, before 3d3a0c9)

• npm run lint (eslint + tsc) and the build (bob build + postbuild) pass.

• Android library sources compile with javac against libwebrtc 150.

• iOS sources pass clang -fsyntax-only against LiveKitWebRTC 150 (iOS simulator slice).

• Full Android and iOS builds, including an Android release build with R8 (ProGuard rules).

• Android screen share: rotation, resolutionScale, API < 31, quick start/stop.

• Codec preferences on both platforms: the preferred codec comes first in the offer.

• Certificates: generate ECDSA and RSA, use one in a connection, and check the fingerprint matches the SDP.

• pc.close(): calling it twice or getStats() after close doesn't crash, and stopping tracks before or after close is safe.

• LiveKit room smoke test on iOS and Android: publish and subscribe, E2EE, encrypted data packets, the iOS audio session and CallKit, and track.stop() releasing the camera.

• e2e-react-native tests run with no new failures.
  🤖 Generated with Claude Code

[xianshijing-lk]

[P1] createVideoTrack() can deadlock the WebRTC executor

This method submits creation to the single-threaded WebRTC executor and waits on .get(). If called from that executor, the submitted operation cannot run.

This is reachable through the public API: createStream() now invokes its success callback on the executor, and a native integration can create another track from that callback.

Please execute inline when already on the executor, or expose an asynchronous alternative. A focused Java probe reproduces the deadlock.

[xianshijing-lk]

[P2] Registration became asynchronous while lookup remained synchronous

registerTrack() previously completed registration before returning. It now queues registration, while public getTrack() still reads directly on the caller’s thread. Consequently, registerTrack(track, source) followed by getTrack(-1, track.id()) can return null.

These lookups also access mutable local and remote registries outside their intended executor. Please define a consistent execution contract that preserves registration/lookup ordering and coordinates lookup with disposal. Concurrent collections alone would not resolve the ordering regression.

[xianshijing-lk]

[P2] Interrupted creation can leave an orphaned camera track

When .get() throws InterruptedException, the method returns null without restoring interruption or handling the submitted creation operation. That operation can still allocate and start a camera track that the caller never receives.

Please restore the interrupt status and cancel pending creation or clean up an abandoned result. Adding a timeout would require the same cleanup: stopping the wait does not stop the work.