Android Video Call SDK: 12 Features & 2026 Prices

Updated October 2026: Android 17 background-audio rules, the API 36 Play deadline, Jetpack Core-Telecom, and 2026 list prices for LiveKit, Twilio and Agora.

Why Fora Soft wrote this guide

We’ve shipped real-time apps since 2005 — 250+ projects, and a stack of Android video calling apps built on WebRTC since it opened on mobile. Recent, on-topic builds: TransLinguist (real-time video interpretation), MyOnCallDoc (HIPAA-grade telemedicine calls), Speakk (anonymous voice chat) and Talensy (multi-party calling). Our WebRTC development team builds these calling stacks as core work, not as a side project.

This is for the founder, head of product or platform engineer shipping or rebuilding an Android video calling app who wants the short version of what we’d actually do today. It’s opinionated and Android-specific — the iOS equivalent is a different article.

Why Android calling is harder than iOS in 2026

iOS has CallKit. Android has a buffet. ConnectionService is the closest thing to CallKit, but it’s optional — and since May 2025 Google’s Jetpack Core-Telecom library (androidx.core:core-telecom 1.0.0) wraps it in a CallsManager API, which is now the recommended way for a VoIP app to plug into the system Telecom stack, and most apps end up combining it with custom in-app UI, foreground services and FCM. Doze and App Standby aggressively throttle background work, yet a calling app still needs to wake within seconds when a call arrives. The rules keep tightening: Android 14 (API 34) made foreground-service types mandatory, Android 15 (API 35) blocked launching a camera or phone-call foreground service from a BOOT_COMPLETED receiver, and Android 16 (stable since June 2025) is now the floor: since 31 August 2026 Google Play accepts new apps and updates only if they target API 36, with extensions running to 1 November 2026. Android 17, stable since 16 June 2026, adds background-audio hardening: audio playback and audio-focus requests made outside a valid app lifecycle now fail — focus requests return AUDIOFOCUS_REQUEST_FAILED and playback fails silently — so a ringtone started from the wrong context simply never sounds. On top of the platform, OEM background killers (Samsung, Xiaomi, Oppo, Vivo) routinely terminate apps that follow every one of Google’s rules. And push delivery is best-effort, so you need a fallback signalling channel.

None of this is unsolvable. All of it has to be designed in from week one — retrofitting after launch is what tanks a video calling app in store reviews.

Figure 1. Where iOS gives you one framework, Android hands you six moving parts to wire together.

The twelve features every Android calling app must ship

The reference architecture — signalling, media, push, foreground

Every credible Android calling app has the same four planes. Where each one runs is the difference between “works in the demo” and “works on Android 14 on a Samsung after eight hours of standby.”

Signalling. WebSocket (or SIP / XMPP if you have a reason) for SDP offer/answer and ICE candidate exchange, room state, presence. Keep the connection alive in the foreground service when the app is open; reconnect quickly on resume.

Media. WebRTC PeerConnection on the device. DTLS-SRTP for transport. STUN for direct paths, TURN for everything blocked by symmetric NAT — budget for TURN from day one, and measure the relayed share in your own beta from the WebRTC candidate-pair stats rather than trusting a rule of thumb. Simulcast or SVC for video so weak peers don’t drag everyone’s quality down. Codec choice (H.264 vs VP9 vs AV1) trades CPU, battery and bandwidth — our video encoding fundamentals lay out the tradeoffs.

Push. FCM high-priority data messages (not notification messages) on incoming call. The receiver wakes the foreground service, raises a CallStyle notification with full-screen intent, and starts ringing. The code for that step, including the phoneCall service prerequisites and the Android 17 ringtone change, is in our Android call notification guide. For OEMs known to drop FCM, layer a WebSocket keep-alive while the app process is allowed to live, and (where it matters) a proprietary push channel like MiPush.

Foreground service. Started before any audio or camera capture, declared in the manifest with the matching foregroundServiceType (phoneCall for the active call, plus microphone and camera while you capture). On Android 14+, the matching FOREGROUND_SERVICE_* permission must also be in the manifest. Skipping this throws ForegroundServiceStartNotAllowedException at runtime, which in production looks like a crash on first call.

Manifest essentials, in one block

<uses-permission android:name="android.permission.RECORD_AUDIO"/>
<uses-permission android:name="android.permission.CAMERA"/>
<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
<uses-permission android:name="android.permission.USE_FULL_SCREEN_INTENT"/>
<uses-permission android:name="android.permission.MANAGE_OWN_CALLS"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MICROPHONE"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_CAMERA"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_PHONE_CALL"/>
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT"/>

