Fossify Music Player and the case for an offline Android music app

A music player whose only server is your phone

Fossify Music Player sits in the middle of the Android market where a music app is usually also an advertising network. The project's own description calls it a clean music player with a customizable widget and no ads, and the README repeats the point in more detail: the app is ad-free, it does not collect or share user information with third parties, and it operates completely offline.

That offline claim is the part that shapes the whole design. Nothing in the documentation mentions signing in to a streaming service, a catalogue sync, or a network request of any kind, and the app is described as not requesting unnecessary permissions. Read strictly, this is a player for music you already hold on the device, not a front end for a subscription library. That is a narrower product than the large streaming apps, and the appeal is precisely that the music never leaves the handset and no account is required.

The audience is therefore fairly specific: people who have a folder of music, an SD card or downloaded albums, and who prefer an app that does not want anything from them beyond the permission to read their own files. The distribution badges in the README point to Google Play, F-Droid and IzzyOnDroid, so the audience also includes people who avoid the Play Store entirely.

Equalizer presets and the sleep timer are the two named audio features

Two audio features get their own sections in the README, and they are the ones that show up in day to day use.

The equalizer is described as offering a range of presets to suit different genres and audio preferences, with adjustment based on the listener's mood, genre, or audio setup. The documentation is deliberately vague here, and it should be read that way: it does not enumerate the preset names, does not say how many bands the equalizer has, and does not explain whether the control is a system-level one or an in-app one. Android treats equalizer access differently depending on the manufacturer and the audio path, and the README does not address that, so treat the availability of a given preset as something to confirm on your own handset.

The sleep timer is simpler and completely described. You choose a duration and the playback fades away rather than stopping abruptly, which is the detail that makes it usable for someone who wants music to end while they fall asleep. The README does not document whether the fade length is fixed, whether the timer can be extended mid-playback, or whether it applies to the queue only or also to the current track, so those behaviours are worth checking rather than assuming.

Neither feature is novel in the Android music player category. What is notable is that they are presented without a subscription attached to them.

Playlist management stops at the device, with metadata you can edit

The README's playlist section covers creating and organising playlists, customising track labels, and editing song information. Playback control is listed alongside it: shuffle, repeat, skip and forward.

The interesting detail is the track label and song information editing. A music player that lets you rewrite tags is effectively a tag editor, which matters for anyone with a library that came from a decade of inconsistent sources. The documentation does not state which metadata fields are writable, whether changes are written back to the file on disk or only kept in the app's own database, or whether a rescan is needed. That last point is a real practical difference between players, and this README is silent on it.

What the README does not mention is at least as informative as what it does. There is no mention of lyrics fetching, no gapless playback, no cross-device or cloud library sync, no podcast support, no audio format list, and no indication of what happens to a file that is removed while the app is running. For a music player, the absence of a stated format list is a genuine gap, since whether FLAC, OGG or WAV playback works depends on the platform and the device rather than on the app alone, and the documentation gives you no way to check.

There is a privacy angle to the offline model worth stating plainly. Because the app works with no network connection, a privacy claim about not sharing data is structurally easy to keep, which is a different and stronger argument than a policy promise from a server-side app.

The widget and headphone buttons are the control surface

The README highlights customizable widgets and interface colours, and says you can control playback from the status bar, the widget, or the headphone buttons. This is the part of the design that separates a phone music player from a file manager with an audio button.

The widget is the interesting piece because it is persistent. A widget is visible from the home screen or lock screen without opening the app, so the common loop of checking what is playing, skipping a track, or pausing becomes a one-gesture action instead of a launch, a scroll and a tap. The project description calls it a customizable widget, and the README says the interface colours are customizable too, which suggests the widget presentation is not fixed but themed alongside the app.

The headphone button handling is worth calling out because it addresses a genuine annoyance in music apps: getting a track paused by a stray button press while the phone is in a pocket. The documentation does not specify which hardware buttons are supported or how they are mapped, and it does not describe any gesture handling, so the exact behaviour on your device is something to verify rather than assume.

