MissingCore Music and the deliberate limits of a local Android music player

A local player with Nothing's visual language

The project describes itself as a Nothing inspired local music player, and the word local is doing the most important work in that sentence. There is no account, no catalogue and no streaming integration in the feature list. What the app does is organise and play the audio files already on your device.

The design intent is explicit enough to name. The feature list includes work with the Nothing Music Widget and the Glyph music visualisation, which is a specific hardware integration rather than a general aesthetic. A vinyl record on the Now Playing screen acts as a seekbar, with 24 seconds for a full rotation, or 1.8 seconds if the Standard Vinyl Speed option is enabled. That is a playful choice, but it is a choice about how the app should feel, and it is a stronger differentiator than another set of rounded corners.

The stack behind it is worth noting for anyone who wants to contribute. The README lists React Native, Expo, TypeScript, Zustand for state, React Query, React Native Audio Browser for the file system side, Tailwind CSS for styling and Drizzle for the database layer. That is a modern, entirely JavaScript and TypeScript stack, and it means the app is built with the same tooling a web developer already knows.

The repository is not an application in the desktop sense. The top level contains a mobile directory, a docs directory, a LICENSE file, a PRIVACY_POLICY.md and a THIRD_PARTY.md, and the default branch is dev.

dev is where the work lands, main is where the stable build is

The README is direct about the branch layout: the default branch dev is the development version of the repository, and for the stable version you look at the main branch. That is worth reading twice, because the default branch of a GitHub repository is also what a clone gives you and what most badges and links point at.

The release history shows a project moving quickly. Recent tags include v3.6.0-rc.1 on 2026-09-09, v3.6.0 on 2026-10-10 and v3.7.0 on 2026-10-14, and the last push was on 2026-10-20. A minor version and a patch version landing four days apart, followed by more commits within a week, is the pattern of a project in active development rather than one in maintenance.

The consequence for a user is simple. If you clone the repository you get the development branch, which is not what the Play Store serves. If you want to look at the code that matches a released APK, look at main and then at the tag.

The release cadence has a second effect on support. Documentation in the repository, including the pages on building the app, customisations, experimental features and widgets, is likely to describe the dev branch, and therefore the newest and least settled version of the app.

Play Store and GitHub APKs cannot update each other

The installation section is short, because the app is distributed in the two usual ways for an Android app, and the app itself is published on the Play Store with a matching listing.

The Google Play route is the ordinary one. The GitHub route is a manual sequence: go to the Releases page, download the latest APK, enable Install unknown apps if you need to, and install the APK on your device.

The single most important line in that section is a note rather than a step. If you install the app via Google Play, you cannot update it via the APKs from GitHub, and the same applies in the other direction. The two channels are separate installations with different signing, so an APK from one will not replace an app installed from the other.

That is not a bug, it is the normal consequence of how signing works on Android, but it does mean you have to choose. A user who installs from the Play Store and then finds a newer APK on the Releases page cannot sideload over the top of it, and a user who sideloads never receives a Play Store update. Pick the channel before you install, and if you are testing an experimental build, expect to be on the GitHub side.

The permission table is the clearest statement of what the app touches

The README includes a full permission list, described as hopefully covering all the permissions the app requires, based on those requested in the code and defined in the Android Manifest. For a local player this is the section to read, because the permission set tells you exactly what the app is doing with your device.

Storage access is the core of it. READ_MEDIA_AUDIO covers Android 13 and up and exists to read and play your music files, READ_EXTERNAL_STORAGE covers devices before Android 13, and WRITE_EXTERNAL_STORAGE covers devices before Android 11 and is used to write files to other directories such as backup and M3U.

Playback in the background is handled by FOREGROUND_SERVICE, FOREGROUND_SERVICE_MEDIA_PLAYBACK and WAKE_LOCK, and the stated purpose is to enable media playback while the app is in the background. Two network permissions appear for reasons that are worth noticing. ACCESS_NETWORK_STATE and INTERNET are both present, and the stated purposes are a workaround for ExoPlayer requiring network permissions, and checking and notifying you if a new update is available, with update checks able to be disabled.

