How to Test Video Calls on Android (Complete Guide)

Video calling is no longer a niche feature; it is a core interaction for telehealth, remote work, education, and social apps. On Android the complexity multiplies because the platform exposes a hetero

Why Video Call Testing Demands Special Attention on Android

Video calling is no longer a niche feature; it is a core interaction for telehealth, remote work, education, and social apps. On Android the complexity multiplies because the platform exposes a heterogeneous set of hardware capabilities, permission models, and background‑process behaviors. A defect that survives unit tests can surface as a dropped call, garbled audio, or a privacy leak when a real user experiences fluctuating network conditions, receives an incoming SMS, or switches to battery‑saver mode.

Testing video calls therefore requires a blend of functional verification, media‑path validation, and system‑level stress testing. The following guide walks through a complete methodology: from a concrete test matrix to manual steps, automated scripts, and finally how autonomous, persona‑driven exploration can surface issues that scripted tests never consider.

---

Common Failure Modes Seen in Production

Understanding what typically goes wrong helps prioritize test effort. The table below aggregates failure categories observed across multiple Android video‑call apps in the wild.

Each of these rows informs a specific test case; the next section consolidates them into a usable matrix.

---

Comprehensive Test Matrix

The matrix below organizes test scenarios by dimension (functional, error, edge, accessibility, security) and indicates the recommended verification method. Use it as a checklist when building test suites.

*Tip:* When constructing automated suites, group tests by dimension and run them in parallel on a device farm to keep total execution time manageable.

---

Manual Testing – Step‑by‑Step Walkthrough

Even with automation, a disciplined manual pass catches nuances that scripts gloss over. Follow this procedure on a physical device (or a well‑configured emulator) before committing to CI.

1. Device Preparation

• Enable Developer Options → USB debugging.
• Set adb shell settings put global window_animation_scale 0.0 and similarly for transition and animator scales to eliminate animation noise.
• Clear app data (adb shell pm clear com.example.videocall) to start from a clean state.
• Grant required permissions via adb shell pm grant com.example.videocall android.permission.CAMERA and android.permission.RECORD_AUDIO.

1. Baseline Happy Path

• Launch the app, navigate to the call screen.
• Tap “Start Call” with a second device (or a test user account) ready to accept.
• Observe:
• Both video feeds appear within 2 seconds.
• Audio levels move in sync with speech (use a speaker and watch the waveform in the UI if available).
• No overlay or toast appears indicating permission issues.
• End the call from either side and verify that the UI returns to the idle state, camera preview stops, and microphone icon disappears.

1. Permission Flow

• Revoke camera permission (adb shell pm revoke com.example.videocall android.permission.CAMERA).
• Attempt to start a call.
• Verify that a rationale dialog appears, the call button stays disabled, and the app does not crash.
• Re‑grant permission and repeat the happy path to confirm recovery.

1. Audio Focus Ducking Test

• Start a music player (e.g., YouTube) and begin playback.
• Initiate the video call.
• Confirm that the music volume lowers (or pauses) as per the app’s audio focus request.
• End the call and ensure music resumes at its original level.

1. Network Stress

• Connect the device to a Wi‑Fi network routed through a Linux box running tc.
• Apply tc qdisc add dev wlan0 root netem delay 200ms 50ms distribution normal loss 2%.
• Place a call and note any freezing, pixelation, or audio dropouts.
• Remove the netem rule and verify the call recovers without manual intervention.

1. Interrupt Handling

• While in a call, trigger an incoming voice call (using a second SIM or a VoIP app).
• Accept the voice call; the video call should pause, releasing camera/mic.
• End the voice call and verify the video call resumes with both streams restored.
• Repeat with an incoming SMS notification that heads‑up displays; ensure the video UI does not get obscured.

1. Orientation & Multi‑Window