What the documentation does confirm about the interface is a material design, a dark theme option, and a general approach of visual restraint. There is no mention of themes beyond colour, no tablet-specific layout, and no indication of how the app handles rotation or large screens.

Building from the Gradle wrapper instead of the store

The README documents distribution through the three store badges and contains no build or install commands, so there is nothing to copy here for a local build. The repository layout is where the build story lives. At the top level there is `build.gradle.kts` and `settings.gradle.kts`, a `gradle/` directory, the `gradlew` and `gradlew.bat` wrapper scripts, and `gradle.properties`.

Those wrapper scripts are the standard way to build this project and the only build entry point in the tree:

gradlew
gradlew.bat

Two more entries in the same list tell you what a self-build would involve. There is a `keystore.properties_sample`, which means the project expects a release signing configuration that you supply yourself rather than one committed to the repository. There is also a `detekt.yml` for static analysis and a `lint.xml` for Android lint, so the project carries its own analysis configuration. A `Gemfile` and `Gemfile.lock` sit alongside them, and the `fastlane/` directory with `fastlane/metadata/android/en-US/images/` holds the store listing material, which is how the screenshots in the README are stored.

A build from source therefore needs the Android SDK and a JDK on the path, plus your own keystore for a signed release. The documentation does not give a version requirement for either, and it does not describe a release process, so an in-house rebuild of a signed artifact is more work than the store route suggests.

GPL-3.0, a three-patch release day, and what the licence means for shipping it

The licence field on the repository says GPL-3.0. For an end user installing the app from a store this has no practical effect. For an organisation that wants to bundle the app into an image, redistribute a modified build, or run it on managed devices, GPL-3.0 carries the usual obligations around conveying source and licensing derivatives, and it is worth having a lawyer read the terms for your specific distribution model rather than taking a summary as advice.

The release history shows a quick cadence at the top of the version range: 1.8.2, 1.8.3 and 1.8.4 were all published on 2026-10-10, and the last push to the repository was on 2026-10-19. The project is not archived, and the recent activity is consistent with an application that ships small fixes often. The `CHANGELOG.md` in the root is the place to read what actually changed between builds, and with three releases on one day, the changelog matters more here than the version number.

The main upgrade cost for an adopter is the gap between store channels. The Play Store, F-Droid and IzzyOnDroid builds are packaged and signed separately, so a version bump on one channel does not arrive on the others at the same moment. The repository has a `CONTRIBUTING.md` and a `CODEOWNERS` file, and a `.fossify/` directory, which suggests the branding and shared configuration are managed centrally, but the README does not describe a release automation pipeline, so treat the channel lag as a fact to check rather than a timing question.

Where this player is the wrong choice

Three cases stand out.

First, if your music lives in a streaming service, this app does not address it. There is no sign-in, no catalogue, and no sync described anywhere in the documentation, and the offline design is a deliberate constraint rather than a missing feature waiting to be patched.

Second, if you are on iOS. The project is an Android application, with Kotlin, Gradle and the `app/` source directory, and the distribution badges point to Android stores only. A team that needs one player across both mobile platforms has to keep two applications.

Third, if the music lives on a NAS or a media server rather than on the phone. The model here is on-device playback, and the documentation describes no remote library browsing, no streaming over the local network, and no ability to point the app at a different library folder.

Compared with the alternative approach of indexing a library on a desktop machine and syncing the resulting files or a remote stream to the phone, Fossify keeps the entire job on the handset. That removes a server to run and a network to trust, and it costs you remote access to a large collection. Which trade is better depends on where the music is and who maintains the device, not on which player has more features.

Editorial conclusion

Pick Fossify Music Player if you want a single on-device app for a local music collection, you care about ad-free playback, and you are willing to install builds from a store rather than from a vendor site. Do not pick it if your library lives in a streaming service, if you need gapless playback, lyrics or cross-device sync, since none of those appear in the documented feature set. Before you switch, check the download source you intend to use, because the Play Store build, the F-Droid build and the IzzyOnDroid build are separate artefacts that can lag each other, and confirm that version 1.8.4 behaves the way you need on your device.

Frequently asked questions

Official sources

1. FossifyOrg/Music-Player on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases