Auxio plays the files you already have, and builds only on Unix

Auxio indexes a folder tree instead of a streaming catalogue

Auxio is a local music player. It reads audio files that already sit on the device and builds its library from them, which is the whole design in one sentence. There is no account, no catalogue service and no streaming tier anywhere in the feature list, which closes on "Completely private and offline".

That constraint is the appeal for a particular reader: someone with a folder of FLAC and MP3 files who is tired of a subscription and of a phone app that will not play a disc number correctly. The audience is narrower than "music lovers". It is people who already tag their files and have opinions about the result.

The feature list is built around that reader too. Disc numbers, multiple artists, precise and original dates, sort tags, an artist system that unifies artists and album artists, SD Card-aware folder management, search, and embedded cover art. Automatic gapless playback and full ReplayGain on MP3, FLAC, OGG, OPUS and MP4 files sit alongside, plus external equalizer support such as Wavelet and Android Auto support.

The permissions tell the same story. Storage access comes as `READ_MEDIA_AUDIO` and `READ_EXTERNAL_STORAGE` for reading the files, `FOREGROUND_SERVICE` and `WAKE_LOCK` for keeping playback alive in the background, and `POST_NOTIFICATION` for the ongoing playback and music loading notifications. Three permission groups, and no network permission anywhere in that list.

The patched Media3 is the reason a source build needs a Unix shell

Auxio does not use stock Media3. It relies on a patched version of Media3 that enables some extra playback features, with taglib handling metadata parsing, and the patch is why the build carries 3 caveats, and the project states all of them plainly.

All three are non-negotiable. `cmake` and `ninja-build` have to be installed before building. The project uses submodules, so an initial clone needs `git clone --recurse-submodules` to pull the external code down properly. And you are "unable" to build the project on Windows, because the custom Media3 build runs shell scripts that only work on Unix-based systems.

That last point is the interesting one, and it is easy to skim past. The extra playback features and the Unix-only requirement are the same fact. A Windows developer cannot get a partial build either; there is no supported workaround documented, and no Gradle-only path is offered.

The top-level tree reflects that native weight. Alongside the usual `app/`, `gradle/`, `gradlew` and `fastlane/` entries sit `media`, `musikr/` and `eclipse-cdt.xml`.

Cloning with submodules, then assembling the debug APK

There is no single install command in this project, because there is nothing to install: Auxio ships as an Android application, distributed through F-Droid and Accrescent under the package id `org.oxycblt.auxio`, with releases also published on GitHub. Building it yourself needs Android Studio, the NDK, and a Unix host, and the clone has to pull submodules:

git clone --recurse-submodules

Select NDK version 28.2.13676358, found under Languages & Frameworks > Android SDK, and Java 21 installed through the system package manager:

sudo pkg -S jdk21-openjdk

It also gives the package manager line for Android Studio itself:

pkg -S android-studio

With the JDK set to jdk21-openjdk in the IDE and the NDK present, the build is a Gradle invocation from the repository root:

./gradlew assembleDebug

To get it onto a phone over USB, enable Developer Options by tapping Build number seven times under Settings > About phone, turn on USB debugging under Settings > Developer options, connect the cable and accept the prompt. Check that the device is detected from the SDK platform-tools directory:

cd ~/Android/Sdk/platform-tools
./adb devices

Install, and Auxio appears in the app list:

./gradlew installDebug

To try it without a desktop library already in place, push a folder across:

cd ~/Android/Sdk/platform-tools
./adb push ~Music/ /sdcard/Music

That path assumes the SDK under `~/Android/Sdk`, and the README writes the source folder as `~Music`. The rest of the recipe, the Gradle commands, are portable across Unix.

Unifying artists and album artists will collide with some tagging habits

The artist system changes what a user sees more than any other feature, and it is a deliberate choice rather than a bug. Auxio unifies artists and album artists.

