feat(android): add authenticated presence alive beacons by steipete · Pull Request #73373 · openclaw/openclaw

steipete · 2026-04-28T07:22:50Z

Summary

Problem: Android nodes currently rely on live WebSocket presence; after disconnect, paired node metadata can lose the most recent authenticated app-alive signal.
Why it matters: this keeps Android parity with the newly landed iOS node.presence.alive path and makes node.list last-seen metadata useful after reconnects/background transitions.
What changed: Android publishes authenticated node.presence.alive events on node connect and throttled background transitions, checks handled: true, and documents the behavior.
What did NOT change (scope boundary): no Android push/wake transport was added; this only uses the existing authenticated node session and node.event RPC.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related feat(ios): add background alive beacon support #63123
Related feat: add authenticated iOS background presence beacon #73330
This PR fixes a bug or regression

Root Cause (if applicable)

N/A

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: NodePresenceAliveBeaconTest, GatewaySessionInvokeTest
Scenario the test should lock in: Android builds the presence payload, treats old { ok: true } acks as not durable, and preserves the structured node.event response.
Why this is the smallest reliable guardrail: it covers the Android-owned payload/response logic and the GatewaySession RPC framing without requiring a live device.
Existing test that already covers this (if any): gateway server tests already cover persistence and auth identity boundaries for node.presence.alive.
If no new test is added, why not: N/A

User-visible / Behavior Changes

Android paired nodes now publish durable last-seen metadata after node connect and background transitions when the gateway supports node.presence.alive.

Diagram (if applicable)

Before:
Android node connects -> live presence only -> disconnect hides newest alive signal

After:
Android node connects/backgrounds -> node.presence.alive -> paired metadata lastSeenAtMs/lastSeenReason

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? Yes
Command/tool execution surface changed? No
Data access scope changed? No
If any Yes, explain risk + mitigation: Android sends an existing authenticated node.event RPC over the already-paired node session. Gateway persistence remains bounded by the authenticated node device identity.

Repro + Verification

Environment

OS: macOS
Runtime/container: Android Gradle :app:testPlayDebugUnitTest, Android SDK at ~/Library/Android/sdk
Model/provider: N/A
Integration/channel (if any): Android node app
Relevant config (redacted): N/A

Steps

Build the Android play debug unit test graph.
Run NodePresenceAliveBeaconTest.
Run GatewaySessionInvokeTest.

Expected

Beacon helper payload/response behavior passes.
GatewaySession sends node.event params with payloadJSON and returns the structured response.

Actual

Passed.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Focused command:

ANDROID_HOME="$HOME/Library/Android/sdk" ANDROID_SDK_ROOT="$HOME/Library/Android/sdk" ./gradlew :app:testPlayDebugUnitTest --tests ai.openclaw.app.node.NodePresenceAliveBeaconTest --tests ai.openclaw.app.gateway.GatewaySessionInvokeTest

Result after rebase:

BUILD SUCCESSFUL in 3s
30 actionable tasks: 30 up-to-date

Also ran git diff --check.

Note: ./gradlew :app:ktlintFormat is currently blocked by pre-existing Android ktlint debt across unrelated files; this PR did not include those cleanup changes.

Human Verification (required)

Verified scenarios: focused Android unit tests for payload generation, response decoding, old gateway ack handling, and node.event structured response framing.
Edge cases checked: recent-success throttling requires a connected gateway; old { "ok": true } responses do not count as handled.
What you did not verify: real-device background transition or full Android app install.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: Older gateways acknowledge node.event without durable presence support.
- Mitigation: Android treats that as an RPC ack only and requires handled: true before recording a local success.

aisle-research-bot · 2026-04-28T07:22:56Z

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

#	Severity	Title
1	🔵 Low	Untrusted gateway `reason` string written to logs (log injection / info disclosure)

1. 🔵 Untrusted gateway `reason` string written to logs (log injection / info disclosure)

Property	Value
Severity	Low
CWE	CWE-117
Location	`apps/android/app/src/main/java/ai/openclaw/app/NodeRuntime.kt:704-707`

Description

NodeRuntime.sendNodePresenceAliveBeacon logs the gateway-provided reason field when the node.presence.alive event is not handled.

Input (untrusted): response?.reason is parsed from result.payloadJson, which originates from the gateway RPC response.
Sink: Android Log.d(...) writes this string to device logs.
Issue: sanitizeReasonForLog() only replaces ISO control characters and truncates to 200 chars. It does not neutralize other potentially misleading/log-forging content (e.g., Unicode bidi override characters) and still allows the server to cause arbitrary text to be written to logs. If logs are collected (e.g., via adb, OEM tooling, or any future log-upload feature), this can also leak sensitive server-supplied details into diagnostic logs.

