User Tools

Site Tools


access

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).

access.txt · Last modified: by 127.0.0.1