MusicFree ships no music sources
The primary README is Chinese, and most issue traffic is Chinese too. An English README covers the main product, warnings, plugin model, and download route. MusicFree itself is an Android and Harmony OS player. Search, albums, artists, online playback, playlist import, and lyrics come from plugins rather than built-in service integrations. That distinction matters because a fresh install is a player shell until the user supplies a local plugin or a network plugin list.
The app side is reasonably focused. It stores playlists and settings locally, plays local files, supports light and dark themes, accepts custom backgrounds, and can associate one track's lyrics with another. Our measured commit d118b18 contained 500 files, about 34,374 lines of source, and 9.5 MB of checked-out code. It uses React Native 0.76.5 and Expo 52, while the published 0.6.2 release provides APKs for several Android CPU architectures.
CommonJS plugins carry the search and security burden
A MusicFree plugin is a CommonJS module implementing functions for search, playback, albums, artists, playlists, or lyrics. The host handles concerns such as pagination and caching. That separation lets one player work with different legal, self-hosted, or public sources. It also means the quality and continuity of online playback depend on code that may have a different author, update schedule, and data source from MusicFree itself.
The README tells users to inspect third-party plugins for suspicious network requests and warns against installing unknown code. That is unusually direct and entirely appropriate. A .js file fetched from a URL is executable logic, not a passive playlist. Our 130-second install failure says nothing about plugin safety, and the repository makes no promise to vet every external source. Anyone deploying this for less technical users should control the plugin list instead of asking each person to judge JavaScript.
What happened when we ran it
Our sandbox tried the repository's Yarn path at commit d118b18. Installation failed with exit code 1 after 130 seconds. Yarn reported that minimatch@10.0.1 accepts Node 20 or versions at least 22, but the runtime it saw was Node 18.20.8. It printed the same incompatibility again after restarting its install output. The failure occurred during package fetching, before this run established a build or test result.
The log also warned about package-lock.json and advised against mixing package managers. We do not have evidence that the second lockfile caused the engine failure, so those are separate findings. The manifest declares Node >=18, which does not match the dependency's requirement on the path Yarn resolved. Although our container image was labeled lab-node:22, Yarn reported 18.20.8. The log does not show why. That discrepancy needs reproduction before anyone changes an engine field or lockfile.
The lab scan found 1 CI workflow, no Dockerfile, and no tests directory. Those signals do not prove the project lacks tests, since its manifest defines a Jest command. They do show that the repository does not supply a container recipe matching its mobile build. Source contributors must reconcile the JavaScript install before Gradle can produce an APK.
The only CI workflow uses npm, Node 20, and Java 17
The beta workflow takes a different route from our failed Yarn install. It runs npm ci on Node 20, sets up Temurin Java 17, then invokes the Android Gradle wrapper. Release signing is conditional on repository secrets. This gives contributors a concrete working outline, but it also exposes the lockfile ambiguity: the declared project ecosystem includes Yarn artifacts while the automated Android build trusts package-lock.json and npm.
No build or test measurement followed our 130-second failure, so the workflow cannot be treated as a substitute lab result. It triggers on version changes in the development branch or by manual dispatch, and it builds beta APK artifacts. There is no broad pull-request workflow visible in the measured checkout. A contributor should copy the CI versions first, use npm's lockfile path, and then verify Jest and the release Gradle task locally.
Local app data does not make downloaded plugins private
The project says MusicFree stores its own data locally and does not collect personal information. That is a useful default for playlists and preferences. Network plugins remain outside that promise: their job is to contact sources, and the README assigns responsibility for third-party plugins and their generated data to the user. Treat every plugin URL as a software installation. Review changes when a subscription updates, especially if the source controls many plugins at once.
Current reports also make backups important. Issue 595 describes a 0.6.3 beta user who could create a local backup but could not select it for restore, while WebDAV backup returned a network failure. Issue 647 describes version 0.6.2 freezing or crashing on Android 13 after a source containing many plugins was installed, leaving app-data clearing as the reporter's recovery. These reports are specific cases rather than proof that every device fails, but both hit recovery paths users depend on.
Android and Harmony OS are the supported mobile targets
The README names Android and Harmony OS only and directs desktop users to the separate MusicFreeDesktop repository. The 0.5.0 changelog says the React Native 0.76.5 update raised the floor to Android 7. Harmony OS support also has open platform gaps: issue 645 asks for status-bar controls on a newer Harmony OS device, and issue 464 requests a HarmonyOS Next HAP package. Buyers should test notification controls, background playback, storage access, and restore on the exact phone.
The project remains active even though stable release 0.6.2 was published on October 11, 2025. GitHub recorded the last push on September 6, 2026, with new issue activity the next day. It had 26,739 stars and 277 open issues and pull requests when fetched. The maintainer's own README calls it a hobby project with limited daily time, irregular updates, and a long unstable-test period. That warning is more useful than the star count when deciding whether to depend on it.