NOVA Video Player (aos-AVP): an Android player built from a manifest of git repos

What aos-AVP actually is, and who it is for

The README is explicit that this repository is not the player. It says the repo is "the entry point repo" whose "purpose is to provide the manifest to fetch all needed git repos with sources and then bootstrap the build environment." The player itself is NOVA, an open source Android video player described as a fork of the original Archos Video Player Community Edition, with the upstream at archos-sa/aos-AVP. The README points readers to sibling repositories for the parts, naming Video as "nova's Video UI code" and listing FileCoreLibrary, MediaLib and AVP among the top-level directories here.

So the audience splits in two. The first group is Android users who want the app: they install it from a store and never touch this repository. The second group is developers who want to compile NOVA, or who want to change something inside it, and for them aos-AVP is the front door. If you fall into the first group, cloning this repo is the wrong move, and the README's own badge row is the right one: Google Play, Amazon Appstore, F-Droid and IzzyOnDroid are all linked for the package org.courville.nova.

The fork relationship matters for expectations. Because NOVA descends from a community edition of a commercial player, the project inherits a codebase it did not design from scratch, and the README frames the work as being "intended to support new features" rather than as a rewrite. Anyone hoping for a small, single-module Android app will be surprised by the repository list.

How the manifest and Makefile wire the build together

The mechanism is a repo-style manifest plus a thin Makefile. The top level contains default.xml, core.mk, androidx.xml, exoplayer.xml and v6_4.xml, which is the pattern used to declare several sets of git projects and then fetch them into a working tree. The Makefile at the root does one thing: it includes AVP/core.mk when that file exists, and otherwise falls back to core.mk.

ifneq ($(wildcard AVP/core.mk),)
include AVP/core.mk
else
include core.mk
endif

That conditional is the whole bootstrap decision. If the AVP directory has been populated with its own core.mk, the build uses the versioned one; if not, it uses the copy sitting at the root. In practice this means the state of your working tree changes which build rules apply, which is convenient during development and confusing the first time a fetch only half-succeeds.

The remaining top-level entries fill in the rest of the picture: android-setup.sh and android-setup-light.sh for preparing the toolchain, android-sdk/ as a local SDK location, native/ for native code, script/ and release/ for packaging, docker/ for a containerised environment, and fastlane/ plus fdroid/ for store metadata. The data flow is therefore: manifest declares projects, the setup scripts install the Android toolchain, the Makefile selects build rules, and the release directory collects outputs. Nothing in the README describes a rollback path if a fetched project moves to an incompatible revision.

Installing NOVA on a device and a first real use

For most readers the install is a store install, and the README links four of them for the package org.courville.nova. On a device with F-Droid configured, the command line client can install it directly.

fdroid install org.courville.nova

After installation the app appears as NOVA. The README does not document a first-run wizard, so the concrete first step it does commit to is reading the application FAQ, which lives in the repository under faq/faq.md. That file is where the project sends people before they ask questions.

If you are building rather than installing, the repository gives you the setup scripts and expects you to have the Android SDK in place. The light variant and the full variant are both present at the top level.

./android-setup.sh
make

The README does not spell out the exact targets the Makefile exposes beyond the include shown above, so treat the make invocation as the entry point rather than a guarantee of a specific artefact name. What you should expect to see is the manifest being resolved into a populated tree and the Android build producing an APK somewhere under the release path. If the fetch step leaves AVP/ empty, the Makefile silently falls back to the root core.mk, which is the failure mode worth watching for on a first build.

Where NOVA is the wrong tool

The clearest limitation is platform. The README describes an Android video player, and the search interest around iOS, Windows and Samsung TV has no counterpart in the repository: no iOS project, no desktop client, no TV-specific build target is named. If your household runs an Apple TV or a Windows HTPC, this project does not address it, and the repository layout gives no hint that it intends to.

A second constraint is the release channel. The most recent release listed is v6.4.66, and its own title marks it as "/!\ v6.4.66 pre-release". The previous two, v6.4.64 and v6.4.63, are labelled as plain releases. A project that ships pre-releases at the head of the tag list expects users to make a choice about which line to follow, and the README does not tell you which one is recommended for daily use. Anyone who wants a stable, predictable version should look at v6.4.64 rather than assuming the newest tag is the safe one.

Third, the build is not a single clone. Because aos-AVP exists to fetch other repositories, a contributor who only clones this one has almost nothing to compile. That is a real cost for anyone who wanted to submit a small patch, and it is the opposite of the experience in a monorepo. The README does not describe a supported way to build a single component in isolation.

How it differs from VLC and from Stremio-style players

The obvious comparison people search for is VLC, and the difference is structural rather than a feature list. VLC is a cross-platform project with desktop and mobile clients under one organisation. NOVA is Android-only and descends from the Archos Video Player Community Edition, so its codebase carries the shape of that original application, including the FileCoreLibrary and MediaLib components visible in the repository listing. If you need the same player on a laptop and a phone, VLC covers both and NOVA covers one. If you specifically want an Apache-2.0 Android player whose UI code you can fork and rebuild, the manifest-driven layout here is the thing VLC does not offer in the same form.

The other comparison the search data surfaces is Stremio, which is a streaming aggregator rather than a local media player. NOVA's README says nothing about add-ons or catalogue streaming, so the two are not substitutes: one plays files you have, the other pulls content from services. Choosing between them is a question about what you want to watch, not about which player is better.

The practical difference with VLC comes down to licensing and build control. NOVA is Apache-2.0, which the README states on its licence badge and which is a permissive licence, so redistributing a modified APK is straightforward from a licensing standpoint. That is a genuine reason to pick it over a player whose mobile client is distributed under different terms.

Maintenance cadence, licence and the cost of upgrading

The last push to this repository was on 2026-09-20, and the release history shows three tags inside September 2026: v6.4.63 on 2026-09-09, v6.4.64 on 2026-09-12 and v6.4.66 on 2026-09-20. The project is therefore moving quickly, and the version numbering suggests a 6.4 line that gets frequent point releases rather than long-lived branches. The top-level file v6_4.xml is consistent with that reading: the manifest is versioned alongside the release line.

For a user, the upgrade cost is low, since the stores handle it. For a builder, the cost is the manifest. Every point release can move the projects that default.xml and v6_4.xml declare, and the README does not document a pinning strategy, a compatibility matrix or a rollback procedure if a fetched revision breaks your local changes. That is the part of the project with the thinnest documentation, and it is the part that matters most to anyone maintaining a downstream fork.

On licensing, the repository ships LICENSE.txt and the README carries an Apache 2.0 badge. Apache-2.0 is permissive and includes an explicit patent grant, which is friendlier for redistribution than a copyleft licence would be. It also means the project cannot relicense your contributions unilaterally in the way a CLA-based project can, though the README does not state a contribution policy either way. This is a description of the licence identifier, not legal advice; read LICENSE.txt yourself before shipping a modified build.

Editorial conclusion

Adopt NOVA if you want an Apache-2.0 Android video player that you can install from Google Play, F-Droid, IzzyOnDroid or the Amazon Appstore, or if you need to rebuild the APK yourself and are willing to work through the multi-repository manifest. Do not adopt it if you need an iOS, Windows or Samsung TV client, since the README lists none of those platforms and the repository is the Android entry point. Before committing, run the manifest fetch and check that every project the file declares has a reachable remote, then decide whether you are willing to pin your build to the pre-release line, since v6.4.66 is labelled as a pre-release while v6.4.64 is the most recent plain release.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nova-video-player/aos-AVP on GitHub
4. README
5. Releases