LX Music Mobile: a React Native music player for Android that ships no audio

The problem LX Music Mobile solves, and who it is actually for

Most Android music players assume the app is also the thing that fetches the audio. LX Music Mobile splits those two roles. The app is a client: it holds your playlists, your search UI, your playback queue and your local list data, and it delegates the actual audio lookup to a custom source configured in its settings. The README describes the split bluntly. The project has no ability to fetch audio data on its own; what it does is pass the song title and artist to the source, and if the source returns a link, the app treats that link as the audio for that song.

That design makes the audience narrower than the download numbers suggest. This is for Android users who already know which source they want to point it at, and who are willing to read the settings before pressing play. The README says so directly: the default settings and UI operations are deliberately not aimed at beginners, and it recommends browsing the settings once and reading the playlist mechanism documentation before use. If you want an app that works the moment it installs, this is not it. If you want a client whose behaviour you can inspect and change, the split is the whole point.

The platform scope is equally explicit. Supported platforms are Android 5 and above. The README states there is currently no plan to support iOS or HarmonyOS NEXT. A desktop sibling exists as a separate repository, lx-music-desktop, and the two are not the same codebase.

How the custom source mechanism actually works

The data flow has three stages, and only the first two live inside the app.

Stage one is the official platform metadata. The README says the online data for the built-in platforms is pulled from their public servers, the same data an unauthenticated user would see in the official app, then lightly filtered and merged for display. The project states it takes no responsibility for the legality or accuracy of that data.

Stage two is the handoff. When you play a track, the app sends the song name and artist to whichever source is selected under the custom source setting. That is the entire contract. There is no format negotiation described in the README, no quality fallback chain, no verification step.

Stage three is entirely outside the project. If the source returns a link, the app uses it. The README is candid that it cannot validate whether the returned audio matches the requested song, so the documented failure mode is playing the wrong track or failing to play at all.

A fourth path exists for your own data. Non-official data such as the contents of your lists comes from local storage or from a sync service you connect. Since v1.0.0 the project publishes a separate sync server, lx-music-sync-server, which you can deploy on your own machine to sync across devices. Nothing in the README suggests a hosted option; the sync server is something you run.

The stack is React Native with Redux, written in TypeScript, and the repository layout reflects that: src/ for application code, android/ and ios/ directories, metro.config.js and babel.config.js at the root. The ios/ directory exists in the tree even though iOS is not a supported target, which is a normal artifact of the React Native template rather than a sign of an imminent iOS release.

Installing the LX Music Mobile APK and configuring a first source

The README points downloads at GitHub Releases and states that the only original distribution channel is GitHub; anything else is a third-party repost unconnected to the project. The default branch is master, while contributions go through the dev branch.

If you build from source instead of installing a release, the README links to a source-usage guide on the documentation site. The package manifest requires Node 18 or newer and npm 8.5.2 or newer. The Android debug build script is named dev, and it runs React Native against the active architecture only:

npm install
npm run dev

For a release build the script is pack:android, which changes into the android directory and invokes the Gradle wrapper. On Windows the script calls gradlew.bat, so if you are on Linux or macOS you will be running the wrapper yourself rather than through that npm script.

npm run pack:android

Before any of that, start the Metro bundler in one terminal and keep it running:

npm start

After installing a release APK on the device, the first real task is not playback, it is the source. Open the settings, find the custom source option, and select the source you intend to use. The README does not document a bundled default source, so treat the selection step as mandatory rather than optional. Then read the playlist mechanism page linked from the README, because the project warns that the default configuration is not beginner-friendly.

One useful development shortcut is in the scripts: menu sends the Android menu key event through adb, which opens the React Native developer menu on a connected device.

npm run menu

Where LX Music Mobile fails, and the failure is by design

The most important limitation is written into the project's own terms. Because the app cannot verify that a returned link matches the requested song, mismatched playback is an expected outcome, not a bug report. If a source returns the wrong URL for a title, the app will play it and consider the job done. There is no checksum, no duration comparison, no metadata cross-check described anywhere in the README.

The second limitation is scope. Android 5 and above only. The README states plainly that iOS and HarmonyOS NEXT are not planned. Anyone searching for an iOS build is looking for something this project says it will not make.

The third is the onboarding cost, which the maintainer treats as intentional. The README says the default settings and UI are not designed to be beginner-friendly, in order to raise the barrier to use. That is an unusual thing to write down, and it should be read as a signal: the project does not want to optimise for the user who installs and immediately complains.

The fourth is legal. The supplementary terms attached to the Apache-2.0 licence require users to clear copyright data produced during use within 24 hours, and prohibit use that violates local law. The README also asks users to respect copyright and support legitimate services. Those are terms written by the project, not a legal opinion, and they place the compliance burden on you.

Finally, the sync service is self-hosted. If you do not have a server, the multi-device sync feature described since v1.0.0 has nowhere to run.

How LX Music Mobile differs from MoeKoe Music

MoeKoe Music appears in the same search space as this project, and the two take opposite architectural positions. MoeKoe Music is a desktop-oriented client built around a specific commercial streaming platform's interface and API surface. Its playback path is tied to that platform.

LX Music Mobile is the inverse. It is mobile-first, Android-only, and platform-agnostic at the audio layer, because the audio layer is not in the app at all. The custom source setting is the abstraction boundary, and everything above it (lists, search, queue) is generic. The practical consequence is that LX Music Mobile's behaviour is only as predictable as the source you configure, whereas a platform-tied client has a fixed, documented set of failure modes.

The desktop comparison inside the same project is also worth noting. LX Music Desktop is a separate repository. If your target is a laptop rather than a phone, the mobile build is the wrong artifact, and the README links to the desktop project for exactly that reason.

Licence terms and what maintenance costs you

The code is Apache-2.0, but the README states that the supplementary terms in the README take precedence where they conflict with that licence. Those terms add restrictions the base licence does not contain: a 24-hour deletion requirement for copyright data, a prohibition on use that violates local law, and a statement that the project accepts no commercial cooperation or donations. If you are evaluating this for anything other than personal technical exploration, read section eight of the README before you assume the Apache-2.0 grant is the whole story. This is a description of what the project wrote, not legal advice.

On maintenance, the repository is not archived, and the last push was on 2026-09-19, with v1.9.1 released the same day. The release cadence visible in the recent history is uneven: v1.8.4 in May 2026, then v1.9.0 in September 2026, then v1.9.1 a week later. Upgrade cost depends on how you consume it. If you install release APKs, upgrading means replacing the app and re-checking that your custom source still returns usable links, since the source is external and can change without any release here. If you build from source, you inherit the toolchain requirements in package.json (Node 18+, npm 8.5.2+) and the Gradle build, and the repository pins an .nvmrc and an .ncurc.js for dependency updates. The README does not document a rollback path for a bad upgrade, so keeping the previous APK is the only recovery route the README supports.

Editorial conclusion

Adopt LX Music Mobile if you are on Android 5 or later, you are comfortable supplying and maintaining your own custom source, and you accept that the app itself has no audio backend. Do not adopt it if you need iOS or HarmonyOS NEXT, since the README states there is no plan to support either, or if you want a player that works out of the box with no configuration. Before installing, verify two things: that the APK comes from the GitHub Releases page, which the README names as the only original distribution channel, and that your chosen source returns a playable link for the track you actually asked for, because the project states it cannot validate that correspondence.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. lyswhut/lx-music-mobile on GitHub
3. Project website
4. README
5. Releases