@@ -601,6 +601,31 @@ pub extern "system" fn Java_nz_diaswarm_jni_SwarmNative_swarmOffer<'a>(
     }
 }
 
+/// Android says the network changed; tell iroh, which cannot see it itself.
+///
+/// **THE MISSING HALF OF A 71-MINUTE OUTAGE.** `netwatch` ships a deliberately
+/// empty route monitor on Android — "Very sad monitor. Android doesn't allow us
+/// to do this" — so nothing native ever learns that wifi became mobile data.
+/// iroh's own documentation says Java has to tell it. This is where Java tells
+/// it. See `Swarm::network_changed`.
+///
+/// Returns 1 if the notification was delivered, 0 if there is no swarm to
+/// notify. Cheap enough to call on every `ConnectivityManager` callback;
+/// upstream says calling it needlessly does no harm.
+#[no_mangle]
+pub extern "system" fn Java_nz_diaswarm_jni_SwarmNative_swarmNetworkChanged(
+    _env: JNIEnv,
+    _class: JClass,
+    handle: jlong,
+) -> jlong {
+    if handle == 0 {
+        return 0;
+    }
+    let pooled = unsafe { &*(handle as *const Pooled) };
+    pooled.runtime.block_on(pooled.swarm.network_changed());
+    1
+}
+
 /// One pass: say what we hold, hear what we should, take on a few of them.
 ///
 /// Returns `pool<TAB>buckets<TAB>held<TAB>wanted<TAB>adopted`, or empty.
 
@@ -365,6 +365,42 @@ impl Swarm {
         if connected > 0 { format!("connected({connected})") } else { "disconnected".into() }
     }
 
