Android ohne Display betreiben — Fallstricke und Lösungen
Headless Android — das klingt nach dem heiligen Gral für Phone-Farm-Betreiber: Keine Displays, die Strom fressen, weniger Hitze, weniger Platz. Aber die Realität ist ein Minenfeld. Ich hab dutzende Stunden mit diesem Thema verbracht, also spar dir den Schmerz und lies weiter.
Warum Android ein Display braucht
Android wurde für Geräte mit Display entwickelt. Punkt. Wenn kein physisches Display erkannt wird, passieren seltsame Dinge:
- SurfaceFlinger (der Display-Compositor) startet nicht richtig
- Manche Apps crashen beim Start, weil sie
getDefaultDisplay()aufrufen und null kriegen - WebViews rendern nicht — die GPU-Pipeline wird nicht initialisiert
- Screenshots via ADB sind schwarz oder leer
- Der Bootloader mancher Hersteller verweigert den Boot ohne angeschlossenes Display
Kurz: Android „ohne Display" gibt's nicht. Du brauchst mindestens einen Dummy.
Lösung 1: HDMI-Dummy-Plug
Die einfachste Lösung für Geräte mit HDMI- oder DP-Ausgang (z.B. Samsung Galaxy S8-S20 via USB-C DP Alt Mode). Ein kleiner HDMI-Dummy-Stecker, der dem Gerät vorgaukelt, ein Display wäre angeschlossen. Kosten: 3-8€ pro Stück bei AliExpress.
Vorteile:
- Plug-and-Play, keine Software-Änderung nötig
- Funktioniert mit Stock-ROMs und Custom-ROMs
- GPU-Pipeline wird vollständig initialisiert
Nachteile:
- Nicht jedes Phone hat DP Alt Mode (Budget-Geräte meistens nicht)
- Kostet pro Gerät extra
- Blockiert den USB-C-Port — du kannst nicht gleichzeitig laden UND Dummy-Plug nutzen. Brauchst USB-C-Hub mit Power Delivery
Lösung 2: Software Display Emulation
Wenn dein Gerät keinen DP-Alt-Mode hat (wie die meisten Budget-Phones), brauchst du eine Software-Lösung. Die funktionieren so: Ein virtuelles Display wird im Android-Framework erzeugt, und Apps denken, es gäbe ein physisches Display.
Option A: Android Emulator-Display nutzen
# Erzeugt ein virtuelles Display via ADB (braucht root):
adb shell settings put global overlay_display_devices 1920x1080/160
Funktioniert auf manchen Custom ROMs, auf Stock-ROMs meistens nicht. Trial and Error.
Option B: scrcpy als Display-Brücke
scrcpy (Screen Copy) ist eigentlich ein Tool zum Screen-Mirroring, aber es erzeugt einen virtuellen Display-Kontext. Wenn scrcpy läuft, denken Apps, ein Display wäre da. Für den Dauerbetrieb:
# scrcpy mit minimaler Auflösung, ohne Fenster (headless):
scrcpy --no-window --max-size 360 --stay-awake
# Alternativ mit niedriger Bitrate für minimale CPU-Last:
scrcpy --no-window --bit-rate 1M --max-fps 5
Der Overhead ist gering (~2-3% CPU auf dem Host), aber du brauchst für jedes Gerät einen scrcpy-Prozess — bei 75 Geräten sind das 75 Prozesse auf dem Host. Das kann knapp werden. Ich hab's mit 30 getestet, der Host-Rechner kam an seine Grenzen.
Lösung 3: build.prop / System-Anpassungen
Auf gerooteten Geräten kannst du System-Eigenschaften anpassen. Das ist meine bevorzugte Lösung für Geräte ohne HDMI:
# In /system/build.prop (oder per Magisk-ResetProp):
ro.sf.lcd_density=160
hw.hdmi_on=1
persist.demo.hdmirotation=portrait
# Wichtigste Zeile — zwingt Android, einen Display-Mode zu verwenden:
debug.sf.nobootanimation=1
persist.sys.boot.check.done=1
Was ich heute mache
Nach zwei Jahren hat sich folgendes Setup bewährt:
- Samsung S10/S9 (mit DP Alt Mode): HDMI-Dummy-Plug + USB-C-Hub mit PD. Perfekt.
- A-Series und Budget-Phones: Physisches Display bleibt dran, aber auf minimalste Helligkeit + Dark Mode + Screensaver (schwarz). Stromverbrauch des Displays: ~0.5W bei minimaler Helligkeit auf AMOLED — verkraftbar.
- scrcpy: Nur für temporären Zugriff, nicht als Dauerlösung.
Der heilige Gral wäre ein Kernel-Patch, der einen virtuellen Display-Treiber einbaut. Aber das ist pro Gerät/ROM individuell und lohnt den Aufwand für mich nicht. Vielleicht in 2027.
Fazit
Headless Android ist ein schöner Traum mit hässlicher Realität. HDMI-Dummy-Plugs sind die beste Allround-Lösung, wenn dein Gerät es unterstützt. Ansonsten: Display auf Minimum, Software-Tricks mit Bedacht einsetzen. Und niemals, wirklich niemals, build.prop ohne Backup anfassen.