Android 14 opened a new path for developers working with Jetpack Compose and raw Surface objects. The AndroidExternalSurface wrapper gives your code a direct route to hardware overlay planes in SurfaceFlinger, skipping the GL composition step entirely. For apps that can use this path, the performance gains are real and measurable.
What Changed and Why It Matters
If you've worked with camera previews or video playback in Android, you've likely encountered TextureView. It connects through SurfaceTexture, which means every frame goes through the GLES texture pipeline. This works reliably across many SDKs, but it adds overhead.
AndroidExternalSurface and SurfaceView work differently. Both expose raw Surface objects that connect directly through BufferQueue to SurfaceFlinger. No GL intermediary in your app process. One GPU pass instead of two.
The critical point: your SDK determines which path you can use. If your SDK requires SurfaceTexture, AndroidExternalSurface is simply unavailable to you. This isn't a configuration choice in your Compose code. It's a fundamental compatibility question about what your rendering pipeline can accept.
At a glance:
- AndroidExternalSurface is the modern Compose wrapper for SurfaceView on Android 14+
- It routes directly to SurfaceFlinger's hardware coverage planes
- TextureView uses the GLES texture path through SurfaceTexture
- These are different surface types—SDK support drives the decision
- Performance roughly doubles for compatible SDKs
The Numbers Behind the Change
A concrete comparison shows the difference clearly. At 880×1320 resolution running at 60fps:
TextureView processes approximately 139 million pixels per second through its fixed-size GLES path. AndroidExternalSurface handles the same workload at roughly 69.7 million pixels per second. That's a 50% reduction in pixel processing cost, plus you gain a dedicated hardware coverage level that your compositor would otherwise manage.
For automotive applications or any battery-sensitive use case, these savings compound over time. The GPU isn't just processing fewer pixels—it's doing so without the memory copies and format conversions that GLES requires.
Our Analysis
This matters most for developers building apps that process video or camera streams within Compose. The automotive sector has embraced this path heavily, which explains why the documentation frames examples around vehicle displays. But the underlying optimization applies anywhere you need efficient in-app video rendering.
Who benefits most? Teams with SDKs that already output raw Surface objects. If you're integrating a camera library, video codec, or remote display SDK that accepts Surface input, you can immediately reduce your GPU footprint by switching from TextureView to AndroidExternalSurface.
Who doesn't benefit yet? Developers locked into SDKs that only understand SurfaceTexture. Some Unreal Engine configurations fall into this category. For these teams, the optimization is unavailable regardless of how they structure their Compose code. The right move is pushing SDK vendors to add raw Surface support.
The broader pattern here reflects a shift in Android graphics architecture. Google continues investing in direct hardware paths that bypass the traditional GL compositor. AndroidExternalSurface is one piece of that larger direction.
Say you're building a vehicle infotainment app with multiple camera feeds. Your camera SDK supports raw Surface input. Currently using TextureView inside Compose to display feeds. By migrating to AndroidExternalSurface, each feed drops from 139M to 69.7M pixels/sec processing. With three camera views on screen simultaneously, you've reclaimed enough GPU capacity to render your UI smoothly without frame drops.
The migration isn't trivial if your code assumes TextureView behavior, but the performance trade-off often justifies the effort for graphics-heavy applications.
What to Watch Next
The immediate next step is checking whether your current SDK dependencies support raw Surface input. SDK vendors are actively adding this support as automotive and industrial use cases grow. Watch release notes from your key library providers over the next several months.
If you're starting a new project with video or camera requirements, prioritize SDKs that offer raw Surface output. You'll have access to the more efficient rendering path by default.
Key takeaways
- AndroidExternalSurface requires SDK support for raw Surface, not SurfaceTexture
- Hardware overlay eliminates GL composition overhead entirely
- Performance roughly doubles compared to TextureView for compatible SDKs
- SDK compatibility—not Compose configuration—determines which path you can use
- Automotive and video-heavy apps see the most immediate benefit
Frequently asked questions
Can I use AndroidExternalSurface with any camera SDK?
Only if your SDK accepts raw Surface input. Some require SurfaceTexture and cannot use this path, regardless of your Compose configuration.
What's the main performance benefit of this approach?
A single GPU pass instead of two, plus direct access to a hardware coverage plane. This roughly halves pixel processing costs for the affected rendering path.
Does AndroidExternalSurface work outside Compose applications?
Yes. The wrapper is specifically for Compose, but SurfaceView itself has always used the direct Surface path. Non-Compose apps get the same efficiency by avoiding TextureView.
How do I determine which surface type my SDK requires?
Check your SDK documentation for Surface versus SurfaceTexture requirements, or contact the vendor directly to confirm which input types they support.
Is TextureView now obsolete?
Not entirely. Many SDKs still only support SurfaceTexture. TextureView remains the correct choice when you're locked into those dependencies.