Понимание экрана ИИ на Android: UI-состояние, скриншот и безопасное действие
Как Android AI agent выбирает между деревом UI, одобренным скриншотом и гибридной проверкой: свежее состояние, разрешения, подтверждение и безопасный откат.
- Для текста, ролей, переключателей и доступных действий Android-агенту лучше начинать со свежего семантического состояния экрана, а не со старого снимка или догадки.
- Скриншот нужен для визуальных фактов: изображения, графика, карты, цвета, оверлея или кастомной отрисовки; это чувствительное чтение экрана и требует явного одобрения.
- Понимание экрана не дает права действовать: поддерживаемое Android-действие должно идти через разрешенный путь, подтверждение и повторную проверку свежего состояния.
- Если подписи, состояние, визуальные данные или полномочия недостаточны, безопасный результат — остановка, уточнение или ручная передача управления, а не попытка нажать по скриншоту.
Что выбрать: дерево UI, скриншот или оба сигнала
Короткий ответ: выбирайте самый узкий сигнал, который доказывает следующий шаг. Если вопрос относится к тексту, роли элемента, состоянию переключателя, полю ввода, доступному действию или иерархии экрана, начинайте со свежего дерева UI. Если вопрос относится к тому, что видно глазами: изображению, карте, графику, цвету, оверлею, нестандартной кнопке или расположению элементов, нужен скриншот. Если один источник дает только половину ответа, используйте оба, но сверяйте их перед действием.
Понимание экрана ИИ на Android не должно превращаться в правило «всегда сделай снимок». Скриншот раскрывает больше видимого контекста, чем обычно нужно для простого выбора кнопки. Дерево UI компактнее и ближе к действиям, но зависит от того, насколько хорошо приложение передает семантику Android. Поэтому первый вопрос должен быть не техническим, а практическим: что именно надо доказать перед следующим шагом?
| Вопрос пользователя | Лучший первый сигнал | Почему |
|---|---|---|
| Какая кнопка доступна? | Свежее дерево UI | Нужны роль, подпись и действие |
| Включен ли переключатель? | Дерево UI, затем проверка состояния | Состояние должно быть текущим |
| Что показано на графике? | Скриншот с одобрением | Факт существует в пикселях |
| Можно ли нажать сейчас? | Дерево UI плюс свежая проверка | Нужны полномочия и актуальное состояние |
| Есть конфликт между подписью и картинкой? | Оба сигнала | Нужно сверить семантику и видимый экран |
Если нужен более широкий путь от намерения к выполнению на телефоне, используйте отдельное руководство Управление Android ИИ-агентом: намерение, подтверждение и проверка результата. Здесь фокус уже: как отличить доказательство экрана от права выполнить действие.
Используйте свежее состояние доступности для элементов
Семантическое состояние полезно там, где приложение сообщает Android, что именно находится на экране. В официальной документации Android AccessibilityService описано, что служба доступности может получать доступное содержимое окон и выполнять поддерживаемые действия через API доступности. Для агента это означает: текст, описания, роли, состояния, фокус, границы и доступные действия могут быть основой для безопасного следующего шага.
Но состояние должно быть свежим. Нельзя прочитать узлы один раз, затем ждать, пока пользователь прокрутит список или приложение обновит экран, и продолжать действие по старой цели. Перед нажатием, вводом текста, изменением настройки или отправкой данных агент должен заново проверить текущий экран. Иначе он рискует действовать по элементу, который уже исчез, сместился, стал недоступен или относится к другой карточке.
Практическая проверка выглядит так:
- Прочитайте текущий экран и найдите целевой элемент по подписи, роли и состоянию.
- Проверьте, что элемент один, видим и доступен для нужного действия.
- Сверьте, что экран относится к ожидаемому приложению или шагу задачи.
- Перед действием обновите состояние, если была прокрутка, анимация, системный диалог или задержка.
- После действия перечитайте экран и убедитесь, что состояние изменилось ожидаемо.
Семантическое дерево не гарантирует полную картину каждого приложения. Некоторые элементы могут быть плохо подписаны, нарисованы в canvas, скрыты внутри WebView или представлены одинаковыми узлами в повторяющемся списке. В таких случаях правильный маршрут — не угадывать, а собрать дополнительное доказательство или передать шаг пользователю.
В FoneClaw мы используем экранное состояние как отдельный путь чтения, а не как разрешение на любое действие. Оно помогает понять, что видно и какие поддерживаемые шаги возможны, но значимое изменение все равно должно идти через управляемый инструмент, Android-разрешение и проверяемый результат.
Скриншоты нужны для визуальных фактов и требуют одобрения
Скриншот отвечает на вопросы, которые не сводятся к подписи или роли элемента. Он показывает цвета, изображения, карту, график, перекрытие, визуальное выделение, состояние загрузки, нестандартную отрисовку и фактическое расположение объектов. Если пользователь спрашивает «какая карточка выделена», «есть ли красное предупреждение», «появился ли QR-код» или «видно ли ошибку под полем», семантического дерева может быть недостаточно.
При этом снимок экрана — чувствительное чтение. Он может включать имена, сообщения, фотографии, адреса, уведомления, финансовые данные или фрагменты других приложений. Поэтому скриншот не должен быть скрытым универсальным запасным способом автоматизации. Его нужно запрашивать с понятной целью: какой визуальный факт проверяется и зачем он нужен для следующего решения.
| Когда снимок оправдан | Что ограничить | Что сделать после анализа |
|---|---|---|
| Карта, изображение, график или QR-код | Не собирать лишние экраны | Объяснить найденный визуальный факт |
| Оверлей закрывает кнопку | Не нажимать по старому узлу | Попросить закрыть окно или выбрать безопасный шаг |
| Цветовой статус важен для решения | Не переносить вывод на другие экраны | Проверить свежий экран перед действием |
| UI плохо размечен семантически | Не использовать координаты как единственное доказательство | Сверить снимок с доступными действиями |
Для задач с пользовательскими изображениями и повторным анализом полезен отдельный материал Контекст изображения ИИ на Android: повторный анализ без потери исходника. Здесь же главное правило такое: визуальное понимание помогает принять решение, но не заменяет разрешение на действие.
Отрасль быстро движется к более богатому визуальному контексту. Например, Google описывает реальные визуальные сигналы и фоновые вызовы инструментов в обновлении Gemini Live. Это полезный контекст для рынка, но не означает интеграцию с FoneClaw и не меняет границы Android-разрешений.
Действуйте только поддерживаемым путем и проверяйте результат
Понять экран — еще не значит иметь право действовать. Android AI agent должен сначала определить, поддерживается ли нужное действие, есть ли текущий экран, выдано ли разрешение и можно ли проверить результат. Если пользователь просит «нажми отправить», агенту недостаточно распознать кнопку на снимке. Нужно знать приложение, получателя, текст, состояние черновика, доступный инструмент и точку подтверждения.
В FoneClaw поддерживаемые действия выполняются через управляемые инструменты и видимые результаты. Например, если задача относится к настройке, агент должен показать, что изменится, запросить нужное разрешение и после выполнения проверить новое состояние. Если задача относится к сообщению, пользователь должен видеть получателя и текст до финального действия. Если результат нельзя проверить свежим состоянием, безопаснее остановиться.
Порядок выполнения:
- Определите цель и приложение, где должен появиться результат.
- Прочитайте свежий экран через семантический путь.
- Запросите скриншот только для недостающего визуального факта.
- Сверьте, что цель, визуальная область и доступное действие относятся к одному месту.
- Покажите пользователю параметры действия и запросите подтверждение для значимого изменения.
- Выполните только поддерживаемый шаг.
- Проверьте результат новым чтением экрана, а при визуальной задаче — новым снимком с одобрением.
Этот подход особенно важен для плавающего помощника поверх текущего приложения. Пользователь может переходить между экранами, а агент должен сохранять контекст задачи, не превращая старый экран в основание для нового действия. Практический слой текущего экрана разобран в статье Плавающий ИИ-ассистент Android и текущий экран: контекст, действия и контроль.
Если экран изменился между анализом и действием, нужно обновить состояние. Старый узел, старый снимок или старые координаты не должны использоваться как основание для касания, ввода или отправки.
Когда нужно остановиться и передать управление
Безопасная остановка — нормальный результат, если у агента недостаточно доказательств или полномочий. Остановиться нужно, когда подписи элементов слишком общие, на экране несколько одинаковых целей, состояние устарело, визуальный факт противоречит дереву UI, поверх кнопки появился диалог, отсутствует разрешение или действие не входит в поддерживаемый путь.
Неправильный fallback — попытаться использовать скриншот как координатную карту и нажать «примерно туда». Скриншот может объяснить, что видно, но сам по себе не доказывает, что точка клика соответствует допустимому действию. Особенно это касается платежей, отправки сообщений, удаления данных, публикаций, настроек безопасности и экранов с личными данными.
| Проблема | Безопасное поведение | Чего не делать |
|---|---|---|
| Две одинаковые кнопки | Спросить пользователя или уточнить контекст | Выбирать первую попавшуюся |
| Состояние устарело | Перечитать экран | Действовать по старому узлу |
| Нужно разрешение | Показать запрос и объяснить связь с задачей | Имитировать успех |
| Скриншот показывает оверлей | Остановиться или закрыть его с подтверждением | Нажимать скрытую кнопку под ним |
| Неподдержанный шаг | Передать управление вручную | Обещать универсальный контроль приложения |
Восстановление начинается с диагностики: что уже выполнено, что изменилось на экране и какой шаг остался незавершенным. Повторяйте только незавершенный и обратимый этап. Если действие может создать дубликат или внешний эффект, сначала проверьте место назначения вручную.
Понимание экрана не равно праву на действие
Визуальное понимание, семантическое состояние и полномочие на Android-действие — разные вещи. Агент может увидеть кнопку, распознать текст и объяснить экран, но это не означает, что он должен нажать, отправить, изменить или удалить. Для действия нужны поддерживаемый путь, актуальное состояние, разрешение, подтверждение и проверяемый итог.
Эта граница защищает пользователя. Видимый экран может содержать конфиденциальные данные, временный диалог, чужой аккаунт, старый результат или интерфейс, который изменился после последнего чтения. Поэтому FoneClaw отделяет чтение экрана от выполнения: видимая информация помогает планировать, а последствия проходят через управляемые инструменты и результат, который можно проверить.
Если задача только объяснительная, достаточно минимального доказательства: дерево UI для текста и ролей, скриншот для визуального факта. Если задача меняет состояние телефона, нужен другой уровень контроля. После ответа на вопрос «что видно?» обязательно задайте следующий вопрос: «имеет ли агент поддерживаемый и подтвержденный путь для действия?»
Актуальные поддерживаемые возможности смотрите на странице функций FoneClaw, а способ установки — на странице загрузки FoneClaw. Эти страницы помогают перейти от понимания экрана к проверяемому, разрешенному действию там, где такой сценарий поддержан.