11 сценариев Gemini в Android Studio: тесты, превью, Agent Mode и падения

Android-разработчику редко нужен ещё один список хитрых промптов для ИИ. Помогает другое: меньше переключений контекста, более быстрая обратная связь и меньше времени на механическую рутину. Именно здесь Gemini в Android Studio и оправдывает своё место.

Не стоит считать его коллегой, которому можно отдать фичу и уйти. Скорее это быстрый напарник по парному программированию прямо в IDE. Он хорошо разбирается в незнакомом коде, набрасывает однотипную работу, читает шумные ошибки и собирает несколько мелких шагов в один дифф, который можно проверить.

Разница между этими двумя ролями в точности. Просьба вроде "сделай эту фичу" слишком расплывчата, а просьба проследить поток состояния, предложить минимальное исправление, прогнать нужные тесты и показать дифф описывает настоящую инженерную работу.

На сентябрь 2026 года Gemini в Android Studio умеет работать с несколькими файлами в Agent Mode, вести параллельные диалоги, генерировать юнит-тесты и превью Compose, помогать с ошибками сборки и Logcat, разбирать падения из App Quality Insights, обновлять зависимости и даже запускать приложение на подключённом устройстве и взаимодействовать с ним. Это задокументированные возможности продукта, а не демо из будущего: они перечислены в обзоре функций Gemini. Практический вопрос в том, как пользоваться ими так, чтобы ревью не съедало больше времени, чем они экономят.

Ниже собраны сценарии, которые стабильно окупаются в ежедневной Android-разработке.

1. Один раз дайте Gemini карту проекта

Самый выгодный промпт часто вовсе не промпт. Это короткий файл AGENTS.md, закоммиченный рядом с кодом.

Gemini подхватывает файлы AGENTS.md из рабочей директории и из всех родительских папок над ней. Поэтому общие правила можно положить в корень репозитория, а более узкие указания добавить внутрь отдельных модулей. Файл лежит рядом с кодом, так что вся команда получает одни и те же инструкции через систему контроля версий. Подробности есть в документации по agent files.

# Android project guidance
- Kotlin only.
- Follow the existing Clean Architecture boundaries.
- Keep business logic out of Composables and Activities.
- Expose immutable UI state from ViewModels.
- Collect Flow with lifecycle awareness.
- Prefer the libraries already used in the target module.
- Make the smallest safe diff; do not reformat unrelated files.
- Add or update tests for changed behavior.
- Before finishing, run the narrowest relevant Gradle test task.

В многомодульном приложении добавляйте локальные файлы там, где правила отличаются:

AGENTS.md
player/AGENTS.md
androidtv/AGENTS.md
billing/AGENTS.md

Здесь важна краткость. Стоит включить архитектурные решения, точки входа каждого модуля, предпочитаемые библиотеки для тестов и места, которые никому трогать нельзя. Манифест на 200 строк быстро превращается в устаревший контекст.

Проверьте одну деталь с версиями. Google указывает поддержку AGENTS.md начиная с Android Studio Narwhal 4 Feature Drop Canary 4, а Narwhal 3 Feature Drop ожидал файл в единственном числе, AGENT.md. Прежде чем рассчитывать, что файл работает, посмотрите версию своей IDE.

2. Пишите бриф задачи в четыре строки

Длинный промпт не становится лучше сам по себе. Надёжный короткий формат состоит из четырёх частей:

Goal: Add retry support to PlaybackRepository.
Context: Inspect PlaybackRepository, its interface, and existing tests.
Constraints: Preserve public APIs; use the existing coroutine/test stack; minimal diff.
Verification: Add failure-then-success tests and run the relevant module test task.

Он работает, потому что снимает четыре типичные неясности: что нужно изменить, где искать, что должно остаться стабильным и что значит "готово".

Для рискованной работы добавьте ещё одну строку:

Before editing, explain the likely root cause and propose a plan.

Для рутинных задач обходитесь без церемоний и сразу просите дифф. Размер промпта должен соответствовать риску.

3. Держите контекст узким, а треды раздельными

Если навалить контекста, ответ может стать хуже, когда большая его часть не относится к вопросу. Если для рассуждения об изменении этого хватает, приложите ViewModel, модель состояния, контракт репозитория и соседние тесты, а остальное приложение оставьте в стороне. Android Studio позволяет прикреплять файлы проекта прямо к запросу.

Заводите отдельные треды под отдельные задачи, например:

• баг воспроизведения
• миграция зависимостей
• генерация тестов
• работа над UI в Compose

Gemini помнит историю диалога. Google отмечает, что раздельные треды повышают качество ответов, ограничивая контекст текущей темой, а очистка устаревшей истории помогает, когда чат ушёл в сторону. См. Chat with Gemini. Простое правило: если в следующем промпте хочется написать "забудь всё, что выше", откройте новый тред.

4. Отдайте нудную сопутствующую правку Next Edit Prediction

Автодополнение работает там, где стоит курсор. Next Edit Prediction идёт дальше и угадывает связанное изменение в другом месте файла или проекта. Особенно хорошо это работает сразу после таких правок:

