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 закриває механічний відрізок між наміром і доказом того, що все працює. Архітектура, компроміси й відповідальність лишаються роботою інженера.