<service
    android:name=".CallForegroundService"
    android:exported="false"
    android:foregroundServiceType="phoneCall|microphone|camera"/>

Figure 2. The four planes and where each one runs. Get the split wrong and the demo works but production doesn’t.

Video call SDK for Android: which one to pick in 2026

Short answer: for most new Android video calling apps in 2026 we pick the LiveKit Android SDK — open source, Kotlin-first, with Jetpack Compose components, and you can run it on LiveKit Cloud or your own servers. Pick raw WebRTC when calls are strictly 1:1 and you have strong native Android engineers. Pick Twilio Video or Agora when you want a managed service billed per minute with no media servers to run, and Sendbird Calls only if you already use Sendbird chat. Whatever you pick, a video call SDK covers the media plane only: push delivery, Telecom integration and foreground services stay your job.

Four broad paths. The right one depends on engineering depth, regulation and how much of the operational tail you want to own.

How to integrate video calling into an Android app: six steps

1. Add the SDK. One Gradle dependency: io.livekit:livekit-android, com.twilio:video-android, io.agora.rtc:full-sdk, or a WebRTC build.
2. Mint access tokens on your backend. Never ship an API secret inside the APK.
3. Ask for permissions. RECORD_AUDIO, CAMERA and POST_NOTIFICATIONS at runtime, foreground-service types in the manifest.
4. Register the call with the system. Add it through Core-Telecom’s CallsManager and start a phoneCall foreground service before you open the mic or camera.
5. Join and render. Connect to the room, publish local audio and video tracks, render remote video in a Compose or SurfaceView renderer.
6. Wire incoming calls and telemetry. An FCM high-priority data message rings the device; WebRTC stats go to your dashboards from the first beta.

Google WebRTC native library

The foundation. Battle-tested, zero licensing cost, full control. You build signalling, UI, push handling, foreground services, audio routing, and recording. Right when you have 1–2 strong native Android engineers and chat/calling is core. Our WebRTC-on-Android primer is here. One catch in 2026: Google publishes no current prebuilt Android library. The old org.webrtc:google-webrtc artifact is on neither Maven Central nor Google’s Maven repository (checked October 2026), so you either compile libwebrtc yourself or use a maintained build such as io.github.webrtc-sdk, which shipped M150 in October 2026 and is the build LiveKit’s own Android SDK depends on.

LiveKit Android SDK — the multi-party fast lane

High-level wrapper that gives you rooms, multi-party, and an SFU. Great docs, growing ecosystem, sane defaults. Cloud-hosted or self-hosted; our LiveKit development team ships both. Reach for it when you want to ship in weeks rather than months and you’re comfortable with usage-based pricing or running an SFU. Pair with our LiveKit voice-agent build guide if you’re layering AI on top. The current release is livekit-android 2.29.2 (26 October 2026). LiveKit Cloud’s free Build plan includes 5,000 WebRTC minutes a month; Ship starts at $50 a month with 150,000 minutes and $0.0005 per extra minute (LiveKit pricing page, October 2026). The server is Apache 2.0, so self-hosting costs only your infrastructure.

mediasoup-client-android

Lower-level than LiveKit but more control over media; pairs with a self-hosted mediasoup SFU. Strong fit when you need fine-grained bandwidth adaptation, custom layouts, or tight cost control on dedicated infrastructure.

SaaS calling (Twilio, Agora, Sendbird Calls) — the procurement-friendly path

Fully managed. Twilio leads on regulated workloads (HIPAA, SOC 2). One thing worth knowing: Twilio announced a December 2026 sunset for Programmable Video in 2024, then reversed it that October, so Twilio Video is a supported product again: the Android SDK ships as com.twilio:video-android 7.10.4 (April 2026), and Group Rooms list at $0.004 per participant-minute (Twilio pricing, August 2026). Agora leads on low-latency interactive video at scale. Since 29 August 2025 it bills new accounts in standard minutes: HD video lists at $3.99 per 1,000 minutes and Full HD at $8.99, and the free plan’s 10,000 standard minutes a month equal 2,500 HD minutes, because each HD minute counts as four (Agora pricing docs, 2026). Sendbird Calls leads when you also need their chat; it is still maintained, with Android SDK 1.12.5 released on 23 September 2026. Trade time-to-launch for per-minute cost and lock-in. Agora alternatives covered separately.