• Start a call in portrait.
• Rotate to landscape; verify that video feeds rotate correctly and UI elements remain accessible.
• Drag the app into split‑screen mode with another app (e.g., Chrome).
• Confirm that the video continues, the preview does not stretch, and touch targets remain usable.
• Exit multi‑window and return to full screen; ensure no UI corruption.

1. Picture‑in‑Picture

• With an active call, press Home.
• Confirm the video shrinks to a PiP window that remains interactive (tap to expand).
• Drag the PiP window to different screen corners; ensure it does not get stuck under the system bar.
• Return to the app via the PiP window; verify full‑screen call restores correctly.

1. Accessibility Check

• Enable TalkBack.
• Navigate through the call screen using swipe gestures.
• Listen for descriptive labels on each button (e.g., “Mute microphone, toggle”).
• Change font size to largest and verify that no text is clipped and touch targets stay ≥ 48 dp.

1. Security & Privacy Spot‑Check

• Attempt a screenshot while in a call; verify the result is black (indicating FLAG_SECURE).
• Start a packet capture (adb shell tcpdump -i wlan0 -s 0 -w /sdcard/call.pcap) and place a brief call.
• Inspect the capture with Wireshark; confirm that signaling traffic uses TLS and that no raw audio/video payloads are visible (they should be encrypted via SRTP).
• Reboot the device, relaunch the app, and confirm that previously granted permissions are still present without a re‑prompt.

If any step fails, log the exact device model, Android version, and the precise state (e.g., network condition, battery level). This information is invaluable for reproducing the issue later in an automated test or bug report.

---

Automated Approaches – Tooling and Sample Code

1. UI‑Level Testing with Espresso + Idling Resources

Espresso excels at verifying UI state and synchronizing with asynchronous operations (signaling, media preparation). The following snippet demonstrates a happy‑path test that waits for the remote video surface to appear.

@RunWith(AndroidJUnit4::class)
class VideoCallTest {

    private lateinit var activityScenario: ActivityScenario<MainActivity>

    @Before
    fun setUp() {
        activityScenario = ActivityScenario.launch(MainActivity::class.java)
        // Grant permissions programmatically for the test
        ShellUtils.grantPermission(
            InstrumentationRegistry.getInstrumentation().targetContext,
            Manifest.permission.CAMERA,
            Manifest.permission.RECORD_AUDIO
        )
    }

    @Test
    fun happyPathCallEstablishesVideo() {
        // Tap start call button
        onView(withId(R.id.btn_start_call)).perform(click())

        // Idling resource that waits until signaling reports CALL_CONNECTED
        val callConnectedIdling = object : IdlingResource {
            override fun getName() = "CallConnectedIdling"
            private var callback: IdlingResource.ResourceCallback? = null
            override fun isIdleNow(): Boolean {
                val isConnected = CallManager.getInstance().isConnected()
                if (isConnected) callback?.onTransitionToIdle()
                return isConnected
            }
            override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback) {
                this.callback = callback
            }
        }
        IdlingRegistry.getInstance().register(callConnectedIdling)

        // Wait for remote SurfaceView to appear (indicating video decode)
        onView(withId(R.id.remote_surface))
            .check(matches(isDisplayed()))
            .check(matches(withEffectiveVisibility(View.VISIBLE)))

        // End call and verify cleanup
        onView(withId(R.id.btn_end_call)).perform(click())
        onView(withId(R.id.btn_start_call)).check(matches(isDisplayed()))
        IdlingRegistry.getInstance().unregister(callConnectedIdling)
    }
}

Key points

• Use a custom IdlingResource that polls the signaling layer for connection state.
• Verify both local and remote SurfaceView visibility; you can also capture a frame via MediaProjection and compare against a known bitmap to ensure decoding succeeded.
• After the call ends, assert that UI elements return to their idle state and that no stray SurfaceView remains leaked (you can check Activity.getWindow().getDecorView().findViewsWithText for leftover views).

2. Media Path Validation with Camera2 Test Source

