Next Player reads files, remotes and TV remotes instead of a library

The front door is a file picker, not a library screen

The entry point is a media picker that switches between tree, folder and file view modes, and beyond that sit three separate sources of video. Local files come through the storage access framework, so the app gets access to a document you pick rather than to the whole volume. A URL can be opened directly. And network storage over SMB, FTP, SFTP and WebDAV is supported.

That arrangement fits a specific person: someone with a season sitting on a NAS, or a phone with almost no free storage, who wants one installed app that can reach all of it. It also fits a second audience the repository takes seriously enough to build for separately, the Android TV user driving a couch with a remote rather than a thumb. Vertical swipe moves brightness on the left half and volume on the right, and horizontal swipe seeks.

Gestures replace the control panel you would tap for

On a phone, the surface of the video is the control surface. Swipe down on the left side and brightness changes; swipe down on the right and volume changes; swipe sideways and the playhead moves through the timeline. Zoom is a gesture too. None of this needs a button bar, which matters on a ten foot screen where a misplaced tap costs a second of the film.

Audio track and subtitle track selection exist, and playback speed control exists, and subtitle delay exists as its own adjustment rather than a fixed offset baked into a file. Background playback and picture-in-picture are both present, so a video can keep running while the user backs out of the app, and picture-in-picture keeps it on top of whatever else is open. Search functionality is listed too, which is the one feature here that presumes a collection large enough to be worth searching.

Decoding sits with ExoPlayer, and two codecs get a software fallback

The architecture is closer to a thin shell than to a bundled engine. Audio support is attributed in the README to the ExoPlayer FFmpeg extension, which is where the long codec list in the subtitle-adjacent section actually comes from: Vorbis, Opus, FLAC, ALAC, PCM, MP3, AAC, AC-3, DTS, DTS-HD and TrueHD. For video, H.263, H.264, H.265, MPEG-4 SP, VP8, VP9 and AV1 are named, with support depending on the Android device.

On top of that sit software decoders for h264 and hevc, which is the project's answer to a device that will not decode those two in hardware. A separate developer document, DECODER_SWITCHING.md under feature/player, covers switching decoders at runtime, so the choice is meant to be changeable while a video plays rather than locked at startup. H.264 is qualified further: Baseline Profile everywhere, Main Profile on Android 6 and later.

There is no build command here, only four places to take the APK

The README carries no install command, no Gradle invocation and no build recipe for producing the app yourself. It is a distribution page, not a developer setup guide, so a reader looking for a terminal line to run will not find one. What it offers instead is a choice of where the binary comes from, and that choice is the interesting part.

GitHub releases are listed first, and the project publishes its own tagged builds there. F-Droid carries the package dev.anilbeesetti.nextplayer, and IzzyOnDroid also hosts an APK of the same package name. Google Play carries dev.anilbeesetti.nextplayer as well. For anyone taking the GitHub build, the page gives a verification anchor: a SHA-256 fingerprint certificate for the release build, D3:7C:AB:F3:67:6C:F5:82:24:FB:24:2C:8D:D2:09:12:9D:05:88:03:79:29:5F:AA:A6:D0:FB:60:7B:EC:13:1B, which is the value to check against the app you actually installed.

The format list and the disclaimer printed underneath it

Read the supported formats section carefully and it contradicts itself in a useful way. The video line lists H.264, H.265, VP9 and AV1 as supported, and the next indented line under it says support depends on the Android device. So the list is a ceiling, not a promise: a codec on the list still fails on a handset whose decoder or system version cannot handle it, and the README never says which devices qualify.

Subtitles go further and name their own ceiling. SRT, SSA, ASS, TTML, VTT and DVB are listed, and SSA/ASS is annotated as having limited styling support, with a link to an ExoPlayer issue for the detail. A second contradiction sits in the feature list: audio and subtitle track selection is a shipped feature, while external audio support sits under planned features. Track switching between the tracks inside a container works. Pointing the player at a separate audio file does not, yet.

Remote mounts are first-class, which is also the sharpest edge

Treating SMB, FTP, SFTP and WebDAV as peers of the local document picker is what separates Next Player from a plain local player, and it is also where failures will show up. A share is a network object with a latency profile and a credential store, and this app puts a codec pipeline and a swipe gesture layer directly on top of it. Nothing in the documentation describes reconnect behaviour, buffering policy for a stalled mount, or how credentials are held once the app is backgrounded.

For a large file on a flaky WiFi link, that silence is the thing to test before you commit. What is documented is narrower and still useful: seeking is a horizontal swipe, playback speed is adjustable, and subtitle delay can be corrected on the fly, which together cover most of what a viewer notices during a bad connection.

Where VLC and MX Player take a different route

VLC arrives with its own decoding and demuxing stack and a format surface built over decades of desktop work, including disc structures and stream types this project never lists. MX Player arrives on Android as a player with codec extensions fetched alongside it. Both take the approach of shipping decoder breadth with the application, and both accept a heavier install for it.

Next Player takes the opposite route. It stays a native Kotlin app with Material 3, defers audio decoding to the ExoPlayer FFmpeg extension, and adds software decoders only for h264 and hevc, the two formats that decide whether a phone can play its own library. The source is public, so the decoding path and the gesture layer can be read, patched or reused rather than reverse engineered.

Editorial conclusion

Adopt Next Player if your video is spread across network shares and external subtitles and you want a phone and TV build from one codebase with no ads. Skip it if you need the audio-track file selection the project still lists as planned, or if your device cannot decode AV1. Before anything else, open one AV1 or H.265 file from your own share and check that the hardware or software path decodes it, because the codec list is qualified by the device itself. The documentation also stops short on dropped network streams: no reconnect or resume behaviour is described for a file that stalls on SMB or WebDAV, so test that exact file before you move a library onto the mount.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes