Jellyfin for Android: a WebView client for self-hosted media

What Jellyfin for Android actually is, and who it is for

Jellyfin is a media server you host yourself, and this repository is the official Android client that connects to it. The README is unusually direct about the design: "Even though the client is only a web wrapper there are still lots of improvements and bug fixes that can be accomplished with Android and Kotlin knowledge." That sentence tells you most of what you need to know. The app is not a from-scratch native player. It embeds the official Jellyfin web client, which lives in a separate repository, and adds Android-specific plumbing around it: playback integration, background behavior, and platform APIs.

The audience follows from that. If you run a Jellyfin instance on a home server or a VPS and want to watch your library on a phone or tablet, this is the reference client. It is also the client that ships on Google Play, the Amazon Appstore and F-Droid, so it is the one most users will find first. If instead you want to write a client, the repository is a Kotlin and Gradle project with detekt and Android lint configuration, and the README explicitly invites pull requests, asking that larger features be discussed in an issue before implementation.

The project was rewritten from scratch with a fresh git history between July and August 2020, replacing an older Cordova-based client that now sits in the jellyfin-archive organization. That history matters when you read older forum posts, because advice written before the rewrite describes a different codebase.

How the web wrapper architecture shapes behaviour

The core mechanism is a WebView that loads the Jellyfin web client, with Kotlin code bridging between the web layer and Android. The README calls the web client "the base for the Android client as well," which has a concrete consequence for translators: most strings live in the web client's Weblate project, and only a smaller set of app-specific strings lives in the Android project's own Weblate instance.

The practical effects of this design are worth stating plainly. Interface changes usually arrive through the web client rather than through app releases, so the look of the app can shift without a version bump in this repository. Conversely, anything the web client cannot do, the Android app generally cannot do either, unless the Kotlin layer adds a native bridge for it. That is why the README describes the remaining work as "improvements and bug fixes" rather than new playback engines.

This is a deliberate trade-off, not an oversight. A single web codebase means one set of features and one set of translations across desktop browsers and Android, at the cost of native performance and platform-native controls. Whether that trade is acceptable depends on your library. A server that direct-plays its content will feel fine. A server that must transcode heavily puts the burden on the server, not on the phone.

Installing Jellyfin for Android and connecting to a server

Most users should install from a store. The README links Google Play, the Amazon Appstore and F-Droid, all under the package name org.jellyfin.mobile. There is also a download archive at repo.jellyfin.org for direct APKs.

If you want to build it yourself, the only listed dependency is the Android SDK. The README gives these steps:

git clone https://github.com/jellyfin/jellyfin-android.git
cd jellyfin-android
./gradlew assembleDebug

That produces a debug APK. To put it on a connected device or emulator, the README gives a second command:

./gradlew installDebug

The README notes you can replace "Debug" with "Release" to get an optimized release binary. You can also open the project in Android Studio and run it from there.

Once the app is installed, the first real task is pointing it at your server. The app connects to Jellyfin instances; the README does not walk through the connection screen, so expect to enter your server address and sign in with the credentials your server uses. If the app cannot reach the server, the problem is usually the address or the network path, not the client.

The libre and proprietary flavors, and why the choice matters

The README documents two flavors of the app, and this is the decision most users get wrong. The proprietary version ships with Google Chromecast support. The libre version does not. The proprietary build is what you find on Google Play and the Amazon Appstore; the libre build is what F-Droid distributes.

So the distribution channel effectively decides the feature set. If you install from F-Droid because you prefer free software builds, you are choosing the version without Chromecast. If casting to a TV is part of how you watch, you need the proprietary flavor, and that means Google Play, the Amazon Appstore, or a direct download.

Beta releases exist for both flavors, but the README states that only the proprietary version is published to a beta track on Google Play. If you want to test a beta outside Google Play, the README points to the GitHub releases page. That is a narrower testing path than the stable channel, and it is worth knowing before you opt into it.

Where this client is the wrong tool

The clearest limitation is the architecture itself. Because the app is a web wrapper, it inherits the web client's playback behaviour rather than implementing its own. If your library contains formats the web player handles poorly, or if you depend on tight control over hardware decoding and subtitle rendering, a native client will serve you better. This app does not promise that, and the README does not claim it.

Second, the README describes an Android app, and the related searches around Android TV are a separate question that this document does not answer. Nothing in the README describes a television interface, a remote-control layout, or a leanback launcher entry. Treating this repository as the Android TV client is an assumption the README does not support.

Third, the project is a client, not a server. If you have no Jellyfin instance running, installing this app gets you nowhere. The README assumes an existing server to connect to. Users searching for a Jellyfin server on Android are looking for something this repository does not provide.

Finally, the README does not document rollback or downgrade behaviour. If a release breaks something on your device, there is no stated procedure for reverting, so you would be relying on the release archive and your own judgement.

How it compares with a native Android client

The obvious alternative is a native Android client built directly against the Jellyfin API rather than wrapping the web client. The difference in approach is structural. A native client owns its player, its navigation and its rendering, so it can tune decoding, gesture handling and performance for the device. It also has to reimplement every feature the web client already has, and it maintains its own translations.

This app takes the opposite position. It reuses the web client as the base, so feature parity with the browser experience comes largely for free, and translation work flows through the shared web client project. The cost is that the app sits one layer away from the hardware, and its interface is constrained by what a browser engine can do on Android.

Neither approach is universally better. If you value consistency with the browser client and a single translation pipeline, the web wrapper wins. If you value playback control and platform-native interaction, a native client wins. The README's own framing, calling this "only a web wrapper," is an honest description of which side of that line the project sits on.

Maintenance, releases and the GPL-2.0 licence

The repository is not archived, and the most recent push recorded is 2026-09-24, with releases v2.7.3 on 2026-09-14, v2.7.2 on 2026-08-28 and v2.7.1 on 2026-08-11. That is a steady release cadence across recent months. The repository also carries a renovate.json file and a .tools-versions file at the top level, which indicates dependency and toolchain updates are automated rather than handled by hand.

The licence is GPL-2.0, stated in LICENSE.md and reflected in the README badge. For users, that means the app is free software you can install and inspect. For anyone planning to redistribute a modified build, the copyleft terms apply to the derivative work, and the two flavors complicate that picture: the proprietary flavor bundles Google Chromecast support, which is not part of the GPL-licensed codebase. If redistribution is part of your plan, read LICENSE.md and the flavor definitions in the build configuration before assuming the two builds are interchangeable. This is a description of what the repository states, not legal advice.

Upgrade cost is low from a user's perspective, since store installs update normally. The real cost sits with anyone building from source: the project depends on the Android SDK, and the build configuration is Gradle-based with detekt and Android lint rules that will flag code in a fork.

Editorial conclusion

Adopt Jellyfin for Android if you already run a Jellyfin server and want the official client on a phone or tablet, especially if you need Chromecast, which only the proprietary flavor provides. Skip it if you need a native player with full codec control, or if you are looking for an Android TV interface, since the README describes this app as a phone client and the TV experience is a separate concern. Before installing, verify which flavor you need by checking whether you rely on Chromecast, confirm your server version against the latest release notes, and decide whether you want stable or beta builds from the release page.

Frequently asked questions

Official sources

1. jellyfin/jellyfin-android on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases