ADB, the Android Debug Bridge, is the standard tool for interacting with Android devices over USB. It provides an interactive shell, file transfer, port forwarding, and more all through a mobile phone USB cable. It’s mature, its protocol is simple and well documented, and the adb client ships in most Linux distributions and every Android SDK.

There’s a catch though: ADB is heavily tied to Android. So, embedded Linux boards such as Raspberry Pis or custom SBCs don’t have any real counterpart. Getting a shell typically means setting up SSH over a network, wiring up a serial console, or other ad-hoc solutions, none of which come close to the convenience of adb shell.

Some board vendors have addressed this by porting the ADB daemon from the Android tree. It works, but with significant friction: the Android codebase uses its own build system, relies on Android-specific properties and init infrastructure, and generally assumes it’s running on Android. Dealing with that friction and keeping it building against a regular Linux user space is a maintenance burden. On top of that, the Android ADB daemon has no standalone release process: it’s part of the platform tree, versioned and shipped as part of the full Android OS source release. Building a product around it means pinning to an arbitrary tree snapshot with no stability guarantees, or support.

Adibi takes a different approach: a from-scratch Rust implementation of the ADB device side, built for regular Linux from the start. It uses the USB gadget subsystem (ConfigFS + FunctionFS) to make any device with a USB Device Controller look like an Android device to a stock adb client. It doesn’t require any kernel patch, custom host tools, or build scripts; just plug a USB cable and go.

The end result is a codebase of a couple thousand lines of Rust with a small dependency footprint. The entire event loop runs on io_uring, is fully asynchronous, and the daemon is socket-activated via systemd: it only runs when a host actually connects. This all makes the footprint pretty minimal, and with no extra cost if a client isn’t actively using adb.

What It Supports

The core ADB operations work today:

• adb shell, with both interactive and one-shot commands
• adb pull and adb push with chunked transfer, permissions, and timestamps
• adb forward over TCP, abstract UNIX sockets, and filesystem UNIX sockets
• adb reboot

It discovers device identity automatically from the device-tree, the DMI tables, /proc/cpuinfo, /etc/hostname, /etc/machine-id, and /etc/os-release, so the board identifies itself with a meaningful name and serial number.

Try It

cargo build --release
sudo install -m 755 target/release/adibi /usr/bin/adibi
# install systemd units and FunctionFS blobs (see README)
sudo systemctl enable adibi-gadget.service adibi.socket

Then from the host:

$ adb devices
List of devices attached
a1b2c3d4e5f6	device

$ adb shell
$

Adibi is early but functional. Reverse forwarding, the TCP backend, logcat-style log streaming, and distribution packaging are on the roadmap.