Comprensión de pantalla con IA en Android: estado, captura y acción segura

Elegir estado UI, captura o ambos según la pregunta

La decisión directa es esta: usa estado semántico de la interfaz cuando la pregunta trata de controles, texto, roles, estados o acciones disponibles; usa una captura cuando la pregunta depende de lo que se ve como imagen, color, gráfico, mapa, diseño o contenido renderizado; usa ambos cuando una sola señal deja una duda que puede cambiar la respuesta o la acción.

La comprensión de pantalla con IA en Android no mejora por mirar más datos de forma automática. Mejora cuando el agente elige la evidencia mínima suficiente para responder o preparar una acción. Un botón con etiqueta, un campo editable o un interruptor con estado marcado suelen resolverse mejor con información de accesibilidad. Un gráfico sin descripción, un icono sin etiqueta o una foto necesitan evidencia visual.

En FoneClaw separamos tres ideas que a menudo se mezclan. La información visible de pantalla es una ruta de lectura. La captura de pantalla es una lectura sensible que requiere aprobación. La acción Android con consecuencia necesita una ruta soportada, permisos, confirmación cuando corresponde y resultado visible. Ver una pantalla no significa tener permiso para actuar sobre todo lo que aparece.

Para entender cómo una intención pasa a acción verificada en el teléfono, Controlar un teléfono Android con agente de IA: de intención a acción verificada explica la arquitectura más amplia sin reducirla a una simple lectura de pantalla.

Usar estado de accesibilidad fresco para controles visibles

El estado semántico es la señal preferida cuando la tarea depende de controles visibles. La documentación oficial de AccessibilityService de Android describe cómo los servicios de accesibilidad pueden recibir contenido de ventana expuesto y actuar mediante APIs compatibles. Esa capacidad depende de lo que Android y la aplicación exponen; no convierte todas las apps en interfaces completas para agentes.

Cuando la app ofrece buena semántica, el agente puede leer texto, descripciones, foco, límites en pantalla, estados seleccionados o marcados y acciones disponibles. Eso sirve para preguntas como “¿qué campo está enfocado?”, “¿este interruptor está activado?” o “¿hay un botón Enviar?”. También reduce la necesidad de procesar una captura completa cuando la tarea solo necesita un dato estructurado.

El punto crítico es la frescura. Una pantalla puede cambiar después de la lectura: aparece un teclado, entra una notificación, se abre un diálogo, termina una carga o un botón se desactiva. Por eso el agente no debe reutilizar nodos antiguos como si siguieran siendo ciertos. Antes de una acción con efecto, debe confirmar que el elemento sigue en la pantalla, que su estado coincide y que la ruta sigue siendo soportada.

El estado semántico también puede fallar. Algunas apps dibujan controles personalizados, exponen etiquetas genéricas o duplican textos. En esos casos, no conviene forzar una pulsación. La respuesta responsable es pedir confirmación, solicitar una captura aprobada si la duda es visual o pasar a una continuación manual.

• Usa estado semántico para campos, botones, casillas, listas y estados claros.
• Vuelve a leer antes de actuar si la pantalla pudo cambiar.
• No trates un nodo sin etiqueta como objetivo seguro.
• Si hay varios elementos parecidos, pide aclaración antes de tocar.

Esta disciplina es especialmente importante en un asistente flotante que trabaja con la pantalla actual. Para ese flujo, Asistente de IA flotante en Android: usar la pantalla actual con control explica cómo aprovechar el contexto sin perder la revisión del usuario.

Usar capturas para hechos visuales con aprobación explícita

Una captura de pantalla aporta evidencia cuando la pregunta es visual. Puede mostrar una imagen, un mapa, un gráfico, un color, una superposición, una tarjeta renderizada o una distribución espacial que el árbol de accesibilidad no explica. También ayuda cuando la semántica y la apariencia parecen contradecirse, por ejemplo si un botón existe en los nodos pero un modal lo tapa.

Pero una captura es una lectura sensible. Puede incluir mensajes, nombres, ubicaciones, fotos, pagos, notificaciones o datos de salud. En FoneClaw la captura no debe tomarse por costumbre: debe responder a una pregunta concreta y contar con aprobación explícita del usuario. Si el estado semántico basta, no hace falta exponer más pantalla.

La captura tampoco es un mando a distancia. Puede ayudar a describir dónde está algo, pero no revela por sí sola la intención de un control, su estado real, sus permisos ni si tocarlo es seguro. Por eso no usamos la imagen como fallback universal de control por coordenadas. Si la acción importa, debe pasar por una ruta soportada y verificarse después.

Google ha descrito avances de contexto visual en tiempo real y llamadas de herramientas en modelos Gemini Live en su anuncio sobre Gemini Live. Lo citamos como contexto del sector: no implica integración de FoneClaw con Gemini ni capacidades idénticas.