• новое свойство в UI-состоянии
• переименованный вариант sealed-класса
• изменённая сигнатура функции
• одна ветка повторяющегося маппинга, которую вы только что обновили
• та же защитная проверка, нужная по соседству

Когда редактор показывает Tab to move, первый Tab переносит вас к предложенному изменению, а второй применяет его. Если догадка неверна, нажмите Esc. Предсказания можно приостановить, а задержку перед запросом настроить в параметрах AI-редактора; об этом рассказывает страница Next Edit Prediction.

Принимать подсказки на автомате — плохая привычка. Одна быстрая неправильная правка, размноженная по файлам, всё равно остаётся регрессией.

5. Спрашивайте прямо с места ошибки

Когда падает синхронизация Gradle или крашится приложение, у IDE уже есть структурированный контекст. Вместо того чтобы вставлять шум в чат, используйте действие Ask Gemini прямо там.

В Logcat Gemini может получить нужный стектрейс и ответить кратким объяснением простым языком, вероятными причинами и предложенными исправлениями. Это описано в документации по интеграции с Logcat. Хорошо работает уточняющий вопрос, который ставит ответ под сомнение:

Trace this to the first frame owned by our app. Explain the state that makes it fail.
Propose the smallest fix, identify any behavior change, and add a regression test.
Do not hide the problem with a broad try/catch or a non-null assertion.

Последняя инструкция отсекает два частых исхода в духе "сборка зелёная, а исправление плохое".

При ошибках сборки попросите Gemini отделить корневую ошибку от цепочки вызванных ею сбоев. Исправить самую раннюю осмысленную ошибку обычно быстрее, чем гоняться за 40 последующими сообщениями.

6. Генерируйте тесты от поведения, а не от реализации

Gemini может написать полноценные классы юнит-тестов на Kotlin или Java с кодом настройки, моками и отдельными кейсами и подстраивает их под уже существующую конфигурацию проекта. При этом Google всё ещё называет весь сценарий превью и документирует его для Android Studio Panda 4 Canary 3 и новее. Подробности на странице о генерации юнит-тестов.

Слабый запрос выглядит так:

Write tests for PlaybackViewModel.

Полезный выглядит так:

Generate unit tests for PlaybackViewModel.
Cover observable behavior:
- initial state;
- successful playback start;
- repository failure;
- duplicate play requests;
- cancellation when the ViewModel is cleared.
Use the test libraries and coroutine dispatcher pattern already present in this module.
Do not test private methods or reproduce the implementation in the assertions.
Use deterministic virtual time and verify emitted UI states in order.
Run the narrowest relevant test task after editing.

Проверяйте всё, что он пишет. Спросите себя, может ли каждый тест упасть по правильной причине. Типичные проблемы: слишком мягкие моки, ассерты, повторяющие настройку, реальные задержки, отсутствие проверки отмены и тесты, намертво привязанные к приватным деталям реализации.

ИИ отлично убирает трение при создании каркаса, но стратегия тестирования остаётся вашей.

7. Генерируйте превью Compose до запуска эмулятора

Превью — дешёвый способ получить обратную связь в Compose, но писать правдоподобные данные для них скучно. Gemini создаст превью для одного Composable или для каждого подходящего в файле, вместе с моковыми данными для параметров превью. Результат вы видите как дифф, который можно принять или отклонить. См. Generate Compose previews.

Один удачный сценарий мало что доказывает, поэтому попросите компактную матрицу состояний:

Generate previews for compact phone, tablet, and Android TV widths.
Include loading, populated, empty, long-title, and error states.
Use the existing theme and PreviewParameterProvider pattern.
Do not call a ViewModel, network layer, or dependency injection from previews.

Тогда превью работают как дешёвые дизайн-тесты. Допущения вёрстки обычно ломаются на очень длинных заголовках, пустом контенте, обработке фокуса и больших экранах.

Для Android TV явно просите варианты с фокусом и без. Вёрстка, которая нормально работает при касании, может развалиться, когда по ней ходят D-pad'ом пульта.

8. Направляйте Agent Mode на ограниченный вертикальный срез

В Agent Mode Gemini может набросать план многошаговой задачи, править несколько файлов, запускать инструменты, собирать проект и повторять попытку при сбое. Можно вести и несколько диалогов параллельно, как описано в документации по Agent Mode.

Оптимальная зона — ограниченный вертикальный срез, а не "модернизируй приложение". Например:

Add a Saved Episodes filter to the Downloads screen.
First inspect the existing state, reducer/ViewModel, domain model, repository, and tests.
Reuse the current filter component and architecture.
Do not change persistence or navigation contracts.
Implement the smallest complete slice, add tests, build the module, and summarize every file changed.
Pause before any public API or database schema change.

Такая задача достаточно большая, чтобы выиграть от работы с несколькими файлами, и достаточно маленькая, чтобы её можно было проверить.

