USB display link is NCM; app must bind to the Ethernet network

Tested with the tablet: it picks NCM, not RNDIS, from the Orin's L4T
gadget. Android won't route app traffic over a network without internet
while WiFi or cellular is up, so app-flutter has to request and bind
the Ethernet network. The Orin's USB-C port has no PD, so the tablet is
charged through a PD hub in the car.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
mikkeli
2026-10-09 00:12:45 +09:00
parent 6fc187570c
commit ac4626640c
+7 -1
View File
@@ -190,9 +190,15 @@ subscribes to the bus and renders itself.
| Path | Transport | Notes | | Path | Transport | Notes |
|---|---|---| |---|---|---|
| `app-flutter` | USB (RNDIS), or WiFi | The display. Full client, richest UI, also the audio sink | | `app-flutter` | USB (NCM: tablet is host, Orin at `192.168.55.1`), or WiFi | The display. Full client, richest UI, also the audio sink |
| `app-esp32` + RLCD/e-ink | WiFi, or USB/BT serial | Low-rate glanceable subset. Not in current scope | | `app-esp32` + RLCD/e-ink | WiFi, or USB/BT serial | Low-rate glanceable subset. Not in current scope |
Over USB, Android sends app traffic only via its *default* network, and the
USB link, having no internet, never becomes default while WiFi or cellular is
up. `app-flutter` must request the Ethernet network (`TRANSPORT_ETHERNET`) and
bind to it. The Orin's USB-C port can't charge the tablet (no USB PD), so in the
car the link runs through a PD hub that feeds the tablet from the car charger.
Displays reaching the bus over IP connect to the broker through `svc-gw`, which Displays reaching the bus over IP connect to the broker through `svc-gw`, which
owns the boundary. For transports without IP — BT SPP, plain USB serial — owns the boundary. For transports without IP — BT SPP, plain USB serial —
`svc-gw` bridges serial ↔ bus rather than each device inventing its own protocol. `svc-gw` bridges serial ↔ bus rather than each device inventing its own protocol.