Cuando la tarea gira en torno a imágenes aprobadas, Contexto de imagen con IA en Android: conservar, reanalizar y verificar desarrolla cómo conservar y volver a analizar evidencia visual sin convertir la captura en autorización automática.

Actuar solo por una ruta soportada y verificar estado fresco

Un agente Android debe actuar solo cuando dispone de una ruta soportada. Esa ruta puede ser una acción de accesibilidad válida, una herramienta gobernada, una función del sistema admitida o un paso aprobado por el usuario. La comprensión visual puede preparar la decisión, pero la acción necesita autoridad concreta.

El flujo seguro tiene una secuencia clara. Primero se identifica la pantalla actual. Después se decide si basta el estado semántico o si hace falta captura aprobada. Luego se prepara la acción y se muestra al usuario qué cambiará. Si el paso tiene consecuencia, se pide confirmación. Por último, se verifica el resultado con estado fresco, no con la lectura antigua.

1. Leer. Identificar app, pantalla, controles y datos relevantes.
2. Resolver dudas. Añadir captura solo si una pregunta visual lo requiere.
3. Preparar. Mostrar objetivo, destino y consecuencia posible.
4. Aprobar. Mantener visible cualquier paso sensible.
5. Ejecutar. Usar solo una ruta soportada.
6. Verificar. Confirmar el resultado con una lectura nueva.

Ejemplo: si el usuario pide enviar un mensaje, el agente debe comprobar destinatario, contenido, aplicación y estado actual. Una captura puede ayudar a revisar un borrador visible, pero no autoriza el envío. El envío necesita una ruta soportada, permiso aplicable y confirmación cuando corresponde. Después hay que comprobar que el resultado existe en el destino adecuado.

En FoneClaw, las acciones con consecuencia usan herramientas gobernadas y resultados visibles. La página oficial de funciones de FoneClaw resume el alcance actual de esas capacidades. La regla de producto es deliberada: entender una pantalla ayuda, pero completar una tarea exige controles, permisos y verificación.

La información más reciente de FoneClaw también refuerza notas de voz revisables y resúmenes de transcripción. Eso ayuda a revisar lo que el usuario pidió y a reducir ambigüedad en la intención, pero no cambia el requisito central: antes de actuar, el estado de la pantalla y la autoridad de la acción deben seguir siendo válidos.

Detenerse cuando faltan etiquetas, estado o autoridad

La parada segura forma parte de una buena experiencia de agente. Si faltan etiquetas, si la pantalla cambió, si una captura contradice el estado semántico, si hay varios objetivos parecidos o si no existe una ruta soportada, el agente debe detenerse y explicar la duda. Continuar por intuición puede producir un toque, envío o cambio equivocado.

La parada no tiene que ser vaga. Debe decir qué falta: “no encuentro una etiqueta fiable”, “la pantalla cambió desde la última lectura”, “la imagen muestra un modal encima del botón”, “falta permiso” o “esta acción no está soportada”. Esa explicación permite al usuario decidir si concede permiso, toma una captura, navega manualmente o cancela.

La recuperación debe ir por el paso mínimo. Si solo falta una lectura nueva, no se reinicia toda la tarea. Si falta permiso, se solicita el permiso aplicable y se vuelve al punto adecuado. Si el usuario quiere continuar manualmente, el agente puede resumir qué encontró y qué queda pendiente.

Este límite protege tanto la privacidad como la precisión. Una captura no debe convertirse en control por coordenadas; un nodo sin etiqueta no debe convertirse en certeza; y una respuesta del modelo no debe presentarse como resultado si la aplicación no cambió.

Separar comprensión visual y autoridad para actuar

La comprensión visual responde a “¿qué aparece en la pantalla?”. La autoridad para actuar responde a “¿qué puede hacer el agente de forma permitida, visible y verificable?”. Separarlas evita dos errores frecuentes: creer que una captura permite controlar cualquier app y creer que un nodo visible garantiza que la acción seguirá siendo válida unos segundos después.

FoneClaw es un runtime de agente Android. Su papel es coordinar acciones soportadas del teléfono mediante herramientas gobernadas y resultados visibles. No prometemos cobertura semántica universal de todas las apps, no usamos capturas como sustituto general de control y no afirmamos integración con Gemini. Cuando una tarea está soportada, debe seguir el camino de permisos, aprobación y verificación.

La decisión final puede resumirse así: usa estado semántico fresco para controles; usa captura aprobada para hechos visuales; combina ambas señales si hay incertidumbre; actúa solo por una ruta soportada; y detente cuando falten etiquetas, estado o autoridad. Esa pauta mantiene la comprensión de pantalla útil sin convertirla en automatización insegura.