+    /// Tell iroh the network underneath us may have changed.
+    ///
+    /// **THIS IS THE 71-MINUTE OUTAGE OF 2026-09-15, AND IT IS OURS.** The loop
+    /// phone left the house at 15:05, moved from wifi to mobile data, and its
+    /// relay connection went and stayed gone until 16:16, when wifi came back.
+    /// AAPS never faltered: it sealed 84 epochs into that hole, `holds` climbed
+    /// 1470 -> 1560, `missing 0, lost 0, failures 0`. The data was made and
+    /// kept. It simply had nowhere to go.
+    ///
+    /// The reason is upstream, documented, and deliberate. `netwatch`'s Android
+    /// route monitor is a stub whose comment reads "Very sad monitor. Android
+    /// doesn't allow us to do this", and its wall-time poll is set to an hour on
+    /// mobile to save battery — and fires only on a *clock* jump, never a
+    /// network one. So on Android iroh cannot see a network change at all. Its
+    /// own docs say what to do instead:
+    ///
+    /// > some systems like android do not expose this functionality to native
+    /// > code. Android does however provide this functionality to Java code.
+    ///
+    /// So Java has to say so, and this is the way in. Not calling it means a
+    /// phone that changes network keeps sockets bound to the interface it just
+    /// left: not a carrier blocking us, not doze, not the foreground service —
+    /// a notification we never sent.
+    ///
+    /// Cheap and idempotent by upstream's own account — "even when the network
+    /// did not change [...] there is no harm in calling this function" — so the
+    /// callers err towards calling it.
+    pub async fn network_changed(&self) {
+        match self.iroh_endpoint().await {
+            Ok(ep) => ep.network_change().await,
+            // Nothing to notify yet. The endpoint takes its first look at the
+            // network when it starts, so a change before that is already seen.
+            Err(e) => eprintln!("diaswarm: no endpoint to notify of a network change ({e})"),
+        }
+    }
+
     pub async fn pool_members(&self) -> Result<Vec<String>> {
         let me = self.node_id().await?;
         let mut ids: Vec<String> = self
 
@@ -797,6 +797,101 @@ record. The thing the TODOs are about is the thing this decision removes.
 per record somewhere, which would mean the separation is less clean than both
 the API and those TODOs suggest.
 
+### D32 · Android must tell iroh the network changed, because iroh cannot see it
+
+**Settled and implemented 2026-09-15.** The measured cause of a 71-minute outage,
+and it is ours, not the carrier's.
+
+#### 1. What happened
+
+The loop phone left the house at 15:05 and came back at 16:16. From
+`AndroidAPS.log`, which is the only reason any of this is knowable — logcat's
+ring buffer had long since rolled past it:
+
+```
+15:04:24  pool 3 peers, 4 buckets, holding 3, relay=connected(1)
+15:05:25  pool 2 peers, 2 buckets, holding 3, relay=disconnected
+   ...    88 consecutive passes, 71 minutes
+16:16:23  pool 2 peers, 2 buckets, holding 3, relay=connected(1)
+```
+
+The laptop peer's `holding` froze at 2025 for 56 passes and then jumped `+44` in
+a single pass on recovery. Ayni's reading went to `3471s old` and was back to
+`52s` two passes later.
+
+**AAPS never faltered.** Into those 71 minutes it sealed **84 epochs**, `holds`
+climbed 1470 → 1560, and every pass said `missing 0, lost 0, failures 0`. The
+data was made and it was kept. It had nowhere to go.
+
+#### 2. It was not doze, not the carrier, and not the foreground service
+
+All three have been blamed for overnight failures before, and this was none of
+them. AAPS is on the battery-optimisation whitelist
+(`user,info.nightscout.androidaps,10310`), it runs at `targetSdk 32` and is
+exempt from the whole foreground-service timeout regime, and it went on doing
+its work throughout — a sealing app is not a sleeping one.
+
+`relay=disconnected` is not our inference either. It is iroh's own
+`home_relay_status()`, read straight out of the endpoint.
+
+#### 3. The cause: a notification we never sent
+
+`netwatch`'s Android route monitor is a stub. Its entire body is a comment:
+
+```rust
+// Very sad monitor. Android doesn't allow us to do this
+```
+
+and its wall-time poll is stretched to an hour on mobile to save battery — and
+fires on a *clock* jump, never a network one. **So on Android, nothing native
+ever learns that wifi became mobile data.** iroh's own documentation says so, and
+names the platform and the remedy:
+
+> On many systems iroh is able to detect network changes by itself, however some
+> systems like android do not expose this functionality to native code. Android
+> does however provide this functionality to Java code. This function allows for
+> notifying iroh of any potential network changes like this.
+
+`Endpoint::network_change()` is public, and we had never called it. What we lost
+by not calling it is everything in `handle_network_change`: the UDP **rebind**,
+`dns_resolver.reset()`, a fresh net report, and the QUIC stack being told to
+migrate. Our relay is `https://aps1-1.relay.n0.iroh.link.` — a **hostname** — so
+every reconnect needs DNS, and a resolver still pointing at the network the phone
+walked away from fails every time until it walks back.
+
+#### 4. Why a brief wifi toggle looks fine, which is how this hid
+
+Switching wifi off at home and on again keeps working, and that observation is
+what makes the mechanism specific rather than vague. Live QUIC connections keep
+flowing over the wildcard socket via cellular, and nothing needs to re-resolve
+anything. **The failure needs a network change that outlives its connections** —
+leaving, not toggling. That is why every short test passed and why the finding
+only appeared on a real errand.
+
+#### 5. The fix
+
+`Swarm::network_changed` → `swarmNetworkChanged` (JNI) → `NetworkWatch`, a
+`ConnectivityManager.registerDefaultNetworkCallback` in both apps. It notifies on
+every callback rather than guessing which ones matter, because upstream is
+explicit that a needless call does no harm and the failure it guards against is
+an hour of silence. Bursts coalesce to one in-flight notification. The logger is
+injected so the lines land in `AndroidAPS.log` rather than the buffer that lost
+the last one.
+
+*Reopens if:* a phone that genuinely leaves the house still loses the relay for
+longer than a reconnect takes. That would mean the notification is delivered and
+insufficient, and the next suspect is the endpoint rebuild `relay_state`'s
+doc comment has always declined to do.
+
+#### 6. What this corrects
+
+**"Off-LAN is proven" was recorded on weaker evidence than it sounded.** The
+2026-09-11 result had the phone on mobile data *while still at home*. The first
+time it genuinely left, sharing stopped. Off-LAN via relay is real and still
+holds — the relay reconnected and everything resumed — but it is now known to
+depend on a notification that was not being sent, so it was never as robust as
+the record claimed.
+
 ### D31 · A rendezvous that depends on a number nobody agrees on
 
 **Open, recorded 2026-09-14, not yet fixed.** Found by asking what happens with
 
@@ -1,28 +1,52 @@
-# Handover — 2026-09-15 07:30
+# Handover — 2026-09-15 16:45
 
-Everything is committed and pushed. The only uncommitted files are
-`README.md` and `fdroid/nz.diaswarm.ayni.yml`, which carry **the user's own
-edits — do not commit them**.
+`README.md` and `fdroid/nz.diaswarm.ayni.yml` may carry **the user's own edits —
+check `git status` before committing anything.**
 
 ---
 
-## 1. What is running right now, and when it answers
+## 1. The headline: the off-LAN outage is explained and fixed
 
-**A soak on phone B, started 07:13.** It is the only thing with a clock on it.
+**A 71-minute outage on 2026-09-15 had one cause, and it was ours.** See D32 in
+[decisions.md](decisions.md) and the end of [migration.md](migration.md).
 
 ```
-scratchpad/fgs-soak.log      one line every ten minutes
+15:04:24  relay=connected(1)
+15:05:25  relay=disconnected      <- phone left the house, wifi -> mobile
+   ...    88 consecutive passes, 71 minutes
+16:16:23  relay=connected(1)      <- came home, wifi back
 ```
 
-**The question:** does Ayni's foreground service survive past **372 minutes**
-(~13:25), which is where the previous build died. Anything before that proves
-nothing.
+**AAPS never faltered**: 84 epochs sealed into the hole, `holds` 1470 → 1560,
+`missing 0, lost 0, failures 0`. Not doze (AAPS is whitelisted and at
+`targetSdk 32`), not the carrier, not the foreground service.
 
-Baseline at start: `pid 19707 · types=0x40000000 · effective=NONE`.
+**The cause:** on Android, `netwatch`'s route monitor is an empty stub — *"Very
+sad monitor. Android doesn't allow us to do this"* — and its wall-time poll is an
+hour on mobile and fires only on a *clock* jump. **iroh cannot see an Android
+network change.** Its own docs say Java must call `Endpoint::network_change()`.
+We never did.
 
-Phone B is screen-off and on USB. **Charging does not affect the thing being
-measured** — the foreground-service time limit is not a doze mechanism — and it
-isolates the variable. Unplug only if a combined doze test is wanted instead.
+**The fix:** `NetworkWatch` (in `nz/diaswarm/jni/`, duplicated in both apps) →
+`SwarmNative.swarmNetworkChanged` → `Swarm::network_changed`.
+
+⚠️ **A BRIEF WIFI TOGGLE DOES NOT REPRODUCE THIS**, which is why it hid for
+days. Live QUIC connections keep flowing over the wildcard socket via cellular
+and nothing has to re-resolve. It needs a network change that **outlives its
+connections** — leaving, not toggling.
+
+⚠️ **"Off-LAN is proven" was over-claimed** from 2026-09-11 onward: every such
+test had the phone on mobile data *while still at home*.
+
+---
+
+## 1a. The foreground-service soak: PASSED
+
+`specialUse` works. First process ran **8h03m** (07:19 → 15:22) against
+`dataSync`'s death at 6h12m, `effective=NONE` and `doze=IDLE` across all 60
+samples, two-minute cadence held. It then restarted and **came back**, which
+`dataSync` could not ("Time limit already exhausted"). The 15:22 restart is a
+separate question — most likely the known Ayni memory leak.
 
 ---
 
 
@@ -3228,3 +3228,73 @@ the actual overnight case: a looping phone in somebody's pocket or beside a bed,
 on mobile data, sharing with a parent who is asleep. An hour-long silent gap in
 that scenario is the thing the follower's age display exists to make survivable —
 but survivable is not the same as working.
+
+---
+
+## The cause, established — and it was not doze
+
+**2026-09-15, same day, from `AndroidAPS.log`.** The durable log covers the
+window; logcat had rolled past it hours before, which is the whole reason AAPS
+keeping its own log on disk mattered here.
+
+The outage has a single, exact signature:
+
+```
+15:04:24  pool 3 peers, 4 buckets, holding 3, relay=connected(1)
+15:05:25  pool 2 peers, 2 buckets, holding 3, relay=disconnected
+   ...    88 consecutive passes
+16:16:23  pool 2 peers, 2 buckets, holding 3, relay=connected(1)
+```
+
+Seventy-one minutes, bracketing both readers' observations exactly.
+
+**The publisher never faltered.** Into that hole AAPS sealed **84 epochs**,
+`holds` climbed 1470 → 1560, and every single pass reported `missing 0, lost 0,
+failures 0`. The data was made and it was kept. It had nowhere to go — which is
+precisely why nothing was lost and the backlog arrived complete.
+
+⚠️ **Doze is ruled out, not merely doubted.** AAPS is on the battery
+optimisation whitelist (`user,info.nightscout.androidaps,10310`), it runs at
+`targetSdk 32` and is exempt from the foreground-service regime entirely, and it
+was demonstrably working throughout — a phone sealing an epoch a minute is not a
+phone Android has stopped. The previous entry's suspicion was reasonable and
+wrong. That makes **three** overnight failures now blamed on doze and caused by
+something else.
+
+`relay=disconnected` is not our inference either: it is iroh's own
+`home_relay_status()`.
+
+### Why it happened
+
+`netwatch`'s Android route monitor is a deliberate stub —
+
+```rust
+// Very sad monitor. Android doesn't allow us to do this
+```
+
+— and its wall-time poll is stretched to an hour on mobile for battery, and
+fires on a *clock* jump rather than a network one. **So on Android iroh cannot
+see a network change at all.** Its own docs name the platform and the remedy:
+`Endpoint::network_change()` is public and exists for exactly this. We had never
+called it.
+
+What that costs is everything in `handle_network_change`: the UDP rebind,
+`dns_resolver.reset()`, a fresh net report, and the QUIC stack being told to
+migrate. The relay is a **hostname**, so reconnecting needs DNS — and a resolver
+still aimed at the network the phone walked away from keeps failing until it
+walks back. Which is what 16:16 is.
+
+### Why every previous test passed
+
+Switching wifi off at home and on again keeps working, and that observation is
+what makes this specific rather than hand-waving. Live QUIC connections keep
+flowing over the wildcard socket via cellular, and nothing has to re-resolve
+anything. **The failure needs a network change that outlives its connections** —
+leaving, not toggling. Every off-LAN test so far was run from the house.
+
+### What was recorded too strongly
+
+"Off-LAN is proven" has been in the record since 2026-09-11. It was measured
+with the phone on mobile data **while still at home**. Off-LAN via relay is real
+and the relay did come back — but it depended on a notification that was never
+being sent, so it was never as robust as the record claimed. See D32.
@@ -61,6 +61,13 @@ object Endpoint {
             return
         }
         handle = h
+        // **AFTER THE HANDLE IS SET, SO THE FIRST CALLBACK FINDS ONE.** iroh
+        // cannot see an Android network change; without this the phone keeps
+        // sockets bound to the network it left. See [nz.diaswarm.jni.NetworkWatch].
+        nz.diaswarm.jni.NetworkWatch.start(
+            context.applicationContext,
+            { Log.i(SyncWorker.TAG, it) }
+        ) { handle }
         Log.i(SyncWorker.TAG, "in the pool as ${SwarmNative.swarmNodeId(h).take(16)}")
     }
 
@@ -83,6 +90,9 @@ object Endpoint {
         val app = context.applicationContext
         Thread {
             synchronized(this) {
+                // BEFORE THE HANDLE GOES ANYWHERE — `swarmLeave` frees it, and
+                // this returns only once no notification still holds it.
+                nz.diaswarm.jni.NetworkWatch.stop(app) { Log.i(SyncWorker.TAG, it) }
                 val old = handle
                 handle = 0L
                 if (old != 0L) {