v2.29.1

CHANGELOG.md

@@ -1,5 +1,19 @@
 # client-sdk-android
 
+## 2.29.1
+
+### Patch Changes
+
+- Scale the `x-google-start-bitrate` hint by connection setup time: the 1 Mbps camera cap now applies to connections that set up within 1.5 s and ramps linearly down to 300 kbps at 3.5 s or slower, with screen share capped the same way once the cap is below 1 Mbps. - [#1031](https://github.com/livekit/client-sdk-android/pull/1031) ([@changt](https://github.com/changt))
+
+- Seed the bandwidth estimator with `x-google-start-bitrate` for all video codecs, not just SVC, so published video reaches its target quality in the first second or two instead of ramping from ~300 kbps over 5-15 seconds. The hint is 90% of the track's target bitrate, capped at 1 Mbps for camera tracks (screen shares are exempt, since they are published at high bitrates for text legibility) and skipped below a 300 kbps target, where seeding high costs more than it gains. - [#973](https://github.com/livekit/client-sdk-android/pull/973) ([@xianshijing-lk](https://github.com/xianshijing-lk))
+
+  Because libwebrtc applies these codec fmtp parameters to the whole peer connection rather than the m-section carrying them, the SDK now writes a single connection-level value to every video m-section, once per publisher connection. Re-seeding a converged estimator is avoided: the value persists in libwebrtc's bitrate configurator and is automatically re-applied on network route changes, and a full reconnect builds a new peer connection and seeds it again.
+
+  **Behavior change:** the SDK no longer writes `x-google-max-bitrate` into SDP. That value was promoted to a ceiling on total send bandwidth for the entire connection, so a camera publication could throttle a concurrent screen share. Per-track and per-layer limits continue to be enforced through `RtpParameters.Encoding.maxBitrateBps`, which is correctly scoped per encoding. Applications that relied on the SDP value as a connection-wide cap should set encoding bitrates instead. This matches client-sdk-js and the Rust SDK, neither of which writes it.
+
+  `TrackBitrateInfo` and `TrackBitrateInfoKey` are now `internal`. They were never intended as public API (both were `@suppress`ed and only reachable through a `@VisibleForTesting` helper) and were public only to be visible from the test module, which is no longer necessary.
+
 ## 2.29.0
 
 ### Minor Changes

README.md

@@ -84,7 +84,7 @@ LiveKit for Android is available as a Maven package.
 ```groovy title="build.gradle"
 ...
 dependencies {
-  def livekit_version = "2.29.0"
+  def livekit_version = "2.29.1"
 
   implementation "io.livekit:livekit-android:$livekit_version"
 
@@ -95,7 +95,7 @@ dependencies {
   implementation "io.livekit:livekit-android-track-processors:$livekit_version"
 
   // Snapshots of the latest development version are available at:
-  // implementation "io.livekit:livekit-android:2.29.1-SNAPSHOT"
+  // implementation "io.livekit:livekit-android:2.29.2-SNAPSHOT"
 }
 ```
 

gradle.properties

@@ -33,7 +33,7 @@ kapt.use.worker.api=true
 ###############################################################
 
 GROUP=io.livekit
-VERSION_NAME=2.29.0
+VERSION_NAME=2.29.1
 
 POM_DESCRIPTION=LiveKit Android SDK, WebRTC Rooms
 

package.json

@@ -1,6 +1,6 @@
 {
   "name": "client-sdk-android",
-  "version": "2.29.0",
+  "version": "2.29.1",
   "repository": "https://github.com/livekit/client-sdk-android.git",
   "license": "Apache License 2.0",
   "private": true,