Chocola: an offline Android music player with an equalizer and lyrics

What Chocola does, feature by feature

Chocola is described as a cute and powerful offline music player for Android, and it was formerly CuteMusic. The rename is visible in the repository's own links, where the GitHub releases page and the F-Droid listing both still point at com.sosauce.cutemusic, and in the badges, which reference the CuteMusic repository. The project has been under a new name for long enough that both identities are still in circulation.

The feature list is more informative than the tagline. Material 3 Expressive design, a UI described as fluid and highly customizable, a built-in equalizer, embedded and synced lyrics support, a metadata editor, blacklist and whitelist folders with additional scanning rules, custom playlists with customization support, and rich playback controls covering speed and pitch, repeat modes and a sleep timer.

Two of those deserve more than a list entry.

The metadata editor is unusual for a player. A music player that can write tags is a different thing from one that only reads them, and the reason a local player needs it is that the tag is the only metadata the file has. If your files came from a download with no tags, or with tags from a different tool, the player has nothing to show you until something writes them. A built-in editor means the library can be fixed rather than replaced.

The blacklist and whitelist folders with additional scanning rules are the other one. Any local music player faces the problem that a music folder also contains ringtones, voice memos, podcasts and notification sounds, and the usual answer is that the player tries to guess. Chocola takes the position that the user tells it, which is both simpler to reason about and more predictable, and the additional scanning rules cover cases where a folder boundary is not the right boundary.

The remaining claim is about resources: offline, low storage usage of roughly 15Mb on a fresh install, and no unnecessary permissions. For an Android app, the permissions line is the substantive one, since a music player that asks for network access or location for no reason is a common complaint, and an offline player that asks for nothing beyond storage access has a narrow attack surface.

The primary language is Kotlin, the licence is GPL-3.0, and the release history shows v4.4.2, v4.4.3 and v4.4.4 in the last week of September 2026, with the last push on 2026-10-15.

Three distribution channels, and the recommendation to skip two of them

The README links three places to get the app, and then tells you to prefer one of them.

The three are GitHub releases, IzzyOnDroid at apt.izzysoft.de, and F-Droid at f-droid.org, with the F-Droid badge and the IzzyOnDroid badge both in the README.

The recommendation is explicit: I recommend installing from GitHub, as it guarantees access to the latest update. That is a statement about release ordering rather than about quality. F-Droid builds from source on its own infrastructure and its own schedule, so a commit merged upstream appears on F-Droid later. IzzyOnDroid is a community repository maintained by a different person, with its own build cadence. The GitHub release is built by the author and is therefore the newest available artefact.

That is a real trade-off, and it is the usual one. The GitHub release is the current code and carries the author's own signature; the F-Droid build is the one that is more likely to be reproducible, to be built by a third party from a signed tag, and to be delivered through a channel that does not depend on one person. For a user who cares about getting the newest features, GitHub is the answer; for a user who cares about the provenance of the binary and the app's continued availability, F-Droid is the safer dependency.

The project addresses the provenance question directly. You can find the SHA-256 here, linking to a page on the author's site, and the README puts that line right at the end near the copyright notice. Publishing a checksum on a separate site is a weaker arrangement than a signed release, but it is more than most projects do, and it gives a user something concrete to check the downloaded APK against.

The build system in the repository supports the F-Droid route, which tells you something about how the project is set up. There is a build.gradle.kts, a settings.gradle.kts, a gradle.properties, the gradle/ directory with the wrapper, and the gradlew and gradlew.bat wrappers. There is an app/ directory, which is the standard Gradle layout for a single-module Android application, and a fastlane/ directory for release automation and store metadata. A fastlane setup is what makes it feasible to publish to F-Droid and IzzyOnDroid, since both need a reproducible build from a tag rather than an artefact uploaded by hand.

The package identifier is com.sosauce.cutemusic, and it has not changed with the rename, which is why both repositories list the same app.

A teen developer's project, and what that means for its pace

There is a line at the end of the README that says, plainly, that if you are enjoying Chocola you should consider giving a star to support a teen develop the experiences you love most, next to a picture of the app's chibi character waving.

That single detail tells you a great deal about the project. It is maintained by one young developer, which means several things at once. The release cadence is fast, with three tagged releases in the final week of September 2026, because a single maintainer shipping to their own audience is not going to wait for a quarterly cycle. The support model is informal, with a Discord server and a ProtonMail address, [email protected], and a link to a support page on the author's own site.

The tone of the project is a deliberate part of its identity, and it is consistent throughout: the name Chocola, the pink badge colour, the description of the UI as Gorgeous, fluid and highly customizable, and the closing line Makes you a cutie. For a music player, that is a coherent position. A music player is a personal, emotional object that people look at more than they configure, and the difference between an app that feels designed and one that feels like a settings screen is exactly the kind of thing a single author with a strong opinion can deliver and a committee cannot.

None of that is a technical argument, and it should not be mistaken for one. But it is a genuine input for an adopter. The project is GPL-3.0, which means anyone can fork it, and the copyright notice puts the year at 2026 with the author named as sosauce. For a community member who wants a local music player with a specific behaviour that the upstream does not have, a small, readable, well-structured Kotlin application is a good base to fork, and the licence permits that without asking.

