Allow Android WebRTC selection regardless of CLI default transport - #99
krystofwoldrich-agent wants to merge 1 commit into
Conversation
krystofwoldrich-agent
left a comment
There was a problem hiding this comment.
🤖 This is an automated review. Addressing it doesn't guarantee a merge.
Verdict: APPROVE
Findings: 0 critical · 0 design · 0 suggestion · 0 nit
Reviewed all five changed files against the PR base, the Android hook and dashboard consumers, and serve-emu's standalone and middleware capability/signaling paths. The change correctly enables viewer-local WebRTC from the advertised H.264 profile regardless of the CLI default, preserves older hosts that expose only launch settings, and respects explicitly unavailable or invalid WebRTC profiles. No actionable issues found.
Validation: independently ran the three changed test files (65 tests passed) and checked the diff for whitespace errors. Live device/browser playback was not exercised. Submitted as COMMENT to allow self-review; the substantive verdict is APPROVE.
Co-authored-by: Krystof Woldrich <31292499+krystofwoldrich@users.noreply.github.com> Co-authored-by: Codex <noreply@openai.com>
d5daa55 to
8ef8d6e
Compare
Android viewers can now select WebRTC when the CLI starts with its default WebSocket transport. The client reads the server’s existing
viewerTransportscapabilities and WebRTC ICE profile, while retaining support for older hosts that expose only launch settings. The unavailable-state message no longer tells users to restart the CLI.Validation: 193 hub-client tests and 51 dashboard tests pass, including switching from WebSocket to WebRTC and rejecting unavailable or malformed capability profiles. Both shared packages build, typecheck, and lint successfully. Live device/browser playback has not been exercised for this change.