# LX-X Music Mobile keeps its whole manual inside the changelog

> WalnutBai/lx-lxwalnut-music-mobile is a personal-use React Native music client for Android, forked from a third-party build of lx-netease-music-mobile. Its README is a running changelog rather than a manual, and its build depends on nine patch scripts that rewrite React Native on every install.

**WalnutBai/lx-lxwalnut-music-mobile** — 基于lx-netease-music-mobile改版，满足个人需求，仅个人自用！！！

- Repository: https://github.com/WalnutBai/lx-lxwalnut-music-mobile
- Stars: 492 · Forks: 45
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-20 · Updated: 2026-09-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/walnutbai-lx-lxwalnut-music-mobile

## The README is nineteen changelog entries and no manual

Open the README and the first thing you get is a release note, not an introduction. Everything visible is version history, newest first, running from 26.09.28 back to 26.06.10 in nineteen dated entries, and each entry is split into four buckets: what was added, what was optimised, what was fixed and what was removed. The version numbers are dates, and the package manifest agrees with the top of the list, carrying version 26.09.28 with a versionCode of 260928. Three GitHub releases exist, for 26.09.28, 26.09.20 and 26.08.19, so the release page and the README track the same three most recent versions. The entries are also wildly uneven: 26.09.20 runs to several dozen lines covering an aggregated platform page, NetEase cloud disk management, a floating bottom player and thirteen separate removals, while 26.09.28 is one addition, five optimisations and four fixes. There is no installation or build section anywhere in it, and the documentation that does exist sits elsewhere, in a doc/ folder and a FAQ.md at the repository root. So the README answers what changed and the manifest answers how it builds, and a reader has to visit both. The project itself is small and busy: 492 stars, 45 forks, 21 open issues, a last push on 2026-09-28 and no repository homepage, which for a personal fork is about what you would expect.

## Nine patch scripts rewrite React Native on every install

The postinstall hook is the single longest line in the package manifest and the most telling one. It runs nine Node scripts in sequence, starting with a local media layout patch and then eight that patch React Native itself: an event queue patch, an edge-to-edge patch, a transition crash patch, a slider patch, a multi-file-system patch, a fetch and blob patch, a fullscreen cutout patch and a foreground patch. That list explains a large part of the changelog without anyone having to write it down. Edge-to-edge behaviour, transition crashes, slider behaviour, fullscreen cutouts on notched displays, the system file picker and background foregrounding are all Android integration problems, and the answer here is to modify the framework in place rather than configure around it. The cost is structural: every npm install rewrites files inside the dependency tree, so a clean checkout is not the same as a fresh install, and a dependency bump can be undone by a patch that no longer applies. There is also a separate build step for themes, a Node script that generates the theme files, and a publish entry point that is a local script rather than an npm publish.

## Android is the only target the scripts admit

Nothing in the build is cross-platform. The dev script runs react-native with the run-android target and an active-architecture-only flag, the release path changes into the android directory and calls a Windows batch file to assemble a release, and the bundle script writes a development bundle straight into the Android assets tree:

```bash
react-native bundle --platform android --dev true --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle --assets-dest android/app/src/main/res
```

The release command is the second half of that story:

```bash
cd android && gradlew.bat assembleRelease
```

The manifest requires Node 18 or newer and npm 8.5.2 or newer, and the package is marked private, so nothing is distributed through a registry and the tagged release is the delivery mechanism. The smaller scripts show the same Android bias: the dev server starts with the experimental debugger flag, one variant exports a NO_FLIPPER environment variable before launching, a reset script clears the Metro cache, another opens the standalone React devtools, and a separate test bundle writes to a different output path than the real one. Two details tell you what building it involves: the dev menu is opened over adb with a key event, and the full clean command explicitly preserves the keystore properties file and the keystore files themselves while deleting everything else, which means the signing key is yours to supply and the scripts are written to survive around it. A few features are plainly Android accommodations too, a notification bar keep-alive so the system does not reap the process, and a keep-awake toggle on the playback page.

## Playback is a fallback chain, because the stream is treated as unreliable

The most repeated theme in the changelog is what happens when a song will not play, and the answer has three layers. A default retry switch governs how often playback is attempted again. Automatic source switching kicks in when a source fails, which means the app tries a different route to the same track rather than giving up. And when the network load itself fails, a fallback plays the copy already cached on the device. A cache-hit control switch was added later to let that behaviour be governed, and the web player got its own source-switch strategy for when playback is interrupted mid-stream. Supporting detail in the same area: the 418 response stopped being an unhandled case, the priority quality setting stopped conflicting with the quality actually being played, and the playback page now shows both the platform the audio is really coming from and the real quality specification instead of the requested one. Read together, these entries describe an app that assumes the upstream stream will fail regularly and has been hardened against that assumption, which is the opposite posture from a client that treats failure as an exception.

## The audio source layer is a plugin system carrying its own accuracy claim

The area that received the most engineering is the one that resolves playable audio, and it is built as an extensible layer. Each of the three platforms, NetEase Cloud Music, QQ Music and Kugou, can be given its own custom source plugin, files are opened or imported as JavaScript with a share target and a multi-select batch import, and the cap on imported sources was raised to 50. There is a source test screen, and its logic was rewritten to be much faster, and the detection module behind it was rebuilt with the project claiming recognition accuracy above 90%. Playback quality and download quality are set per platform, and the quality tier a track actually receives is reported on the playback page with a switch to change it. The failure modes are equally specific: master-tier tracks from some sources would not play at all, some sources reported a master tier even when the test had failed outright, and some sources could not complete the test. Cookies are the other half, since the changelog extends their survival and adds a popup when one expires. Metadata gets its own repair pass too: a suspected-value matching mechanism was fixed to identify data more accurately, and imported history from the original version now has its tags filled in automatically the next time a track plays. The practical consequence is that this layer is only as good as the plugin files and cookies you supply.