For a library labelled by someone careful, that is exactly right, and it is what makes multi-artist compilation browsing tolerable. For a library that uses album artist as a filter, an ensemble field to separate a guest appearance from a band credit, or a compilation credit, check how the unified view presents a distinction the tagger made on purpose.

The same trade-off shows up in the UX description itself, which calls the experience "Opinionated UX that prioritizes ease of use over edge cases". Read that as a specification rather than a slogan. The disc number, the original versus precise date choice and the sort tag handling all push the same way: Auxio resolves ambiguity in favour of the browsable result, and the edge cases lose.

A useful counterweight is the SD Card-aware folder management.

The dev branch is the unstable one, and that trips up contributors

The default branch of the repository is the development version, and a stable version sits on the `master` branch. Anyone who clones without reading that line gets the moving target.

For a user pulling a signed build from F-Droid or Accrescent, the branch question does not arise. For a reader who wants to read the source, or a contributor who wants something that builds, it decides whether the checkout in front of them matches what most people run. Neither branch has a documented cadence or a support window.

The repository is not archived, and the last push landed on 2026-11-02.

Contributions run through a Contribution Guidelines document, and the project is direct about what it turns down: feature additions and major UI changes are the ones turned down most often, with a wiki page titled Why Are These Features Missing? behind that. For an app that intends to stay small, that is a coherent way to keep it small.

What Auxio leaves out: sync, a server, and its own equalizer

The omissions are as much a part of the design as the features. Auxio has no cloud library and no phone-to-phone sync, because a library built from files on the device is a library with no second copy anywhere. Moving to a new phone means transferring the music again, then pointing Auxio at it.

The equalizer is external. Support for one such as Wavelet is what Auxio offers, which means the audio path has to pass through another app's processing, and the in-app tone controls stay outside Auxio's own surface. If you want per-track EQ decisions made in the player, that decision is not available here.

What Auxio does not give up is playback correctness for the formats it does handle. Full ReplayGain on MP3, FLAC, OGG, OPUS and MP4, automatic gapless playback, playback state persistence so the app resumes where it stopped, headset autoplay, and adaptive home-screen widgets are all in the feature list. The gaps are all about moving music around and shaping the sound, not about playing the album in order.

The cloud-streaming alternative is the real comparison, and the difference is architectural rather than cosmetic. YouTube Music or Spotify hold the catalogue on a server, resolve the correct recording of each album for you and stream it, which is why a phone with no copy of an album can still play it. Auxio takes the opposite position: the tags on your disk are the authority, which is what makes disc numbers and original date stamps render correctly, and what makes a full-library restore your problem instead of the vendor's.

Verify one multi-artist album before moving a whole library

Adopt Auxio if your music is already a folder tree of files with real tags on the device, and if the payoff you want is playback correctness: gapless between tracks, ReplayGain normalisation across a compilation, disc numbers that survive the browse. Reading the source is a reasonable exercise too, since the build is a documented Gradle invocation and the packaging is under `fastlane/`.

Do not adopt it expecting a streamed catalogue, cross-device sync, or a built-in equalizer, and do not plan a Windows build, since the custom Media3 step runs shell scripts and the project says so without offering a fallback.

Verify one thing first: how the unified artist system renders a multi-artist or compilation album from your own tags, before you point the app at everything. Grant `READ_MEDIA_AUDIO` on Android 13 or later, let the scan finish, and open an album where the band credit and the guest credit differ. What you see there decides whether the rest of your library is going to read correctly.

Editorial conclusion

Auxio suits anyone whose music already lives in a folder tree on one device and who wants gapless playback, ReplayGain and disc numbers without an account or a network call. It does not suit people who want a streamed catalogue, phone-to-phone sync or a built-in equalizer, because none of those appear anywhere in the project. Verify one thing before you move a whole library across: open a single multi-artist or compilation album with the `READ_MEDIA_AUDIO` permission granted, and see whether the unified artist entry matches what the tags say.

Frequently asked questions

Official sources

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