Android Media3 1.11.1 Released: Important ExoPlayer Fixes for Streaming Apps

Google has released AndroidX Media3 1.11.1, a maintenance update containing several important fixes for applications using ExoPlayer for video and audio playback.

Released on September 10, 2026, Media3 1.11.1 is currently Google’s stable Media3 release. Rather than introducing a large collection of brand-new user-facing APIs, this update concentrates on reliability: playback stalls, renderer prewarming, live timelines containing server-side inserted advertisements, stale frames during scrubbing, Matroska seeking, HLS loading, DASH image tracks, and native decoder stability are all addressed.

That makes the release particularly relevant to streaming applications. A viewer may never know whether an app uses ExoPlayer, but playback problems such as freezing after a seek, a stale frame appearing during scrubbing, or a live stream crashing around an ad transition directly affect the perceived quality of the application.

For Android TV, Google TV, phones, tablets, and other Android-based media experiences built with Media3, version 1.11.1 is therefore less about visible features and more about making playback behave more predictably.

Jetpack Media3 is Google’s recommended set of Android libraries for building audio and video experiences.

It includes ExoPlayer, Google’s extensible implementation of the Media3 Player interface. ExoPlayer handles core playback functionality while supporting components for buffering, rendering, streaming formats, tracks, and other advanced media requirements. Google recommends Media3 for new Android media applications rather than the older platform MediaPlayer API.

Media3 can also be used with dedicated modules for technologies such as DASH and HLS.

For developers starting a project today, Google’s current documentation shows Media3 dependencies at version 1.11.1, including media3-exoplayer and Media3 UI modules.

Because ExoPlayer operates underneath the application interface, Media3 updates can influence some of the most important parts of a streaming product: startup, seeking, adaptive playback, live streams, advertisements, subtitles, decoding, and output rendering.

Android Media3 1.11.1 Changes at a Glance

These fixes come directly from Google’s official Media3 1.11.1 release notes. 

ExoPlayer Playback Stall Fix Is One of the Most Important Changes

One of the most important fixes in Media3 1.11.1 addresses a playback stall caused while prewarming a secondary renderer that was not transitioning.

Renderer prewarming is an optimization intended to help ExoPlayer prepare playback resources before they are needed. This can help reduce disruption when the player moves between media or rendering states.

But optimization logic becomes problematic if the player ends up waiting on a renderer that is not actually going to become active.

Google says 1.11.1 corrects such a case. For viewers, the technical details are irrelevant. The visible symptom is what matters: video can stop progressing when it should continue.

That makes this fix particularly important for developers evaluating playback problems that appeared only under specific transitions or timing conditions.

Surface Handling After Seeking Has Also Been Fixed

Media3 1.11.1 contains another prewarming fix involving Android’s video surface.

Google says a Surface is now correctly returned to the primary renderer when a seek operation resets playback and disables both renderers.

The surface is essentially where decoded video is rendered for display.

When applications use more advanced renderer management, ensuring that the correct renderer owns the surface at the correct time is essential.

Problems in this area can produce symptoms such as missing video, delayed frames, or transitions where audio continues but the expected picture does not immediately return.

The fix is highly technical, but it reinforces a major theme in 1.11.1: making newer renderer-prewarming behavior more robust under real playback conditions.

Live Streaming With Server-Side Ads Gets an Important Crash Fix

Media3 1.11.1 also addresses an issue especially relevant to live streaming applications using server-side ad insertion.

Google fixed an issue ArrayIndexOutOfBoundsException that could occur when a live timeline refresh moved the default playback position beyond a server-side inserted ad that was currently playing.

Live timelines are constantly changing.

Unlike an on-demand movie with a fixed beginning and end, a live stream moves forward while the application is running. The player may refresh the available timeline as older content disappears and new segments become available.

When advertisements are inserted into that changing timeline, additional timing complexity is introduced.

The Media3 bug could produce an invalid index under a particular sequence involving a timeline refresh and an active ad.

For developers running monetized live streams, this is exactly the kind of edge case that can be difficult to reproduce consistently but serious when it happens.

Scrubbing Should No Longer Briefly Show Stale Frames

Seeking and scrubbing also receive a visual fix.

Media3 provides ScrubbingModeParameters that developers can use to control player behavior while a user rapidly moves around the timeline.