## Sync and backup carry the author's own warning

The header of the README says in one line that sync and backup are not fully tested and that you should back up important files yourself, and that warning sits above everything else the project has to say. The feature set around it is substantial: WebDAV automatic sync with four update frequencies, real time, on every launch, once a day and once a week, with the backup contents selectable rather than all or nothing, so history, download records and listening statistics can each be included. Openlist compatibility was added, along with cover art fetching for WebDAV tracks and the ability to upload a song to a WebDAV target. One constraint is documented precisely: a locally mounted server has to be given the machine's own IP, because a loopback address cannot play. NetEase cloud disk management arrived in the same release as the aggregated platform page, with browsing, search inside the current disk and direct upload. For a fork described as personal use, this is the area with the least outside verification, since the failure modes depend on which server you point it at and what the sync finds on the way.

## The settings are a record of the UI changing its mind

One release in the middle of the list is worth reading as a design history rather than a feature list, because 26.09.20 removes thirteen things. The separate sidebar entries for the three platforms' playlists, daily recommendations and cloud disk all disappear, folded into a single aggregated page. Two independent sidebar settings, one for following the theme and one for following the dynamic background, are removed because the global settings now cover them. Two display settings, song duration and the highest supported quality, lose their switches and become always on. The old My Lists interface and the sidebar grouping feature are deleted outright, along with the Bilibili multi-part switch, since that content is now shown as playlists. Earlier entries show the same pattern in reverse: a new player page interface was added in June, the bottom bar became a floating card in September, and the next release adds a switch to restore the original bottom player style plus margin controls for the floating version. A personal fork accumulates switches to undo its own past decisions, and this one keeps them instead of hiding them behind a reset.

## A Xiaomi speaker and a song recogniser are the integrations nobody asked for

Two integrations stand out as the work of one household rather than one feature request. The first is speaker control: the changelog describes talking to a Xiaomi smart speaker over the local network with no Bluetooth pairing, after signing in with the same Xiaomi account, and it names the device it was tested on, a Xiaomi Smart Speaker Pro. From there the app pushes local and online playlists and loads the whole playlist after the push, controls playback, pause, track changes and volume from the phone, parses a music URL and sends it straight to the speaker, and adds a manual push button to the song and playlist menus. Voice commands gained batch delivery of the first twenty search results. The second is song recognition, which gained NetEase Cloud Music as a recognition source and a choice between the microphone and system audio as the recording input. Elsewhere the same release train adds a Scheme URL document under doc/ for specifying platform and search type, plus landscape layouts for car head units and tablets, a 4 by 2 home screen widget, and a listening statistics page that replaced the playback history page.

## Conclusion

This is a fork to read rather than a base to build on, and it is honest about that. Its value is the record: nineteen dated entries show exactly which parts of the upstream music client a single user had to change, and the changelog is more informative than any installation guide would be. Three things to settle before you rely on it. The build is Android-only and scripted through gradlew.bat, with a signing key you supply and a postinstall step that patches the framework. The sync and backup path carries the author's own warning that it is not fully tested. And the audio source layer, which is where the work went, depends on plugin files and cookies you import yourself, so a quality tier or a source that stops working is a question about your own files rather than a bug you can file. Version 26.09.28 is the current one, and releases are cut under date-based tags.

## FAQ

### What is lx-lxwalnut-music-mobile built on top of?

It is a personal-use fork built on a third-party modified version of lx-netease-music-mobile, whose own upstream the README points at separately, and it says in its header that it exists to meet personal needs and is for personal use only. The app is a React Native project whose manifest targets Android.

### How do I build lx-lxwalnut-music-mobile?

The README carries no build section, so the package manifest is the source: the dev script runs the React Native Android target, the release path assembles with gradlew.bat from the android directory, and the bundle script writes the JavaScript bundle into the Android assets tree. It needs Node 18 or newer and npm 8.5.2 or newer, and the package is private.

### Which music platforms does lx-lxwalnut-music-mobile support?

NetEase Cloud Music, QQ Music and Kugou, each able to take its own custom source plugin, with playback quality and download quality set separately per platform and mobile login for NetEase and QQ. Version 26.09.20 folded the three into one aggregated page and removed their separate sidebar entries.

### What happens when a song fails to play in lx-lxwalnut-music-mobile?

There are three layers: a default retry switch, automatic switching to another source after a failure, and a fallback that plays the locally cached copy when the network load fails. A cache-hit control switch and a separate source-switch strategy for the web player were added alongside them.

### Can I rely on the WebDAV sync in lx-lxwalnut-music-mobile?

The header warns that sync and backup are not fully tested and tells you to back up important files yourself. Automatic sync offers four update frequencies and selectable backup contents, Openlist is supported, and a locally mounted server must be given the machine's own IP because a loopback address cannot play.

## Sources

- [Issues](https://github.com/WalnutBai/lx-lxwalnut-music-mobile/issues)
- [License: Apache-2.0](https://github.com/WalnutBai/lx-lxwalnut-music-mobile/blob/main/LICENSE)
- [README](https://github.com/WalnutBai/lx-lxwalnut-music-mobile/blob/main/README.md)
- [Releases](https://github.com/WalnutBai/lx-lxwalnut-music-mobile/releases)
- [WalnutBai/lx-lxwalnut-music-mobile on GitHub](https://github.com/WalnutBai/lx-lxwalnut-music-mobile)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/walnutbai-lx-lxwalnut-music-mobile