UAC SNI Spoofer Android picks a VPN config by measuring it, not by guessing

Selection is by measured result, and results are keyed by config and fingerprint

The premise sits in a blockquote near the top of the README: no config gives the best result on all networks. The stated goal is to find the best available route for the network you are on right now, automatically, from real testing rather than from a provider ranking.

The claim worth checking first is how results are keyed. A network fingerprint is built from connection type (WiFi or Mobile), the operator, the ASN and the serving provider, and a main plus alternative edge set is chosen to match that operator. Test outcomes are then stored separately for every config crossed with every fingerprint. The same config can win on one network and lose on another without either result being thrown away.

From that store the engine selects a Champion and a Backup per config per network, so failover comes from recorded history instead of a fixed ordering. Successful runs are learned from and used directly in later connections, and a Cooldown mechanism keeps failing routes out of repeat testing, which is what stops a large parameter matrix from draining the battery.

The consequence for a reader is precise: the final list produced by a speed test belongs to one config and one fingerprint. Changing networks does not erase your history, it selects a different row of it.

Edge x DNS x Fragment x MTU, run as a staged competition

Independent combinations of Edge, DNS, Fragment and MTU produce hundreds of routes for each config. No sampling shortcut is offered.

Those routes compete in stages rather than in one flat race: initial screening, then verification, then stability, then stress, and a final stage named A-B-B-A whose meaning is not spelled out. Ranking is shown live while the test runs, any stage can be stopped or continued, and any stage can be rejected by hand.

The measurement list explains the staging. Cold start of the Xray core is timed, which separates a proxy that wins on throughput but takes half a minute to come up from one that is ready when you need it. A multi-destination HTTP test stops a single friendly endpoint from flattering a route. DNS and Bootstrap response are timed apart from the data path. The remaining figures are received payload volume, throughput, ping, jitter, success rate and a confidence percentage.

Config Maker has two entry points. Quick Scan stops at the first healthy result, the sensible mode on a metered connection. Deep Adaptive Test walks the full matrix and is the one that produces a ranking you would keep.

Staging is what makes a matrix that size survivable on a phone: the cheap stages run first and prune before the expensive ones, and the confidence percentage gives you a number to weigh against the routing decision rather than a verdict you have to accept.

One TUN bridge sits under every core, which is why path switching is cheap

The stack is layered in one fixed order. Android's `VpnService` owns the system-level tunnel. `hev-socks5-tunnel` provides the native TUN route and bridges TUN to SOCKS. Above that sits the proof of work adaptive engine, written in Kotlin with a native Aether engine in Rust underneath it.

Six cores sit below the engine. `Xray` carries VLESS, VMess and Trojan. `Psiphon` arrives through Go and JNI, `Tor` through libtor, `WebTunnel` stands on its own, and `Aether` handles the low-level native operations. The sixth is a Direct Compat Route, and its purpose is narrow: it tests a config without replacing the address, ALPN or FinalMask values.

That last piece changes how the name should be read. SNI, Host, Path, ALPN, Fingerprint, plus the security and transport settings, are preserved from the config rather than rewritten. What varies underneath is the route, not the values your handshake presents.

Two connection modes are offered: a full Tunnel VPN, and a SOCKS Local Proxy for apps that want a local socket instead of a device-wide tunnel. Android TV is supported through a `tv` mode built on the `armeabi-v7a` architecture, which is the same binary line as the one shipped for older 32-bit phones.

Three app routing modes, and QUIC, Mux and MTU left as manual levers

Which traffic enters the tunnel is a three-way choice rather than a single switch: everything goes through the VPN, selected apps are bypassed, or the VPN applies only to the apps you pick. Set that against the Tunnel and SOCKS modes and one config has four effective shapes.

The advanced controls are listed flat, with no explanation of which the engine chooses for you: routing, QUIC, Keepalive, Mux, MTU, FinalMask and Fragment. Read them as knobs you adjust after a test rather than defaults you can count on.

DNS is handled on its own axis. Five resolvers are offered (Cloudflare, Google, Quad9, AdGuard, OpenDNS), each usable through DoH plus Bootstrap, and the resolver is one of the four variables the speed test varies alongside Edge, Fragment and MTU.

Subscription handling is the quiet feature with the longest reach. Several subscriptions can be merged without clearing results collected earlier, and duplicates are dropped automatically. Because stored results survive, refreshing a subscription does not wipe the Champion or reset the Cooldown table, which is the behaviour that makes per-network memory worth having at all.

Note that FinalMask and Fragment appear twice in the documentation: once as manual controls, once as values the Direct Compat Route is careful not to touch. A config can therefore be tested through one path with its own values intact, then run through a substituted path later.

Ghost Handover and Adaptive Obfuscation are the two reactions to a quality drop

Four behaviours are grouped under routing and hardening. `Ghost Handover` moves traffic from one route to another when quality drops or the network changes, without a complete cut. `Adaptive Obfuscation` picks obfuscation techniques to match the network it detects. `Page Turbo` optimises the routes that get visited often. Under those sit a Psiphon transport layer with its own independent IPC and a Tor-style routing layer.

