# androidx/media: ExoPlayer, Transformer and MediaSession in one Jetpack library set

> Jetpack Media3 packages Android playback, editing and media session APIs into versioned AndroidX modules published on Google Maven. The README documents installation, local checkout builds and an API stability policy, but leaves a few practical questions open.

**androidx/media** — Jetpack Media3 support libraries for media use cases, including ExoPlayer, an extensible media player for Android

- Repository: https://github.com/androidx/media
- Website: https://developer.android.com/media/media3
- Stars: 3,015 · Forks: 971
- Language: Java
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/androidx-media

## What androidx/media replaces for Android media developers

Historically, an Android app that played video pulled in ExoPlayer, and an app that showed a lock screen control pulled in a separate MediaSession library. They were related but versioned apart. Jetpack Media3 merges that work into a single AndroidX group, androidx.media3, with the README describing the scope as local playback via ExoPlayer, video editing via Transformer, and media sessions.

The audience is narrow and specific: Android app developers writing in Java or Kotlin who need playback, editing or media session behaviour inside an Android process. Nothing in the repository targets iOS, desktop or the web. The primary language of the repository is Java, and the modules are consumed as Gradle dependencies, so this is not a tool you run on a server or in a terminal on its own.

The practical gain is version alignment. One release trains all three concerns together, and the 1.11.x releases show a regular cadence rather than three separate projects drifting apart. If your app currently pins ExoPlayer and MediaSession independently, the migration is mostly a dependency rename plus an API review, and the README points to a migration guide on developer.android.com for existing ExoPlayer and MediaSession users.

## How the modules, API stability policy and OptIn annotation fit together

The repository is a multi-module Gradle build. Under libraries/ each media concern gets its own module, so an app depends only on what it uses: media3-exoplayer for the player core, media3-exoplayer-dash for DASH, media3-ui for player views. The README points at the libraries directory for modules that depend on external libraries and are built manually rather than fetched from Maven. The decoder_midi module is the concrete example: it is disabled as a local dependency by default because it needs extra Maven repository configuration.

The API story is the part worth reading closely. AndroidX Media releases carry API stability guarantees, and the README states that the API surface stays backwards compatible for the most commonly used APIs. Anything aimed at advanced use cases is marked unstable. Calling an unstable method produces a lint warning unless you annotate the call site with OptIn. That is a real design decision with a cost: your build will tell you when you cross from the guaranteed surface into the moving one, and you either accept the annotation or avoid the API.

The build logic lives in build-logic-settings/ and build-logic/, with a modules.kt file controlling which modules participate. Development happens on the main branch; the release branch holds the most recent stable release. That split matters if you intend to depend on a local checkout, because the branch you clone determines whether you get stable code or in-progress work.

## Installing Media3 from Google Maven and playing a first file

The README gives the Maven path as the easiest way to start. Add Gradle dependencies on the modules you need in your app module's build.gradle.kts, keeping every media3 module on the same version. The README uses 1.X.X as a placeholder for your preferred version and states that all modules must be the same version.

```kotlin
implementation("androidx.media3:media3-exoplayer:1.X.X")
implementation("androidx.media3:media3-exoplayer-dash:1.X.X")
implementation("androidx.media3:media3-ui:1.X.X")
```

Groovy DSL is supported too, for projects still on build.gradle.

```groovy
implementation 'androidx.media3:media3-exoplayer:1.X.X'
implementation 'androidx.media3:media3-exoplayer-dash:1.X.X'
implementation 'androidx.media3:media3-ui:1.X.X'
```

Then turn on Java 8 support in every build file that depends on AndroidX Media, by adding targetCompatibility to the android section. The README says to do this if it is not enabled already.

```kotlin
compileOptions {
  targetCompatibility = JavaVersion.VERSION_1_8
}
```

After a Gradle sync, the media3 classes resolve from Google Maven and the DASH and UI artifacts appear alongside the player core. The README does not include a player initialisation snippet, so for the actual playback code you need the developer guide and class reference it links, not the README itself. If you would rather build against a local checkout, the README describes cloning the repository and adding an includeMedia3 call to settings.gradle.kts, which makes the checkout appear as a separate included build and causes Gradle to resolve the seemingly published versions against your local copy. The README notes that a version you pin in your build file is then completely ignored, so you can leave those lines intact.

## Where Media3 is the wrong dependency

The clearest limitation is platform. Every module here is an Android library published for AndroidX, so a project that needs one player implementation across Android, iOS and web gets nothing from this repository. There is no server component, no CLI and no standalone binary.

The second limitation is the unstable API boundary. The README is explicit that only the most commonly used APIs carry backwards compatibility guarantees, and advanced APIs need an OptIn annotation to silence lint. If your feature depends on an unstable method, a minor release can change it, and the annotation is a marker of that risk rather than a fix for it.

The third is the local checkout path. Depending on a local copy is required for some libraries and is the way to use the main branch, but it changes how Gradle resolves dependencies: the README states that a version you specify is completely ignored. Teams that need reproducible builds tied to a published artifact should stay on Google Maven rather than a checkout.

One build-level trap is documented directly: if you hit NDK not configured, the README says to check that local.properties in the media checkout has sdk.dir set. That file is autogenerated when you open the media project in Android Studio. It is a small thing that will stop a local checkout build outright.

## Media3 against a single-purpose player library

The obvious alternative approach is to use a standalone Android player such as the original ExoPlayer artifact on its own, without the Media3 packaging and without the Transformer and media session modules. The difference is scope and versioning, not playback capability. A single-purpose player dependency gives you one artifact to track; Media3 gives you a family of modules that share a release train and a documented API stability policy, at the cost of depending on more artifacts and keeping their versions aligned.

A second alternative is to build playback on the platform MediaPlayer class and skip third-party dependencies entirely. That removes the dependency management problem but also removes the DASH module, the UI components and the Transformer editing path that the README lists as part of this project's scope.

The choice comes down to whether you want editing and media session behaviour in the same dependency family as playback. If you only ever play a single local file and never touch media sessions, the wider module set is weight you do not need. If you ship DASH, a player view and a media session in one app, keeping them on one version is the reason this repository exists.

## Release cadence, licence and upgrade cost

The last push to the repository was on 2026-09-23, and the most recent releases are 1.11.1 on 2026-09-11, 1.11.0 on 2026-08-07 and 1.11.0-rc01 on 2026-07-22. The repository is not archived. The pattern visible in those dates is a release candidate followed by a stable release roughly three weeks later, then a patch about a month after that. The release notes file in the repository root is where the README says major changes per release are documented, so that file is the first place to look before bumping a version.

The upgrade cost is governed by two README statements. First, all modules must be the same version, so an upgrade is an all-or-nothing edit across your dependency list, not a per-module decision. Second, the backwards compatibility guarantee covers the most commonly used APIs, so an upgrade can require changes where you opted into unstable APIs. Budget the upgrade as a dependency sweep plus a lint pass, because the OptIn annotations mark exactly where the risk sits.

On licensing, the repository carries Apache-2.0, which is a permissive licence that generally allows use in closed-source applications. This is a description of the licence identifier in the repository, not legal advice; review the LICENSE file and your own obligations before shipping.

## Conclusion

Adopt androidx/media if you are building Android playback, editing or media session features and want one set of versioned modules instead of separate ExoPlayer and MediaSession dependencies. Do not adopt it if you need a cross-platform player or a non-Android target, since every module here is an Android library. Before migrating, verify three things: that all media3 modules in your build share one version, that your Gradle files set targetCompatibility to JavaVersion.VERSION_1_8, and that any advanced API you call is either stable or annotated with OptIn. The README states that all modules must be the same version, so a mixed version list is the first thing to fix.

## FAQ

### How do I install androidx/media in an Android project?

Add Gradle dependencies on the media3 modules you need from Google Maven, for example media3-exoplayer, media3-exoplayer-dash and media3-ui, keeping all modules on the same version. Then enable Java 8 support by setting targetCompatibility to JavaVersion.VERSION_1_8 in the android section of every build file that depends on AndroidX Media.

### Can I depend on a local checkout of androidx/media instead of the published artifacts?

Yes. The README describes cloning the repository and adding an includeMedia3 call to settings.gradle.kts, which makes the checkout appear as a separate included build. The README states that a version you pin in your build file is then completely ignored.

### What does the UnstableApi annotation mean for androidx/media users?

AndroidX Media guarantees backwards compatibility for the most commonly used APIs, while APIs for advanced use cases are marked unstable. Using an unstable method or class produces a lint warning unless you add the OptIn annotation before using it.

### Which branch of androidx/media holds the stable release?

The README states that development work happens on the main branch and that pull requests should normally be made there, while the release branch holds the most recent stable release.

## Sources

- [androidx/media on GitHub](https://github.com/androidx/media)
- [License: Apache-2.0](https://github.com/androidx/media/blob/release/LICENSE)
- [Project website](https://developer.android.com/media/media3)
- [README](https://github.com/androidx/media/blob/release/README.md)
- [Releases](https://github.com/androidx/media/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/androidx-media