feat: Data Tracks

[davidliu]

Adds data track support, sharing the Rust UniFFI core (livekit-uniffi-android) with the other SDKs.
Most of room/datatrack/ is a thin wrapper around that core. The Android-specific work is the WebRTC, signaling, and reconnect glue.
Actual changes

• RTCEngine / DataTrackFrameSender — _data_track channel, send backpressure, wait-for-open, reconnect
• SignalClient — publish / unpublish / subscriber-handle / request-response forwarding
• Room, LocalParticipant, RemoteParticipant — public API, attach/park remote tracks, events
• IncomingDataTrackManager / OutgoingDataTrackManager — bridge UniFFI managers to the engine
• DataTrackCryptor / E2EEManager — E2EE via the existing data-packet cryptor
• DataChannelManager, RTCModule, test DI — channel metering and injectable factories

Simple wrappers (FFI type/API mapping, little Android-specific logic)

• LocalDataTrack, RemoteDataTrack, DataTrackStream
• DataTrackFrame, DataTrackInfo, DataTrackSid, DataTrackSchema, DataTrackPublishOptions, DataTrackException
• DataTrackManagerFactory, IncomingDataTrackEvent

E2E tests: https://github.com/livekit/e2e-android/pull/13

[changeset-bot]

🦋 Changeset detected

Latest commit: d4c5e7a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
client-sdk-android	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[devin-ai-integration]

Note

This report is out of date. Scroll down for Devin Review's latest report on this PR.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

[pblazej]

Compared this against the Swift (#975), JS (#1994) and Rust implementations, looking for behavior diffs.

Before merge

1. DataTrackPublished is dropped, not deferred — Room.kt:905 gates it on emitWhenConnected, but joinImpl attaches tracks while state is CONNECTING/RECONNECTING, so it never fires for tracks present at join or after a full reconnect. DataTrackUnpublished posts directly (:821), so apps can see an Unpublished with no Published. JS deliberately uses plain emit for both; Swift notifies unconditionally.
2. Data-track init can fail Room.connect — RTCEngine.kt:303 calls handleSfuJoinResponse unguarded and builds the UniFFI manager there on every connect, catching only HandleSignalResponseException. So an UnsatisfiedLinkError fails the connect for apps that never touch data tracks — reachable on API 21–23, where tools:overrideLibrary (AndroidManifest.xml:17) hides that the AAR won't load and nothing gates on SDK_INT. Swift's call is try?. handlePacketReceived has no try/catch at all and runs on a WebRTC thread.
3. waitUntilInboundDataTrackChannelReady() precedes resendSubscriptionUpdates() — RTCEngine.kt:781. If the SFU opens the subscriber channel in response to a subscription, the wait can't clear until the call after it runs; at best it adds MAX_ICE_CONNECT_TIMEOUT_MS to every full reconnect with remote tracks. Swift, JS and Rust all resubscribe straight after transport connect — suggest deleting the gate. The unit test hand-feeds the channel, so it passes either way.
4. A dead transport can report CONNECTED — RTCEngine.kt:362 suppresses DISCONNECTED while reconnecting, then the success branch sets CONNECTED unconditionally after up to ~40 s of waiting. An ICE failure in between is swallowed and overwritten, and connectionChangeListener can't cover it because reconnect() early-returns while reconnectingJob is live. Not data-track scoped.

Public surface — cheaper to settle now

• DataTrackPublishOptions (:22) allows either field null and never checks compatibility (JsonSchema + Cdr passes locally, fails remotely). Swift uses two constructors, JS validates against COMPATIBLE_SCHEMA_ENCODINGS. A validating factory is additive later, but the permissive constructor is forever. No test covers an invalid pair.
• The LocalDataTrack KDoc's "releasing the last reference unpublishes it" is Swift's ARC text — on the JVM the DropGuard waits on the UniFFI Cleaner, so a dropped reference can leave the publication live on the SFU. Nothing is AutoCloseable and close() only clears the map. I'd fix the doc now and let AutoCloseable follow.

Small

• RTCEngine.kt:1079 — the observer wrapper captures the old manager while the gate reads the current field, so a stale CLOSED flips an already-open replacement back to WAITING and the next publish burns the full timeout. Swift guards with guard dataChannel === publisherChannel.
• IncomingDataTrackManager.kt:62 — the delegate captures its manager and Rust holds it as a JNI global ref, so the cycle spans the FFI boundary and retains the engine and both PCs unless close() runs. Swift split out a weak-holding shim. Same shape in OutgoingDataTrackManager.
• SignalClient.kt:745 — unguarded parseFrom inside the UniFFI forward task throws across the boundary; Swift logs and skips.
• OutgoingDataTrackManager.kt:78 — startsWith("Timed out") to classify the error; reword RTCEngine.kt:1024/1038 and every timeout silently becomes a disconnect. Two exception types instead.
• RTCEngine.kt:1580 — subscribe-only clients negotiate a publisher PC via the shared sendDataTrackSignalRequest; both references keep subscribe signal-only, and the hasPublished guard is redundant (:814).
• DataChannelManager.waitUntilOpen() has three tests and no production caller; sendOrQueue's per-frame copyOf() copies already-fresh packets on the RTC thread.

[xianshijing-lk]

is this dataTrackDataChannelSub needed ? I don't see how it is used rather than assign and clear, is it intentional ?

[davidliu]

Hmm, looks like all of the sub channels may need DataChannelManager handling, will handle in a follow up PR.

[pblazej]

LGTM, added 2 non-blockers above

[MaxHeimbrock]

A second draft PR for these changes according to @1egoman's "Commit Reshuffle" strategy to build a story line through commits and some ideas from me for structured PR description for API changes: #1019

Please have a look and give feedback to @1egoman and me if this strategy could help review PRs.

[devin-ai-integration]

Devin Review found 1 new potential issue.

2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)