Vulnerable code:

Log.d(
  "OpenClawNode",
  "node.presence.alive not handled: ${NodePresenceAliveBeacon.sanitizeReasonForLog(response?.reason)}",
)

Recommendation

Avoid logging untrusted server-provided free-form text in production, or strongly neutralize it.

Options:

Log only a stable code (preferred):

val reasonCode = response?.reason?.takeWhile { it.isLetterOrDigit() || it == '_' || it == '-' }?.take(50)
  ?: "unsupported"
Log.d("OpenClawNode", "node.presence.alive not handled; reasonCode=$reasonCode")

If free-form text is required, escape/encode it before logging (e.g., JSON-string encode) and strip bidi/format characters:

fun safeForLog(raw: String?): String {
  val s = raw?.trim().orEmpty().take(200)
  val noControls = s.filterNot { it.isISOControl() || Character.getType(it) == Character.FORMAT.toInt() }
  return kotlinx.serialization.json.JsonPrimitive(noControls).toString() // quoted/escaped
}

Log.d("OpenClawNode", "node.presence.alive not handled: ${safeForLog(response?.reason)}")

Also consider gating the log behind a debug flag (or using Log.w with a fixed message) to reduce exposure in release builds.

Analyzed PR: #73373 at commit 4603e21

_{Last updated on: 2026-04-28T07:51:20Z}

cursor · 2026-04-28T07:23:01Z

PR Summary

Medium Risk
Changes connection-time/background network behavior and node.event RPC handling, which could affect presence reporting and error handling on flaky networks. Scope is limited to Android client code with added tests and backward-compatible response parsing.

Overview
Android node sessions now publish authenticated node.presence.alive beacons via node.event after connect and on background transitions (throttled by last successful record) to keep paired node lastSeen metadata durable across disconnects.

This introduces a NodePresenceAliveBeacon helper to build the payload and interpret gateway responses, and extends GatewaySession with sendNodeEventDetailed (structured RpcResult) while making sendNodeEvent treat a completed RPC as success even when the gateway returns an error payload.

Adds unit/seam tests for the new beacon payload/response handling and the node.event RPC framing, and updates the Android docs/README and changelog to describe the new presence beacon behavior and backward compatibility with older gateways.

^{Reviewed by Cursor Bugbot for commit 4603e21. Bugbot is set up for automated code reviews on this repo. Configure here.}

greptile-apps · 2026-04-28T07:25:22Z

Greptile Summary

Adds Android parity for node.presence.alive beacons: a new NodePresenceAliveBeacon helper builds and decodes the payload, GatewaySession gains a sendNodeEventDetailed variant that returns the full RpcResult, and NodeRuntime fires a beacon on connect and on background transitions with a 10-minute dedup guard.

nodePresenceAliveLastSuccessAtMs is declared as a plain var in a class whose coroutine scope uses Dispatchers.IO (multi-threaded). Without @Volatile, the JVM memory model does not guarantee cross-thread visibility, so a concurrent connect + background transition can both read a stale null, both bypass the throttle, and both emit — silently defeating the dedup guard.

Confidence Score: 3/5

Mostly safe; a missing @Volatile on the throttle timestamp can cause duplicate beacons under concurrent IO coroutines, which should be fixed before merging.

One P1 finding: nodePresenceAliveLastSuccessAtMs lacks @Volatile in a multi-threaded Dispatchers.IO scope, breaking the dedup throttle under concurrent coroutine execution. A P1 ceiling is 4/5; the concurrency issue is isolated to the throttle path (no data corruption or security impact), pulling the score to 3/5.

apps/android/app/src/main/java/ai/openclaw/app/NodeRuntime.kt — the nodePresenceAliveLastSuccessAtMs field needs @Volatile.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/NodeRuntime.kt
Line: 250

Comment:
**`nodePresenceAliveLastSuccessAtMs` not visible across IO threads**

`scope` is `CoroutineScope(SupervisorJob() + Dispatchers.IO)`, a multi-threaded pool. Without `@Volatile`, the JVM memory model does not guarantee that a write to this `var` in one IO coroutine is visible to a concurrent read in another. The connect beacon (coroutine C1) and an immediate background beacon (coroutine C2) can both read `null`, both skip the throttle, and both emit, silently defeating the 10-minute dedup guard.

