Árvore de UI ou captura: como um agente Android entende a tela
Aprenda quando um agente de IA Android deve usar árvore de acessibilidade, captura de tela ou as duas, com critérios de evidência, privacidade, custo e verificação.
- Use a árvore de acessibilidade quando a tarefa depende de texto, função, estado, foco, hierarquia e ações de controles Android representados de forma confiável.
- Use uma captura quando a evidência importante está nos pixels: imagem, gráfico, mapa, canvas, layout visual, cor, ícone, sobreposição ou conteúdo customizado.
- Combine árvore de UI e captura quando uma rota sozinha deixa lacunas, conflito ou baixa confiança; mais contexto só ajuda quando responde a uma dúvida real da tarefa.
- Na FoneClaw, aplicamos essa decisão a tarefas de tela atual com informações estruturadas, capturas escolhidas quando necessário, progresso visível, aprovação e verificação do estado final.
Escolha árvore de UI, captura ou as duas para uma tela Android
A decisão mais confiável é simples: comece pela árvore de UI quando a tarefa depende de estrutura semântica; use captura quando a resposta está nos pixels; combine as duas quando qualquer uma deixa uma lacuna importante. Um agente Android multimodal não deve fotografar a tela por hábito nem confiar cegamente em nós de acessibilidade. A rota certa depende da tela, da pergunta do usuário e da consequência da próxima ação.
A árvore de acessibilidade é uma representação hierárquica de elementos que o Android e os aplicativos expõem para tecnologias assistivas. Ela pode trazer texto, descrições de conteúdo, estados, foco, limites, relação entre pais e filhos e ações possíveis. Isso é valioso para selecionar um botão, entender se uma opção está marcada ou confirmar que um campo contém determinado texto.
Uma captura de tela é evidência visual. Ela mostra pixels: imagens, posição relativa, cores, mapas, gráficos, canvas, ícones, banners, sobreposições e conteúdo que talvez não apareça como nó semântico. Ela ajuda quando a pergunta é visual, mas custa mais em privacidade, largura de contexto e interpretação. OCR em uma imagem pode ler palavras, mas não prova sozinho que aquele texto é um controle clicável ou que tocar ali é a ação correta.
Na prática, mais entrada não é automaticamente melhor. Um agente deve pedir o mínimo necessário para decidir com segurança, propor a ação quando ela tem consequência e verificar o estado final com informação fresca. Para o ciclo completo de intenção, proposta, confirmação, ação e verificação no Android, leia Controlar telefone Android com agente de IA: da intenção à ação.
O que a árvore de acessibilidade revela e onde falha
No Android, serviços de acessibilidade são tecnologias especializadas que podem ajudar pessoas a usar o aparelho de formas assistivas. A documentação de serviços de acessibilidade do Android descreve como um serviço pode receber eventos, inspecionar conteúdo de janelas quando configurado para isso e, em alguns casos, agir em nome do usuário. Essa capacidade exige habilitação e configuração explícitas; ela não deve ser tratada como atalho genérico para automatizar qualquer app.
A unidade técnica central é o AccessibilityNodeInfo, que representa um nó no conteúdo de janela acessível. Quando o app fornece dados de boa qualidade, o agente pode usar texto visível, content description, classe do controle, estado checked, selected ou enabled, foco, bounds na tela, relações de hierarquia e ações disponíveis. Esses campos ajudam a responder perguntas como: qual botão envia, qual caixa está marcada, qual campo está focado, qual item pertence a uma lista e qual elemento tem ação de clique.
A força da árvore de UI está na precisão semântica. Se o usuário pede para ativar uma opção com nome claro, um nó rotulado e clicável costuma ser evidência melhor do que uma imagem. Se a tarefa é preencher um campo, esperar um estado ou confirmar que uma tela mudou, a hierarquia pode dar uma base compacta, mais barata e mais fácil de verificar. A orientação de testes com UI Automator reforça o valor de seletores estáveis, descrições, texto visível e esperas explícitas de estado, ainda que isso não signifique que a FoneClaw use essa ferramenta internamente.
As falhas aparecem quando o app não expõe a tela de forma completa. Conteúdo desenhado em canvas pode virar uma área genérica. Ícones sem descrição podem perder significado. Listas podem duplicar nós ou reciclar posições. Overlays, webviews, jogos, mapas, gráficos e componentes customizados podem oferecer texto parcial, bounds imprecisos ou estados atrasados. Também existe risco de nó obsoleto: a tela muda entre a inspeção e a ação. Por isso, a árvore de acessibilidade é evidência poderosa, mas não uma visão total da tela.
Quando a evidência em pixels é necessária
Uma captura de tela entra quando a pergunta depende do que está renderizado, não apenas do que foi exposto como semântica. Se o usuário pergunta qual imagem aparece, se um gráfico subiu, onde fica um marcador no mapa, qual cartão está destacado por cor, se um botão parece coberto por um banner ou se a tela mostra um erro visual sem texto acessível, os pixels podem responder melhor do que a árvore.
Essa rota é especialmente útil em interfaces customizadas: jogos, editores visuais, apps de desenho, mapas, câmeras, leitores de imagem, dashboards com gráficos, cards com ícones sem rótulo e telas com elementos sobrepostos. Um agente de IA móvel precisa de aterramento visual quando a relação espacial é a própria informação: o botão está no canto superior ou inferior, o item está abaixo do alerta, o gráfico está parcialmente escondido, o banner bloqueia o formulário, a tela está em modo paisagem ou um teclado cobre o campo.
Mas pixels também falham. Primeiro, uma captura é um instante: animações, loading, rolagem e pop-ups podem mudar logo depois. Segundo, coordenadas dependem de tamanho de tela, orientação, escala, recortes, teclado e sobreposições. Terceiro, imagem pode expor conteúdo sensível que não era necessário para a tarefa. Quarto, visão computacional pode confundir ícone com botão, decoração com estado ou texto lido por OCR com intenção de ação. Quinto, pixels mostram aparência, mas não revelam estado oculto, permissão de clique, identidade do controle ou consequência real de tocar.
Por isso, a captura deve responder a uma pergunta específica. Em vez de capturar tudo para qualquer comando, o agente deve perguntar: qual fato visual falta? A cor confirma o estado? A imagem é o objeto da tarefa? A relação espacial muda a decisão? Se a resposta é não, a árvore de UI ou uma leitura estruturada pode bastar e reduzir exposição desnecessária.
Compare árvore de UI e captura pela qualidade da evidência
A melhor comparação não é árvore de acessibilidade versus captura como rivais fixos. É semântica versus pixels como tipos de evidência. Um agente Android precisa saber qual evidência responde à pergunta com menor custo e maior possibilidade de verificação.
| Critério | Árvore de UI | Captura de tela | Decisão prática |
|---|---|---|---|
| Texto e rótulos | Boa quando o app expõe nós claros | Depende de OCR e qualidade visual | Prefira árvore para campos, botões e listas rotuladas |
| Função e ação | Pode indicar clique, foco, estado e hierarquia | Mostra aparência, mas não ação suportada | Use árvore para escolher controles executáveis |
| Imagem, gráfico e mapa | Frequentemente parcial ou genérica | Mostra composição visual e relações espaciais | Use captura quando o conteúdo é visual |
| Custo de contexto | Mais compacto quando os nós são bons | Maior, especialmente com multimodalidade | Capture só a região ou tela necessária quando possível |
| Privacidade | Pode expor textos e rótulos estruturados | Pode expor tudo que está visível | Use o mínimo que responde à tarefa |
| Estabilidade | Pode ficar obsoleta se a tela muda | Também envelhece com animações e overlays | Releia estado antes de agir ou verificar |
| Valor de verificação | Bom para confirmar estado de controles e campos | Bom para confirmar aparência e resultado visual | Verifique pelo mesmo tipo de evidência que prova o objetivo |
| Falha típica | Nós ausentes, duplicados, ruins ou atrasados | OCR errado, coordenada frágil, conteúdo sensível ou ambiguidade visual | Pare quando as evidências conflitam |
Essa matriz evita dois erros comuns. O primeiro é achar que a árvore contém tudo que está na tela. O segundo é achar que uma captura resolve qualquer ambiguidade. A árvore é compacta e orientada a ação quando o app coopera. A imagem é rica visualmente, mas menos explícita sobre intenção e permissões. Em tarefas importantes, o agente deve reconciliar as duas em vez de escolher por hábito.
Monte um fluxo híbrido de aterramento semântico e visual
O fluxo híbrido que usamos como referência começa com inspeção e termina com verificação. Primeiro, leia o estado semântico disponível: tela atual, nós relevantes, texto, controles, foco, bounds e ações. Isso responde à maioria das perguntas de interface comum com menos custo e menos exposição visual. Se a tarefa é abrir uma opção, escolher um item rotulado ou confirmar um campo, essa leitura pode ser suficiente.
Segundo, detecte lacunas. Há canvas, mapa, gráfico, imagem, ícone sem rótulo, botão desenhado, sobreposição, erro visual, layout dependente de posição ou conteúdo que não aparece na hierarquia? A árvore contradiz o que o usuário vê? O texto existe, mas o elemento certo não está claro? Esses sinais justificam uma captura ou uma leitura visual seletiva.
Terceiro, capture apenas quando os pixels respondem a uma dúvida real. A captura deve ter finalidade: identificar o cartão destacado, verificar se o teclado cobre o botão, ler um erro renderizado como imagem, comparar layout, encontrar uma área desenhada ou confirmar uma relação espacial. Uma imagem sem pergunta aumenta custo e risco sem melhorar a decisão.
Quarto, reconcilie nós e pixels. Se a árvore diz que há um botão Enviar e a captura mostra um pop-up cobrindo a área, a ação segura é parar, explicar a incerteza e pedir confirmação ou remover o bloqueio. Se a captura mostra um ícone, mas a árvore não indica ação, o agente deve evitar tocar em coordenada cega quando a consequência importa. Se ambos concordam, a proposta fica mais forte: alvo, estado atual, mudança esperada e forma de verificação.
Quinto, aprove antes de agir quando a ação tem consequência. Preencher uma busca pode ser baixo impacto; enviar mensagem, aceitar termos, alterar configuração, excluir dado ou confirmar compra exige proposta visível. O agente deve mostrar o que fará, em qual app ou tela, e qual resultado será considerado sucesso. Para formulários, a decisão se torna ainda mais sensível porque campos parecidos podem carregar dados pessoais; por isso mantemos o guia Preenchimento de formulários com Gemini: o que esperar no Android como leitura específica desse fluxo.
Sexto, verifique com estado novo. Não presuma que um toque funcionou. Releia a árvore, capture novamente se o objetivo é visual, ou use as duas rotas quando o resultado precisa de semântica e aparência. Se a tela mudou, a verificação deve acompanhar a nova tela, não a evidência antiga. Se houver conflito, o melhor resultado é relatar o que mudou, preservar o contexto e pedir uma próxima decisão.
Aplique a decisão às tarefas de tela atual na FoneClaw
Na FoneClaw, construímos a compreensão de tela como parte de um runtime de agente Android, não como promessa de controle universal. O usuário pode começar com o modelo padrão gratuito ou configurar um modelo compatível; o modelo raciocina, e a FoneClaw fornece ferramentas governadas para ações suportadas. A decisão entre estrutura e pixels entra antes da ação, porque ela define o tipo de evidência que sustenta o próximo passo.
Para tarefas de tela atual, usamos informações estruturadas sempre que elas bastam. Ferramentas como get_screen_info e cross_app_read_screen ajudam a reunir contexto semântico e estado visível de forma mais compacta: textos, controles, foco, app em primeiro plano e elementos que o Android consegue expor. Esse caminho é bom para resumir a tela, identificar botões rotulados, confirmar um campo e decidir se a tarefa precisa de permissão ou de uma pergunta ao usuário.
Quando a pergunta depende de pixels, a rota muda. screenshot_take e screenshot_open permitem trabalhar com uma imagem da tela ou uma captura escolhida. A FoneClaw melhorou o tratamento de anexos de imagem, a reanálise de capturas, a preservação de dimensões e referências de arquivo, a preparação multimodal e o feedback de progresso entre apps. Em termos práticos, isso nos permite usar uma captura para responder a uma dúvida visual real, sem transformar toda tarefa em leitura de imagem.
O limite continua explícito. A FoneClaw não controla todos os apps nem ignora permissões do Android. Acesso de acessibilidade, captura, leitura de tela e ações consequentes dependem de habilitação, permissões, edição instalada, app de destino e política de aprovação. Quando uma ação toca dados, mensagens, configurações ou contas, a proposta precisa ficar visível e o resultado precisa ser conferido.
Esse é também o papel do assistente flutuante: aproximar a tarefa do contexto em que o usuário está trabalhando, mantendo controle e revisão. Para detalhes de interface e uso da tela atual, veja Assistente de IA flutuante no Android: use a tela atual com controle. Para revisar o alcance público das capacidades, use recursos da FoneClaw; para instalar a edição adequada ao seu teste, siga por download da FoneClaw.
Teste a compreensão de tela com uma tarefa Android reversível
Um bom teste de compreensão de tela não começa com pagamento, exclusão, envio ou alteração de conta. Escolha uma tela inofensiva no aparelho, app e versão do Android que você pretende usar. O objetivo é descobrir quando a árvore de UI basta, quando a captura acrescenta evidência e como o agente se comporta quando o estado muda.
- Escolha uma tela simples: configurações de aparência, notas de teste, calendário vazio ou app sem dados sensíveis.
- Defina o alvo esperado: nome do botão, estado atual, resultado desejado e limite do que não deve acontecer.
- Teste a rota semântica: peça ao agente para identificar controles e estados usando a informação estruturada disponível.
- Adicione pixels só para a lacuna: use captura quando houver gráfico, ícone, cor, sobreposição ou layout que a árvore não explica.
- Mude o estado: altere orientação, abra teclado, role a tela ou provoque um pop-up para ver se o agente reavalia.
- Interrompa uma vez: pare antes da ação final e confira se o progresso e a próxima decisão ficam claros.
- Verifique ou desfaça: confirme o estado final com leitura fresca e reverta a mudança quando o teste terminar.
Um sucesso isolado não certifica compatibilidade ampla. Ele mostra que aquela tela, naquele aparelho, naquele app e naquele fluxo ficou compreensível. Para desenho formal de métricas, casos de falha e avaliação repetível, o próximo passo é Benchmark de agentes Android: como avaliar phone agents em 2026. Para entender por que permissões do telefone e limites de agente continuam separados mesmo quando a tela está compreendida, leia Sandbox de agentes de IA e permissões do telefone: por que limites ainda importam.