Google says version 1.11.1 fixes a case where a stale video frame could briefly appear during seeking when it allowSkippingMediaCodecFlush was enabled.

A stale frame might only be visible for a moment, but that moment can make a polished video interface feel less responsive.

Imagine dragging a progress bar toward a later scene and briefly seeing an image from the previous playback position before the correct frame appears.

That is the sort of issue users notice even though they may not know what caused it.

For streaming applications with rich seek interfaces, thumbnails, or frequent user scrubbing, the fix should help provide cleaner visual transitions.

Matroska Seeking Gets Fixed

Media3 1.11.1 includes a meaningful improvement for Matroska containers, commonly associated with .mkv files.

Google says files where the Tracks element appears after media clusters could fail to produce a seekable timeline. That issue is now fixed.

Matroska is a flexible container, and not every file is structured in exactly the same order.

A player therefore needs to handle valid variations rather than assuming important metadata will always appear before media data.

For users, an incorrect timeline can mean that a video plays but seeking does not behave properly.

For developers building applications that support user libraries or diverse media files, broader container robustness can be as important as support for another codec.

HLS Chunk Loading Gets More Predictable

HLS receives a smaller but useful reliability fix. Google fixed a situation where a fully consumed HlsMediaChunk could retry loading after the extractor received an EOFException.

A chunk that has already been completely consumed should not need to be loaded again simply because the extractor reached the end of the available data.

Unnecessary retry behavior can waste requests and make debugging network playback more complicated. The change is particularly relevant because HLS remains widely used for adaptive video streaming.

Media3’s HLS implementation supports regular live playback, low-latency Apple HLS, and adaptive selection between variants based on bandwidth and device capabilities.

So even a relatively narrow chunk-loading fix can affect a large category of Android streaming applications.

DASH Image-Track Timing Is Corrected

DASH applications receive a fix as well.

Media3 1.11.1 corrects sample timestamp calculations for image tracks containing a presentationTimeOffset.

Image tracks can be used for functionality such as timeline imagery and preview-related experiences.

If timestamps are calculated incorrectly, an image associated with one point in the media timeline could be presented as though it belongs somewhere else.

That can create subtle synchronization issues.

For developers building sophisticated seek experiences, correct timing of auxiliary tracks is essential because users expect timeline previews to accurately match the position they are selecting.

Opus Decoder Gets a Memory-Corruption Fix

Some of the most serious fixes in Media3 1.11.1 are in native decoder extensions.

Google fixed memory corruption that could occur when multiple OpusDecoder instances were initialized concurrently.

Opus is a widely used audio codec, particularly in web-oriented and real-time media environments.

Memory corruption is more serious than a visual glitch because it can lead to unpredictable behavior or application crashes.

The issue required concurrent initialization of multiple decoder instances, meaning not every application would encounter it.

But applications that create several player instances, rapidly replace players, or manage multiple concurrent media sessions could be more exposed to such edge conditions.

MPEG-H Receives Multiple Stability Improvements

The MPEG-H decoder extension receives several fixes in the same release.

Google says Media3 1.11.1 fixes a memory leak, truncation of non-ASCII characters, and a potential native crash under low-memory conditions when sending commands to MpeghUiManager.

The low-memory crash is particularly relevant to TV devices.

Connected-TV hardware can operate with considerably tighter memory constraints than flagship smartphones.

A playback stack therefore needs to behave reliably even when available memory is limited.

This is another example of why point releases can be important for television applications even when there is no major new feature to advertise.

HAGC Metadata Configuration Has Changed

Media3 1.11.1 also makes an API-level adjustment involving HAGC metadata for progressive media.

The configuration flag has moved from MediaSource.Factory to ExtractorsFactory.

Google removed the previous setExperimentalEnableHagcPlayback method and replaced the functionality with ExtractorsFactory.setParseHagcMetadata. The change also fixes an issue where disabling the behavior did not work correctly for Matroska/WebM containers.

Developers who were already using the experimental method should review their code before upgrading.

This is one of the few areas in 1.11.1 that may require an actual code change rather than simply benefiting from an internal fix.

How Media3 1.11.1 Builds on Media3 1.11.0

Media3 1.11.1 is a patch release on top of the larger 1.11.0 update from August 5, 2026.

Version 1.11.0 introduced broader changes, including stuck-player detection, default wake-lock handling, and improvements around track types and player behavior.

The new 1.11.1 release is more focused. Instead of expanding the player architecture significantly, it fixes problems discovered around real playback workflows introduced or exposed in the current release family. This is normal for a mature playback SDK.

Large releases expand functionality; subsequent point releases often provide the stability developers need before deploying that generation widely in production.

Should Streaming App Developers Upgrade?

Developers already using Media3 1.11.x should strongly evaluate 1.11.1, particularly if their applications use advanced seeking, live playback, server-side advertisements, Matroska files, HLS, Opus, or MPEG-H.

Google currently identifies 1.11.1 as the stable Media3 release, and its getting-started documentation uses 1.11.1 in current dependency examples.

That does not mean teams should push the update to production without testing.

Playback SDK upgrades should still be validated against the application’s actual device matrix, media catalog, advertising setup, DRM configuration, audio formats, and network conditions.

Connected-TV applications deserve particular attention because older or lower-memory hardware can reveal issues that are not obvious on modern development phones.

Why Media3 Updates Matter for Android TV and Google TV Apps

Media3 is important because it sits close to the heart of the viewing experience.

The application UI may determine what a user chooses to watch, but the playback engine determines whether that content starts correctly, seeks smoothly, survives live timeline changes, and continues running for hours.

ExoPlayer is also highly customizable and supports multiple streaming technologies without being tied to the Android operating system’s built-in media player implementation.

That makes Media3 release notes particularly valuable for teams maintaining video applications.

A single line such as “fix playback stall” may represent the resolution of a production issue that previously affected only a small percentage of users but generated a disproportionate number of support complaints.

Final Thoughts

Android Media3 1.11.1 is a good example of why smaller playback SDK updates deserve attention. There is no dramatic new interface or headline media format.

Instead, Google has addressed issues that can directly determine whether a streaming experience feels reliable: playback stalls, incorrect Surface ownership after seeking, live ad timeline crashes, stale frames during scrubbing, Matroska seeking, unnecessary HLS retries, and decoder-level memory problems.

For Android streaming teams, these are practical improvements. The update is particularly relevant for applications dealing with live content, complex player transitions, large media libraries, and advanced audio/video formats.

Media3 1.11.1 is now Google’s stable release, making this a good time for development teams to review the changelog, update test builds, and verify playback across their supported Android and connected-TV devices.

FAQs About Android Media3 1.11.1

1) When was Android Media3 1.11.1 released?

Google released Media3 1.11.1 on September 10, 2026. It is currently listed as the stable Media3 release. 

3) Does Media3 1.11.1 improve HLS playback?

It fixes a case where a fully consumed HLS media chunk could retry loading after an extractor EOFException. 

4) Does Media3 1.11.1 fix Matroska seeking?

Yes. Google fixed a Matroska issue where files with tracks located after clusters could fail to expose a seekable timeline. 

5) Are there audio-decoder fixes?

Yes. Opus receives a concurrent decoder memory-corruption fix, while MPEG-H receives fixes for a memory leak, non-ASCII text handling, and a possible native crash under low-memory conditions.

6) Is ExoPlayer still part of Media3?

Yes. ExoPlayer is Media3’s default implementation of the Player interface and remains Google’s feature-rich, extensible playback solution for Android media applications.

7) What version should developers use now?

Google’s current Media3 documentation lists 1.11.1 as the stable release and uses that version in its current dependency examples. 

Stay Updated with the Player SDK Guide Hub

Playback SDKs and streaming platforms change constantly. A small ExoPlayer fix, a new Android Media3 release, a Fire TV SDK update, or a connected-TV platform change can directly affect playback stability and application performance. That’s why we created the Player SDK Guide Hub.

The Player SDK Guide Hub covers the latest Android Media3, ExoPlayer, Fire TV, Google TV, Roku, Apple TV, Plex, Kodi, VLC, and streaming-device developments, including player SDK releases, playback fixes, operating-system updates, developer APIs, codec changes, and connected-TV platform news.

Whether Google releases another Media3 update, ExoPlayer gains new playback capabilities, or a major streaming platform changes its developer requirements, our Guide Hub helps explain what changed, why it matters, which playback workflows are affected, and what development teams should test next.

Explore the Player SDK Guide Hub for the latest player SDK news, streaming-device updates, developer guides, and media-playback insights. I can also monitor new Media3 and ExoPlayer release notes and alert you only when a genuinely new update appears, without repeating topics you’ve already covered.