ADB-TCP vs USB — Wann welcher Zugriffsweg?

2. Juni 2026 · Autor: Romic · ~1.100 Wörter · Kategorie: ADB

Die Frage kommt ständig: „Soll ich ADB über TCP oder USB machen?" Kurze Antwort: Beides. Lange Antwort: Kommt drauf an, was du vorhast. Ich hab beides monatelang im Produktivbetrieb und kann dir sagen, wann welcher Weg der richtige ist — mit konkreten Zahlen.

Die Grundlagen: ADB über USB

ADB über USB ist der Standardweg. Du schließt das Phone per Kabel an, adb devices zeigt's an, fertig. Es läuft über USB 2.0 mit einer theoretischen Bandbreite von 480 Mbit/s — in der Praxis kommt davon vielleicht ein Zehntel bei ADB an, weil's ein Debug-Protokoll ist, kein Datentransfer-Protokoll.

Vorteile USB

Stabil: Solange Kabel und Port okay sind, reißt die Verbindung nicht ab
Schnell bei Bulk-Transfers: APK-Installation von 100MB — USB schlägt TCP um Faktor 3-4
Boot-Phase erreichbar: Im Recovery und Fastboot geht nix über TCP
Keine Authentifizierungs-Probleme: RSA-Key-Pairing ist einmalig und sitzt

Nachteile USB

Kabelsalat: Bei 75 Geräten kannst du dir vorstellen, wie das aussieht
Stromverbrauch über Host-Port: Manche Hubs liefern nicht genug Saft
Fehleranfällig bei schlechten Kabeln: Und rate mal, welche Kabel am häufigsten kaputtgehen
Nur ein Gerät pro Port: Adressierung ist physisch, kein Multiplexing

ADB über TCP/IP

ADB over TCP läuft über Port 5555. Aktivieren tust du es entweder in den Developer Options („ADB over Network") oder per Kommando:

# Am Gerät (über USB):
adb tcpip 5555

# Dann Verbindung vom Host:
adb connect 192.168.1.101:5555

# Prüfen:
adb devices
# Ausgabe: 192.168.1.101:5555    device

Klingt einfach. Ist es auch — bis das Netzwerk zickt.

Vorteile TCP

Keine Kabel: Ein Traum für große Setups. Alles über WiFi.
Bessere Skalierbarkeit: Du kannst von einem Host Dutzende Geräte parallel ansteuern, ohne USB-Hubs
Einfacheres physisches Layout: Geräte können überall im Rack liegen, solange WiFi-Empfang da ist
Hot-Swap-freundlicher: Gerät neustarten, TCP-Verbindung kommt von selbst wieder — kein USB-Reconnect nötig

Nachteile TCP

Langsamer: Siehe Benchmarks unten
Netzwerkabhängig: WiFi-Aussetzer = ADB-Aussetzer
Auth-Probleme nach Reboot: Manche ROMs verlieren die ADB-over-TCP-Einstellung
Sicherheitsbedenken: Port 5555 offen im Netz — im VLAN okay, im offenen Netz ein No-Go

Benchmarks: USB vs TCP — kalte Zahlen

Ich hab einen simplen Benchmark gemacht: Installation einer 87MB APK, Datei-Push einer 50MB-Datei, und 1000 adb shell-Aufrufe hintereinander. Gerät: Samsung Galaxy S10, WiFi 5GHz, Link-Speed ~433 Mbps. Host: Linux-Rechner mit USB 3.0 (auch wenn ADB nur USB 2.0 nutzt).

Operation	USB	TCP (5GHz)	TCP (2.4GHz)
APK install (87 MB)	4.2s	11.8s	24.1s
File push (50 MB)	2.1s	4.9s	9.7s
1000x adb shell (echo)	8.7s	38.2s	62.5s
ADB connect time	0.3s	1.2s	2.8s
Connection drops (24h)	0	2	8

Die Zahlen sprechen für sich: USB ist bei Bulk-Transfers 3x schneller, bei vielen Einzelkommandos fast 5x schneller. TCP hat dafür im 24-Stunden-Langzeittest nur 2 Drops auf 5GHz — akzeptabel.

Achtung bei 2.4GHz: 8 Verbindungsabbrüche in 24 Stunden sind für Produktivbetrieb zu viel. Wenn du TCP nutzt, geh auf 5GHz. Und wenn deine Geräte nur 2.4GHz können (ältere Budget-Phones), dann bleib bei USB oder upgrade die Hardware.

Mein Hybrid-Ansatz in der Praxis

Nach zwei Jahren Erfahrung hat sich bei mir ein klares Muster etabliert:

Erst-Setup und Recovery: Immer USB. Keine Diskussion.
Tägliche Automatisierung: TCP. Mein Python-Framework verbindet sich beim Start zu allen Geräten via TCP und pollt regelmäßig.
Bulk-Operationen (50+ APKs installieren): USB, aber parallelisiert. Ich hab dafür ein Batch-Setup mit 4 USB-Hubs parallel.
Monitoring: TCP. Einfacher Ping auf Port 5555 reicht für Basic Health Check.
Notfall-Zugriff: Immer USB-Backup. Ich hab für jede Geräte-Gruppe einen USB-Port am Host reserviert.

Konkrete ADB-TCP-Befehle für den Alltag

Persistente TCP-Verbindung nach Reboot:

# Einmalig setzen (braucht root):
adb shell setprop service.adb.tcp.port 5555
adb shell setprop persist.adb.tcp.port 5555

# Prüfen:
adb shell getprop persist.adb.tcp.port

Mehrere Geräte parallel ansprechen (Shell-Skript):

#!/bin/bash
# Alle Geräte neustarten
DEVICES=("192.168.10.101" "192.168.10.102" "192.168.10.103")
for ip in "${DEVICES[@]}"; do
  adb connect $ip:5555
  adb -s $ip:5555 reboot &
done
wait

ADB-TCP-Ausfall automatisch reconnecten (Python-Snippet):

import subprocess, time

def ensure_connected(ip, port=5555):
    addr = f"{ip}:{port}"
    result = subprocess.run(
        ["adb", "devices"], capture_output=True, text=True
    )
    if addr not in result.stdout:
        subprocess.run(["adb", "connect", addr], capture_output=True)
        time.sleep(1)
    return addr

Fazit

USB ist der ungeschlagene König für Stabilität und Geschwindigkeit. TCP gewinnt bei Skalierbarkeit und Komfort. In einer gut designten Phone Farm nutzt du beide: TCP für den täglichen Betrieb, USB für Setup, Recovery und Bulk-Operationen.

Wenn du beides clever kombinierst, hast du das Beste aus beiden Welten. Und nein, du musst dich nicht entscheiden — das ist kein Glaubenskrieg, das sind Werkzeuge.