Arbre UI ou capture d’écran : comprendre un écran Android avec un agent IA
Guide FoneClaw pour choisir entre arbre d’accessibilité, capture d’écran ou approche hybride selon la tâche Android, la preuve, la confidentialité et la vérification.
- Pour comprendre un écran Android, commencez par l’arbre d’accessibilité quand les libellés, rôles, états et cibles sont fiables ; ajoutez une capture quand la preuve visuelle change la décision.
- L’arbre UI donne une structure compacte et actionnable, mais il peut manquer du contenu rendu sur mesure, afficher des libellés incomplets ou refléter un état devenu obsolète.
- La capture d’écran apporte les pixels, la mise en page, les images, les cartes et les états visuels, mais elle coûte plus cher à analyser et demande une attention plus forte à la confidentialité.
- Dans FoneClaw, nous choisissons l’information d’écran, la lecture inter-apps ou la capture selon la question réelle, puis nous proposons, confirmons, exécutons et vérifions l’action Android prise en charge.
Choisir arbre UI, capture ou approche hybride
Un agent Android doit choisir sa preuve d’écran selon la tâche. L’arbre d’accessibilité convient d’abord lorsque les éléments sont bien nommés, hiérarchisés et actionnables : bouton, champ, case cochée, texte, état sélectionné, zone cliquable. La capture d’écran devient utile lorsque l’information décisive est visuelle : carte, graphique, image, canvas, disposition, couleur, relation spatiale ou composant rendu sans sémantique suffisante. L’approche hybride sert lorsque l’une des deux vues laisse une incertitude.
Cette décision est au cœur de la compréhension d’écran par un agent IA Android. Plus d’entrée ne signifie pas automatiquement plus de fiabilité. Une capture peut exposer davantage de données personnelles et augmenter le coût d’analyse sans aider si l’arbre UI donne déjà la cible exacte. À l’inverse, un arbre riche en nœuds peut rater une icône dessinée, un graphique ou une zone personnalisée où les pixels portent le sens.
Chez FoneClaw, nous partons de la question de l’utilisateur : que faut-il comprendre pour agir correctement ? Si la demande est « ouvre le bouton Confirmer », la structure sémantique peut suffire. Si la demande est « compare les deux graphiques visibles » ou « que montre cette carte ? », les pixels deviennent nécessaires. Si la demande touche une action sensible, nous privilégions un chemin qui rend la preuve, la proposition et la confirmation visibles.
La règle pratique tient en trois lignes : utilisez l’arbre UI pour trouver des cibles nommées et des états déclarés ; utilisez une capture pour les preuves visuelles ; combinez les deux lorsque la cible, le contexte ou le résultat doivent être recoupés avant action.
Ce que révèle l’arbre d’accessibilité Android
L’arbre d’accessibilité Android représente l’écran sous forme hiérarchique. La documentation officielle sur les services d’accessibilité Android explique qu’un service activé par l’utilisateur peut inspecter le contenu de fenêtre et interagir dans des cas d’assistance. Cette capacité exige une configuration explicite du service, notamment pour récupérer le contenu de fenêtre ou exécuter certaines actions.
La référence AccessibilityNodeInfo décrit les nœuds qui composent cette vue. Selon ce que l’application expose, un nœud peut fournir un texte, une description de contenu, une classe, un rôle implicite, un état coché ou sélectionné, la possibilité de cliquer, le focus, les actions disponibles, la hiérarchie parent-enfant et les bornes à l’écran. Pour un agent, ces champs servent à identifier une cible sans deviner uniquement à partir de pixels.
La force de l’arbre UI est sa compacité. Il dit souvent que tel élément est un champ de saisie, que tel bouton s’appelle « Envoyer », que telle case est cochée, ou que telle liste contient plusieurs entrées. Il aide aussi à éviter les erreurs de coordonnées : appuyer sur un nœud identifié par son texte et son rôle est plus stable que viser un point approximatif dans une image.
Ses limites sont tout aussi importantes. Premier mode d’échec : certains contenus rendus sur mesure, jeux, cartes ou canvas exposent peu de sémantique. Deuxième : les libellés peuvent être absents, dupliqués ou trop génériques, par exemple plusieurs boutons « OK ». Troisième : l’état peut être obsolète si l’écran change entre inspection et action. Quatrième : les bornes peuvent exister sans révéler le sens visuel réel. Cinquième : les superpositions, dialogues ou vues du constructeur peuvent modifier la hiérarchie attendue.
Les guides Android sur UI Automator montrent aussi la valeur des sélecteurs stables, des descriptions de contenu, des relations de hiérarchie et des attentes explicites d’état. Nous utilisons cette leçon comme principe de conception : une action téléphone gagne en fiabilité lorsque la cible est nommée, stable et vérifiée.
Quand les pixels deviennent nécessaires
Une capture d’écran est une preuve visuelle. Elle montre les pixels rendus au moment de la capture : texte visible, images, cartes, graphiques, couleurs, disposition, icônes, état apparent, superpositions et relations spatiales. Elle aide quand l’arbre UI ne contient pas l’information décisive ou quand l’utilisateur demande une interprétation visuelle.
Les cas typiques sont nombreux : un graphique dans une app de finances, une carte avec itinéraire, une image à décrire, une interface dessinée dans un canvas, un jeu, une prévisualisation de document, un tableau rendu comme image, une zone où la couleur porte le statut, ou une mise en page qui montre « l’option de gauche » plutôt qu’un libellé explicite. Dans ces situations, arbre UI et vision par ordinateur se complètent.
La capture a aussi ses modes d’échec. Premier risque : l’OCR lit un texte sans comprendre que l’élément est cliquable ou désactivé. Deuxième : la capture fige un instant, alors qu’une animation, un chargement ou une notification peut changer juste après. Troisième : les coordonnées dépendent de l’orientation, de la densité, de la taille d’écran et des barres système. Quatrième : les superpositions ou bulles flottantes peuvent masquer une partie du contenu. Cinquième : une image expose souvent plus de données personnelles qu’un extrait sémantique minimal.
Les pixels ne révèlent pas l’état caché d’une application. Une capture peut montrer un bouton bleu, mais elle ne prouve pas que l’action est disponible, autorisée ou correctement liée au compte. Elle peut indiquer la position d’un élément, mais pas toujours son rôle, son identifiant ou sa conséquence. C’est pourquoi une capture doit répondre à une question précise : « qu’est-ce qui est visible ? », « quel graphique est affiché ? », « quelle option semble sélectionnée ? », puis être recoupée avant une action engageante.
La confidentialité mérite un choix volontaire. Une capture peut contenir messages, photos, noms, adresses, montants ou notifications. Dans FoneClaw, nous cherchons à utiliser une image lorsque les pixels ajoutent une preuve réelle, pas comme réflexe systématique. Les services configurés en ligne peuvent nécessiter un transfert réseau ; le bon usage consiste donc à limiter le contexte à la tâche.
Comparer arbre UI et capture par qualité de preuve
Le choix entre arbre d’accessibilité ou capture d’écran devient plus simple lorsqu’on compare la preuve, le coût et la valeur de vérification. L’arbre est souvent meilleur pour les cibles nommées et les états déclarés. La capture est meilleure pour ce que l’application montre sans le décrire. L’approche hybride devient utile lorsque le sens et la position doivent être alignés.
| Critère | Arbre UI | Capture d’écran | Route conseillée |
|---|---|---|---|
| Texte et libellés | Compact quand les nœuds sont bien fournis | Utile si le texte est rendu comme image | Arbre d’abord, capture si texte absent |
| Rôle et action | Peut exposer clic, focus, case cochée, champ | Montre l’apparence mais pas toujours le rôle | Arbre pour agir |
| État visible | Bon si l’app déclare l’état | Bon pour couleur, sélection visuelle, badge | Hybride si l’état compte |
| Images, cartes, graphiques | Souvent incomplet | Preuve principale | Capture ciblée |
| Disposition spatiale | Bornes et hiérarchie disponibles selon l’app | Relations visuelles directes | Hybride pour coordonner |
| Coût et latence | Généralement plus léger | Plus lourd à analyser | Limiter la capture au besoin |
| Confidentialité | Peut réduire l’exposition si les champs sont minimaux | Expose tout ce qui est visible | Choisir le minimum utile |
| Vérification | Bon pour relire l’état déclaratif | Bon pour confirmer l’apparence finale | Relire après action |
Aucun chemin ne supprime les permissions Android. Un service d’accessibilité reste une capacité spécialisée activée par l’utilisateur. Une capture reste un accès visuel à l’écran. Un agent Android multimodal fiable ne traite pas ces entrées comme des raccourcis de contrôle ; il les utilise comme preuves bornées pour proposer une suite.
Pour la boucle complète intention, proposition, confirmation et vérification, Contrôler un téléphone Android avec un agent IA : intention, confirmation et vérification fournit le cadre général. Ici, nous nous concentrons sur la sélection de preuve d’écran.
Construire un ancrage sémantique et visuel
Le meilleur workflow hybride commence par une lecture sémantique. L’agent inspecte l’écran actuel, relève les textes, descriptions, états, actions et bornes disponibles. Il cherche ensuite les lacunes : plusieurs cibles similaires, libellé absent, composant personnalisé, graphique, carte, image, couleur d’état, ou relation spatiale que l’arbre ne décrit pas.
Lorsque ces lacunes changent la décision, la capture devient justifiée. Elle doit répondre à une question précise : reconnaître une icône, lire un graphique, vérifier la disposition, confirmer qu’un bouton est visible, ou comprendre une zone non décrite. Cette capture minimale évite d’exposer des pixels qui n’aident pas la tâche.
La troisième étape consiste à réconcilier les preuves. Si l’arbre dit qu’un bouton « Continuer » existe et que la capture montre ce bouton au bon endroit, la confiance augmente. Si l’arbre donne deux boutons identiques et que l’image montre lequel se trouve sous le bon paragraphe, l’hybride résout l’ambiguïté. Si les deux sources se contredisent, le workflow doit s’arrêter ou demander une précision.
Ensuite vient la proposition. L’agent ne doit pas agir silencieusement sur une cible incertaine. Il peut dire : « je vais toucher le bouton Continuer en bas de l’écran » ou « je vais ouvrir le champ de recherche visible ». Pour une action sensible, la proposition doit montrer la cible, l’effet attendu et la possibilité de reprise.
L’action doit être suivie d’une nouvelle lecture. L’écran peut changer entre inspection et appui : chargement, animation, clavier, fenêtre système, orientation, notification, permission ou superposition. La vérification utilise donc un état frais, pas l’hypothèse que le toucher a réussi. Si le résultat n’apparaît pas, l’agent peut relire l’écran, proposer une correction, demander une permission ou passer à un repli manuel.
- Inspecter l’arbre UI disponible.
- Identifier les éléments fiables et les zones d’incertitude.
- Capturer seulement si les pixels apportent une preuve utile.
- Aligner libellés, bornes, apparence et relation spatiale.
- Arrêter ou demander une précision en cas de conflit.
- Proposer l’action avec cible et effet attendu.
- Obtenir l’approbation pour les étapes conséquentes.
- Agir, puis relire l’état final.
Pour les formulaires, cette logique devient encore plus importante : champ, libellé, valeur, validation et bouton final doivent rester alignés. Notre guide Remplissage de formulaires Gemini sur Android : points à vérifier avant de faire confiance à Gemini traite ce cas spécialisé.
Appliquer la méthode aux tâches d’écran FoneClaw
FoneClaw est notre runtime d’agent Android. Le modèle configuré raisonne sur la demande, tandis que FoneClaw fournit des outils gouvernés et des actions prises en charge. Pour les tâches d’écran, nous appliquons le même choix de preuve : utiliser l’information structurée quand elle répond à la question, ajouter une capture lorsque les pixels sont nécessaires, puis vérifier le résultat sur l’écran final.
Les outils actuels incluent notamment get_screen_info pour obtenir des informations sur l’écran, cross_app_read_screen pour lire un contexte inter-apps pris en charge, screenshot_take pour capturer l’écran et screenshot_open pour ouvrir une capture. Ces noms servent à comprendre la route de preuve ; l’utilisateur voit surtout une progression, une demande de permission utile, une proposition et un résultat.
Nous avons renforcé les chemins d’image et de capture afin que les fichiers, dimensions et références restent disponibles pour les suites de tâche, avec préparation multimodale et retour de progression plus lisible. Cela aide lorsqu’un utilisateur choisit de fournir le contexte visuel d’un écran. Le bon usage reste ciblé : si le libellé et l’état sont disponibles dans l’arbre, nous privilégions la route compacte ; si l’information est visuelle, nous ajoutons l’image.
FoneClaw peut commencer avec le modèle par défaut gratuit ou un modèle compatible configuré par l’utilisateur. La page Fonctionnalités FoneClaw présente les capacités actuelles et les 100+ outils intégrés. Pour l’installation et le choix du canal disponible, Télécharger FoneClaw donne le point d’entrée pratique.
Cette approche accompagne aussi l’assistant flottant. Lorsqu’un utilisateur appelle FoneClaw depuis l’écran en cours, il attend une aide située : lire ce qui est visible, comprendre une cible, préparer l’action et rester capable de s’arrêter. Le guide Assistant IA flottant Android : comprendre et agir depuis l’écran actuel approfondit cette expérience d’invocation.
La frontière reste claire : l’arbre UI, la capture et l’hybride sont des preuves pour décider. Ils ne créent pas une autorité illimitée sur toutes les applications. Les permissions, confirmations et limites d’Android restent le cadre de l’action.
Tester la compréhension d’écran avec une tâche réversible
Le test doit se faire sur votre appareil, votre version Android et l’application réellement concernée. Choisissez une tâche réversible : ouvrir un réglage, sélectionner un onglet non sensible, créer un brouillon non envoyé, lire un état ou vérifier une option déjà visible. Évitez les achats, suppressions, envois et changements de compte comme premier essai.
Commencez par noter la cible attendue : texte, position, état et résultat final. Testez ensuite la route arbre UI seule. L’agent identifie-t-il le bon élément ? Les libellés sont-ils assez clairs ? Les états sont-ils fiables ? Ajoutez une capture uniquement si une information visuelle reste nécessaire : graphique, icône, carte, couleur ou disposition.
Changez une variable : orientation, clavier ouvert, thème sombre, zoom, notification ou état de l’élément. Interrompez une fois la tâche, puis vérifiez si l’agent explique ce qui a changé et reprend proprement. Enfin, relisez l’état final ou annulez l’action. Un bon test ne cherche pas à prouver une compatibilité générale ; il mesure si la tâche réelle utilise la bonne preuve et garde le contrôle visible.
Pour des protocoles d’évaluation plus complets, Benchmark d’agents Android : évaluer un agent téléphonique en 2026 propose une méthode plus formelle. Pour les limites entre sandbox, permissions et contrôle téléphone, Sandbox d’agent IA et permissions du téléphone : pourquoi les limites restent essentielles complète la lecture.