feat(app): keep the tunnel alive via the OS, drop the workarounds

0 Fork 0

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]>

This commit is contained in:

esefxdzandClaude Opus 5 committed 2026-09-01 00:16:05 +03:00

1 parent ac52681452

commit 186dc906da

12 files changed

+422 -291

No files matched your search

									
										pubspec.yaml
									
		+1
		-1
	
												View File
												
				@@ -15,7 +15,7 @@ publish_to: "none" # Remove this line if you wish to publish to pub.dev

				# In iOS, build-name is used as CFBundleShortVersionString while build-number used as CFBundleVersion.

				# Read more about iOS versioning at

				# https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html

				version: 3.3.1+27

				version: 3.3.2+28

				environment:

				  sdk: ">=3.0.0 <4.0.0"