WebRTC in Android Explained: SDKs, Capture, Compose UI, and the Five Gotchas | Fora Soft

Why Fora Soft wrote this playbook

We have shipped Android WebRTC clients on every credible engine — libwebrtc directly, Stream Android SDK, LiveKit Android, Daily, Agora, 100ms, and bespoke SFU clients. BrainCert, ProvideoMeeting, and a number of NDA-bound healthcare and surveillance products run Android WebRTC clients we wrote. Around 40% of our engineering capacity sits in real-time and mobile.

This article is the playbook we hand to Android engineers joining a WebRTC project. It explains the canonical flow, names the five Android-specific gotchas that eat sprints, and points to the SDK choice for a given product profile. Conceptual primers on WebRTC sit in our What is WebRTC explainer; the architecture map sits in our WebRTC architecture guide for business 2026.

WebRTC core concepts — the pieces every Android client needs

Every Android WebRTC client — whether you build directly on libwebrtc or via an SDK — reuses the same five primitives. Knowing them up front prevents most of the head-scratching.

Camera capture — the part Android-specific bugs love

libwebrtc ships with two camera capturers: Camera1Enumerator (legacy) and Camera2Enumerator (post-Lollipop). Always pick Camera2 for new code.

val enumerator = Camera2Enumerator(context)
val capturer = enumerator.deviceNames.firstOrNull { enumerator.isFrontFacing(it) }
  ?.let { enumerator.createCapturer(it, null) }
  ?: throw IllegalStateException("No front camera")

capturer.initialize(surfaceTextureHelper, context, source.capturerObserver)
capturer.startCapture(1280, 720, 30)

Mind the foreground service. From Android 14 onwards, camera capture from a background or background-launching activity is restricted. Wrap the capture in a FOREGROUND_SERVICE_TYPE_CAMERA service for any session that survives backgrounding.

Signalling — SDP offer/answer and ICE candidates

WebRTC does not specify the signalling channel; you bring your own. Most products use Socket.IO, plain WebSocket, gRPC, or a vendor SDK’s built-in signalling. The protocol carries three message types between peers (or to the SFU):

1. SDP offer — the offerer’s media capabilities. 2. SDP answer — the answerer’s capabilities. 3. ICE candidates — network-path candidates exchanged as both sides discover them.

peerConnection.createOffer(object : SdpObserver {
  override fun onCreateSuccess(sdp: SessionDescription) {
    peerConnection.setLocalDescription(this, sdp)
    signalingClient.sendOffer(sdp)
  }
  override fun onSetSuccess() {}
  override fun onCreateFailure(p0: String?) { /* handle */ }
  override fun onSetFailure(p0: String?) { /* handle */ }
}, MediaConstraints())

Android WebRTC SDKs compared — libwebrtc, Stream, LiveKit, Daily, Agora, 100ms

Most teams ship via an SDK rather than libwebrtc directly. The SDK adds room concepts, adaptive bitrate, and a steady migration path through Android API changes. Below is the lay of the land.

Five Android-specific gotchas that eat sprints

1. Foreground service for camera and mic. Android 14+ blocks camera capture from background activities. Wrap the call in a FOREGROUND_SERVICE_TYPE_CAMERA/_MICROPHONE service or your sessions die when users navigate away.

2. Audio focus and mode. WebRTC needs MODE_IN_COMMUNICATION on the AudioManager and an AudioFocusRequest with USAGE_VOICE_COMMUNICATION. Skipping this gives you echo, low volume, and Bluetooth-routing chaos.

3. Hardware codec selection. H.264 hardware encoders on older Snapdragons mishandle keyframes; VP9 is more reliable across the fleet but uses more CPU. Override the codec preference list per device class.

4. Simulcast tuning. Default simulcast layers are configured for desktops. On phones, drop one layer (typically the 1080p one) to keep CPU within budget. Keep the 360p “low” layer for receivers on weak networks.

5. Doze and Network changes. When the device dozes or switches network, ICE restarts. Implement peerConnection.restartIce() with backoff; without it your reconnects fail in unintuitive ways.

Jetpack Compose UI — rendering remote video without recomposition jank

SurfaceViewRenderer is a View, not a composable. Wrap it in AndroidView and remember the renderer instance to avoid repeated init/release on recomposition.

@Composable
fun RemoteVideoRenderer(track: VideoTrack, modifier: Modifier = Modifier) {
  val renderer = remember {
    SurfaceViewRenderer(context).apply { init(eglBase.eglBaseContext, null) }
  }
  DisposableEffect(track) {
    track.addSink(renderer)
    onDispose { track.removeSink(renderer); renderer.release() }
  }
  AndroidView(factory = { renderer }, modifier = modifier)
}