```suggestion
  @Volatile private var nodePresenceAliveLastSuccessAtMs: Long? = null
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/node/NodePresenceAliveBeacon.kt
Line: 35-46

Comment:
**`isGatewayConnected` branch is dead code at the only call site**

`sendNodePresenceAliveBeacon` in `NodeRuntime` always passes `isGatewayConnected = true`, so the early-return on `!isGatewayConnected` (which returns `false` / "don't skip") is never exercised in production. The intent of the parameter is also unclear: returning `false` when not connected means "proceed to send", yet the caller's outer `if (!_nodeConnected.value) return` guard already handles that. Consider removing the parameter from `shouldSkipRecentSuccess` and relying solely on the existing connection guard in `sendNodePresenceAliveBeacon`.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat: add Android presence alive beacons" | Re-trigger Greptile}

greptile-apps · 2026-04-28T07:25:26Z

  private var gatewayAgents: List<GatewayAgentSummary> = emptyList()
  private var didAutoRequestCanvasRehydrate = false
  private val canvasRehydrateSeq = AtomicLong(0)
+  private var nodePresenceAliveLastSuccessAtMs: Long? = null


nodePresenceAliveLastSuccessAtMs not visible across IO threads

scope is CoroutineScope(SupervisorJob() + Dispatchers.IO), a multi-threaded pool. Without @Volatile, the JVM memory model does not guarantee that a write to this var in one IO coroutine is visible to a concurrent read in another. The connect beacon (coroutine C1) and an immediate background beacon (coroutine C2) can both read null, both skip the throttle, and both emit, silently defeating the 10-minute dedup guard.

Suggested change

private var nodePresenceAliveLastSuccessAtMs: Long? = null

@Volatile private var nodePresenceAliveLastSuccessAtMs: Long? = null

Prompt To Fix With AI

This is a comment left during a code review. Path: apps/android/app/src/main/java/ai/openclaw/app/NodeRuntime.kt Line: 250 Comment: **`nodePresenceAliveLastSuccessAtMs` not visible across IO threads** `scope` is `CoroutineScope(SupervisorJob() + Dispatchers.IO)`, a multi-threaded pool. Without `@Volatile`, the JVM memory model does not guarantee that a write to this `var` in one IO coroutine is visible to a concurrent read in another. The connect beacon (coroutine C1) and an immediate background beacon (coroutine C2) can both read `null`, both skip the throttle, and both emit, silently defeating the 10-minute dedup guard. ```suggestion @Volatile private var nodePresenceAliveLastSuccessAtMs: Long? = null ``` How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-04-28T07:25:27Z

+  fun shouldSkipRecentSuccess(
+    isGatewayConnected: Boolean,
+    nowMs: Long,
+    lastSuccessAtMs: Long?,
+    minIntervalMs: Long = MIN_SUCCESS_INTERVAL_MS,
+  ): Boolean {
+    if (!isGatewayConnected) return false
+    val last = lastSuccessAtMs ?: return false
+    if (last <= 0) return false
+    val elapsed = nowMs - last
+    return elapsed >= 0 && elapsed < minIntervalMs
+  }


isGatewayConnected branch is dead code at the only call site

sendNodePresenceAliveBeacon in NodeRuntime always passes isGatewayConnected = true, so the early-return on !isGatewayConnected (which returns false / "don't skip") is never exercised in production. The intent of the parameter is also unclear: returning false when not connected means "proceed to send", yet the caller's outer if (!_nodeConnected.value) return guard already handles that. Consider removing the parameter from shouldSkipRecentSuccess and relying solely on the existing connection guard in sendNodePresenceAliveBeacon.

Prompt To Fix With AI

This is a comment left during a code review. Path: apps/android/app/src/main/java/ai/openclaw/app/node/NodePresenceAliveBeacon.kt Line: 35-46 Comment: **`isGatewayConnected` branch is dead code at the only call site** `sendNodePresenceAliveBeacon` in `NodeRuntime` always passes `isGatewayConnected = true`, so the early-return on `!isGatewayConnected` (which returns `false` / "don't skip") is never exercised in production. The intent of the parameter is also unclear: returning `false` when not connected means "proceed to send", yet the caller's outer `if (!_nodeConnected.value) return` guard already handles that. Consider removing the parameter from `shouldSkipRecentSuccess` and relying solely on the existing connection guard in `sendNodePresenceAliveBeacon`. How can I resolve this? If you propose a fix, please make it concise.

steipete · 2026-04-28T07:29:24Z

Addressed the bot review findings in e287975d73:

Made nodePresenceAliveLastSuccessAtMs @Volatile for cross-thread visibility on Dispatchers.IO.
Removed the dead isGatewayConnected parameter from the Android throttle helper.
Stopped returning/logging raw exception messages from sendNodeEventDetailed.
Sanitized and bounded gateway reason before Android logging.

Validation rerun in Blacksmith Testbox tbx_01kq9ff6whsrq37vn9hb4ks40h:

cd apps/android && ./gradlew :app:testPlayDebugUnitTest --tests ai.openclaw.app.node.NodePresenceAliveBeaconTest --tests ai.openclaw.app.gateway.GatewaySessionInvokeTest

Result: BUILD SUCCESSFUL in 1m 45s.

cursor

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit e287975d73b615f72e822d7324a37579b499e363. Configure here.}

steipete · 2026-04-28T07:40:02Z

Follow-up in f3ab4e2fc4 addresses the remaining Android review items:

Bounded node.presence.alive response JSON before parsing to avoid oversized gateway payload work.
Restored sendNodeEvent(...) compatibility: existing callers now treat a completed node.event RPC as sent even if the gateway response has ok: false; sendNodeEventDetailed(...) still exposes strict ok/payload/error for the presence beacon.
Removed the unused Android trigger normalizer that only tests called.

Validation rerun in Blacksmith Testbox tbx_01kq9ff6whsrq37vn9hb4ks40h on the exact patched tree:

cd apps/android && ./gradlew :app:testPlayDebugUnitTest --tests ai.openclaw.app.node.NodePresenceAliveBeaconTest --tests ai.openclaw.app.gateway.GatewaySessionInvokeTest

Result: BUILD SUCCESSFUL in 4s.

steipete · 2026-04-28T07:49:08Z

Rebased onto current origin/main to pick up the unrelated src/video-generation/provider-registry.test.ts isolation fix, then reran the Android focused gate in Blacksmith Testbox tbx_01kq9ff6whsrq37vn9hb4ks40h on the rebased head 4603e21af8:

cd apps/android && ./gradlew :app:testPlayDebugUnitTest --tests ai.openclaw.app.node.NodePresenceAliveBeaconTest --tests ai.openclaw.app.gateway.GatewaySessionInvokeTest

Result: BUILD SUCCESSFUL in 566ms.

* feat: add Android presence alive beacons * fix: harden Android presence beacon review findings * fix: address Android presence review findings

openclaw-barnacle Bot added docs Improvements or additions to documentation app: android App: android size: M maintainer Maintainer-authored PR labels Apr 28, 2026

greptile-apps Bot reviewed Apr 28, 2026

View reviewed changes

cursor Bot reviewed Apr 28, 2026

View reviewed changes

Comment thread apps/android/app/src/main/java/ai/openclaw/app/node/NodePresenceAliveBeacon.kt Outdated

Comment thread apps/android/app/src/main/java/ai/openclaw/app/gateway/GatewaySession.kt Outdated

steipete added 3 commits April 28, 2026 08:48

feat: add Android presence alive beacons

4ca7ffc

fix: harden Android presence beacon review findings

6cb6e58

fix: address Android presence review findings

4603e21

steipete force-pushed the feat/android-background-presence-beacon branch from f3ab4e2 to 4603e21 Compare April 28, 2026 07:49

steipete merged commit 04e774e into main Apr 28, 2026
38 of 39 checks passed

steipete deleted the feat/android-background-presence-beacon branch April 28, 2026 07:55

clawsweeper Bot mentioned this pull request Jun 26, 2026

feat(ios): add background alive beacon support #63123

Closed

25 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

feat(android): add authenticated presence alive beacons#73373

feat(android): add authenticated presence alive beacons#73373
steipete merged 3 commits into
mainfrom
feat/android-background-presence-beacon

steipete commented Apr 28, 2026

Uh oh!

aisle-research-bot Bot commented Apr 28, 2026 •

edited

Loading

Description

Recommendation

Uh oh!

cursor Bot commented Apr 28, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Apr 28, 2026

Uh oh!

greptile-apps Bot Apr 28, 2026

Uh oh!

greptile-apps Bot Apr 28, 2026

Uh oh!

steipete commented Apr 28, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

Uh oh!

steipete commented Apr 28, 2026

Uh oh!

steipete commented Apr 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

	private var nodePresenceAliveLastSuccessAtMs: Long? = null
	@Volatile private var nodePresenceAliveLastSuccessAtMs: Long? = null

Uh oh!

Uh oh!

Conversation

steipete commented Apr 28, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

aisle-research-bot Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Aisle Security Analysis

Description

Recommendation

Uh oh!

cursor Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

greptile-apps Bot commented Apr 28, 2026

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps Bot Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 28, 2026

Choose a reason for hiding this comment

Uh oh!

steipete commented Apr 28, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

steipete commented Apr 28, 2026

Uh oh!

steipete commented Apr 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

aisle-research-bot Bot commented Apr 28, 2026 •

edited

Loading

cursor Bot commented Apr 28, 2026 •

edited

Loading