docs(changelog): correct 3.3.7, which advertised behaviour it does not have
Android CI / android (push) Canceled after 0s
Android CI / android (push) Canceled after 0s
A Fable review checked every entry against the commits in the release and found the SOCKS5 Reconnect bullet is false for the shipped binary: tag v3.3.7 containse67f0b9(/session/stop) but note751a9d(the fix), so in that build Reconnect ends the session instead of re-attaching. The public changelog promised the opposite. It now carries a Known issue box naming the symptom and the workaround. Also corrected, same review: - The warning's "now actually arrives when the app is closed" named the sleeping-phone case and claimed to fix it. It does not: the backstop is Handler.postDelayed on uptimeMillis, which stalls under true suspend, and a late delivery is then dropped by the window check - so the failure mode there is no warning, not a late one. The evidence was an emulator under forced idle, which never suspends the CPU. Dropped the Fixed entry (the feature is new in 3.3.7 anyway, so it fixed no released bug) and let the honest Added bullet carry it. - /session/stop fires only from the app's own disconnect button, not on expiry, cap, revoke or a kill. Scoped the claim. - The ad entry moved to Groundwork: ads are off in this build and the path was reviewed, never exercised against a real SSV callback. - "One restart now brings it back" rested on one emulator run killing a warm core, and the cold-start exit-23 is unfixed. Softened. - Core recovery "says why" -> logs why; no user sees it. - Added the two countdown fixes fromd1ea13band34722c7, which were user-visible and had no entry at all. - Dropped "the tunnel stopping unexpectedly": that path never reaches stopAll, so no alert is posted for it. Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
1 parent
e751a9d6e4
commit
73d76c04f2
1 file changed
+34
-31
+34
-31
@@ -7,15 +7,22 @@ Versions follow [semver](https://semver.org/): MAJOR.MINOR.PATCH
|
||||
|
||||
## [3.3.7] — 2026-10-17
|
||||
|
||||
> **Known issue — fixed in the next release.** In SOCKS5 mode, the **Reconnect**
|
||||
> button in Settings ends your session instead of re-attaching to it, and then
|
||||
> fails with "Session not activated". It only appears when a proxy session has
|
||||
> been orphaned, and you lose the rest of that session rather than anything
|
||||
> worse. Workaround: connect again from the main screen. The "SOCKS5 Reconnect"
|
||||
> entry below describes the intended behaviour, which this build does not have.
|
||||
|
||||
### Added
|
||||
- **A warning before a session ends.** The VPN service schedules it off the same
|
||||
deadline it already enforces, so it still arrives when the app is closed, and
|
||||
a support top-up moves it with the deadline. It does not promise an exact
|
||||
number of minutes: on a sleeping phone Android may hold it back, and the app
|
||||
would rather say "soon" than say "5 minutes" with one left.
|
||||
- **"Disconnected — not protected" notification** when a session ends without
|
||||
you asking: the 2-hour expiry, the data limit, the server ending the
|
||||
session, or the tunnel stopping unexpectedly.
|
||||
deadline it already enforces, so it arrives even with the app closed, and a
|
||||
support top-up moves it with the deadline. It does not promise an exact number
|
||||
of minutes: on a deeply sleeping phone Android can hold it back past the end
|
||||
of the session, in which case it is skipped rather than shown late.
|
||||
- **A "disconnected — not protected" notification** when a session ends without
|
||||
you asking: the 2-hour expiry, the data limit, or the server ending the
|
||||
session.
|
||||
- **SOCKS5 mode now asks for the notification permission.** It never did,
|
||||
because it never raises the VPN consent dialog, so on Android 13+ these
|
||||
alerts would have been dropped before they were shown.
|
||||
@@ -28,36 +35,32 @@ Versions follow [semver](https://semver.org/): MAJOR.MINOR.PATCH
|
||||
to disconnect itself after about two minutes of failed status polls, putting
|
||||
you back on your real IP; it now keeps the tunnel up and shows
|
||||
"Can't reach the server — still connected". Expiry is still enforced by the
|
||||
VPN service's own deadline and by the server.
|
||||
VPN service's own deadline, which keeps running regardless.
|
||||
|
||||
### Fixed
|
||||
- **Rewarded ads no longer break connecting.** With ads enabled, the ad's
|
||||
server-side-verification nonce and the nonce the connect flow waited for were
|
||||
minted separately, so the client rejected the very session the ad created and
|
||||
failed with "Session not activated". The ad's nonce is now passed through to
|
||||
the connect call, the fake bypass callback is skipped when a real ad was
|
||||
watched, and the client polls longer (~36 s) for Google's callback.
|
||||
- **SOCKS5 "Reconnect" re-attaches to the current session** instead of
|
||||
requesting a new one, so repairing a lost proxy no longer needs (or grants)
|
||||
a fresh session.
|
||||
- **The end-of-session warning now actually arrives when the app is closed.**
|
||||
It was scheduled only on an inexact alarm, and a sleeping phone could hold
|
||||
that alarm back past the end of the session it was warning about — so in the
|
||||
one case the warning exists for, it never came. It now also runs off the VPN
|
||||
service's own timer, the same one that already ends the session on time.
|
||||
- **The countdown no longer over-reports after the phone sleeps**, and a clock
|
||||
moved backwards can no longer stretch a session.
|
||||
- **A session that expired while the phone was asleep is recognised on waking**,
|
||||
by wall clock rather than by time the device spent awake.
|
||||
- **Disconnecting from Android's VPN settings no longer leaves a countdown in
|
||||
the notification shade.** It used to sit there frozen, showing time remaining
|
||||
on a tunnel that was already gone.
|
||||
- **The VPN reconnects itself after the tunnel core stops.** Recovery never
|
||||
worked: every attempt failed on the same internal error, and each one left
|
||||
another copy of the core running in the background. One restart now brings it
|
||||
back without dropping the connection.
|
||||
- **Disconnecting now releases your session on the server** instead of leaving
|
||||
it open until it expires on its own.
|
||||
- **A core that fails to start now says why.** Its output was being thrown
|
||||
away, so the only trace was an exit code.
|
||||
- **The VPN recovers after the tunnel core stops.** Recovery never worked:
|
||||
every attempt failed on the same internal error, and each one left another
|
||||
copy of the core running in the background. It now usually comes back on the
|
||||
first retry, without dropping the connection.
|
||||
- **Disconnecting with the app's own button now releases your session on the
|
||||
server** instead of leaving it open until it expires.
|
||||
- **SOCKS5 "Reconnect" re-attaches to the current session** instead of
|
||||
requesting a new one — see the known issue above; this does not work in 3.3.7.
|
||||
- **A core that fails to start now logs why.** Its output was being discarded,
|
||||
so the only trace was an exit code.
|
||||
|
||||
---
|
||||
### Groundwork
|
||||
- **Rewarded-ad plumbing.** Ads are switched off in this build, so none of this
|
||||
is reachable yet: the ad's verification nonce is now carried through to the
|
||||
connect call rather than being minted twice, and the client waits longer
|
||||
(~36 s) for Google's callback. Reviewed, not yet exercised end to end.
|
||||
|
||||
## [3.3.6] — 2026-10-08
|
||||
|
||||
|
||||
Reference in new issue
Block a user