Android Einrichtung

Die Android App versteht man am besten als Außengerät, nicht als Gateway in der Hosentasche. Dein eigentliches Gateway bleibt auf einem stabilen Host. Android hängt sich als Node daran und bringt die Dinge mit, die dein Server nicht hat: Bewegung, Kamera, Bildschirm, Benachrichtigungen, Stimme und Standort.

Genau diese Unterscheidung spart viel Leerlauf. Wenn du erwartest, dass Android die komplette Laufzeit übernimmt, wirkt das Setup schief. Wenn du es als mobile Erweiterung eines echten Gateways behandelst, ergibt das Design schnell Sinn.

Was Android zu OpenClaw ergänzt

Denk an das Gateway als Leitstelle und an das Android-Telefon als Rover. Der Host übernimmt die Orchestrierung. Das Telefon geht hinaus und erledigt die menschennahen Dinge.

• Dauerhafte Node-Verbindung über einen Foreground Service
• Canvas-Anzeige und Snapshots
• Kamera-Fotos und Clips
• Benachrichtigungs-Weiterleitung und Gerätestatus
• Voice-Erfassung, Talk Mode und gesprochene Antworten
• Standortbasierte Automationen auf einem gekoppelten Mobilgerät

Das ist eine starke Mischung. Sie kommt aber mit mobilen Regeln. Android ist an manchen Stellen flexibler als iOS, interessiert sich aber immer noch sehr für Berechtigungen, Vordergrundzustand und saubere Netzwerkpfade.

Was du vor dem Start brauchst

• Ein funktionierendes OpenClaw Gateway auf macOS, Linux oder Windows mit WSL2
• Einen Android-Build der OpenClaw App
• Einen erreichbaren Gateway-Endpunkt
• CLI-Zugriff auf den Gateway-Rechner, damit du das Pairing freigeben kannst

Du hast realistisch drei Verbindungswege:

1. Dasselbe LAN mit mDNS- oder NSD-Discovery
2. Dasselbe Tailscale-Tailnet mit sicherem wss://-Endpunkt
3. Manuelle Eingabe von Host und Port als Fallback

Wenn möglich, starte im selben LAN. Langweilig ist hier ein Qualitätsmerkmal.

Schritt 1: Starte zuerst das Gateway

Bevor die Android App sich verbinden kann, muss das Gateway laufen und erreichbar sein.

openclaw gateway --port 18789 --verbose

Im normalen LAN ist plain ws:// in Ordnung. Für Tailscale oder öffentliche Erreichbarkeit empfiehlt die Android-Doku jedoch einen echten sicheren Endpunkt statt eines improvisierten Tailnet-Binds.

openclaw gateway --tailscale serve

Wenn du dir nur eine Regel merken willst, dann diese: privates Netzwerk darf simpel sein, Remote-Zugriff sollte sauber abgesichert sein.

Schritt 2: Lass Android das Gateway finden

Öffne die App, gehe in den Tab Connect und wähle dort entweder Setup Code oder Manual. Discovery ist der glatte Weg. Host und Port manuell einzutragen ist der Plan B, wenn dein Netzwerk gerade kreative Laune hat.

Option A: Discovery im selben LAN

Wenn Telefon und Gateway im gleichen lokalen Netz hängen, kann die App das Gateway per mDNS oder NSD finden. Für das erste Pairing ist das die am wenigsten fragile Route.

Option B: Tailscale oder Remote-Zugriff

Für mobiles Pairing über verschiedene Netzwerke hinweg solltest du einen sicheren wss://-Endpunkt nutzen. Die aktuelle Doku empfiehlt dafür ausdrücklich Tailscale Serve oder einen anderen echten TLS-Endpunkt. Genau dort trennt sich ein sauberes Setup von einer Konstruktion aus Hoffnung und Glück.

Option C: Host und Port manuell

Wenn Discovery scheitert, trägst du Host und Port direkt ein. Im privaten LAN ist ws://hostname.local:18789 okay. Remote solltest du auf wss:// wechseln.

Schritt 3: Koppel das Android-Gerät

Sobald die App das Gateway sieht, schickst du die Pairing-Anfrage von Android aus und gibst sie auf dem Host-Rechner frei.

openclaw devices list
openclaw devices approve <requestId>

Wenn die Anfrage einmal scheitert, genehmige nicht stur immer dieselbe alte ID. Aktualisiere die Liste. Mobile Retries können eine ältere Anfrage durch eine neue ersetzen.

Schritt 4: Prüfe, ob der Node wirklich existiert

Ein gekoppeltes Gerät sollte als verbundener Node mit Fähigkeiten sichtbar sein. Prüfe das von der Gateway-Seite aus und nicht nur nach Gefühl.