The first two are what change how a bad network feels. Automatic recovery when the network changes is listed separately, and combined with per-fingerprint Cooldown it means the reconnect does not start by re-walking the routes that already failed on that network.

Monitoring sits alongside that logic rather than after it. Live values cover ping, up and down traffic, exit IP, country and connection health status, with technical reports and logs kept for troubleshooting. Connect and disconnect are available from Android Quick Settings and the notification carries the same controls, so a failed route can be cycled without opening the app. Configs can also be imported by QR code through ZXing.

A Kotlin pow package sitting on a Rust core reached through AetherNative

The published folder layout stops partway through the engine package, and what it shows is enough to place the language boundary. The path runs `app/src/main/java/com/uacspoofer/mobile/engine/pow/`. Inside it, `AetherNative` is the bridge to the native `libaether` library written in Rust, and beside it sit `PowCoreConfig`, `PowEngineStore` and `PowConnectionCoordinator`.

The remaining names map one to one onto the features above: `PowNetworkScoreboard`, `PowAdaptiveObfuscation`, `PowGhostHandover`, `PowPageTurbo` and `PowPathProbe`. So the Kotlin layer owns configuration, persisted results, connection coordination, scoring, obfuscation choice, handover, route caching and probing, and delegates the low-level work to Rust. The directory diagram breaks off inside that same package, so the rest of the internal layout is not visible there.

The native core lives in `core/`. At the top level the repository carries `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties`, the `gradlew` and `gradlew.bat` wrappers, a `gradle/` directory, `scripts/`, `third_party/`, `THIRD_PARTY_NOTICES.md`, `icon.png`, a `.gitignore`, and both a `README.md` and a `README.en.md`. Two READMEs at the top level is worth noticing, since the walkthroughs will differ in language between them.

Every class in that package carries the same `Pow` prefix, which is a small but useful signal: this is one subsystem rather than a scattering of helpers, and the eight names map onto eight distinct responsibilities you can look for when you need to change one behaviour without disturbing the rest.

Building from source needs JDK 17, SDK 35, a pinned NDK and a Rust toolchain

The requirements table lists seven rows, and several are toolchain pins rather than device limits. JDK 17 is needed for building, Android SDK 35 is the target, and the NDK is pinned to `26.3.11579264`, the kind of exact pin that breaks a local build the moment a different NDK is installed. A Rust toolchain is required to build `core/aether`, and Python 3 runs the pre-build scripts.

The rest are device constraints. Android 7.0 or newer (API 24+) is the floor. The VPN permission is mandatory on first connection. Other VPN apps must be disabled while this one is in use, so there is no way to run two tunnel clients at once.

The dependency list is short and mostly not yours to choose. Xray is the proxy core for VLESS, VMess and Trojan. hev-socks5-tunnel is the native TUN to SOCKS bridge. Psiphon Tunnel supplies alternative and hardened routes, Tor comes through libtor, and the Aether Rust core does the native proof of work work. On the presentation side: Jetpack Compose with Material 3, Kotlin Coroutines for concurrency, ZXing for QR codes, and Fresco for image and WebP loading.

One gap is worth naming before anyone rebuilds and redistributes this. No LICENSE file appears at the top level of the tree, although `THIRD_PARTY_NOTICES.md` does, and several of the bundled cores are separately licensed projects.

Three APK builds by CPU architecture, and the install walkthrough stops at step three

Installation is a download rather than a build. Step one points at the Releases page, and step two says to install and run the app. Three builds are published and they differ only in CPU architecture:

UAC-{version}-arm64-v8a-Android7plus.apk
UAC-{version}-armeabi-v7a-Android7plus.apk
UAC-{version}-universal-Android7plus.apk

The arm64 file is the recommended one for 64-bit phones from 2017 onward, armeabi-v7a is for older 32-bit devices, and the universal build covers every architecture at the cost of a larger download. Each filename carries the `Android7plus` suffix, which matches the API 24 floor in the requirements table.

The third installation step is cut off partway through in the published walkthrough, so whatever configuration follows first launch is not written down there. That matters more than a missing detail usually would, because the first thing the tool wants to do is start a test matrix that you would want configured before it runs.

Release cadence is fast. Versions 2.0.5, 2.0.6 and 2.0.7 were published on 2026-09-09, 2026-09-12 and 2026-09-15, and the last push to the main branch carries the same 2026-09-15 date. With three releases in six days and a scoring engine at this level of detail, treat a version number as a narrow set of behaviour rather than a stable target.

Editorial conclusion

Take it if your problem is that one subscription behaves well on office WiFi and badly on mobile data, since per-fingerprint storage is the part no single static config list solves. Leave it if you want a quiet VPN, because a deep adaptive test walks hundreds of Edge, DNS, Fragment and MTU combinations and the ranking it produces holds only for the network it was measured on. Before the first connect, match the APK architecture to your device and clear the two runtime requirements stated up front: the VPN permission on first run, and every other VPN app turned off.

Frequently asked questions

Official sources

1. Floxu1/UAC-SNI-Spoofer-Android on GitHub
2. Issues
3. README
4. Releases