Comparison matrix — SDKs at a glance

List prices from the vendors’ own pricing pages, checked 28 October 2026. Contract and volume pricing differ; none of these include your TURN or engineering cost.

Audio — the deceptively hard layer

Audio is where calling apps lose stars. Set the AudioManager to MODE_IN_COMMUNICATION and request audio focus with USAGE_VOICE_COMMUNICATION. Skip this and you get echo, low volume and Bluetooth-routing chaos. Use AAudio in low-latency mode on Android 8.1+. Wrap the WebRTC AudioDeviceModule with AcousticEchoCanceler, NoiseSuppressor and AutomaticGainControl effects, falling back to software echo cancellation when hardware AEC isn’t available. Watch AudioDeviceCallback for device changes; don’t poll.

Bluetooth is the trap. SCO/HFP connection lifecycles vary by OEM and headset; route changes mid-call (user pulls headset out, car Bluetooth connects) need a deterministic state machine and a clean speaker fallback. Test with at least four devices — AirPods (yes, on Android), Samsung Buds, a generic car system, and an enterprise headset.

Push delivery — the most common production failure

FCM high-priority data messages are the right primary channel for incoming calls, but they are best-effort. OEMs aggressively kill apps to save battery, and the only reliable mitigation is a layered design.

Layer 1 — FCM data, not notification. Notification messages are drawn by the system tray and need the POST_NOTIFICATIONS permission on Android 13+; a high-priority data message wakes your own code, so you can register the call and raise the CallStyle UI yourself.

Layer 2 — foreground-service-on-receipt pattern. The FCM listener immediately starts the foreground service, raises a CallStyle notification with full-screen intent, and acquires a brief partial wake lock to ensure the device wakes.

Layer 3 — OEM allowlist guidance. First-launch flow that detects Samsung / Xiaomi / Oppo / Vivo and walks the user through battery allowlisting. Without this step, a non-trivial share of users will miss calls regardless of how clean your code is.

Layer 4 — WebSocket fallback. While the app process is allowed to live, keep a signalling WebSocket open with sane keep-alives; route incoming calls through it when present. Don’t rely on it for cold-start delivery.

Figure 3. Each layer catches a different failure mode. Ship all four and the call rings even on a locked-down Xiaomi.

Permissions you actually need to ask for

Request the dangerous ones at runtime, declare the rest in the manifest, and explain each one before the system prompt fires — conversion drops sharply if the prompt is the user’s first encounter.

Core (runtime). RECORD_AUDIO, CAMERA, POST_NOTIFICATIONS (13+).

Telecom & UI. MANAGE_OWN_CALLS (for Core-Telecom / ConnectionService), USE_FULL_SCREEN_INTENT. On Android 14+ full-screen intent is a special app access, and since 22 January 2025 Google Play keeps it on by default only for apps whose core function is calls or alarms — declare that on the Play Console App content page or the incoming-call screen won’t appear on a locked phone.

Foreground services (manifest, Android 14+). FOREGROUND_SERVICE, FOREGROUND_SERVICE_PHONE_CALL, FOREGROUND_SERVICE_MICROPHONE, FOREGROUND_SERVICE_CAMERA. Google Play also asks you to declare each type in Play Console with a demo video; for phoneCall the use case is “Calling: Cellular/VoIP/Telecom APIs”.

Bluetooth. BLUETOOTH_CONNECT (12+).

Optional. READ_PHONE_NUMBERS (display caller-ID), ACCESS_NETWORK_STATE (connectivity awareness).

Security & compliance — the buyer-side checklist

Calls go encrypted or they don’t ship. DTLS-SRTP for transport (handled by WebRTC), TLS 1.3 for signalling, AES-256 at rest for any recording, BAAs for HIPAA-eligible storage. For premium tiers, layer end-to-end encryption with WebRTC Insertable Streams — the keys never leave the device. Our WebRTC security primer covers the full picture.

Recording demands explicit consent banners shown to every participant before capture begins, plus retention policies that satisfy GDPR and the relevant US state two-party-consent laws. More on the NFR framing here.

KPIs that prove the calling app is healthy

Reliability KPIs. Call setup time p95 (target <1 s); call drop rate (target <0.5%); ICE-reconnect success on network change (target >95%); foreground-service uptime per call (target >99.9%).

Quality KPIs. MOS (target >4.0); time-to-first-frame video p95 (target <2 s); one-way audio latency p95 (target <200 ms in-region); jitter buffer underruns per minute.

Adoption & trust KPIs. Inbound-call answer rate; permission-grant rate (RECORD_AUDIO and CAMERA); battery drain per 30-min call (mAh); store rating regression on Android 14 vs 13 cohorts.

Five pitfalls that kill Android calling apps

1. Foreground service crashes on Android 14+. Missing foregroundServiceType or the matching permission throws ForegroundServiceStartNotAllowedException. CI must fail any build that omits these manifest entries.

2. Push delivery you don’t test on real OEMs. Pixel works. Samsung doesn’t. Test on at least Samsung, Xiaomi, Oppo, Vivo and a Pixel before launch. Add the OEM allowlist guidance flow.

3. Bluetooth audio routing left to chance. Headset disconnect mid-call without a clean fallback → silent dead air for the user. Build the state machine, don’t rely on framework defaults.

4. Battery drain in standby. Holding wake locks “just in case” or polling on a timer drains battery and gets you blocked by the OS. Use partial wake locks only on the critical path; rely on FCM for incoming-call wakes.

5. No telemetry on quality. Without MOS, drop-rate and ICE-reconnect dashboards, you discover problems through one-star reviews. Build dashboards in week one, not after a regression.

Mini case — rebuilding an Android calling app for a telemedicine client

A client of our telemedicine software development practice came to us with a 1.0 Android calling app shipped a year earlier on a now-outdated SDK. Symptoms: incoming calls reliably missed on Samsung, foreground-service crashes appearing in Android 14 crash reports, audio routing broken on car Bluetooth, no MOS or call-drop dashboards. Pass-through rate to a connected doctor was sitting at 71%.

In ten weeks we rebuilt the calling layer on Google WebRTC + LiveKit (HIPAA-eligible self-hosted), added the manifest fixes for Android 14+, layered FCM data + WebSocket fallback + OEM allowlist flow, replaced the audio manager with a deterministic Bluetooth state machine, and shipped MOS / drop-rate / ICE-reconnect dashboards.

Outcome twelve weeks post-relaunch: connected-call rate up to 94%, P0 crash rate cut by 86%, store rating recovered from 3.6 to 4.5 over the next two release cycles. The biggest single contributor was push reliability — the SDK choice mattered far less than the four-layer push design. If your numbers look like the “before” column, grab 30 minutes with us and we’ll tell you which layer is leaking.

Figure 4. Before and after the 10-week rebuild, measured 12 weeks post-relaunch.

A five-question decision framework for Android calling

Q1. Are calls 1:1 or multi-party? 1:1 → raw WebRTC peer-to-peer is fine. Multi-party → you need an SFU (LiveKit, mediasoup, or a SaaS).

Q2. Is the data regulated? HIPAA / GDPR-strict residency → self-hosted LiveKit / mediasoup, or Twilio. Standard B2C → any path.

Q3. Who’s on-call for this in 12 months? Strong Android team → native WebRTC. Smaller team or outsourced → LiveKit or SaaS.

Q4. What’s your unit-economics ceiling per minute? If per-minute SaaS pricing breaks the model, self-host. If your team-cost dwarfs minutes, buy SaaS and ship.

Q5. Are you a default-dialer replacement? If yes, ConnectionService is mandatory. If no, it’s optional — but even niche apps benefit from native call-log integration.

Figure 5. The same five questions as a decision tree — follow the branches to your SDK.

When you should not build calling on Android first

If your audience is heavily iOS, your team has no Android calling experience, and your timeline is short, ship iOS first with a polished CallKit experience, then take the Android lessons (and budget) and build it properly. Half-finished Android calling apps are a leading indicator of one-star app-store reviews and burned engineering budgets.

Likewise, if you only need a chat-style voice note feature, don’t build a full calling stack. Use existing recording APIs and async audio messages.

FAQ

What is the best video call SDK for Android?

For most new apps in 2026, the LiveKit Android SDK: open source, Kotlin-first, multi-party out of the box, and runnable on LiveKit Cloud or your own servers. Choose raw WebRTC for strictly 1:1 calls with a strong native team, and Twilio Video or Agora when you want a managed service billed per minute.

Is there a free video calling SDK for Android?

