Flugmodus-Tricks für Phone Farms — Was du nie tun solltest und warum

Flugmodus klingt harmlos. Ist es in einer Phone Farm absolut nicht. Ich hab einmal versehentlich auf 20 Geräten den Flugmodus aktiviert und damit gleichzeitig WiFi und ADB gekillt. Die Geräte waren danach tot — kein Zugriff mehr, kein ADB, kein SSH-in-die-Nähe. Einziger Weg zurück: physisch an jedes Gerät gehen und den Flugmodus per Touchscreen deaktivieren. Bei Geräten OHNE Display? Katastrophe.

Was passiert bei Flugmodus auf Android?

Flugmodus auf einem Standard-Android-Gerät macht drei Dinge:

  1. WiFi wird deaktiviert → ADB-over-TCP-Verbindung ist WEG
  2. Mobilfunk wird deaktiviert → Kein 4G/5G, keine SMS (für die meisten Farms irrelevant)
  3. Bluetooth wird deaktiviert (meistens, nicht immer)

Der Knackpunkt ist Punkt 1: Wenn dein einziger Zugriffsweg WiFi/ADB-TCP ist, hast du nach Flugmodus-Aktivierung null Verbindung zum Gerät.

Goldene Regel: Wenn du ein Gerät nur per WiFi/ADB-TCP erreichst (kein Display, kein USB), schalte NIEMALS den Flugmodus ein. Nicht per ADB, nicht per Automatisierung, nicht manuell. Der einzige Weg zurück ist physischer Zugriff.

Wann Flugmodus sinnvoll ist (mit USB-Backup)

Trotzdem hat Flugmodus legitime Use-Cases, wenn du einen zweiten Zugriffsweg hast:

Der sichere Weg: Nur WiFi togglen (nicht Flugmodus)

Wenn du nur WiFi neustarten willst, toggel WiFi direkt — nicht Flugmodus:

# WiFi AUS:
adb shell svc wifi disable

# WiFi AN:
adb shell svc wifi enable

# Oder via settings (persistenter):
adb shell settings put global wifi_on 0  # AUS
adb shell settings put global wifi_on 1  # AN

Das deaktiviert NUR WiFi, nicht alle anderen Schnittstellen. Wichtig: Nach svc wifi disable verlierst du kurz die ADB-Verbindung — aber das Gerät reconnectet automatisch, sobald WiFi wieder an ist (im Gegensatz zum Flugmodus, der WiFi dauerhaft blockiert).

Automatischer WiFi-Reconnect

Hier ist mein Skript, das bei WiFi-Abbrüchen automatisch reconnectet, ohne Flugmodus zu nutzen:

#!/system/bin/sh
# wifi-watchdog.sh — Läuft auf jedem Gerät per init.d oder Magisk
while true; do
    # Check WiFi-Status
    WIFI_STATUS=$(dumpsys wifi | grep "Wi-Fi is" | awk '{print $3}')
    if [ "$WIFI_STATUS" != "enabled" ]; then
        svc wifi enable
        sleep 5
    fi
    
    # Check ob Verbindung zu einem AP besteht
    CONNECTED=$(dumpsys wifi | grep "mNetworkInfo" | grep "CONNECTED")
    if [ -z "$CONNECTED" ]; then
        # WiFi disconnect → reconnect
        cmd wifi reconnect
        sleep 10
    fi
    
    sleep 30
done

Flugmodus per ADB (nur mit Safety-Net)

Falls du Flugmodus unbedingt brauchst, hier ein abgesicherter Ansatz:

# Flugmodus EIN (NUR mit USB-Backup!):
adb shell settings put global airplane_mode_on 1
adb shell am broadcast -a android.intent.action.AIRPLANE_MODE

# Flugmodus AUS:
adb shell settings put global airplane_mode_on 0
adb shell am broadcast -a android.intent.action.AIRPLANE_MODE

# Wichtig: Nach AUS 5-10 Sekunden warten bis WiFi reconnectet
Sicherheitsnetz: Bevor du Flugmodus auf einem Gerät testest, das du nur per ADB-TCP erreichst, richte einen Cronjob auf dem Gerät ein (via Termux oder Magisk init.d), der nach 60 Sekunden automatisch WiFi wieder einschaltet. So überlebst du den Test, selbst wenn die ADB-Verbindung abbricht.

Mein schlimmster Flugmodus-Unfall

Juni 2025, 2 Uhr nachts. Ich schreibe ein Automatisierungsskript, das alle 75 Geräte nacheinander in den Flugmodus schicken soll — für einen Netzwerk-Reset. Teste es auf einem Gerät, funktioniert. Merge in den Master-Branch, Cronjob deployed, schlafen.

Um 4:12 Uhr wache ich auf, weil mein Monitoring Alarm schlägt: 62 Geräte offline. Der Cronjob war gelaufen, hatte Flugmodus auf allen Geräten aktiviert — und dann war die ADB-Verbindung weg. Das Skript konnte den Flugmodus nicht wieder deaktivieren. Ich bin um 4:30 ins Büro gefahren und hab 3 Stunden lang jedes Gerät einzeln per Power-Button neugestartet.

Lektion: Flugmodus nur mit zweitem Zugriffsweg. Immer. Keine Ausnahme.