v2rayNG: A dual-core Android client for V2Ray, Xray, and v2fly

What v2rayNG solves and who it targets

v2rayNG is an Android client for V2Ray, but it is not limited to the original v2fly core. The README states that it supports both Xray core and v2fly core, which makes it a single entry point for two separate proxy engines. The intended user is someone who already runs a V2Ray or Xray server and needs a mobile client to connect to it. The project explicitly positions itself as the mobile counterpart to the desktop v2rayN, with a note in the README that says "v2rayNG is the mobile version" and directs desktop users to the v2rayN repository. That distinction matters: this is not a general-purpose VPN app, and it does not try to be one. It is a specialized client for a specific protocol family.

How the dual-core mechanism works

The architecture is split between the Android UI and the actual proxy engine. The UI is a Kotlin project under the V2rayNG folder, and the proxy logic lives in a separate Go-based library packaged as an aar file. The README names two source repositories for that aar: AndroidLibV2rayLite for the v2fly core and AndroidLibXrayLite for the Xray core. That means the app does not embed the cores directly in the main repository. Instead, it links against a prebuilt aar, and the core version is fixed at the time that aar was compiled. The routing logic uses geoip.dat and geosite.dat files, which the app stores in Android/data/com.v2ray.ang/files/assets. The app can download enhanced versions of these files from the Loyalsoldier/v2ray-rules-dat repository, but the README adds a caveat: that download feature needs a working proxy. So you cannot bootstrap the enhanced rules without already having a route out.

Getting it running: releases, signatures, and permissions

The primary installation path is the GitHub releases page. The README tells users to download the latest release from https://github.com/2dust/v2rayNG/releases, and it does not mention any alternative like F-Droid or Google Play. Release files are signed with GPG, and the README provides a fingerprint: 7694 5E9F 3E9A 168F 8070 F195 805D 661C 134D FAF6 8903 C199 463C 31E5 AE90 3AE0. That signature is meant to guard against mirror, ISP, or CDN hijacking, which is a real threat for proxy clients. For emulator use, the README notes that v2rayNG can run on Android Emulators, and for Windows Subsystem for Android (WSA) you need to grant VPN permission with the command: appops set [package name] ACTIVATE_VPN allow. That is a concrete, non-obvious step that most users will not guess.

Building from source: where the friction starts

The development guide is honest about a significant limitation. It says the Android project under the V2rayNG folder can be compiled directly in Android Studio or with the Gradle wrapper, but the v2ray core inside the aar is "(probably) outdated." That is a direct quote from the README, and it changes the calculus for anyone who wants to build a custom client. To get a fresh core, you must compile the aar yourself from the Go projects AndroidLibV2rayLite or AndroidLibXrayLite. That requires the Go Mobile toolchain and a working Makefile build, which is a substantially higher bar than building a normal Android app. The README points to the Go Mobile wiki and a Makefile tutorial, but it does not provide a step-by-step guide for this repository. So the default build path gives you an old core, and the fresh-core path demands Go expertise.

Geoip and geosite handling: flexibility with a catch

The routing data is not hardcoded. The app reads geoip.dat and geosite.dat from a device-specific assets folder, and the README says the path may differ on some Android devices. That path is Android/data/com.v2ray.ang/files/assets, which is scoped storage on modern Android versions. Users can manually import the latest official domain list from Loyalsoldier/v2ray-rules-dat and the IP list from the geoip repository. The README also mentions that third-party dat files can be placed in the same folder, giving an example of the h2y file from the v2fly guide. That is a real strength: you are not locked into the bundled rules. But the catch is that the enhanced download feature requires an already-working proxy, so updating rules while offline or on a fresh install is not possible. You have to side-load the files manually if you have no active connection.

Licence and maintenance reality

The project is licensed under GPL-3.0, which means any derivative work that you distribute must also be GPL-3.0. That is a standard copyleft licence, but it matters if you plan to fork the client for internal use or for a commercial product. The repository is not archived, and the last push was 2026-08-20, with releases 2.3.5, 2.3.4, and 2.3.3 released within a two-week window. That cadence suggests active maintenance. The README also links to a Telegram group and a Telegram channel for community support, which is a practical resource but also a sign that official documentation is thin. The wiki is mentioned, but the README does not summarize its contents. Maintenance cost for a user is low: you install the APK and update when a new release appears. For a developer, the cost is higher because the core build is separate and the aar version lag is a known issue.

When v2rayNG is the wrong tool

If you need a client that works out of the box with a recent core, v2rayNG may not be the best choice. The README explicitly warns that the bundled core in the aar is probably outdated, so users who depend on the latest protocol features or security fixes cannot get them from a standard release. They must either wait for the maintainers to update the aar or build it themselves. Also, the app is Android-only. The README directs desktop users to v2rayN, so there is no cross-platform story here. If your use case is a desktop or server environment, this project is irrelevant. Another limitation is the routing data bootstrap problem: the enhanced geoip/geosite download needs a proxy, so a user who cannot connect yet is stuck with the default rules unless they manually copy files. That is a real operational gap for first-time setup in a restricted network.

Alternatives and the difference in approach

The most direct alternative is the desktop client v2rayN, which the README itself points to. v2rayN is a separate project that runs on Windows, and it is not a mobile app. The difference is not just the platform: v2rayN has its own release cycle and its own core packaging, so the outdated-core problem may or may not affect it. Another alternative is to use a generic V2Ray client that only supports one core, such as a v2fly-only client. The advantage of v2rayNG is that it supports both Xray and v2fly cores in one app, which is not common among Android clients. But that dual support comes at the cost of a more complex build system, because two separate Go projects must be compiled to produce the aar. A single-core client would be simpler to build and update, but it would lock you into one protocol implementation. The trade-off is flexibility versus simplicity.

Editorial conclusion

Adopt v2rayNG if you need a maintained, dual-core Android client for V2Ray or Xray and you are comfortable installing APKs from GitHub releases. Skip it if you require a fully reproducible build: the bundled core inside the aar is likely outdated, and you will need to compile the Go-based core yourself via AndroidLibV2rayLite or AndroidLibXrayLite. Before relying on it, verify the GPG signature of the release file against the published fingerprint, and check whether the geoip/geosite assets in the app match the routing rules you intend to use. The project is actively pushed, with releases as recent as August 2026, but the core version lag is a documented, unresolved trade-off.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes