11 Aug 2026
Android Developers Blog
Media3 1.11 - What's new?

Media3 1.11 is out. Powering the vast majority of top Android media apps, this release brings new features, bug fixes, and improvements across playback, editing, and UI components. We're expanding our Jetpack Compose UI modules with customizable Player slots and easy to use defaults, interactive gestures, state observers, and short-form video preloading using PlayerPool. We also modernized the Media3 Cast integration with SystemUI Output Switcher support, introduced a new Ktor HTTP client network extension, and added new muxing utilities for Ogg and WAV files.
Read on for key highlights, and check out the full release notes for a comprehensive list of changes.
Playback UI and Compose
With Android becoming Compose-first, we are continuing to expand the media3-ui-compose and media3-ui-compose-material3 modules. This update introduces more granular control over your player layout, richer interaction patterns, and deeper integration with Material3.
Customizable Player layout
The Material 3 Player Composable now supports dedicated content slots for topControls, centerControls, bottomControls, and errorOverlay. You can drop in your own Composables or use the ready-made defaults published in PlayerDefaults:
Player(
player = player,
topControls = { PlayerDefaults.TopControls(player) },
centerControls = { PlayerDefaults.CenterControls(player) },
bottomControls = { PlayerDefaults.BottomControls(player) },
)
The Player Composable also integrates FocusRequester support, enabling seamless D-pad and keyboard navigation on Android TV, foldables, and desktop environments. large-screen devices.
Gestures and playback speed control
PlaybackSpeedState now provides a fast-forward/slow-motion API. The demo-compose app showcases this with a long-press gesture to fast-forward playback and seeking with double tap. Combined with the ProgressSlider introduced in 1.10, the Compose player UI now offers rich touch and gesture interactions out of the box.
Short-form video preloading with PlayerPool
For apps with sliding-window media feeds (for example, short-form vertical video), managing multiple ExoPlayer instances efficiently is a common challenge. Media3 1.11 introduces PlayerPool (in common-ktx) and rememberPooledPlayer (in ui-compose) to handle player recycling and preloading automatically.
The new ShortFormPlayerScreen in demo-compose shows this in action, a vertically paging feed where players are pooled, preloaded, and seamlessly recycled as the user scrolls.
MiniController
A new MiniController Composable in media3-ui-compose-material3 provides a compact playback bar displaying the current item's title, artist, artwork, and progress alongside play/pause controls. As all our default Composables in media3-ui-compose-material3, the MiniController supports Material3 Dynamic Color integration, allowing it to automatically adapt to the user's wallpaper theme.This is ideal for persistent bottom-sheet or mini-player affordances, for example while the user browses content or during active Cast sessions.
Expanded state holders for metadata and errors
We added several new reactive state holders to media3-ui-compose:
rememberCurrentMediaItemState- observe metadata about the currently playing itemrememberPlaylistState- observe the full playlist and active indicesrememberErrorState- track playback errors, with a matchingErrorTextComposable and defaultErrorOverlayin Material3
We'll continue working on new additions and more customization options in upcoming releases. Please share your thoughts on the project issue tracker.
Modernized Cast integration
Media3 1.11 updates the Cast extension with programmatic configuration options and support for OS-level routing.
CastParams and SystemUI Output Switcher
You can now configure the Cast extension using CastParams:
val castParams = CastParams.Builder()
.setShowSystemOutputSwitcherOnCastButtonClick(true)
.build()
Cast.getSingletonInstance(context).initialize(castParams)
Setting setShowSystemOutputSwitcherOnCastIconClick(true) configures the MediaRouteButton to open Android's native SystemUI Output Switcher on supported platform versions, providing a unified output picker experience.
Reactive MediaRouteButton state in Compose
Apps using Jetpack Compose can now easily add the Media routing button (also known as Cast button), which automatically observes the dialog state and updates accordingly. No further logic needed when used together with Media3's CastPlayer!
@Composable
fun TopAppBarWithCast() {
Row {
Text(text = "App Title")
MediaRouteButton()
}
}
Core playback and session enhancements
Eclipsa Video - HAGC dynamic HDR metadata (API 37+)
Eclipsa Video promises a more consistent HDR experience across devices, with a consistent baseline HDR white, adaptive headroom depending on the screen and the surroundings, ensuring the creative intent is preserved on all devices.
ExoPlayer now supports playback of the necessary HAGC (ST 2094-50) timed metadata for progressive media (MP4, Matroska). The player automatically merges HAGC metadata tracks with the associated video track and delivers the metadata out-of-band to the decoder on API 37+ devices. On older devices, ExoPlayer seamlessly falls back to providing a standard HDR playback experience without the adjustments.
New Ktor HTTP client extension
A new media3-datasource-ktor extension module provides KtorDataSource, backed by the Ktor HTTP stack. This offers a Kotlin-first, coroutine-friendly alternative to the existing Cronet and OkHttp data source modules.
Asynchronous MediaSession connections
MediaSession.Callback now includes onConnectAsync(), which lets you process controller connection attempts asynchronously - for example, to verify authorization before accepting a connection. You can return an immediate Future with Futures.immediateFuture(ConnectionResult) for the same behavior as the existing onConnect.
override fun onConnectAsync(
session: MediaSession,
controller: MediaSession.ControllerInfo
): ListenableFuture<MediaSession.ConnectionResult> {
return authenticateControllerAsync(controller)
}
Safer MediaSession defaults
For apps that don't override onConnect or onConnectAsync in MediaSession.Callback, the library now defaults to a more secure configuration. Specifically, session data is no longer shared by default with untrusted controllers, meaning third-party or non-system apps lacking notification access are restricted from accessing session data unless you explicitly implement these callback methods to authorize the connection.
New Muxer implementations & container parsing
OggMuxer and WavMuxer
We've added two new dedicated muxers: OggMuxer for muxing OPUS and VORBIS streams into standard .ogg files, and WavMuxer for generating uncompressed and floating-point PCM .wav audio files.
Container parsing and track references
- MP4 Track References (tref):
Mp4Muxer.addTrackReferenceallows linking dependent metadata or aux tracks to primary video streams. - Chapter Extraction: QuickTime and Nero chapter from MP4 files (.m4a, .m4b), and Matroska chapters, are now extracted as Chapter metadata entries for audiobook and podcast navigation.
Please use the issue tracker to report any bugs, or if you have questions or feature requests. We look forward to hearing from you!
11 Aug 2026 4:00pm GMT
06 Aug 2026
Android Developers Blog
Inside Android Skills - Built for deprecation
Posted by Jose Alcérreca, Developer Relations Engineer, Android Developer Relations
We released the official Android Skills in April, and the response surpassed all our expectations. In this blog post, I'll address some of the feedback we received, explaining the philosophy and methodology behind the project. Hopefully, this will also help you understand what happens behind the scenes when you install and use skills, allowing you to make better use of tokens and your own time.
Why are there so few official skills?
Currently, we only consider new skills when there's a verifiable knowledge gap in state-of-the-art (SOTA) models. Put simply: you don't need to teach the model what it already knows. (Though there are a few exceptions-read on!)
We've released around 20 official skills so far, and they intentionally target highly specific, fast-moving areas that standard models aren't fully grounded on yet-things like AGP 9, Navigation 3, advanced Camera APIs, and Perfetto SQL.
What about core, more general, skills? Every installed skill injects 100-200 tokens into the baseline context of every task you start. If that skill actually activates, that count can quickly jump into the thousands. In most cases, hoarding basic skills is both counterproductive and expensive. Before installing a skill for writing basic Kotlin or Compose, consider if your LLM of choice really needs it, or if it knows those topics well enough already.
Evaluating skills
Before their release, each skill is tested against a comprehensive set of evals that prove that the skill delivers clear value. These evals should pass when the skill is active, and fail otherwise. Evals are to skills what integration tests are to code.
timeout_s: 1200
repository:
url: [redacted - internal git repo]
working_dir: wear_compose_m3_empty_app
category_ids:
- wear
prompt: |-
Add a horizontal pager to MainActivity.kt. Have three pages in the pager. Each page should contain
the text "Page 1", "Page 2", and "Page 3" respectively in the center of the screen.
commands:
build:
- ./gradlew assembleDebug
acceptance_criteria:
project_builds: true
llm_diff_judge:
- Must use `HorizontalPagerScaffold`.
- Each page should use `AnimatedPage` to wrap a `ScreenScaffold`.
Example eval that checks the correct implementation of a horizontal pager on a wear app
At a minimum, we test the skill in Android Studio using the latest Gemini Flash model. Depending on the skill, we also ensure compatibility with other models such as Gemini Pro and other agents such as Antigravity, and third-party systems.
All of the evals run with access to the Knowledge Base, so if the information is in the documentation, and models decide to search for it, we don't publish a skill for it.
Using the Android Knowledge Base (Android Studio or Android CLI)
If you develop Android apps, you should always use the Android Knowledge Base to have access to the official documentation. If you use the agent in Android Studio, it's already available as a tool, but if you use another agent, install Android CLI. Among other things, it contains the docs command, which gives your agent access to the official Android documentation. Having a single tool is much more efficient than installing hundreds of skills.
If your model is acting overconfident, and you want it to consult the documentation more often, a very common way to motivate it is to add "Always consult the official Android documentation when dealing with Android APIs" to your AGENTS.md file or equivalent. Of course, you can also force this by asking the agent to check the documentation directly in your prompts.
Why are pull requests disabled?
Because our evaluation framework depends on internal infrastructure that cannot be open-sourced, we are unable to accept direct pull requests for new skills-without this infrastructure, we would have no way to re-evaluate incoming PR changes. However, we actively monitor community feedback. If you want to report a bug, suggest an optimization, or request a new official skill, please file an issue!
When do core or basic skills make sense?
While SOTA models generally don't need basic skills, there are some scenarios where enabling core or community-built skills adds real value. For example:
- You're using vague prompts: Skills amplify your intent. If you give a loose prompt like "add animations to this screen," a specific Compose animation skill can inspire the model, pushing it toward modern APIs or screenshot testing patterns it might not have otherwise considered.
- You want to use smaller, cheaper models: Frontier LLMs are expensive. If you are offloading routine tasks to smaller open-weight models like Gemma 4, enabling basic skills fills the knowledge gaps that smaller parameters miss.
- You're refactoring or reviewing legacy code: Models excel at generating code that works, but when editing old codebases, they often prioritize staying consistent with the surrounding legacy patterns over rewriting things with modern accuracy. A specialized reviewer agent equipped with core skills can help break that habit.
- You deviate from the norm: LLMs love the standard "Google way" of architecting Android apps. If your team uses a highly customized view-layer architecture, the model will struggle to stay aligned. A custom skill explicitly describing your architecture goes a long way.
Where can I find core skills?
The Android community has your back. Chris Banes has a comprehensive collection of skills for Compose and Kotlin, Ivan Morgillo published a skill that audits Compose projects, and Jaewoong Eum created two on testing and performance.
Always download skills from reputable sources! I personally wouldn't trust repositories containing dozens or hundreds of Android skills as they're probably AI-generated and untested, and they could even contain malicious or biased instructions. Also, don't install general software engineering skills blindly; a lot of them are tailored for web development.
Goal: deprecation
Loosely paraphrasing Karpathy: Skills of today will be in the models of tomorrow. As SOTA models keep improving, we expect skills to be obsolete, especially those built around new APIs. To figure out when to retire them, we run our evals when new models drop. If they pass, we'll keep them around for a few months until most users have transitioned over.
06 Aug 2026 4:00pm GMT
29 Jul 2026
Android Developers Blog
Delivering safer, age-appropriate experiences on Google Play