The honest counterpoint is that a single-maintainer project carries continuity risk, and the fastest-moving releases mean the app's behaviour, including the equalizer and the scanning rules, can change between versions. Chocola is at version 4.4.4, so the API and the preferences have already been through four major lines of change.

Contributing, and the GET_STARTED file that points the way

The contributing story is one line in the README, and it points to a file.

To get started with contributing, please check the get started readme, linking to GET_STARTED.md in the repository. The top-level listing confirms that file is there, alongside a README_ES.MD, which is the Spanish translation, and the repository's own README.

The presence of GET_STARTED.md as a separate document rather than a section of the README tells you something about the project's maturity. A project with a single developer and a fast release cadence does not have time to write a long contribution guide into its front page, so the guide lives in its own file and the README points at it. For a contributor, that file is where the actual workflow is described, and the fact that it is named for beginners rather than for maintainers suggests the project is actively recruiting people who have not contributed to an Android app before.

The Spanish README is a related detail worth noting. The README badges include a Disponible en español badge, and the file is README_ES.MD rather than a separate locale directory, which suggests the project keeps a second full translation rather than a set of per-language files.

And the translation of the app itself is run through Weblate, with the hosted project at hosted.weblate.org for chocola and a widget showing the translation status. That is the same model AutoShade and Rush use, and it is the sensible one: the string catalogue lives in a translation management platform where the strings are translated in context, and the app pulls the result at build time.

The community contact is a Discord server, and the support route is a donation link on the author's own site. There is no issue tracker policy described in the README, no code of conduct file mentioned in the visible text, and no security policy either, which for a GPL application distributed as an APK is a small gap in the documentation.

Where Chocola is the wrong choice

There are three limits, and the first one is the obvious one.

The first is that it is an offline player for local files. Every feature in the list, the equalizer, the metadata editor, the folder rules, the synced lyrics, is in service of a collection you already hold on the device. If your listening is on Spotify or Apple Music, this is the wrong app, and the name offline is the whole specification rather than a limitation of it.

The second is that the synchronised lyrics support is bounded by what the app can do with a lyrics file. Lyrics with timestamps, the LRC format, are a file format, and a file format is either present alongside the audio or it is not. A player that ships with a lyrics feature cannot manufacture synchronised lyrics for a track that has none, and the README does not describe any service that would fetch them. The same applies to the embedded form, which is a tag inside the file. So the feature works, but it works on libraries that have already been prepared.

The third is the metadata editor, and this one has a subtlety. Editing tags writes to the file, and the README's own claim of low storage usage and no unnecessary permissions sits oddly next to a feature that mutates the user's library. The scanning rules and the blacklists and whitelists exist to keep the app away from files it should not touch, and the metadata editor is the one feature that reaches the other way. A user who points Chocola at a music library that is also their only copy, without a backup, is relying on the editor to behave. The README does not document a backup step, an undo, or how the app treats read-only media, so the practical advice is to back up before editing tags.

There is also the continuity point from the previous section, and it applies more strongly to an Android app than to a library. A single-maintainer app that ships releases weekly will change its preferences, its scanning behaviour and its database layout without a deprecation cycle, and an app installed from GitHub is not covered by the Play Store's update guarantees. IzzyOnDroid and F-Droid exist partly to mitigate that, and choosing the GitHub release to get the newest version means choosing the fastest-moving channel as well.

Chocola against the alternative music players

The comparison splits cleanly by what the player is for, and the honest answer is that Chocola is a local-files player and a large part of the category is not.

The first alternative is a streaming client's offline mode. Spotify, YouTube Music and Apple Music all cache to the device and play without a connection, and they bring a catalogue, a recommendation engine, cross-device sync and a proper queue. What they do not give you is the equalizer that acts on the file, the metadata editor that writes to your library, and folder scanning rules that decide what is music. Chocola is better on those three and much worse on everything else, and the choice is about which of those things matters to you.

The second alternative is the open-source local player category, and here the differences are in the details. The features that distinguish Chocola within that group are the scanning rules, the metadata editor and the synced lyrics, plus the Material 3 Expressive presentation, which for a music player is a real difference rather than a cosmetic one. The licence is GPL-3.0, which is the most permissive of the practical alternatives, and that matters for anyone who wants to fork it.

The third alternative is not a player at all. A media server or a local file server, with the phone as a remote control, plays the same files and does it without a second install. It is more work to set up and it gives you no equalizer and no metadata editor, and the audio quality path is worse because you are streaming over the network rather than playing locally.

So the deciding question is narrow. If your music is on your device, Chocola is a good local player with an unusual amount of library management built in. If your music is in a service, this is the wrong app and no amount of feature comparison changes that.

Editorial conclusion

Adopt Chocola if you want an Android music player that works entirely from local files, you want a real equalizer and synchronised lyrics rather than a streaming client, and you are willing to install a GitHub release rather than a store build. Do not adopt it if you rely on a streaming catalogue or on background playback features the project does not document. Verify first that the release you install matches the source in the repository, using the SHA-256 the project publishes, and that the metadata editor and scanning rules behave the way your library needs before you rely on them.

Frequently asked questions

Official sources

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