Yes. Google’s WebRTC (BSD), LiveKit (Apache 2.0 server and SDK) and mediasoup (ISC) cost nothing to use; you pay only for your servers and TURN bandwidth. Hosted free tiers exist too: as of October 2026, LiveKit Cloud includes 5,000 WebRTC minutes a month and Agora 10,000 standard minutes, which is 2,500 HD video minutes.

How do I add video calling to an existing Android app?

Add the SDK’s Gradle dependency, mint access tokens on your backend, request mic, camera and notification permissions, register each call through Jetpack Core-Telecom with a phoneCall foreground service, then join the room and render remote video. Incoming calls arrive as FCM high-priority data messages. A 1:1 integration on LiveKit or Twilio takes days; production-grade push, Bluetooth and OEM handling takes weeks.

Should I integrate ConnectionService for my calling app?

If your app is a default-phone-replacement or a serious VoIP product, yes — and in 2026 do it through Jetpack Core-Telecom (androidx.core:core-telecom), which wraps ConnectionService in a simpler CallsManager API. It gives you native call-log integration, do-not-disturb respect, and consistent UX with the dialer. For niche in-app conferencing or one-off video calls inside another product, it’s optional. The implementation cost is real (a few weeks), so balance against the UX win.

Is raw WebRTC enough or do I need an SDK like LiveKit?

Raw WebRTC handles the media plane. You still build signalling, UI, push handling, foreground services, audio routing and recording yourself. LiveKit (or Twilio / Agora / mediasoup) abstracts a lot of that, especially for multi-party calls. For 1:1 calling with a small experienced team, raw WebRTC is fine. For multi-party or fast launch, an SDK saves months.

How do I handle incoming calls when the app is killed?

Send an FCM high-priority data message. The FCM listener wakes the foreground service, which raises a CallStyle notification with full-screen intent and starts ringing. Add a partial wake lock for the brief moment between FCM receipt and notification display. Layer a WebSocket fallback while the app process is alive, and add OEM allowlist guidance for users on aggressive Samsung/Xiaomi/Oppo/Vivo devices.

What changed for foreground services in Android 14?

Foreground services now require both a manifest foregroundServiceType declaration and the matching FOREGROUND_SERVICE_* permission. For calling apps that’s usually microphone|camera. Skipping either causes ForegroundServiceStartNotAllowedException at runtime, which surfaces as crashes during call setup. Wire CI to fail any build missing these.

How much does a TURN server cost and can I avoid one?

TURN bandwidth is typically the most expensive line item per call — it’s relayed via your server, not direct peer-to-peer. The relayed share depends on your users’ networks: corporate firewalls and some mobile carriers push it up. Measure it from candidate-pair stats in the first week of beta and price TURN from that number. You can’t avoid TURN entirely without dropping the calls behind symmetric NAT. Optimise by preferring direct candidates (mDNS, IPv6) when available.

How do I handle a 4G ↔ Wi-Fi network change mid-call?

Listen on ConnectivityManager.NetworkCallback. On any change, gather fresh ICE candidates and trigger an ICE restart on the PeerConnection (renegotiation with new candidates). Clients should keep the call alive for at least 5–8 seconds across the transition; if no new media arrives by then, drop and reconnect cleanly with a user-visible toast.

Do I need end-to-end encryption (E2EE)?

DTLS-SRTP encrypts media in transit between clients and the SFU. True end-to-end encryption (where even the server can’t decrypt) needs WebRTC Insertable Streams or a similar approach. It’s required for regulated or sensitive workloads (legal, healthcare, defence) and a strong differentiator for consumer privacy positioning. Plan for 4–6 weeks of additional engineering.

Can I support Android Auto and Wear OS for calls?

Yes, but only with ConnectionService integration as the foundation. Android Auto routes calls through Telecom; Wear OS apps use the standard Telecom + companion patterns. Plan extra engineering for both surfaces. For most apps, ship Android phone first, expand to Auto/Wear in a second wave.

What to Read Next

Ready to ship an Android calling app that doesn’t miss calls?

An Android calling app in 2026 is a four-plane system — signalling, media, push, foreground service — engineered against OEM background killers, foreground-service rules, and Bluetooth audio routing that breaks in five different ways. Get the twelve features right, ship telemetry from day one, and pick the SDK that matches your team rather than the one that won the marketing page.

Most calling apps that fail in production fail on Android-specific surfaces, not on WebRTC itself. The good news: every one of those surfaces is solvable, and the playbook above is the one we’d follow on a fresh project tomorrow.