# Flixclusive: a Jetpack Compose and Media3 player app for Android and TV > Flixclusive is a Kotlin application built with Jetpack Compose and Media3 ExoPlayer, organised as a Gradle multi-module project with separate app, core, data, domain and feature modules, and it hosts no streaming content of its own. It suits developers who want to study a modern Android media app or build a player front end, and it is not a source of movies or shows. **flixclusiveorg/Flixclusive** — A jetpack compose media3 player application - Repository: https://github.com/flixclusiveorg/Flixclusive - Stars: 539 · Forks: 66 - Language: Kotlin - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/flixclusiveorg-flixclusive ## The disclaimer is the first line of the README, and it is the point Flixclusive is described as a jetpack compose media3 player application, and the README opens with a section called Disclaimer containing one sentence: the app DOES NOT host and contain movies and tv shows streaming links. That sentence is doing considerable work, so it is worth reading it as a design decision rather than a legal footnote. The application is a player. It provides the interface, the playback engine, the navigation and the settings, and the content comes from somewhere else. The repository is the application, and the streaming sources are not part of it. This is the same shape as any media client: a browsing and playback front end that expects a catalogue and a set of playback URLs. What makes Flixclusive's position unusual is that it is presented as open source without the catalogue, so the repository is a complete application shell rather than a working service. The topic tags reinforce the scope: android, compose-ui, jetpack-compose, media3, media3-exoplayer, movie, netflix-clone and tv. The netflix-clone tag describes the interface it imitates, not a Netflix integration, and the tv tag tells you the app targets the television form factor as well as the handset. The primary language is Kotlin, and the licence is MIT with a `LICENSE` file at the top level of the tree, so the code can be reused and modified freely as long as the notice is retained. This is a description of the published terms, not legal advice. For an engineer, the practical reading is that this is an excellent reference implementation of a streaming front end, and not a streaming service. ## The Gradle module layout is the architecture The repository is a Gradle multi-module project, and the top level directory listing is the clearest description of how the application is put together. There is `app-mobile/`, which is the Android application module, and a `feature/` directory, which in this layout holds the individual feature modules that make up the user-facing screens. There is `core/` for shared infrastructure, `data/` for the data layer, and `domain/` for the domain layer. That split is the standard clean-architecture arrangement for a modern Android codebase, and it is the reason the project is worth reading as a reference. The dependency direction runs from the feature and app layers inward to domain, and from data inward to domain, so that the domain layer holds the models and the use cases while the data layer holds the repositories and the remote or local sources behind them. The result is that a screen can be developed and previewed without a network, and that the data source can be replaced without touching the UI. The `build-logic/` directory is the other half of the story. Convention over configuration plugins live there, which is how a project of this size keeps its Gradle setup consistent across modules rather than repeating the same block of build script in each one. The `build.gradle.kts`, `settings.gradle.kts` and `gradle.properties` files at the root, together with the `gradlew` and `gradlew.bat` wrapper scripts, are the conventional Kotlin DSL setup, and the wrapper means a contributor does not need a matching local Gradle version to build the project. The `docs/` directory holds the project's documentation, and the `.idea/` directory and the `.editorconfig` file show the editor configuration the maintainers expect contributors to work with. ## Jetpack Compose and Media3, and what each one is doing Two technologies do most of the work, and the topic tags name both of them along with their subcomponents. Jetpack Compose is the UI toolkit, and `compose-ui` and `jetpack-compose` in the topic list point at it specifically. For a media application, Compose matters because the interface is a scrolling catalogue grid, a details page, a search interface and a settings screen, and the same components have to work on a phone, on a tablet and on a television. Compose's declarative model and its adaptive layout primitives are a natural fit for that, and the `app-mobile/` module is where that code lives. Media3 is the playback layer, and the tags `media3` and `media3-exoplayer` name both the framework and the ExoPlayer component inside it. Media3 is the current generation of the ExoPlayer library, and the topic list calling out `media3-exoplayer` specifically suggests the project uses the player component rather than only the session and data source abstractions. The division of labour is the interesting part. Compose owns everything about how the media looks and how the user moves through it, and Media3 owns the part that has to deal with containers, codecs, buffering, playback state and the platform's own media session, which is what lets the app hand playback off to a device or a notification. A well-built media app keeps those two concerns separate, and the module split in this repository is consistent with that. One thing the tags do not tell you is the streaming protocol side. Media3 supports a range of sources, and the repository says nothing about which manifest formats or DRM schemes are wired up, so that has to be read from the `data/` module rather than inferred. ## Releases: from commit-named builds to version 3.0.0 The release history is short and shows a recent change of approach. The three listed releases are 3.0.0 on 2026-10-06, PR-92918a7 on 2025-09-22 and PR-c62ada6 on 2025-02-16. The two older entries are named after pull requests, which is the pattern that comes from an automated release workflow that publishes a build per merged change. The newest entry is a plain semantic version, 3.0.0, which is the pattern of a project that has moved to releasing deliberate versions rather than a continuous stream of artefacts. The README badges reinforce the two-track setup. There is a separate badge for the stable release, pointing at the releases page of the main repository, and another for a pre-release build, pointing at a distinct `preview-builds` repository. A project that publishes previews separately from stable releases is making a clear statement that it wants testers on the new version without pushing it at everyone, which is a reasonable approach for an application with a large UI surface. The last push to the default branch was on 2026-10-12, a few days after the 3.0.0 tag, and the repository is not archived. The version numbering reaching 3.0.0 also suggests the project has been through a substantial amount of structural change, which is consistent with the clean architecture module layout described above. There is no project homepage in the repository metadata, and the README's only outbound links besides the badges are the Discord invite and the contributors image, so the community channel is where the project communicates. ## Where Flixclusive is the wrong tool The first and most obvious wrong-tool case is expecting content. If you install this app expecting it to browse and play a catalogue of films and series, the disclaimer says it will not, and no amount of configuration will change that. The media source is the part you supply. The second case is a production Android release. This is a community project with a Discord, a preview build channel and a recent move to version 3.0.0, and the repository carries no information about a release signing setup, a store listing, crash reporting, or an update policy. None of that is documented, which means a team shipping to users through the Play Store has work to do that the repository does not help with. The third case is anything that is not Android or Android TV. Despite the Netflix-clone framing, the topics list `android`, `compose-ui` and `tv`, and the module is `app-mobile/`, so this is an Android application. A web or desktop player is a different codebase, and the interesting parts of this project, the Compose screens and the Media3 session handling, do not transfer. The fourth is a project that needs an official content API. The repository does not document any catalogue service, authentication scheme or licensed source, so if you need a product with a real catalogue you would be plugging in a service that this project knows nothing about. The alternative worth naming is writing the player layer yourself on top of Media3, which is what many teams do, since Media3 is the piece that does the hard work and is maintained by the platform team rather than by a community. The difference in approach is that you would write the catalogue, the repository, the domain layer and the navigation yourself, and keep only the playback engine. Flixclusive gives you the entire front end, the domain and data layers, the build conventions and a working multi-module setup, and leaves you the one thing it deliberately excludes. ## A roadmap of one item, and what it tells you about the project The README has a Roadmap section containing a single bullet: join the discord; its in there. A one-line roadmap is unusual, and it is a signal about how the project is run. There is no published feature plan, no version roadmap and no issue template referenced in the README. The direction of the project appears to be decided in the Discord rather than in the repository. For someone evaluating the project, that cuts both ways. It means there is no public list of breaking changes to plan around and no committed timeline, which makes it harder to answer the question of whether a feature you need will exist. It also means the repository is not the whole story, and a contributor is expected to talk to the community before starting work, which is a reasonable way to avoid duplicated effort on a volunteer project. What the repository does document is the disclaimer, the release channels, the licence and the build structure. Those four things are enough to decide whether the codebase is a useful starting point, and they are the things a reader should check first. The MIT licence is the friendly part of that picture. For an organisation that wants a reference implementation or a starting point for its own player front end, the permissive terms mean the code can be taken, adapted and shipped, and the only obligation is to keep the copyright notice. The `docs/` directory is the place to look next for anything the README does not cover, including the details of how the app is expected to receive its media. ## Conclusion Adopt Flixclusive as a codebase to learn from, or as the starting point for a player application of your own, because the multi-module Gradle structure with separate `app-mobile/`, `core/`, `data/`, `domain/` and `feature/` directories is a sensible template for an Android app of this size. Do not adopt it expecting a catalogue of titles, since the project states plainly that the app does not host and contain movies and tv shows streaming links, and that disclaimer is the first thing in the README. Before you build on it, read the `docs/` directory and the Gradle module wiring in `settings.gradle.kts`, check that version 3.0.0 from 2026-10-06 is the base you want given the project moved from commit-named releases to a numbered one, and confirm how you intend to supply the media URLs, since that is explicitly outside this repository. ## FAQ ### What is Flixclusive and what does it do? Flixclusive is a Kotlin Android and TV media player application built with Jetpack Compose and Media3, with the topic tags naming Media3 ExoPlayer specifically. The README states plainly that the app does not host and contain movies and tv shows streaming links, so the media source is supplied separately. ### How is the Flixclusive codebase structured? It is a Gradle multi-module project with `app-mobile/` for the application, `feature/` for the screens, plus `core/`, `data/` and `domain/` layers, and a `build-logic/` directory holding the convention plugins. The root has `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties` and the `gradlew` wrapper scripts. ### Where do I download Flixclusive builds? The README links two release channels: a stable release on the Flixclusive repository's releases page and a pre-release build hosted in a separate `preview-builds` repository, each with its own badge showing the download total. ### What licence is Flixclusive released under? The project is MIT licensed, with a `LICENSE` file at the top level of the repository. The MIT terms let you reuse, modify and redistribute the code, including in a commercial application, provided the copyright notice is retained. ### Does Flixclusive include movies or TV shows to stream? No. The README carries a Disclaimer stating that the app does not host and contain movies and tv shows streaming links. The application is the player front end, and the streaming sources are not part of this repository. ## Sources - [flixclusiveorg/Flixclusive on GitHub](https://github.com/flixclusiveorg/Flixclusive) - [Issues](https://github.com/flixclusiveorg/Flixclusive/issues) - [License: MIT](https://github.com/flixclusiveorg/Flixclusive/blob/main/LICENSE) - [README](https://github.com/flixclusiveorg/Flixclusive/blob/main/README.md) - [Releases](https://github.com/flixclusiveorg/Flixclusive/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flixclusiveorg-flixclusive