Problem
Today pi-droid must run on an external host with the adb binary and reach the device over USB or WiFi. That excludes a useful topology: pi-droid running inside the phone itself, as a long-lived worker under Termux. Benefits:
- No host machine required — phone is self-sufficient
- No ADB authorization dialog / USB cable / WiFi reachability
- Phone can participate in the pi-agent mesh as a full node
- Fits the README's "inbound triggers from Telegram/Discord" pattern cleanly
Proposal
Implement OnDeviceTransport per the transport abstraction:
shell(cmd) → direct child_process (no adb shell prefix)
adb(args) → throws UnsupportedByTransport
forward(local, remote) → Termux-API or socat
screenshot() → termux-screenshot (or screencap -p if rooted; fallback if neither)
capabilities.hostFs = "android", capabilities.adb = false, capabilities.screenMirror = "native"
Workspace on Termux
Same workspace resolution as other topologies — PI_DROID_HOME defaults to $HOME/.pi-droid inside Termux. An install script sets this env var and installs deps (pkg install nodejs python openssh).
Which tools degrade gracefully?
- ADB-required tools (
tcpip, install, pm list packages via adb, port forward from another host): return UnsupportedByTransport.
- Shell-based tools (tap via
input tap, key events, screencap, settings queries): work unchanged.
- Plugin flows (Ollama, Gmail): work because they use shell+CDP, not raw adb — once #10 migrates
ollama-setup.ts:167 off direct execAsync.
Deliverables
src/transport/OnDeviceTransport.ts
scripts/install-termux.sh — one-line installer for Termux
- Docs: Termux setup guide under
docs/ON_DEVICE.md
- Capability matrix: which of the ~36 tools work in on-device mode
Design doc
See docs/CONNECTIVITY.md § Topology C.
Depends on
Problem
Today pi-droid must run on an external host with the
adbbinary and reach the device over USB or WiFi. That excludes a useful topology: pi-droid running inside the phone itself, as a long-lived worker under Termux. Benefits:Proposal
Implement
OnDeviceTransportper the transport abstraction:shell(cmd)→ directchild_process(noadb shellprefix)adb(args)→ throwsUnsupportedByTransportforward(local, remote)→ Termux-API orsocatscreenshot()→termux-screenshot(orscreencap -pif rooted; fallback if neither)capabilities.hostFs = "android",capabilities.adb = false,capabilities.screenMirror = "native"Workspace on Termux
Same workspace resolution as other topologies —
PI_DROID_HOMEdefaults to$HOME/.pi-droidinside Termux. An install script sets this env var and installs deps (pkg install nodejs python openssh).Which tools degrade gracefully?
tcpip,install,pm list packagesviaadb, port forward from another host): returnUnsupportedByTransport.input tap, key events, screencap, settings queries): work unchanged.ollama-setup.ts:167off directexecAsync.Deliverables
src/transport/OnDeviceTransport.tsscripts/install-termux.sh— one-line installer for Termuxdocs/ON_DEVICE.mdDesign doc
See
docs/CONNECTIVITY.md§ Topology C.Depends on