Track instability in Compose is a known headache. Our Vkompose performance guide covers Strong Skipping, Modifier.Node, and the recomposition traps that affect WebRTC video grids specifically.

Recording, screen sharing, and PiP on Android

Recording. Per-track recording happens on the SFU; the Android client only emits its own MediaStream. For client-side recording use MediaRecorder with the encoder track, but expect file-size, sync, and battery costs.

Screen share. Use MediaProjection + VirtualDisplay; libwebrtc’s ScreenCapturerAndroid wraps the media projection token. The full implementation walk-through is in our Android WebRTC screen sharing guide.

Picture-in-picture. Plan PiP on phones (Android 8+) and on Android TV. Pause low-tier simulcast layers when entering PiP to save battery; some SDKs do this automatically, others need a hook.

Network handling — congestion, ICE restart, and weak-network UX

Android phones move between Wi-Fi and cellular constantly. Three patterns keep sessions alive:

1. ICE restart with exponential backoff. When PeerConnection.iceConnectionState reports DISCONNECTED, wait 2–5 s before calling restartIce(). Many transient issues self-heal.

2. Adaptive bitrate signalling. Use simulcast layers and let the SFU pick the right one for each receiver; do not try to second-guess the bitrate selection in your app.

3. Bad-network UX. Show a low-quality avatar or last-frame still when stats fall below a threshold. Test with Charles Proxy or our methodology in Simulating slow network connections for video apps.

Testing Android WebRTC — unit, instrumented, and synthetic load

Unit tests. Mock the SDP and ICE callbacks; test signalling state machines independently of libwebrtc.

Instrumented tests. Espresso + UI automator can drive a test client; pair with a CI-controlled SFU sandbox to assert join/leave/freeze metrics.

Synthetic load. Tools like our streaming-optimization guide describe the harness we use to generate 1K+ concurrent fake clients against an SFU; the same approach applies to validating Android WebRTC client robustness.

Cost of building an Android WebRTC client

A decision framework — pick an Android WebRTC path in five questions

1. Does your team have WebRTC experience? No → SDK (LiveKit / Stream / Daily). Yes → libwebrtc directly is on the table.

2. What is the user’s primary device class? Phones → default 720p simulcast. Tablets / TV → bigger video grid, plan for landscape and PiP.

3. Compose or XML? Compose for new builds; XML only for legacy codebases or specific OEM constraints.

4. Do you need screen sharing on Android? Yes → budget $8–$15K and plan a foreground service. No → defer to v2.

5. What is your concurrent-user target? < 200 → SDK fees are tolerable. > 500 → pair the Android client with a self-hosted SFU.

Pitfalls we have watched Android WebRTC teams fall into

1. Skipping the foreground service. Sessions die on backgrounding; reviewers reject the app. Build it from sprint 1.

2. Picking 1080p as the default. Phones overheat and burn battery. Default to 720p simulcast and opt up only on confirmed hardware.

3. Initialising EglBase on every recomposition. A classic Compose mistake; the second instance crashes the renderer. Wrap in remember.

4. Ignoring AudioManager mode. Without MODE_IN_COMMUNICATION you fight echo, low volume, and Bluetooth routing forever.

5. Using Camera1Enumerator in 2026. It still works, but newer devices and codec paths assume Camera2; you will hit obscure bugs.

KPIs — what to measure on the Android client

Quality KPIs. p95 join time < 4 s, freeze rate < 1%, audio MOS > 4.0, simulcast-layer-up success rate > 90%.

Business KPIs. Crash-free sessions > 99.5%, install-to-day-1 retention movement after performance ships, Play Store Vitals “bad behaviours” under threshold.

Reliability KPIs. Reconnect success rate > 95%, Doze-mode session resumption < 5 s, foreground-service uptime 100% during active calls.

When NOT to use WebRTC on Android

Skip WebRTC when (a) the use case is one-way live broadcast to thousands — HLS or LL-HLS scales better; (b) the latency budget is over five seconds — LL-HLS is cheaper; or (c) the team has neither SDK budget nor WebRTC experience — consider a managed video conferencing iframe instead.

FAQ

What to Read Next

Ready to ship a clean Android WebRTC client?

Android WebRTC in 2026 is a solved problem when you respect the platform’s rules: foreground service for capture, audio focus, hardware codec selection, simulcast tuning, and Doze-mode reconnects. SDK choice is downstream of those rules. Compose is the default UI; libwebrtc directly is the right pick for custom SFUs only.

If you want a stage-matched plan — SDK choice, screen sharing, recording, PiP, and a realistic calendar — the fastest next step is a 30-minute call. We will pick the path, scope the work, and tell you honestly when an SDK MVP beats a custom build.