Platforms overview

Application Android

Aperçu de la prise en charge

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 que localhost, 127.0.0.1 et 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 URL wss://.
  • Vous pouvez exécuter la CLI (openclaw) sur la machine du Gateway (ou via SSH).

1) Démarrer le Gateway

bash
openclaw gateway --port 18789 --verbose

Confirmez 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 :

bash
openclaw gateway --tailscale serve

Cela 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 :

bash
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 :

bash
openclaw gateway discover --json

Cela 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) :

  1. Configurez une zone DNS-SD (exemple openclaw.internal.) sur l’hôte du Gateway et publiez des enregistrements _openclaw-gw._tcp.
  2. 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 terminaison wss:// / 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 :

bash
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 :

json5
{  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 comme NO_REPLY / no_reply exacts 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.subscribeevent:"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.

  1. Créez ~/.openclaw/workspace/canvas/index.html sur l’hôte du Gateway.

  2. Naviguez le nœud vers celui-ci (LAN) :

bash
openclaw nodes invoke --node "&lt;Android Node&gt;" --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.snapshot renvoie { 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|microphone avant le début de la capture, puis le rétrograde lorsque le mode Conversation s’arrête. Le service de nœud déclare FOREGROUND_SERVICE_CONNECTED_DEVICE avec CHANGE_NETWORK_STATE ; Android 14+ nécessite aussi la déclaration FOREGROUND_SERVICE_MICROPHONE, l’autorisation d’exécution RECORD_AUDIO et le type de service microphone à l’exécution.
  • Par défaut, Conversation Android utilise la reconnaissance vocale native, le chat Gateway et talk.speak via le fournisseur Conversation configuré du Gateway. La synthèse vocale système locale n’est utilisée que lorsque talk.speak n’est pas disponible.
  • Conversation Android utilise le relais Gateway en temps réel uniquement lorsque talk.realtime.mode est realtime et que talk.realtime.transport est gateway-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.health
    • device.apps uniquement 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.latest
    • contacts.search, contacts.add
    • calendar.events, calendar.add
    • callLog.search
    • sms.search
    • motion.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 :

json5
{  notifications: {    allowPackages: ["com.slack", "com.whatsapp"],    denyPackages: ["com.android.systemui"],    quietHours: {      start: "22:00",      end: "07:00",    },    rateLimit: 5,  },}

Associé

Was this useful?
On this page

On this page