To confirm that the app actually sends frames from the camera (and not a static image), replace the physical camera with a test source that generates a moving pattern. The Android CTS provides android.hardware.camera2.test which can be used via adb shell am instrument.

# Install the camera test source APK (part of platform-tools)
adb install -r /path/to/CameraTestSource.apk

# Grant the test app permission to use the test source
adb shell appops set com.example.videocall CAMERA ignore

# Launch the test source service (it creates a virtual camera)
adb shell am startservice -n com.android.camera2.testsource/.CameraTestSourceService

# Run your Espresso test; the virtual camera will feed a rotating color bar pattern

In your test, after confirming the remote surface is visible, grab a frame using ImageReader attached to the local preview Surface. Compute the average hue; if it matches the expected pattern (e.g., rotating through red‑green‑blue), you know the camera pipeline is active.

3. Audio Path Verification with AudioRecord and Playback

A simple way to ensure audio is being captured and rendered is to record a short snippet from the microphone, play it back through the speaker, and compare the waveform to a known test tone.

private fun captureAndValidateAudio(durationMs: Long = 2000): Boolean {
    val sampleRate = 44100
    val bufferSize = AudioRecord.getMinBufferSize(sampleRate,
        AudioFormat.CHANNEL_IN_MONO,
        AudioFormat.ENCODING_PCM_16BIT)
    val recorder = AudioRecord(
        MediaRecorder.AudioSource.MIC,
        sampleRate,
        AudioFormat.CHANNEL_IN_MONO,
        AudioFormat.ENCODING_PCM_16BIT,
        bufferSize
    )
    recorder.startRecording()
    val samples = ShortArray(bufferSize / 2)
    val start = SystemClock.uptimeMillis()
    val collected = mutableListOf<Short>()
    while (SystemClock.uptimeMillis() - start < durationMs) {
        val read = recorder.read(samples, 0, samples.size)
        if (read > 0) collected.addAll(samples.copyOfRange(0, read))
    }
    recorder.stop()
    recorder.release()

    // Simple energy test: ensure RMS > threshold (indicates non‑silence)
    val sum = collected.map { it.toDouble() * it }.sum()
    val rms = Math.sqrt(sum / collected.size)
    return rms > 100.0   // empirical threshold; adjust per device
}

Call this function before and after the call starts; a significant increase in RMS confirms the mic is live. For the speaker path, you can use AudioTrack to play a known tone and verify with the same recorder on a second device or using a loopback cable.

4. Network Condition Simulation

While tc works on rooted devices or emulators with elevated privileges, you can also use the Android NetworkCapabilities API to inject latency and loss via TrafficShaper (API 29+). Example:

val trafficShader = ConnectivityManager.getTrafficShaper()
val config = TrafficShaper.Config.Builder()
    .setDelayMs(300)
    .setLossPercentage(2)
    .build()
trafficShader.apply(config)

Wrap this in a @Before/@After JUnit rule to apply the condition only for the duration of a test.

5. Cross‑Device Synchronization with UiAutomator

For true two‑party validation, launch the same test on a second device and coordinate via a socket or ADB forwarding. A minimal example:

Device A (caller)

adb -A forward tcp:5555 tcp:5555
adb -A shell am instrument -w -e action start_call -e peer_port 5555 com.example.test/androidx.test.runner.AndroidJUnitRunner

Device B (callee)

adb -B forward tcp:5555 tcp:5555
adb -B shell am instrument -w -e action accept_call -e peer_port 5555 com.example.test/androidx.test.runner.AndroidJUnitRunner

Each test side opens a socket on the forwarded port, exchanges a simple JSON signal ({type: "offer"} or {type: "answer"}), and then proceeds with the UI steps. This approach eliminates reliance on a real signaling server for UI verification while still exercising the full client‑side call flow.

6. Automated Accessibility Scanning

Integrate the androidx.test.espresso.accessibility library:

