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

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

+38
View File
@@ -5,6 +5,44 @@ Versions follow [semver](https://semver.org/): MAJOR.MINOR.PATCH
---
## [3.3.2] — 2026-09-01
Background reliability. 3.3.1 could show "connected" against a tunnel that was no
longer running; this release fixes the cause rather than the symptom, and removes the
machinery that existed to work around it.
### Added
- **Background reliability settings.** Android stops background services of apps that
are not exempt from Doze, and tears down the process group when a task is swiped
away. Two OS mechanisms prevent that, and the app now surfaces both: a one-tap
**battery optimisation exemption**, and a deep link to Android's **Always-on VPN**
settings (with a note about "Block connections without VPN"). Neither can be enabled
programmatically — each needs a single user tap, once.
### Fixed
- **The app could report "connected" with no traffic flowing.** Startup state came from
`getConnectedServerDelay()`, which measures through
`AppConfigs.V2RAY_CONFIG?.LOCAL_SOCKS5_PORT ?: 10807`. `AppConfigs` lives in the VPN's
own process, so from the UI process it is always null and the port always fell back to
10807. That was accidentally correct while the SOCKS port was fixed; 3.3.1's
per-session ephemeral ports made it permanently wrong. Liveness is now determined from
the OS — whether our VPN service process is running, and whether a VPN transport is
actually present.
- **A frozen countdown could outlive the tunnel.** The foreground notification (id 1) is
owned by the VPN service via `startForeground`, but the UI process was posting to the
same id. When that process died, its notification stayed on screen with nothing left to
update it. The app no longer posts for a runtime that is not alive, and clears a stale
notification instead.
### Removed
- **Standard/Extreme resilience modes** and the runtime-restart machinery behind them.
Recovery ran off a disconnect broadcast delivered to the app process, so it could never
fire in the case that actually matters — Android killing that process. It was
complexity substituting for background persistence.
- **Startup restoration**, including the config-snapshot rebuild. With the tunnel kept
alive by the OS, there is nothing to restore; the app simply reports what is running.
- The `resilience_mode` preference and its settings tile.
## [3.3.1] — 2026-08-31
### Added