Параллельные диалоги запускайте только для независимых задач: например, в одном треде генерируются тесты, а в другом разбирается не связанное с ними предупреждение сборки. Два агента, правящие пересекающиеся файлы, — верный путь к конфликтующим допущениям.

9. Пусть агент докажет изменение UI на устройстве

Дифф кода не доказывает, что UI-фича работает.

Агент в Android Studio может установить сборку на подключённое устройство, посмотреть на экран, сделать скриншоты, прочитать Logcat и управлять устройством через инструменты ввода. После исправления UI цикл замыкает примерно такой проверочный промпт:

Build and run the app on the connected device.
Open the Downloads screen, apply the Saved filter, and verify the empty and populated states.
Capture a screenshot of the final state and check Logcat for new errors.
If verification fails, stop and report what you observed before making another broad change.

Оставляйте человека в цепочке подтверждения для всего, что связано со входом в аккаунт, покупками, необратимыми действиями или реальными данными пользователей. Доступ к устройству делает агента способнее, но не делает его более надёжным.

10. Считайте данные о падениях в продакшене отправной точкой

В App Quality Insights можно попросить Gemini кратко описать падение, указать файл, где оно началось, назвать вероятную причину и набросать правку кода. Это разобрано в руководстве Google по анализу падений.

Хорошие уточняющие вопросы:

What evidence in this stack trace supports that root cause?
Which assumptions are you making?
Could this be lifecycle-, concurrency-, process-death-, or device-specific?
What telemetry or test would distinguish the alternatives?

Падения в продакшене часто вскрывают проблемы с таймингом и состоянием, которые один стектрейс не объясняет. Сводка экономит время на чтение, но гипотезу всё равно нужно проверить.

11. Обновляйте зависимости по одной ограниченной группе

Сценарий обновления зависимостей умеет находить совместимые обновления, менять проект, разбирать возникшие ошибки сборки, запускать тесты и в конце выдавать отчёт с диффами по каждому файлу. Он описан в Automate dependency updates.

Инструмент мощный, поэтому уменьшайте радиус поражения:

Update only Kotlin coroutines and the related test artifact.
Do not update AGP, Kotlin, Compose, Gradle, or unrelated libraries.
Read the relevant migration notes first.
Build affected modules, run their unit tests, and report behavior or API changes.
Stop if the update requires a public API, minSdk, targetSdk, or build-system change.

Избегайте одного гигантского ревью "обнови всё", где вместе свалены AGP, Kotlin, Compose, сериализация, DI и двадцать библиотек. Дифф может появиться за минуты, но кому-то всё равно придётся в нём разобраться.

Защитите контекст, прежде чем оптимизировать промпты

Когда включён обмен контекстом проекта, файл .aiexclude определяет, что Gemini может читать. Его синтаксис совпадает с .gitignore, а каждое правило действует на папку с файлом и всё, что ниже. ИИ-функции не видят ничего за пределами открытого проекта и подключённых VCS-корней, но чувствительные файлы внутри этих границ всё равно стоит исключить явно. Шаги описаны на странице настройки .aiexclude.

*.jks
*.keystore
local.properties
secrets/
**/production-config.json
**/customer-data/

Эти два файла не взаимозаменяемы, так что не путайте их. Прежде чем проприетарный код или продакшен-данные куда-то уйдут, узнайте, что разрешено в вашей организации. Для индивидуального тарифа уведомление Google о конфиденциальности говорит, что промпты, ответы, данные об использовании и отзывы могут собираться и читаться людьми-рецензентами, и не рекомендует вводить конфиденциальную или личную информацию. Бизнес-соглашения могут отличаться, поэтому прочитайте условия, которые относятся к вашему аккаунту.

Правило 60 секунд для ревью изменений от ИИ

Прежде чем принять дифф от Gemini, задайте шесть вопросов:

1. Ограничен ли дифф тем, о чём вы просили?
2. Не нарушены ли границы модулей и архитектуры?
3. Не выдумал ли он API, зависимость или соглашение?
4. Ошибки действительно обрабатываются или просто глотаются?
5. Упадут ли новые тесты, если поведение сломается?
6. Подтверждают ли изменение сборка, прогон тестов и проверка на устройстве?

Если ответы не приходят быстро, изменение слишком большое — разбейте его.

Сценарий, который даёт накопительный эффект

Лучше всего работает простой цикл:

Объяснить → спланировать → изменить → протестировать → запустить → проверить → подвести итог.

Gemini полезнее всего, когда сокращает этот цикл внутри Android Studio. И меньше всего, когда выдаёт большой кусок правдоподобного Kotlin, который никто не привязал к репозиторию и не запускал.

Продуктивность берётся не из того, что вы быстрее печатаете. Раньше появляется доверие: стектрейс, который наконец понятен, тест, который компилируется, превью Compose с реалистичными данными, скриншот с устройства и дифф, достаточно маленький, чтобы его прочитать.

Пусть Gemini закрывает механический отрезок между намерением и доказательством того, что всё работает. Архитектура, компромиссы и ответственность остаются работой инженера.