Compréhension d’écran IA Android : arbre UI, capture et action sûre
Guide pratique pour choisir entre état d’accessibilité, capture d’écran approuvée et action Android prise en charge, avec vérification fraîche et arrêt sûr.
- Pour la compréhension d’écran IA Android, utilisez d’abord l’état d’accessibilité lorsque la question porte sur des boutons, champs, libellés ou états visibles.
- Une capture d’écran sert aux faits visuels comme les images, cartes, graphiques, couleurs ou dispositions, et doit rester un accès approuvé car elle peut exposer des données privées.
- Avant toute action Android, l’agent doit relire un état frais : un nœud ou une capture ancienne ne suffit pas à prouver que la cible est encore valide.
- Voir un écran ne donne pas automatiquement le droit d’agir ; les actions conséquentes doivent passer par un chemin pris en charge, avec permissions, confirmation et résultat vérifiable.
Choisir arbre UI, capture ou les deux
La réponse courte est simple : pour la compréhension d’écran IA Android, commencez par l’état d’accessibilité lorsque la question porte sur des éléments d’interface nommés. Utilisez une capture d’écran lorsque la réponse dépend des pixels : image, carte, graphique, couleur, disposition ou zone dessinée sans libellé fiable. Combinez les deux lorsque la cible, le contexte ou le résultat doivent être recoupés avant une action.
Un arbre UI, ou état d’accessibilité, peut révéler des textes, descriptions, rôles, états sélectionnés, champs, boutons et actions disponibles. Il est souvent plus léger et plus proche d’une action sûre qu’une image brute. Mais il dépend de ce que l’application expose réellement. Une application peut fournir des libellés pauvres, plusieurs boutons identiques ou des composants personnalisés qui ne décrivent pas leur sens.
Une capture montre ce qui est visible à l’instant choisi. Elle peut répondre à une question impossible à résoudre par la structure seule, par exemple « que montre ce graphique ? » ou « quelle option visuelle semble sélectionnée ? ». Elle ne doit pas devenir un raccourci universel pour viser des coordonnées. Les pixels aident à comprendre ; ils ne remplacent ni l’état courant, ni la permission, ni la confirmation.
Dans FoneClaw, nous traitons ces entrées comme des preuves distinctes. La question n’est pas « quelle source est la plus impressionnante ? », mais « quelle preuve minimale suffit pour décider sans exposer inutilement l’écran ? ». Pour le cadre général intention, confirmation et résultat, consultez Contrôler un téléphone Android avec un agent IA : intention, confirmation et vérification.
Utiliser un état d’accessibilité frais
L’état d’accessibilité est le bon point de départ lorsque l’utilisateur veut agir sur un élément visible : ouvrir un bouton, remplir un champ, cocher une option, lire un libellé, vérifier si une case est activée ou déterminer quel onglet est sélectionné. La documentation Android sur les services d’accessibilité décrit un cadre où un service peut recevoir le contenu de fenêtre exposé et agir via les API d’accessibilité prises en charge.
La partie décisive est le mot « frais ». Un écran Android peut changer entre la lecture et l’action : chargement, clavier affiché, notification, fenêtre d’autorisation, changement d’orientation, animation ou mise à jour d’une liste. Une action fiable ne doit donc pas réutiliser un ancien nœud comme si l’interface était figée.
| Point à vérifier | Pourquoi c’est utile | Décision sûre |
|---|---|---|
| Libellé | Confirme le nom de la cible. | Agir si le libellé est unique et cohérent. |
| Rôle ou type | Distingue bouton, champ, liste ou case. | Éviter d’appuyer sur un texte non actionnable. |
| État | Indique sélection, activation ou focus. | Relire avant une modification sensible. |
| Actions disponibles | Montre ce que l’interface autorise. | Utiliser seulement une action exposée et prise en charge. |
| Contexte actuel | Évite une action sur le mauvais écran. | Relire après tout changement visible. |
La limite est concrète : toutes les applications ne fournissent pas des informations sémantiques complètes. Un bouton peut s’appeler « OK » sans expliquer l’effet, une carte peut exposer peu de détails, un canvas peut ne fournir presque aucun nœud utile. Dans ces cas, l’agent doit reconnaître l’incertitude au lieu de deviner.
L’assistant flottant FoneClaw aide dans ce contexte parce qu’il travaille depuis l’écran en cours, mais il conserve la même règle : lire l’état actuel, proposer l’action, puis vérifier le résultat. Pour approfondir ce cas d’usage, voyez Assistant IA flottant Android : comprendre et agir depuis l’écran actuel.
Utiliser une capture avec approbation explicite
Une capture d’écran est utile lorsque l’information décisive est visuelle. Elle peut montrer une image, une carte, un graphique, une couleur d’état, une icône sans libellé, une mise en page ou un document rendu comme image. Elle répond à la question « qu’est-ce qui est visible ? » mieux qu’un arbre UI incomplet.
Elle est aussi plus sensible. Une capture peut inclure des noms, messages, notifications, photos, montants, adresses, codes, documents ou informations de santé. Dans FoneClaw, la capture d’écran est donc un accès de lecture sensible qui demande une approbation explicite. Le fait qu’une information soit visible à l’écran ne signifie pas qu’elle doit être capturée automatiquement.
La bonne demande est précise : « décris le graphique visible », « lis ce texte rendu en image », « vérifie quelle option visuelle est sélectionnée », « compare les deux cartes affichées ». La mauvaise demande est trop large : « regarde tout et fais ce qu’il faut ». Plus la demande est vague, plus le risque d’exposer des informations inutiles augmente.
Une capture ne prouve pas non plus l’autorité d’action. Elle peut montrer un bouton « Payer », mais elle ne prouve pas que le compte est correct, que l’action est autorisée, que le bouton est encore actif ou que l’utilisateur a confirmé le montant. Pour un fait visuel, elle apporte une preuve. Pour une action, elle doit être suivie d’un chemin pris en charge, d’un état frais et d’une confirmation adaptée.
Lorsque l’utilisateur souhaite conserver ou réanalyser un contexte visuel, le guide Contexte d’image IA sur Android : conserver, réanalyser et vérifier explique comment traiter l’image comme une preuve à revisiter, sans la confondre avec une permission d’agir.
Agir seulement par un chemin pris en charge
Une action Android sûre commence après la compréhension, pas avant. L’agent peut comprendre un libellé, reconnaître une icône ou décrire une image, mais il ne doit agir que lorsqu’un chemin pris en charge existe. Ce chemin comprend la cible actuelle, l’action disponible, les permissions nécessaires, l’approbation lorsque l’effet est conséquent et la vérification du résultat.
Dans FoneClaw, nous séparons la lecture visible de l’action. La lecture répond à « que voit-on ? ». L’action répond à « que peut-on faire, avec quelle autorisation et quel résultat ? ». Les deux peuvent se suivre, mais ils ne sont pas équivalents. Une capture approuvée ne remplace pas l’approbation d’un envoi, d’un achat, d’un changement de réglage ou d’une modification de données.
- Lire l’état actuel de l’écran ou obtenir une capture approuvée si le fait est visuel.
- Identifier la cible et l’effet attendu.
- Vérifier que l’action fait partie d’un chemin Android pris en charge.
- Demander la permission ou l’approbation nécessaire.
- Exécuter l’action sans réutiliser une cible obsolète.
- Relire un état frais ou contrôler le résultat visible.
La vérification finale doit être concrète. Si l’objectif était de cocher une option, l’état doit indiquer que l’option est cochée. Si l’objectif était de préparer un brouillon, le brouillon doit être visible. Si l’objectif était d’ouvrir une application ou un écran, l’écran attendu doit être présent. Une réponse de l’agent ne suffit pas si l’application cible ne montre pas le résultat.
Les technologies de vision en temps réel progressent vite. Google décrit par exemple des modèles Gemini Live capables de traiter du contexte visuel et des appels d’outils en arrière-plan dans son annonce sur Gemini Live. C’est un signal d’évolution du secteur, pas une intégration FoneClaw ni une preuve que les permissions Android disparaissent.
S’arrêter quand la preuve est insuffisante
Un agent utile doit savoir s’arrêter. Si les libellés sont ambigus, si l’état a changé, si la capture ne montre pas assez, si la permission manque ou si l’effet de l’action est incertain, la meilleure décision est de demander une précision ou de passer la main à l’utilisateur.
Les signes d’arrêt sont faciles à reconnaître : plusieurs boutons portent le même nom, la cible a disparu, un écran de connexion bloque l’action, une fenêtre système demande une autorisation, un bouton est visible mais son effet n’est pas clair, ou une capture montre une zone sensible que l’utilisateur n’avait pas demandé d’analyser. Dans ces cas, continuer par déduction expose à une erreur.
La récupération sûre commence par une description brève : ce qui est certain, ce qui manque, et quelle action manuelle ou quelle précision est nécessaire. Par exemple : « deux boutons Continuer sont visibles ; choisissez celui du haut ou du bas », ou « l’application demande une permission Android ; accordez-la si vous voulez poursuivre ». Cette formulation préserve le contrôle de l’utilisateur.
Pour les tâches sensibles, le repli manuel n’est pas un échec. Il protège l’utilisateur lorsque l’agent ne dispose pas d’un état fiable ou d’une autorité suffisante. Une bonne limite évite les actions doublées, les messages envoyés au mauvais destinataire, les réglages mal modifiés et les validations irréversibles.
Séparer compréhension visuelle et droit d’action
La compréhension visuelle explique ce qui est affiché. Le droit d’action détermine ce que l’agent peut réellement faire. Ces deux dimensions doivent rester séparées. Voir un formulaire ne donne pas le droit de l’envoyer ; reconnaître une carte ne donne pas le droit de modifier la destination ; lire un montant ne donne pas le droit de payer.
Cette séparation protège l’utilisateur et rend l’agent plus prévisible. L’arbre UI, la capture et l’approche hybride servent à établir une preuve. L’action Android passe ensuite par les outils gouvernés, les permissions et les confirmations. FoneClaw se situe dans cette logique : un runtime d’agent Android avec actions prises en charge et résultats visibles, pas une automatisation universelle basée sur les pixels.
Le choix pratique est donc le suivant : utilisez l’état d’accessibilité frais pour les cibles structurées, une capture approuvée pour les faits visuels, et un chemin d’action pris en charge pour modifier réellement quelque chose. Si l’une de ces trois pièces manque, arrêtez-vous, demandez une précision ou effectuez l’étape manuellement.
Pour vérifier les capacités actuellement disponibles, consultez Fonctionnalités FoneClaw. Pour installer l’application ou revoir le point d’entrée actuel, utilisez Télécharger FoneClaw.