@Test
fun accessibilityCheck() {
    AccessibilityChecks.enable()
    onView(withId(R.id.call_screen)).check(matches(isDisplayed()))
}

This will run a series of heuristics (touch target size, contrast, content descriptions) and fail the test if any violation is found, giving you immediate feedback in CI.

---

Autonomous, Persona‑Driven Exploration – Where Scripts Miss Bugs

Traditional automated tests follow predetermined paths; they excel at regressions but often ignore the myriad ways real users interact with an app. Autonomous exploration platforms (e.g., SUSA) simulate distinct personas—each with its own behavior model—to stress the application in ways a script writer might not anticipate.

How Personas Work

Each persona is driven by a stochastic state machine that decides the next action based on the current UI hierarchy, sensor readings (battery, network), and a configurable “aggressiveness” factor. The engine records every visited screen, every action taken, and any anomaly (crash, ANR, unhandled exception, permission denial, accessibility violation).

Why This Finds Issues Scripts Overlook

1. Permission Race Conditions – A script may grant permissions once at startup; an adversarial persona might repeatedly deny and re‑grant the camera permission while a call is in progress, exposing a race where the app tries to reconnect the camera after a denial and crashes.

1. Gesture Conflicts – The curious persona may discover a hidden long‑press on the video preview that triggers a debug overlay; if the overlay incorrectly captures touch events, the call controls become unresponsive—a scenario rarely captured in a linear test script.

1. Multitasking Interference – A power‑user persona often puts the app in split‑screen while simultaneously launching a CPU‑heavy game. The resulting thermal throttling can cause the video encoder to drop frames, leading to noticeable drift that only appears under sustained load.

1. Network Fluctuation Patterns – Rather than a fixed latency, the adversarial persona can enable airplane mode for 200 ms, disable it, then repeat, simulating a flaky Wi‑Fi hand‑off. This can reveal bugs in ICE restart logic where the app fails to renew candidates.

1. Accessibility Overlaps – When TalkBack is enabled, some custom views lose their contentDescription after a configuration change. An accessibility‑focused persona that repeatedly rotates the device while the screen reader is active will catch this regression, whereas a script that tests rotation only once may miss it.

1. Battery‑Saver Induced Frame Drops – The battery‑saver conscious persona will trigger Power Save mid‑call, causing the system to lower the CPU frequency. If the app does not adapt its encoder bitrate, the video may become blocky. Scripts that keep the device plugged in will not see this.

Integrating Persona Exploration into Your Workflow

• Run a baseline persona suite nightly on a device farm (e.g., Firebase Test Lab) to collect a set of discovered anomalies.
• Triangulate findings: any crash or ANR flagged by the persona run should be added as a unit test or Espresso test to prevent regression.
• Feed the discovered flows back into SUSA’s learning engine: the platform remembers which screens lead to dead ends (e.g., a settings page that never returns to the call UI) and prioritizes them in subsequent runs, increasing efficiency over time.
• Combine with manual spot checks: after a persona run highlights a suspicious area (e.g., “camera permission denied during call”), perform a focused manual test to validate the user impact and gather logs for debugging.

While SUSA is one implementation of this idea, the core principle—varying user behavior models to expose hidden interaction bugs—can be adopted with open‑source tools like adb monkey combined with custom scripts, or with frameworks such as AndroidX Test’s ActivityScenario combined with random decision generators.

---

Edge Cases That Surface Only in Production

Even the most exhaustive test matrix can miss conditions that arise from the real‑world device ecosystem. Below is a curated list of production‑only triggers, why they matter, and how you can approximate them in a lab.

To capture these, augment your test matrix with environmental variation steps: toggle a setting, plug/unplug a peripheral, or inject a system broadcast before or during the call. Automate the toggles via adb shell commands within a @Rule that resets the state after each test.

---

Concise Checklist for Engineers

Run this checklist on a representative matrix of devices (different SoCs, Android versions, OEM skins) before marking a feature as release‑