Table of Contents
Getting in (root / ADB)
- The head unit joins the home Wi-Fi and is reachable over the network. adbd runs as root.
- There is no usable USB-ADB port — the exposed USB port is a host port (5 V out, reads
FAT32 sticks). The SoC's device/gadget port is not exposed. So all access is over TCP/ADB.
- The on-device terminal app runs as uid 1000 (system), and there is no working
su.
So network ADB is the only path to root — re-enabling it is the key to everything.
Re-enabling network ADB after a reboot
adbd is a disabled init service, started only by a USB-config trigger, and it reads its TCP port
only at startup. From the uid-1000 terminal you set the ADB TCP port and then cycle the USB
config (sys.usb.config none → adb), which restarts adbd and makes it bind the TCP port. This
is not persistent across reboots — it must be redone after each boot (or automated by a
system-signed app).
Updating apps in place (keeping their data)
The ROM is signed with the standard Android test-keys, which equal the local debug keystore.
So debug builds can legitimately claim sharedUserId=“android.uid.system” and update installed
apps in place without losing their settings — the signatures match. This is what lets a
self-built app run with system privileges (needed for the cluster overlay and CAN access).
