3.3.1 could display "connected" against a tunnel that was no longer
running, with a frozen countdown and no traffic. Three causes, and the
fix for each removes more code than it adds.
Liveness was read from getConnectedServerDelay(), which measures through
AppConfigs.V2RAY_CONFIG?.LOCAL_SOCKS5_PORT ?: 10807. AppConfigs lives in
the :RunSoLibXrayDaemon process, so from the UI process it is always null
and the port always fell back to 10807 -- accidentally correct while the
SOCKS port was fixed, permanently wrong once 3.3.1 made it ephemeral.
Liveness now comes from the OS: is our service process running, and is a
VPN transport actually present.
The foreground notification (id 1) is owned by XrayVPNService via
startForeground, but MainActivity was posting to the same id from the UI
process. When that process died its notification stayed on screen with
nothing left to update it. MainActivity now refuses to post for a dead
runtime and clears the stale notification instead.
Nothing ever asked Android for permission to stay alive. Adds the
battery-optimisation exemption prompt and a deep link to Always-on VPN --
the two sanctioned mechanisms for background survival, each needing one
user tap.
Removes Standard/Extreme resilience and the runtime-restart machinery:
recovery ran off a disconnect broadcast delivered to the app process, so
it could never fire when Android killed that process. Removes startup
restoration and the config-snapshot rebuild along with it; with the OS
keeping the tunnel up there is nothing to restore.
Version 3.3.2+28.
Co-Authored-By: Claude Opus 5 <[email protected]>
Maintainer changes on top of PR #2 (Naveax). Reduces the release to two
deliberate connection modes and resolves the issues found in review:
- Lock-screen privacy: move VISIBILITY_PRIVATE and a generic publicVersion
into MainActivity.updateVpnNotification. The PR's fix lived in an
unreferenced class and never reached the live notification.
- Haptics: restore the default to off, and reduce HapticSettings to a
single success() on connect/disconnect via the native channel.
- SOCKS5: make it a real proxyOnly local-proxy mode rather than a TUN
connection under a different label. TUN stays the default.
- Health probe: restore the idle-only guard so /health is no longer polled
every 30s while connected.
- Recovery: add a _connectionEpoch counter so connect() aborts an
in-flight Extreme recovery.
- Startup restoration: rebuild the recovery snapshot from the still-active
session after an app-process restart (TUN), and surface an honest
orphaned state with a Reconnect action in proxy mode.
Drops per-app routing entirely. It only ever functioned in TUN --
addDisallowedApplication lives inside the VPN-interface setup that
proxyOnly skips -- and its allowlist half had no Dart caller.
Also removes flutter_local_notifications, the global tap-haptic surface,
and unused runtime telemetry.
Co-Authored-By: Claude Opus 5 <[email protected]>
Raise the Gradle heap to 4 GB and cap workers at two so Jetifier and Kotlin release compilation do not exhaust memory while processing Flutter engine artifacts.
Add explicit TUN and SOCKS5 connection modes, app routing controls, authenticated per-session local SOCKS5, Android network monitoring, persistent haptics, resilient session recovery, notification hardening and client-side Hivemind cleanup.
Keep the hosted flutter_vless_android 1.1.5 runtime as the base and apply the Android compatibility/security patches at build time instead of restoring the unstable vendored runtime.
User-Agent spoofed to Chrome on Android (was Dart/3.x). Domain renamed to userevolt.app. Branding to Revolt VPN. Removed duplicate notification, patched flutter_vless for custom icon + dark background. Merged 5 disconnect paths into single idempotent gate, fixed stopVless timeout silently lying about state. Removed kDebugMode guard from AdMob bypass.
