mpvEx: libmpv playback on Android wrapped in a Compose interface

Which project mpvEx is actually forked from

The fork lineage is stated three different ways, and it is worth knowing all three. GitHub's repository description ends with Forked from mpvKt. The README opens by saying that mpvExtended is a fork of mpv-android, built on the libmpv library. The acknowledgements section then credits four projects: mpv-android, mpvKt, Next player and Gramophone.

None of those statements makes the others false. mpvKt was itself an Android mpv client, and mpv-android is the maintained libmpv binding that the current release notes show being consumed as a published library. What the description does not say is which ancestor the current code descends from directly. If you are tracing behaviour to an upstream issue or patching this fork, the acknowledgements list and the dependency coordinates in the release notes are the more reliable places to look than the one-line description.

Naming follows a similar split. The README heading calls the app mpvExtended, while the repository name, the homepage and the Android package identifier `app.marlboroadvance.mpvex` all use mpvEx, as do the release tags. Search for both names if you are chasing an issue thread, and note that the privacy policy and the documentation site live under the mpvEx spelling.

The libmpv engine underneath and the Compose layer on top

The engine is mpv, reached through libmpv, and the project describes its goal as combining the powerful features of mpv with an easy to use interface and additional features. The repository topics name the stack accurately: mpv, ffmpeg, jni-android, mediainfo, jetpack-compose, kotlin, material-design and videoplayer. The JNI topic is the important one, because libmpv is a native library and the Android app talks to it across the JNI boundary rather than through a pure Kotlin layer.

The feature list is where the fork's value shows. On the interface side there is a simpler and easier to use UI, Material 3 Expressive Design, a media picker with tree and folder view modes, search functionality, a zoom gesture, custom playlist management, and file management. On the playback side: enhanced playback features, picture-in-picture, background playback, high-quality rendering, external subtitle support, external audio support, and network streaming with SMB, FTP and WebDAV.

That last group is what separates this from a bare libmpv wrapper. Opening a file over WebDAV or an SMB share, with subtitles and a separate audio track, in picture-in-picture, is a feature set that mobile mpv users historically had to assemble themselves from scripts and settings files.

The README is blunt about maturity, stating that the project is still in development and is expected to have bugs, with a pointer to the issue tracker. GitHub reports 261 open issues against 2,590 stars, which is consistent with an active project that ships imperfect software. The licensing is settled: the repository reports Apache-2.0 and the tree contains a `LICENSE` file, so unlike some forks there is no ambiguity about reuse.

Five APK variants and the stores that narrow them

The build produces multiple APKs, one per CPU architecture, and the README lists the matrix with sizes in mind. The universal APK works on all devices and is larger. The recommended one for most users is arm64-v8a for modern 64-bit ARM devices, with armeabi-v7a for older 32-bit ARM, plus x86 for Intel and AMD 32-bit and x86_64 for 64-bit.

Install paths are three. The primary one is the GitHub releases page for the latest stable version. The second is an IzzyOnDroid repository, which is the F-Droid-adjacent route for people who want automatic updates without a store account. The third is a set of preview builds hosted on a GitHub Pages site, which the README labels for testing purposes only.

The release notes add a distinction the README does not mention: store-specific builds exist alongside the plain APKs. The Play Store variant is a universal APK with the automatic update feature removed, since the store handles updates, and with minimal permissions for compatibility. The F-Droid variant also drops the update feature, additionally removes the install packages permission, and ships arm64-v8a only. Every release publishes SHA-256 checksums per variant, which is a small sign of release discipline and lets you verify a download before installing it.

So the practical decision is: arm64-v8a from GitHub for a normal phone, F-Droid build if you want reproducible sideloading, Play Store build if you would rather not sideload at all. The universal APK exists but pays for it in size.

Version cadence, checksums and a native dependency swap

Release tags use semantic versioning with a v prefix. v1.3.1 was published on 2026-09-25 and v1.3.0 on 2026-09-21, so the two releases are four days apart, while v1.2.9 dates from 2026-03-10. GitHub reports the last push on 2026-09-27, on the master branch.

