Actually keep the phone's sessions alive when the app is backgrounded

The foreground service existed, and four defects in its wiring meant it
mostly did not run. A shell opening was never announced to it — only the
ending was — so the service never came up for a shell at all. An idle
connected Files session counted as nothing. Every refresh restarted the
service, which Android 12+ answers with a crash the moment the app is
backgrounded — a transfer finishing in the pocket took the remaining
connections with it. And POST_NOTIFICATIONS was declared but never
requested, so on Android 13+ the receipt was silently invisible.

Updates while backgrounded now go through the notification manager; a
foregrounded refresh still prefers a real start, so a stop still in
flight cannot leave an orphan receipt over an unprotected process.
This commit is contained in:
2026-08-09 10:14:17 +02:00
parent 810bc48d3f
commit 48ea5e22d5
4 changed files with 241 additions and 49 deletions
@@ -17,22 +17,34 @@ namespace DodoSSH.Client.Android.Platform;
/// tally kept here. It already knows that a session whose shell exited half an hour ago is not live, which
/// a counter incremented on open and decremented on close would not.
/// </para>
/// <para>
/// Three facts feed <see cref="SessionForegroundService.Reconcile"/>, not one: live shells, moving
/// transfers, and an idle-but-connected Files session. The last of those used to be missing entirely —
/// a shell survives backgrounding because somebody opened it, but a Files connection with nothing moving
/// looked, to this class, exactly like nothing being open at all. <c>holdsFileSession</c> below is that
/// gap closed, read the same way the other two facts are: asked, not cached.
/// </para>
/// </remarks>
internal sealed class SessionKeepAlive : IDisposable
{
private readonly TerminalWorkspace workspace;
private readonly Func<int> activeTransfers;
private readonly Func<bool> holdsFileSession;
/// <param name="workspace">The live shells.</param>
/// <param name="activeTransfers">
/// How many transfers are moving bytes. A delegate rather than a queue, because file transfer is out
/// of this head's first scope — see the decision in docs/android-port.md — and this is the seam it
/// will arrive through rather than a dependency taken before there is anything to depend on.
/// How many transfers are moving bytes. A delegate rather than a queue, because ownership of the
/// transfer queue stays with <c>TransfersViewModel</c> — this class only ever asks it a question.
/// </param>
public SessionKeepAlive(TerminalWorkspace workspace, Func<int> activeTransfers)
/// <param name="holdsFileSession">
/// Whether the Files screen holds a live SFTP connection with nothing moving on it — the idle-but-
/// connected case a transfer count alone would miss. See <c>TransfersViewModel.HasLiveFileSession</c>.
/// </param>
public SessionKeepAlive(TerminalWorkspace workspace, Func<int> activeTransfers, Func<bool> holdsFileSession)
{
this.workspace = workspace;
this.activeTransfers = activeTransfers;
this.holdsFileSession = holdsFileSession;
// Raised on whatever thread the pump unwound on, which is fine: starting and stopping a service is
// a binder call and needs no particular thread. Nothing here touches the interface.
@@ -41,13 +53,14 @@ internal sealed class SessionKeepAlive : IDisposable
/// <summary>Re-reads the counts and starts or stops the service to match.</summary>
/// <remarks>
/// Called after anything that could change either count — opening a shell, closing a tab, a transfer
/// finishing. Calling it when nothing changed is free: reconciling to the state it is already in is
/// either a redundant <c>startForegroundService</c> on a running service or a <c>stopService</c> on a
/// stopped one, and Android treats both as no-ops.
/// Called after anything that could change any of the three facts — opening a shell, closing a tab, a
/// transfer finishing, a Files connection opening or closing. Calling it when nothing changed is free:
/// reconciling to the state it is already in is either a redundant <c>startForegroundService</c> — or,
/// now, a redundant notification post — on a running service, or a <c>stopService</c> on a stopped one,
/// and Android treats all of those as no-ops.
/// </remarks>
public void Refresh() =>
SessionForegroundService.Reconcile(workspace.LiveSessionCount, activeTransfers());
SessionForegroundService.Reconcile(workspace.LiveSessionCount, activeTransfers(), holdsFileSession());
/// <inheritdoc />
public void Dispose()
@@ -56,7 +69,7 @@ internal sealed class SessionKeepAlive : IDisposable
// The notification goes with the composition root. Leaving it up over a process that is shutting
// down is how an SSH client acquires a reputation for a notification you cannot get rid of.
SessionForegroundService.Reconcile(0, 0);
SessionForegroundService.Reconcile(0, 0, false);
}
private void OnSessionEnded(object? sender, TerminalSessionEndedEventArgs e) => Refresh();