Summary

• Fixes the Android node gateway handshake window so node.event cannot be sent before the connect RPC has succeeded.
• Adds a bounded queue for failed notifications.changed events and flushes it after node reconnect.
• Reconciles active Android notifications after listener/node reconnect so missed posted notifications are replayed without duplicating already emitted keys.

Real behavior proof

• Behavior or issue addressed: Android notification forwarding could emit notifications.changed as node.event while the WebSocket connect RPC was still pending, making the gateway reject the session because the first accepted request was not the completed connect handshake. Reconnect windows could also drop notification events because failed sends were not queued and active notifications were not replayed.

• Why it matters / User impact: Android users could miss notification forwarding events after app start or reconnect, and the node session could enter an invalid handshake state instead of recovering cleanly.

• Real environment tested: Local Linux Android JVM/Robolectric environment using the production Android GatewaySession, NodeRuntime, and DeviceNotificationListenerService code paths with OkHttp WebSocket + MockWebServer gateway. ANDROID_HOME=$HOME/.android-sdk; JAVA_HOME=$HOME/.jdks/jdk-21.0.7+6.

• Exact steps or command run after this patch: From apps/android: ANDROID_HOME="$HOME/.android-sdk" ANDROID_SDK_ROOT="$HOME/.android-sdk" JAVA_HOME="$HOME/.jdks/jdk-21.0.7+6" ./gradlew --no-daemon :app:testPlayDebugUnitTest --tests ai.openclaw.app.gateway.GatewaySessionInvokeTest --tests ai.openclaw.app.node.DeviceNotificationListenerServiceTest --rerun-tasks

• Evidence after fix: Evidence log: openclaw-issue-79552-evidence/android-focused-tests-after-commit.log

  > Task :app:testPlayDebugUnitTest
  BUILD SUCCESSFUL in 3m 13s
  30 actionable tasks: 30 executed
  

• Observed result after fix: The focused JVM run exercised the production Android WebSocket session and notification listener paths. The new gateway regression verifies sendNodeEvent() returns false while the connect response is pending and the server only observes connect; the companion regression verifies onConnected can immediately send notifications.changed after connect success. The notification regressions verify bounded queue behavior, failed flush re-prepending, active-notification replay, retry when the sink is unavailable, and no duplicate replay of delivered keys.

• What was not tested: No physical Android device, OS notification shade, or external OpenClaw gateway was used; the proof is limited to local Android JVM/Robolectric plus local WebSocket gateway behavior.

• Fix classification: Root cause fix.

Review findings addressed

• No maintainer review findings existed for this new PR at submission time.
• ClawSweeper issue criteria were covered locally: focused GatewaySessionInvokeTest, focused DeviceNotificationListenerServiceTest, and git diff --check.

Regression Test Plan

• Target test file: apps/android/app/src/test/java/ai/openclaw/app/gateway/GatewaySessionInvokeTest.kt and apps/android/app/src/test/java/ai/openclaw/app/node/DeviceNotificationListenerServiceTest.kt.

• Scenario locked in: The regression tests lock the exact lifecycle scenario: a WebSocket is open, the gateway has received the connect request, the connect response is still pending, and Android notification forwarding attempts to send notifications.changed. They also lock the reconnect scenario where queued notification events flush after connect and active posted notifications replay only when their keys have not already emitted a posted event.

• Why this is the smallest reliable guardrail: The guardrail lives at the Android node/gateway boundary that was broken. It checks the real GatewaySession.sendNodeEvent() result and the notification replay state instead of asserting implementation details, so future refactors can change internals without reintroducing pre-handshake node.event delivery or duplicate active-notification replay.

• Android focused JVM tests:

  cd apps/android
  ANDROID_HOME="$HOME/.android-sdk" ANDROID_SDK_ROOT="$HOME/.android-sdk" JAVA_HOME="$HOME/.jdks/jdk-21.0.7+6" ./gradlew --no-daemon :app:testPlayDebugUnitTest --tests ai.openclaw.app.gateway.GatewaySessionInvokeTest --tests ai.openclaw.app.node.DeviceNotificationListenerServiceTest --rerun-tasks
  

  Result: BUILD SUCCESSFUL in 3m 13s; evidence: openclaw-issue-79552-evidence/android-focused-tests-after-commit.log.

