Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Mobile gateway recovery drops structured PROTOCOL_MISMATCH connect details and shows a generic protocol mismatch failure instead of actionable update guidance.

Steps to reproduce

1. Build the Android app from current main before the fix.
2. Start a fake Gateway WebSocket that completes the challenge step, then rejects the operator connect frame with details.code = "PROTOCOL_MISMATCH" and protocol version fields such as clientMinProtocol, clientMaxProtocol, and expectedProtocol.
3. Point the Android onboarding flow at the fake gateway with adb reverse for the gateway port.
4. Complete the app flow until the gateway connection attempt fails.
5. Observe the recovery screen.

Expected behavior

The mobile app should classify protocol mismatch as a non-retryable version-skew recovery state and tell the user which side to update when gateway structured details make that clear. When version fields are absent, it should still show a generic incompatible-version update message instead of raw transport text.

Actual behavior

The Android recovery UI shows only raw protocol mismatch text. The app also treats the auth failure like an ordinary reconnectable gateway failure instead of pausing reconnect around an update-required state.

OpenClaw version

Current main at 4ac5cf8636 before the fix; Android debug build under test.

Operating system

Android API 35 emulator for live reproduction. iOS/OpenClawKit behavior covered with a fake GatewayChannel response harness.

Install method

Source checkout / debug app build.

Model

N/A - failure occurs during Gateway WebSocket connect before model routing.

Provider / routing chain

Mobile app -> local/fake Gateway WebSocket connect handshake.

Additional provider/model setup details

Related desktop/update-prompt issue: #91569. This issue tracks the mobile client recovery behavior only and does not resolve desktop Sparkle/update prompting.

Logs

Fake gateway returned a structured failed connect response with details.code="PROTOCOL_MISMATCH" and protocol fields.
Current main Android recovery rendered raw "protocol mismatch" instead of update guidance.

Screenshots, recordings, and evidence

Live reproduction used the Android onboarding flow against a fake gateway that accepted the socket/challenge path and rejected the operator connect request with a structured protocol mismatch. The fixed branch was then proven against the same flow for app-old, gateway-old, and missing-version fallback cases.

Impact and severity

Affected: Mobile app users connecting to a gateway with incompatible protocol versions.
Severity: Blocks onboarding/recovery because the user gets opaque transport text instead of update guidance.
Frequency: Always observed in the version-skew fake-gateway reproduction.
Consequence: Users cannot tell whether to update the app, update the gateway host, or update both.

Additional information

This is a bug rather than a feature request because the gateway already emits structured PROTOCOL_MISMATCH details; the mobile clients were failing to preserve and map that existing contract into the recovery state.