That last point is the honest one. A player for local files still asks for internet access, because it checks for updates, and the README says you can turn that off. If your threat model does not allow an installed app to reach the network, that permission line is the reason to think twice, and the way to resolve it is the app setting rather than the manifest.

The metadata editor is separate from the files themselves

One of the more careful product decisions in the app is the local metadata editor, described as being for quick changes with the note that it does not modify the actual file. The distinction matters more than it sounds.

Editing metadata normally means rewriting tags inside the audio file, which is a write to your music library, risks corrupting a file if the process is interrupted, and leaves the tags coupled to the format the player happens to support. If the editor only writes to the app's own database, then the operation is reversible, the original files are untouched, and a reinstall or a change of player does not lose the work.

That is the natural fit for a Drizzle based database layer and an app that already stores its own library index, since the tags can live in a SQLite table beside the file path rather than inside the file. The README does not document the internals of the editor, so the exact behaviour of edits, and whether they can be exported back to the files, is not something you can confirm from the documentation available here.

The rest of the organisation features are conventional: albums, artists, favourites, folder structure, genres and playlists, with multi-artist support, artwork customisability for each of those categories, and lyrics that are bring your own, embedded, or provided by a provider. Background playback with a media control notification and queue manipulation with track removal and reordering complete the player side of the feature set.

Experimental features are labelled instead of hidden

Five features carry an experimental marker in the feature list, and the documentation directory has separate pages for two of them. The marked items are the sleep timer, importing and exporting playlists as M3U files, four widget variants, Android Auto support, and a five-band equalizer.

Labelling is the right approach for an app distributed as an APK outside the store, because the store review process and the release process impose different standards. A feature that is not ready can ship behind a marker rather than being withheld until the next version.

It does mean the app contains code paths that may change shape between versions, and the docs for those features live under a path marked experimental, so their behaviour is not guaranteed to be stable across releases. The screenshots in the README show an Experimental Widgets screen alongside the main ones, which suggests the experimental features are surfaced in the interface rather than hidden behind a debug flag.

The theoretical media format support is also stated carefully. The feature list says the app has theoretical support of the media formats listed in the Android developer documentation, and the wording is the point: theoretical, not tested. The dependency on React Native Audio Browser is what makes any format coverage possible at all, and the honest phrasing leaves room for format specific gaps.

AGPL-3.0 is the licence to read before you fork

The project is licensed under AGPL-3.0. For a consumer who installs the app, that is invisible. For anyone who wants to contribute a change, or base a derived player on the code, it is the first thing to read, because the AGPL's network copyleft reaches further than the GPL into how modified versions are offered to users.

The repository also carries a PRIVACY_POLICY.md and a THIRD_PARTY.md, which is a good sign about how the project treats the parts that are not its own code. The privacy policy matters for a local player in particular, since the audience will reasonably assume that a player of local files does not report their listening, and the existence of a written policy is the place to check what the answer is.

The translation effort shows the shape of the community around it. The README explains that translations moved to Crowdin, thanks the earlier translators, and lists the community translations alongside a TRANSLATORS.md file, with a separate documentation page describing how to contribute a translation. A project that asks for translation help and credits translators by name is organised in a way that makes outside contribution cheap.

For a maintainer reading this before adopting the app, the practical check is narrow and concrete: if you plan to modify the player and distribute it, read the AGPL text and the privacy policy in that order, because both affect what you may and must do with a build you ship.

Editorial conclusion

MissingCore Music fits an Android user who wants a local player with a distinctive look, a metadata editor that does not rewrite files, and glyph integration on Nothing phones. It does not fit someone who wants streaming services, cloud libraries or playback sync, since the player is local by design and the README does not describe any online catalogue support. Before installing, decide which channel you want, because Google Play builds and GitHub APKs cannot update each other, and read the AGPL-3.0 terms if you intend to fork the mobile code.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. MissingCore/Music on GitHub
3. Project website
4. README
5. Releases