Providing a safe online experience and protecting users from harm is a top priority at Google Play. We take this responsibility seriously and have been investing continuously to offer baseline protections on our platform while also empowering parents with the tools they need to make decisions for their families. Importantly, we also want to empower Play developers with the capabilities to deliver age-appropriate experiences based on their app's content.
To support this, today, we are taking another big step in our ongoing partnership with parents and developers by announcing the expansion of the Google Play Age Signals API to all Play developers globally. Building on current availability in Brazil, we will expand this experience first to users in Australia and Canada by mid-August, with a full global rollout to all users later this year.
Empowering developers to create age-appropriate experiences
The Play Age Signals API is a privacy-preserving tool that puts parents in the driver's seat allowing them to share their child's age range (e.g. 16-17) directly with apps. It also enables adults to easily share their age when prompted by the app developer. In turn, developers receive the signals they need to tailor their own in-app safety experiences and content for users in an age-appropriate way.
We want to give developers the ability to choose the right protections for the nature of their app. A weather app, for example, shouldn't need the same safety settings as entertainment or media apps. Rather than enforcing one-size-fits-all rules, we give developers the flexibility to choose how they integrate safety signals. With this reliable signal, you retain complete agency to tailor your app's content, features, and settings to match your audience.
Simplifying controls for parents
Parents shouldn't have to manage complex safety settings across dozens of different apps to keep their children safe. The Play Age Signals API simplifies this by putting age-sharing controls in one place, directly inside the Google Family Link app. Parents have a choice to share their child's age range, and if they choose to share, all Play apps that use Play Age Signals API can receive age signals. This lets children jump straight into age-appropriate content without parents having to manually configure settings inside these apps. Age ranges are never shared by default, and parents can update or turn off these settings at any time.
Building on our broader safety tools
The Play Age Signals API builds upon a strong foundation of established safety features and strict policies we have long enforced on Google Play. Today, we already mandate that apps designed for families meet rigorous safety standards, and we continuously review and scan applications to ensure they are safe for children. For developers, we also offer built-in tools like Restrict Minor Access in the Play Console to help them manage who can discover their apps. For parents, Google Family Link remains a trusted, central dashboard where they can manage screen-time limits, PIN-based content filters, and app download approvals.
Expanding the Play Age Signals API globally adds a powerful new tool to our existing safety suite, helping parents and developers work together to make Google Play an even safer, more trustworthy place for families.
29 Jul 2026 1:00pm GMT






.png)
.png)