It is an Android control surface for two established proxy cores
v2rayNG is a mobile client, not a proxy service in a box. It gives Android users a way to operate configurations backed by either Xray core or v2fly core, which is useful when a provider, private server, or organization already supplies compatible connection details. The project is written primarily in Kotlin, requires Android API 24 or newer, and publishes English and Chinese README guidance. That positioning makes it closer to a power-user network utility than a mainstream tap-once VPN application.
The scale is notable: the repository has 61,935 stars and dates back to 2019 according to the supplied community item.
Our measured build worked, while the test suite provided no assurance
On our box, installation succeeded in 43 seconds and installed 156 packages. The build then succeeded in 62 seconds, and the test command completed in 13 seconds. The important catch is that Go reported 0 passed and 0 failed tests because it found 0 tests. A green command here means the measured code compiled, not that its networking behavior, Android UI, configuration import, or upgrade paths were exercised.
Our run targeted the Go project under ./AndroidLibXrayLite/, at commit c548e5f, in an unprivileged golang:1.24-bookworm container with 3 CPUs and 8 GB of RAM. It did not produce or launch the full Android application.
Its strongest features are core choice, routing data, and signed releases
Supporting both Xray and v2fly cores is the clearest reason to choose v2rayNG. Users who already live in that protocol family do not need to change their server-side setup just to get an Android client. Version 2.2.6 was released on July 5, 2026, and the README points directly to GitHub Releases rather than an unexplained mirror. It also clearly redirects desktop users to the separate v2rayN project.
The routing-data instructions are unusually concrete. The README names the device location for geoip.dat and geosite.dat, explains that paths may vary, identifies an enhanced download source, and warns that downloading it requires a working proxy. It also supports manual imports of official domain and IP lists plus third-party data files. For an API 24+ power user troubleshooting regional or domain-based routing, that is practical information rather than marketing copy.
Release verification is another real strength. The project says release files are GPG-signed and publishes the fingerprint needed to check authenticity and integrity. Versioned releases, a visible fingerprint, and a direct repository download path are sensible safeguards for a network client.
The development notes also acknowledge unusual environments. The Android project can be compiled in Android Studio or through the Gradle wrapper, emulator execution is supported, and WSA users get the exact appops permission command needed to allow VPN activation.
The core packaging and missing tests are the main rough edges
The most concerning sentence in the README is its own warning that the V2Ray core inside the AAR is probably outdated. That is honest, but it shifts responsibility onto anyone building from source to understand Android, Go Mobile, Makefiles, and the relationship between the app and its native library. A user installing release 2.2.6 may never touch that path, while a developer auditing or modifying the client cannot safely ignore it.
Automated validation is the other weakness. The repository has 2 CI workflow files, but our measured Go target had no tests directory and go test discovered 0 tests. We therefore have no supplied evidence for how imports, routing updates, malformed profiles, reconnections, or core upgrades behave under test. The absence of a Dockerfile is not surprising for an Android app, but it means the successful container procedure does not appear to be a documented, first-class project workflow.
Documentation covers download, data files, compilation, emulators, WSA, and GPG verification, yet the path from a fresh checkout to a current embedded core remains split across projects. The README gives enough landmarks for an experienced contributor, but it does not establish which core revision ships in each app release or show a single verified command sequence for rebuilding the AAR and APK together.
Current activity looks healthy, but issue responsiveness is unproven
The latest push was August 30, 2026, only 2 days before this review, while the latest supplied release is 2.2.6 from July 5, 2026. Taken together, those dates show active source development and a recent packaged release. The repository also has 42 open issues, a modest number relative to 61,935 stars, though raw issue volume says nothing about response time or resolution quality.
We were given only 1 release date and no closed-issue or maintainer-response data, so a precise release cadence would be guesswork. Telegram group and channel links provide additional community routes, but their activity was not measured in our run.
It belongs on the Android endpoint, behind infrastructure you already trust
v2rayNG fits at the edge of a real network stack: server or subscription management happens elsewhere, compatible profiles arrive on the device, and the app applies connection and routing rules locally. GeoIP and Geosite data then refine which traffic follows those rules. For organizations, the GPL-3.0 code and signed artifacts support review, but deployment still needs a policy for profile distribution, updates, and secrets.
Choose it when Xray or v2fly compatibility is a hard requirement and the operator understands the configuration model. Skip it when you need a managed service, an iOS client, Android below API 24, or strong automated evidence for the entire mobile release. The successful 62-second core build is encouraging, but 0 discovered tests and the AAR freshness warning keep this from being an effortless recommendation for less technical users.