Platforms overview
Application Android
Aperçu de la prise en charge
- Rôle : application de nœud compagnon (Android n’héberge pas le Gateway).
- Gateway requis : oui (exécutez-le sur macOS, Linux ou Windows via WSL2).
- Installation : Google Play pour l’application, Bien démarrer pour le Gateway, puis Appairage.
- Gateway : Runbook + Configuration.
- Protocoles : protocole Gateway (nœuds + plan de contrôle).
Contrôle système
Le contrôle système (launchd/systemd) réside sur l’hôte du Gateway. Consultez Gateway.
Runbook de connexion
Application de nœud Android ⇄ (mDNS/NSD + WebSocket) ⇄ Gateway
Android se connecte directement au WebSocket du Gateway et utilise l’appairage de l’appareil (role: node).
Pour Tailscale ou les hôtes publics, Android nécessite un point de terminaison sécurisé :
- Recommandé : Tailscale Serve / Funnel avec
https://<magicdns>/wss://<magicdns> - Également pris en charge : toute autre URL de Gateway en
wss://avec un vrai point de terminaison TLS - Le
ws://en clair reste pris en charge sur les adresses LAN privées / hôtes.local, ainsi quelocalhost,127.0.0.1et le pont de l’émulateur Android (10.0.2.2)
Prérequis
- Vous pouvez exécuter le Gateway sur la machine « maître ».
- L’appareil/émulateur Android peut atteindre le WebSocket du Gateway :
- Même LAN avec mDNS/NSD, ou
- Même tailnet Tailscale avec Bonjour étendu / DNS-SD unicast (voir ci-dessous), ou
- Hôte/port du Gateway manuel (solution de repli)
- L’appairage mobile tailnet/public n’utilise pas de points de terminaison IP tailnet bruts en
ws://. Utilisez plutôt Tailscale Serve ou une autre URLwss://. - Vous pouvez exécuter la CLI (
openclaw) sur la machine du Gateway (ou via SSH).
1) Démarrer le Gateway
openclaw gateway --port 18789 --verboseConfirmez que les journaux affichent quelque chose comme :
listening on ws://0.0.0.0:18789
Pour l’accès Android distant via Tailscale, préférez Serve/Funnel plutôt qu’une liaison tailnet brute :
openclaw gateway --tailscale serveCela fournit à Android un point de terminaison sécurisé wss:// / https://. Une configuration simple gateway.bind: "tailnet" ne suffit pas pour un premier appairage Android distant, sauf si vous terminez aussi TLS séparément.
2) Vérifier la découverte (facultatif)
Depuis la machine du Gateway :
dns-sd -B _openclaw-gw._tcp local.Notes de débogage supplémentaires : Bonjour.
Si vous avez aussi configuré un domaine de découverte étendue, comparez avec :
openclaw gateway discover --jsonCela affiche local. ainsi que le domaine étendu configuré en une seule passe et utilise le point de terminaison
du service résolu au lieu des seuls indices TXT.
Découverte tailnet (Vienne ⇄ Londres) via DNS-SD unicast
La découverte NSD/mDNS Android ne traverse pas les réseaux. Si votre nœud Android et le Gateway sont sur des réseaux différents mais connectés via Tailscale, utilisez plutôt Bonjour étendu / DNS-SD unicast.
La découverte seule ne suffit pas pour l’appairage Android tailnet/public. La route découverte nécessite toujours un point de terminaison sécurisé (wss:// ou Tailscale Serve) :
- Configurez une zone DNS-SD (exemple
openclaw.internal.) sur l’hôte du Gateway et publiez des enregistrements_openclaw-gw._tcp. - Configurez le DNS fractionné Tailscale pour le domaine choisi, pointant vers ce serveur DNS.
Détails et exemple de configuration CoreDNS : Bonjour.
3) Se connecter depuis Android
Dans l’application Android :
- L’application maintient sa connexion au Gateway active via un service de premier plan (notification persistante).
- Ouvrez l’onglet Connexion.
- Utilisez le mode Code de configuration ou Manuel.
- Si la découverte est bloquée, utilisez l’hôte/port manuel dans les contrôles avancés. Pour les hôtes LAN privés,
ws://fonctionne toujours. Pour les hôtes Tailscale/publics, activez TLS et utilisez un point de terminaisonwss:/// Tailscale Serve.
Après le premier appairage réussi, Android se reconnecte automatiquement au lancement :
- Point de terminaison manuel (s’il est activé), sinon
- Le dernier Gateway découvert (au mieux).
Signaux de présence active
Une fois la session de nœud authentifiée connectée, et lorsque l’application passe en arrière-plan pendant que le
service de premier plan est toujours connecté, Android appelle node.event avec
event: "node.presence.alive". Le Gateway l’enregistre comme lastSeenAtMs/lastSeenReason dans les
métadonnées du nœud/appareil appairé seulement après que l’identité de l’appareil nœud authentifié est connue.
L’application considère que le signal a été correctement enregistré uniquement lorsque la réponse du Gateway inclut
handled: true. Les anciens Gateways peuvent accuser réception de node.event avec { "ok": true } ; cette réponse est
compatible, mais ne compte pas comme une mise à jour durable de la dernière présence.
4) Approuver l’appairage (CLI)
Sur la machine du Gateway :
openclaw devices listopenclaw devices approve <requestId>openclaw devices reject <requestId>Détails de l’appairage : Appairage.
Facultatif : si le nœud Android se connecte toujours depuis un sous-réseau strictement contrôlé, vous pouvez activer l’approbation automatique au premier appairage de nœud avec des CIDR explicites ou des IP exactes :
{ gateway: { nodes: { pairing: { autoApproveCidrs: ["192.168.1.0/24"], }, }, },}C’est désactivé par défaut. Cela s’applique uniquement à un nouvel appairage role: node
sans portées demandées. L’appairage opérateur/navigateur et tout changement de rôle, portée, métadonnées ou
clé publique nécessitent toujours une approbation manuelle.
5) Vérifier que le nœud est connecté
-
Via l’état des nœuds :
bash openclaw nodes status -
Via Gateway :
bash openclaw gateway call node.list --params "{}"
6) Chat + historique
L’onglet Chat Android prend en charge la sélection de session (main par défaut, plus les autres sessions existantes) :
- Historique :
chat.history(normalisé pour l’affichage ; les balises de directive en ligne sont supprimées du texte visible, les charges utiles XML d’appels d’outils en texte brut (y compris<tool_call>...</tool_call>,<function_call>...</function_call>,<tool_calls>...</tool_calls>,<function_calls>...</function_calls>et les blocs d’appels d’outils tronqués) ainsi que les jetons de contrôle de modèle ASCII/pleine chasse divulgués sont supprimés, les lignes d’assistant constituées uniquement de jetons silencieux commeNO_REPLY/no_replyexacts sont omises, et les lignes trop volumineuses peuvent être remplacées par des espaces réservés) - Envoi :
chat.send - Mises à jour push (au mieux) :
chat.subscribe→event:"chat"
7) Canvas + caméra
Hôte Gateway Canvas (recommandé pour le contenu web)
Si vous voulez que le nœud affiche du vrai HTML/CSS/JS que l’agent peut modifier sur disque, pointez le nœud vers l’hôte Canvas du Gateway.
-
Créez
~/.openclaw/workspace/canvas/index.htmlsur l’hôte du Gateway. -
Naviguez le nœud vers celui-ci (LAN) :
openclaw nodes invoke --node "<Android Node>" --command canvas.navigate --params '{"url":"http://<gateway-hostname>.local:18789/__openclaw__/canvas/"}'Tailnet (facultatif) : si les deux appareils sont sur Tailscale, utilisez un nom MagicDNS ou une IP tailnet au lieu de .local, par exemple http://<gateway-magicdns>:18789/__openclaw__/canvas/.
Ce serveur injecte un client de rechargement à chaud dans le HTML et recharge lors des changements de fichiers.
Le Gateway sert aussi /__openclaw__/a2ui/, mais l’application Android traite les pages A2UI distantes comme uniquement rendues. Les commandes A2UI capables d’actions utilisent la page A2UI intégrée appartenant à l’application avant d’appliquer les messages.
Commandes Canvas (premier plan uniquement) :
canvas.eval,canvas.snapshot,canvas.navigate(utilisez{"url":""}ou{"url":"/"}pour revenir à l’échafaudage par défaut).canvas.snapshotrenvoie{ format, base64 }(format="jpeg"par défaut).- A2UI :
canvas.a2ui.push,canvas.a2ui.reset(alias héritécanvas.a2ui.pushJSONL). Ces commandes utilisent la page A2UI intégrée appartenant à l’application pour le rendu capable d’actions.
Commandes caméra (premier plan uniquement ; soumises aux autorisations) :
camera.snap(jpg)camera.clip(mp4)
Consultez Nœud caméra pour les paramètres et les assistants CLI.
8) Voix + surface de commandes Android étendue
- Onglet Voix : Android propose deux modes de capture explicites. Micro est une session manuelle de l’onglet Voix qui envoie chaque pause comme un tour de chat et s’arrête lorsque l’application quitte le premier plan ou que l’utilisateur quitte l’onglet Voix. Conversation est le mode Conversation continu et continue d’écouter jusqu’à ce qu’il soit désactivé ou que le nœud se déconnecte.
- Le mode Conversation promeut le service de premier plan existant de
connectedDeviceàconnectedDevice|microphoneavant le début de la capture, puis le rétrograde lorsque le mode Conversation s’arrête. Le service de nœud déclareFOREGROUND_SERVICE_CONNECTED_DEVICEavecCHANGE_NETWORK_STATE; Android 14+ nécessite aussi la déclarationFOREGROUND_SERVICE_MICROPHONE, l’autorisation d’exécutionRECORD_AUDIOet le type de service microphone à l’exécution. - Par défaut, Conversation Android utilise la reconnaissance vocale native, le chat Gateway et
talk.speakvia le fournisseur Conversation configuré du Gateway. La synthèse vocale système locale n’est utilisée que lorsquetalk.speakn’est pas disponible. - Conversation Android utilise le relais Gateway en temps réel uniquement lorsque
talk.realtime.modeestrealtimeet quetalk.realtime.transportestgateway-relay. - Le réveil vocal reste désactivé dans l’UX/le runtime Android.
- Familles de commandes Android supplémentaires (la disponibilité dépend de l’appareil, des autorisations et des paramètres utilisateur) :
device.status,device.info,device.permissions,device.healthdevice.appsuniquement lorsque Paramètres > Fonctionnalités du téléphone > Applications installées est activé ; liste par défaut les applications visibles dans le lanceur.notifications.list,notifications.actions(voir Transfert de notifications ci-dessous)photos.latestcontacts.search,contacts.addcalendar.events,calendar.addcallLog.searchsms.searchmotion.activity,motion.pedometer
Points d’entrée de l’assistant
Android prend en charge le lancement d’OpenClaw depuis le déclencheur d’assistant système (Google Assistant). Une fois configuré, maintenir le bouton d’accueil ou dire « Hey Google, demande à OpenClaw... » ouvre l’application et transmet la requête dans le compositeur de chat.
Cela utilise les métadonnées Android App Actions déclarées dans le manifeste de l’application. Aucune configuration supplémentaire n’est nécessaire côté Gateway : l’intention de l’assistant est entièrement gérée par l’application Android et transférée comme un message de chat normal.
Transfert de notifications
Android peut transférer les notifications de l’appareil au Gateway sous forme d’événements. Plusieurs contrôles permettent de limiter quelles notifications sont transférées et quand.
| Clé | Type | Description |
|---|---|---|
notifications.allowPackages |
string[] | Transférer uniquement les notifications provenant de ces noms de packages. Si défini, tous les autres packages sont ignorés. |
notifications.denyPackages |
string[] | Ne jamais transférer les notifications provenant de ces noms de packages. Appliqué après allowPackages. |
notifications.quietHours.start |
string (HH:mm) | Début de la plage d’heures silencieuses (heure locale de l’appareil). Les notifications sont supprimées pendant cette plage. |
notifications.quietHours.end |
string (HH:mm) | Fin de la plage d’heures silencieuses. |
notifications.rateLimit |
number | Nombre maximal de notifications transférées par package et par minute. Les notifications en excès sont abandonnées. |
Le sélecteur de notifications utilise également un comportement plus sûr pour les événements de notification transférés, afin d’éviter le transfert accidentel de notifications système sensibles.
Exemple de configuration :
{ notifications: { allowPackages: ["com.slack", "com.whatsapp"], denyPackages: ["com.android.systemui"], quietHours: { start: "22:00", end: "07:00", }, rateLimit: 5, },}