The v1.3.1 notes are the most informative release text in the repository, and they describe a change of substance rather than a bugfix sweep. The local bundled mpv-android AAR was replaced with the official Maven Central release, `io.github.marlboro-advance:mpv-android:1.0.0`, and the 77.6MB binary AAR was removed from the repository tree, which the notes describe as a significant reduction in repository footprint. The same release adds native subtitle rendering with system fonts through dynamic fontconfig fallback, listing Roboto, Noto Sans and Noto Serif, and fixes an Activity leak in `BaseMPVView` triggered on rotation and destroy.

Here is a mismatch worth keeping in view: the README's build prerequisites section still lists only JDK 17, Android SDK build tools 34.0.0 or newer, and Git for version information. It does not mention that the engine now arrives as a Maven dependency. If you are building from source, that coordinate is documented in the release notes rather than in the README's build section, which is the first place to look if Gradle cannot resolve libmpv.

The preview channel uses its own tag shape, which the README documents as part of the release process:

git tag -a v1.0.0-preview.1 -m "Preview release"
git push origin v1.0.0-preview.1

Release signing through four repository secrets

Release builds are signed in GitHub Actions, and the README documents the four secrets you would need to reproduce that. `SIGNING_KEYSTORE` holds the base64-encoded keystore file, in `.jks` or `.keystore` form. `SIGNING_KEY_ALIAS` is the alias name used when creating it. `SIGNING_STORE_PASSWORD` and `KEY_PASSWORD` are the two passwords, and the notes are explicit that the key password can be the same as the store password.

Encoding the keystore for the secret has a per-platform command, and the macOS and Linux form strips newlines so the base64 stays on one line:

base64 -i your-keystore.jks | tr -d '\n' > keystore.txt

The Windows equivalent uses PowerShell to read the bytes directly:

[Convert]::ToBase64String([IO.File]::ReadAllBytes("your-keystore.jks")) | Out-File -FilePath keystore.txt -NoNewline

The stable release procedure is short: update `versionCode` and `versionName` in `app/build.gradle.kts`, commit, then tag and push.

git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

Once the tag is pushed, Actions builds, signs and creates a draft release, which means a human still approves publication. That is the whole release story, and it explains why the repository needs no manual signing steps in its documentation.

Other assets in the tree support the packaging side of the project: a `fastlane/` directory holds the metadata and screenshot images the README displays, `website/` holds the documentation site that mpvex.vercel.app serves, `docs/` sits alongside it, and `PRIVACY_POLICY.md` backs the privacy badge in the README header.

Building from source and the documentation boundary

A source build is a standard Gradle Android project. The tree has the expected Gradle layout: a root `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties`, a `gradle/` directory, both `gradlew` and `gradlew.bat`, and an `app/` module where the version fields live. Java code lives in the single app module, consistent with the Kotlin language field GitHub reports.

The privacy policy deserves more attention than it usually gets. The README header carries a privacy policy badge pointing at a hosted privacy-policy page, and the repository root contains `PRIVACY_POLICY.md`. For an app that reads local files, network shares and external subtitle tracks, having both a repository copy and a published version is a reasonable baseline, and it is one of the more useful things to read before granting storage permissions on first launch.

What the README does not do is document mpv configuration. There is no section on script directories, input.conf, mpv.conf, or the option set that makes mpv powerful in the first place. The README's own framing, advanced configuration and scripting, is a bullet in a feature list with no follow-up section, so anything about tuning the engine means reading mpv's documentation and applying it through the app's settings.

That is the main practical limit of this repository as a source of information: it is a good record of the Android packaging, the fork lineage and the release process, and a thin manual for the engine. For an evaluation, install a stable build, decide which variant fits your device, and then read the engine documentation rather than expecting the fork to restate it.

Editorial conclusion

mpvEx is worth evaluating if you already trust mpv's decoding and want those results on a phone or tablet without configuring a command line. The engine is not the project's contribution: it is libmpv, pulled in through the mpv-android library, and what this repository adds is a Compose interface, a file manager with network backends, subtitle and audio handling, and a build that ships as separate APKs per CPU architecture. The README is a feature list plus release instructions and does not document the engine configuration surface, so treat the mpv documentation as the reference for anything about playback behaviour. Start by installing the arm64-v8a build, then read the repository's own privacy policy, which is present in the tree and linked from the README badges.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. marlboro-advance/mpvEx on GitHub
3. Project website
4. README
5. Releases