subtracks is a native Android client for Subsonic-compatible servers

Why a Subsonic-compatible client keeps mattering

subtracks is an Android client for servers that speak the Subsonic API, and the README names Navidrome, gonic, LMS and Nextcloud Music as the servers it is used with. The problem it addresses is narrow and durable: self-hosted music libraries are common, the servers that host them all implement variations of the same API, and the phone apps for those servers are uneven, often web wrappers or abandoned projects. A client written once against the shared API can therefore serve several back ends at once, and the choice of server becomes a hosting decision rather than a client decision. The target audience is people with a large personal collection who want the listening experience of a modern media player rather than a file browser. The project states plainly that it has no ads and no telemetry, which matters for a client that talks to a server running inside your own house.

Kotlin and Jetpack Compose, with the server treated as an interchangeable backend

The app is written natively in Kotlin with Jetpack Compose, and the current version is a native rewrite based on two and a half earlier iterations of the project that the author coded by hand. That history shows in how the README frames the architecture: decisions belong to the original author even though the code and documentation include text produced by a large language model and reviewed by hand. Architecturally, the important choice is that the server is an implementation detail behind the Subsonic API. A user can connect several servers and switch between them, and the app treats each one as another source of the same library, albums, artists and playlists. The UI leans on artwork: album and artist images appear at full resolution in the detail and now playing views, and the colour scheme is drawn from the artwork of the current song, so the app changes appearance as the music changes.

Building from source with a Nix flake instead of an Android setup

The build story is unusual enough to be worth reading before you try it. The README states that the entire toolchain is provided by a Nix flake, and that the default devshell gives you JDK, Gradle and the Android SDK, so nothing has to be installed by hand. You need Nix itself, and the author points at Lix as the preferred installer. Entering the devshell and assembling a debug build is the whole workflow.

nix develop
gradle :app:assembleDebug

That is a genuine advantage for anyone who keeps a reproducible environment, because the JDK and SDK versions come from the flake rather than from whatever a machine happens to have. It is also a barrier for contributors who do not already use Nix, since the alternative path of installing JDK, Gradle and the Android SDK by hand is not documented in the README.

Installing subtracks without building it

Most people will not build this. The README links a Google Play listing, an F-Droid package under com.subtracks, and GitHub releases, and it also points to signing/README.md for the fingerprints and the commands to verify a download. The presence of a signing document matters for F-Droid and GitHub release builds, where the question of which binary you are running matters, so verifying the fingerprint is a concrete first step rather than a general suggestion. F-Droid carries the project as an open source package, and the README notes that the app has no ads and no telemetry and depends only on free and libre libraries, which are the same properties that make an F-Droid build attractive in the first place.

Offline mode queues stars, scrobbles and play counts

The offline behaviour is the feature that separates subtracks from a simple streaming client. Stars, scrobbles and play counts queue up while the phone has no connection, and they sync back to the server once the phone is online again. That matters because those three values are the ones users care about preserving: play counts drive the recommendation and shuffle logic on the server side, and stars are the hand-made curation that no server can rebuild for you. Download settings sit next to this in the feature list, with per-download quality covering encoding and bitrate, plus a metered-connection setting so large files do not arrive on a mobile data plan. The feature list also covers song-level and bulk downloads, so filling a device for a long trip is a supported path rather than a workaround.

Large libraries and the queue you can rewrite mid-playback

subtracks is built for collections that no other client handles well. The README calls out syncing a whole collection and playing playlists with thousands of tracks as the target case, and the search feature covers the entire library with per-list sort and filter controls, which is what you need once the library is too large to scroll. Playback offers gapless playback, a reorderable queue you can jump through, and loop and shuffle modes. There is also an Up Next action that adds items to the currently playing queue without rewriting it, a small thing that shows the app was designed around an existing queue rather than a replacement one. Stream quality is configurable separately for Wi-Fi and mobile with automatic switching, and system integration covers the media notification and headset or Bluetooth controls.

The GitHub repository is a mirror, and the docs live in two other files

Two structural facts change what contributing means here. The README states that the GitHub repository is a mirror of the repository hosted on a private code forge, synced whenever the author commits there, and that pull requests are pulled in as patches to that forge and synced back, with the contributor kept as the author and the maintainer shown as the committer. Bug reports, feature requests and pull requests are all accepted on GitHub, but a well-crafted issue with reproduction steps and logs is preferred over a pull request. Second, the README delegates detail to two files: AGENTS.md documents the test, lint, screenshot commands and the integration harness, and docs/architecture.md describes the architecture. Neither file is reproduced in the README, so a reader assessing the project has to open them to judge how the code is organised.

GPL-3.0, no ads, and a release line that moved recently

subtracks is free software under the GNU General Public License v3.0. For an end user that means the app can be redistributed and modified, and for anyone who wants to build a variant they must publish their modifications under the same terms when they distribute the result. The project also states that it uses only free and libre dependencies, which is a claim about the dependency tree rather than about the app itself. On the maintenance side the repository is not archived, the last push was on 2026-10-21, and the release history shows v3.0.0 on 2026-10-10 preceded by v2.0.0-alpha.3 from 2023-05-16 and v2.0.0-alpha.2 from 2023-05-07. That gap tells you the native rewrite is what shipped recently, and the v2 alphas are from the older, earlier lineage rather than a current release line.

Editorial conclusion

subtracks suits Android users who already run a Subsonic-compatible server and want a native app with offline scrobble queueing, editable queues and bulk downloads, and it suits contributors who are comfortable with Nix and Gradle. It does not suit iOS users, it will not connect to a music service that does not speak the Subsonic API, and anyone expecting a store app outside the listed channels will not find one. Before adopting it, install from Google Play, F-Droid or a GitHub release and check the signing fingerprints described in signing/README.md, then confirm your server is on the compatible list and that the offline queue syncs the way you expect. Note that the GitHub repository is a mirror of a private forge, so pull requests arrive as patches rather than direct commits.

Frequently asked questions

Official sources

1. austinried/subtracks on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases