LX-X Music Mobile: a personal React Native fork of lx-netease-music-mobile

What LX-X Music Mobile is, and who it is actually for

LX-X Music Mobile is an Android music player written in TypeScript on React Native. It is a fork of a third-party modified version, lx-netease-music-mobile, which itself derives from the lx-music-mobile lineage; the README states plainly that this repository is a further modification of that fork and is meant for personal use. The upstream address is listed as github.com/souvenp/lx-netease-music-mobile.

The changelog is the clearest statement of intent. Releases between June and August 2026 add features that a single maintainer wanted: a 4x2 home screen widget, custom fonts, per-songlist position memory, theme import and export, and a Xiaomi speaker integration that pushes a playlist over the local network after logging into the same Xiaomi account. None of that is a roadmap for a general audience. If you are looking for a maintained product with support, this is the wrong project. If you already run a self-built Android music player and want a base to modify, the repository is public and licensed under Apache-2.0.

The audience is narrow on purpose. You need to be comfortable with the React Native toolchain, because the only documented way to get the app is to build it from source.

How the React Native app is put together

The repository layout follows a standard React Native Android project: index.js as the entry file, src/ for application code, android/ for the native shell, metro.config.js for the bundler, and babel.config.js for transpilation. The package.json name is lx-lxwalnut-music-mobile and the version tracks the release tag, currently 26.08.19 with versionCode 260819.

What is more interesting is the postinstall hook. It runs four patch scripts in sequence: patchMediaLayout.js, scripts/apply-rntp-eq-patch.js, scripts/apply-slider-patch.js, and scripts/apply-file-system-multi-patch.js. These patch dependencies after npm installs them. That pattern tells you something about the project's position: it depends on upstream libraries whose behaviour it needs to change, and rather than vendoring them it rewrites them at install time. It works, but it means a dependency upgrade can break a patch silently, and the patches are part of the build contract whether or not they are documented.

The engines field requires Node 18 or newer and npm 8.5.2 or newer. There is also a build:theme script that runs node src/theme/themes/createThemes.js, which suggests themes are generated rather than hand-written, and a publish script under the publish/ directory used for releases.

Building the APK and a first real session

There is no published APK download in the README; the release badge points at GitHub Releases, but the install path the repository documents is a local build. Start by cloning the repository and installing dependencies. The postinstall step runs automatically, so do not skip it.

npm install

After install, the four patch scripts under postinstall will have run against the dependency tree. If any of them fails, stop and read the error rather than continuing, because the build assumes all four patches applied.

To build a release APK, the package.json defines pack:android, which changes into the android directory and runs the Gradle wrapper. Note that the script as written uses gradlew.bat, so it is oriented at Windows; on other platforms you will need to invoke the Gradle wrapper directly.

npm run pack:android

The output lands under android/app/build/outputs in the usual Gradle layout. For development against a connected device or emulator, the dev script builds and installs a debug variant for the active architecture only.

npm run dev

Once the app is running, the first thing worth configuring is a music source. The changelog mentions a source management area that was split out of basic settings into its own section, a maximum of 50 imported sources, and a source test feature whose logic was reworked in 26.08.19 to speed up testing. Import your source files there, run the test, and confirm which quality tiers each source reports before you rely on playback.

Playback fallbacks, caching and the failure modes the changelog admits

The release notes are unusually candid about how playback fails, which is useful when deciding whether to trust the app. Version 26.08.08 added a fallback strategy: when a network load fails, the player reads a locally cached copy of the song instead. The same release added a notification-bar keep-alive mechanism to stop the system from reclaiming the process. Version 26.06.7 describes reworking audio playback logic to fix an infinite-loading hang caused by expired URLs and local cache problems.

Read those together and you get the real picture. This player depends on remote URLs that expire, on third-party sources that change without notice, and on a mobile OS that kills background processes. Each release is a patch against one of those failure modes. That is not a criticism of the code; it is what any client for scraped or user-supplied sources looks like. But it means reliability is a moving target, and a version that works today can degrade when a source changes.

The 26.08.19 notes also mention fixing a 418 error during playback and repairing metadata for data imported from the original app, which is auto-corrected on the next play. That is a migration path, but a lazy one: it happens at playback time, not at import time. If you have a large library imported from an older build, expect the first pass through it to be the point where problems surface.

WebDAV, local libraries and the sync warning

Two storage features matter for anyone considering this as a daily player. WebDAV playback arrived earlier and was extended in 26.07.23 with Openlist compatibility, with one documented constraint: when mounting a local server you must use the machine's LAN IP, because loopback addresses will not play. WebDAV songs can also fetch cover art automatically, and a later release added uploading songs to WebDAV.

The local side grew in 26.08.08 with library scanning, quality display, metadata editing and file information viewing. That combination, a remote WebDAV library plus a scanned local library, is the reason someone might pick this fork over the upstream.

Against that, the README carries a warning near the top: features involving sync and backup have not been fully tested, and you should back up important files yourself. That is the maintainer telling you the data layer is the least trustworthy part of the app. Treat any backup or restore feature as unverified until you have tested it with disposable data, and keep an independent copy of anything you would be upset to lose.

Where this fork diverges from lx-music-mobile

The obvious alternative is lx-music-mobile, the project this one is ultimately derived from, and the difference is not cosmetic. Upstream is a general-purpose player with a wider user base and a release process aimed at distribution. This fork is a personal branch: the README says so, the changelog reads like a list of one person's fixes, and the package.json is marked private.

The practical difference shows up in what gets removed. Version 26.08.08 removed all GitCode-related functionality, the song source alias display, audio unloading, swipe-to-change-song, and the list auto-refresh. Version 26.06.7 removed the English language configuration outright, with a parenthetical in the notes making clear the maintainer did not see a need for it. A general-purpose project would not make that call; a personal fork can.

So the trade-off is explicit. You get features upstream may never add, such as Xiaomi speaker push and the theme import/export system. You give up the assumption that anyone else cares whether your language, your platform or your workflow still works. If you want the broader project, go to lx-music-mobile. If you specifically want this feature set and can read the code when something breaks, this is the one.

Licence, upgrade cost and what the repository does not tell you

The repository is licensed Apache-2.0, and the LICENSE file is present at the top level. Apache-2.0 permits commercial and private use, modification and redistribution, and it includes an explicit patent grant. It also requires that you retain the licence and notices and state significant changes. For a personal build that requirement is easy to satisfy; if you redistribute a modified APK, it is not optional. This is a description of the licence text, not legal advice, and the fork's own obligations to the upstream projects it derives from are worth checking before any redistribution.

Upgrade cost is the part the repository is quietest about. There is no documented rollback procedure, no migration guide between releases, and no compatibility statement for user data across versions. The release notes describe a fix that auto-repairs metadata imported from the original app on next playback, which implies data formats have already shifted once. The postinstall patch scripts add a second upgrade hazard: bumping a dependency can invalidate a patch.

The honest summary is that upgrades here are a rebuild-and-test exercise, not a download-and-install one. Keep the previous APK before you replace it, and keep an independent backup of your library, because the README does not promise either will be recoverable.

Editorial conclusion

Adopt it only if you are willing to build an Android APK yourself and treat the README's own warning as binding: sync and backup are not fully tested, so back up anything you care about before you rely on it. Skip it if you want a supported product, an iOS build, or a documented upgrade path; the README does not document rollback, and the release notes describe removals, not migrations. Before building, check that your Node version satisfies the engines field and that the Xiaomi speaker features match your hardware, since the notes name only one tested device.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. WalnutBai/lx-lxwalnut-music-mobile on GitHub