openclaw nodes status
openclaw gateway call node.list --params "{}"

Android sendet außerdem Presence-Alive-Events, sobald die authentifizierte Node-Session steht, auch wenn die App mit laufendem Foreground Service in den Hintergrund wechselt. Das hilft dem Gateway beim letzten Lebenszeichen, macht aber nicht automatisch jeden Befehl hintergrundtauglich.

Was heute schon gut funktioniert

Die Android App ist bereits nützlich, wenn du ihre Stärken sauber ausspielst.

• Stabile Gateway-Verbindung über einen Foreground Service mit sichtbarer Benachrichtigung
• Chat-Zugriff und Session-Historie
• Canvas-Navigation und Snapshots, solange die App im Vordergrund ist
• Kamera-Erfassung im Vordergrund und mit freigegebenen Berechtigungen
• Benachrichtigungs-Weiterleitung, Kontakte, Kalender, Fotos und Geräte-Health-Befehle, wenn Gerät und Rechte mitspielen
• Zwei Sprachmodi: kurze Mic-Erfassung und durchgehender Talk Mode

Hier wird Android spannend. Ein Telefon kann damit Live-Sensor, schnelle Bedienoberfläche und Gesprächsendpunkt für dein Agent-Team zugleich werden.

Die Grenzen, die wirklich zählen

Das ist der Teil, den viele überspringen und später mit deutlich mehr Gefühl wiederentdecken.

• Android hostet das Gateway nicht
• Die App ist noch nicht öffentlich veröffentlicht
• canvas.* und Kamera-Befehle sind foreground-only
• Direkte location.get-Anfragen funktionieren auf Android derzeit nur im Vordergrund
• Voice Wake ist in Runtime und UX weiterhin deaktiviert
• Remote-Pairing sollte über sicheres wss:// laufen, nicht über plain Tailnet-ws://

Nützliche Smoke Tests

Teste nach dem Pairing lieber je eine Sache pro Fähigkeitsfamilie, statt alles gleichzeitig anzufassen.

openclaw nodes invoke --node "Android Node" --command canvas.navigate --params '{"url":"http://<gateway-host>:18789/__openclaw__/canvas/"}'

openclaw nodes invoke --node "Android Node" --command canvas.snapshot --params '{"maxWidth":900,"format":"jpeg"}'

openclaw nodes location get --node "Android Node"

Wenn der Standort-Befehl im Hintergrund scheitert, ist das mit dem aktuellen Berechtigungsmodell erwartbar. Hol die App in den Vordergrund und probiere es erneut.

Fehlerbehebung

Die App findet das Gateway nicht

Bring beide Geräte zuerst ins gleiche LAN. Wenn das funktioniert, ist Discovery okay und dein eigentliches Problem liegt im Remote-Netzwerk.

Pairing-Anfragen tauchen auf, aber die Freigabe bleibt nicht hängen

Führe openclaw devices list erneut aus und genehmige die neueste Request-ID. Veraltete Auth-Daten führen leicht dazu, dass du den falschen Versuch freigibst.

Canvas- oder Kamera-Befehle schlagen fehl

Prüfe, ob die App im Vordergrund ist und die Berechtigung wirklich erteilt wurde. Die aktuelle Android-Befehlsfläche ist breit, aber nicht jeder Befehl ist hintergrundfreundlich.

Standort-Befehle laufen in Timeouts oder Hintergrundfehler

Öffne die App, bestätige die Standortfreigabe und halte die Erwartungen realistisch. Android unterstützt direkte Standortabfragen derzeit nur, solange die App aktiv genutzt wird.

Remote-Zugriff läuft am Desktop, aber nicht auf Android

Sieh dir zuerst das Endpunktschema an. Wenn du noch plain ws:// auf einem Tailnet oder öffentlichen Pfad nutzt, ist das sehr wahrscheinlich die Ursache.

Best Practices

• Kopple zuerst im selben LAN, bevor du Remote-Zugriff versuchst
• Lass das Gateway auf einem stabilen Rechner laufen und nutze Android als mobilen Node
• Bevorzuge sicheres wss:// für Remote-Setups
• Prüfe den Status per CLI, nicht nur über die Handy-Oberfläche
• Starte mit einem sauberen Workflow, bevor du fünf halbfertige gleichzeitig baust

Zusammenfassung

Die OpenClaw Android App ergibt heute schon Sinn, wenn du aufhörst, sie als Gateway zu betrachten, und sie stattdessen als mobile Kante deines Systems nutzt. Koppel sie an einen soliden Host, respektiere die Vordergrundgrenzen und nutze sichere Netzwerke, sobald du das LAN verlässt.

Dann wirkt Android weniger wie eine fragile Preview und mehr wie ein praktischer Außennode. Genau das ist heute der richtige Rahmen.