• Android ktlint:

  cd apps/android
  ANDROID_HOME="$HOME/.android-sdk" ANDROID_SDK_ROOT="$HOME/.android-sdk" JAVA_HOME="$HOME/.jdks/jdk-21.0.7+6" ./gradlew --no-daemon :app:ktlintCheck :benchmark:ktlintCheck
  

  Result: BUILD SUCCESSFUL in 22s; evidence: openclaw-issue-79552-evidence/android-ktlint-after-commit.log.

• Whitespace check:

  git diff --check
  

  Result: passed with no output; evidence: openclaw-issue-79552-evidence/git-diff-check-after-commit.log.

Merge risk

• Risk labels considered: merge-risk: 🚨 message-delivery, merge-risk: 🚨 availability, merge-risk: 🚨 session-state.
• What did NOT change: Out of scope: gateway wire format, node.event payload schema, notification action APIs, Android forwarding policy defaults, provider/auth token selection, agent.request, and presence beacon behavior remain unchanged. The patch only changes when the Android node exposes a ready connection and how notifications.changed recovers during reconnect.
• Architecture / source-of-truth check: The source-of-truth boundary is Android GatewaySession connection lifecycle state plus DeviceNotificationStore active-notification state. This does not add a new public contract, schema, default, migration, or partial override; it restores the existing protocol invariant that the first gateway RPC for a socket is connect. Related open PR scan for issue [Bug]: Android node sends node.event before websocket connect handshake completes, causing notification events to be lost #79552 found no linked open PRs in openclaw-issue-79552-evidence/linked-open-prs-for-issue.json.
• Risk explanation: The patch changes Android node connection readiness and notification event delivery around reconnect. It deliberately limits queueing to notifications.changed, keeps agent.request and presence beacon failure semantics unchanged, bounds queued notifications to 128 entries, and only promotes a gateway connection when the completed connect RPC still belongs to the current desired target.
• Why acceptable: The changed behavior is constrained to the broken Android notification forwarding path and handshake exposure boundary. Tests cover the pending-handshake false path, post-connect immediate send path, bounded queue flush/requeue behavior, active notification replay, unavailable sink retry, and duplicate replay prevention.
• Maintainer-ready confidence: High: the fix is focused to Android gateway/session notification delivery, includes production-path regression tests, and has fresh local evidence collected after the final code changes.
• Patch quality notes: No dependency, lockfile, public API, schema, protocol format, or configuration default changes. No unrelated files were changed. Patch quality warnings are intentional lifecycle guard/default boundaries: the connectingConnection guard prevents stale handshakes from being promoted, the notification false returns distinguish unavailable sinks from successful emits, and the queue lock is a process-local monitor for the bounded pending notification list rather than a type escape across APIs.

Root Cause

• Root cause: The Android gateway lifecycle state used currentConnection as both the handshake-stage socket and the ready node socket. That violated the protocol invariant that the first usable gateway RPC on a socket is the successful connect RPC, so notification forwarding could treat a not-yet-connected socket as ready and send node.event during the handshake window. Failed notifications.changed sends were also fire-and-forget, and reconnect did not use active notification state as the source for replaying posted notifications missed while the node connection was unavailable.
• Why this is root-cause fix: The patch restores the lifecycle state invariant at the source: connectingConnection represents a socket whose connect RPC is still pending, while currentConnection becomes visible only after connect success and before onConnected callbacks run. Notification recovery is tied to the same ready-state transition by queueing only failed notifications.changed events, flushing them after reconnect, and reconciling active notification entries that have not already emitted a posted event. This fixes the invalid first-request source path and the missed-notification recovery path without masking the symptom in downstream gateway error handling or changing unrelated node events.