11 schematów pracy Gemini w Android Studio: testy, przeglądy, tryb Agenta oraz rozwiązywanie awarii.

Rozwijający aplikacje na Androida rzadko potrzebują kolejnej listy sprytnych promptów dla sztucznej inteligencji. Pomaga to, że jest mniej zmian kontekstu, szybsze pętle zwrotne oraz mniej czasu poświęcanego na rutynowe zadania. Właśnie tutaj Gemini w Android Studio znajduje swoje zastosowanie.

Nie traktuj go jak kolegi z zespołu, który może samodzielnie zajmować się daną funkcją, podczas gdy ty odchodzisz. Myśl o nim jako o szybkim partnerze do programowania wewnątrz IDE. Doskonale radzi sobie z analizą nieznajomego kodu, przygotowywaniem powtarzalnych zadań, interpretacją skomplikowanych błędów oraz łączeniem kilku małych kroków w jeden raport różnic, który można przejrzeć.

To precyzja odróżnia te dwa podejścia. Prośba taka jak „stwórz tę funkcję” jest zbyt ogólna, by można ją było wykonać, natomiast poproszenie Gemina o śledzenie określonego przepływu stanów, zaproponowanie najmniejszej korekty, uruchomienie odpowiednich testów i pokazanie raportu różnic opisuje prawdziwą pracę inżynierską.

Od września 2026 roku Gemini w Android Studio umożliwia pracę z plikami w trybie Agent, obsługę równoległych rozmów, generowanie testów jednostkowych oraz wstępnych wersji interfejsu Compose, pomaga w rozwiązywaniu problemów z budową aplikacji i błędów w Logcat, analizuje awarie zgłaszane przez App Quality Insights, aktualizuje zależności, a nawet umożliwia rozruch na podłączonym urządzeniu i interakcję z nim. Są to udokumentowane możliwości produktu, a nie spekulatywne demonstracje – ich lista znajduje się w przeglądzie funkcji Gemini. Pytanie praktyczne brzmi, jak je wykorzystać, aby nie stworzyć większej ilości pracy nad recenzją, niż oszczędzą.

Poniższe schematy pracy nadal okazują się przydatne w codziennej pracy z Androidem.

1. Przekaż Gemini mapę projektu raz

Najskuteczniejszy prompt często nie jest promptem – to krótki plik AGENTS.md zapisany razem z kodem.

Gemini pobiera pliki AGENTS.md z katalogu roboczego oraz ze wszystkich katalogów nadrzędnych. Dzięki temu można umieścić ogólne zasady w korzeniu repozytorium, a bardziej szczegółowe wytyczne w poszczególnych modułach. Ponieważ plik znajduje się obok kodu, cały zespół otrzymuje te same instrukcje za pośrednictwem kontroli wersji. Dokumentacja plików agentów zawiera szczegóły.

# 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.

W aplikacji wielomodułowej dodaj pliki lokalne tam, gdzie obowiązują różne zasady:

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

Tutaj liczy się zwięzłość. Warto uwzględnić: decyzje architektoniczne, miejsce rozpoczęcia każdego modułu, preferowane biblioteki testowe oraz obszary, których nikt nie powinien dotykać. Manifest składający się z 200 linii staje się po prostu przestarzałym kontekstem.

AGENTS.md są obsługiwane od wersji Android Studio Narwhal 4 Feature Drop Canary 4, natomiast Narwhal 3 Feature Drop wymagał pojedynczego pliku AGENT.md. Sprawdź wersję swojego IDE, zanim założysz, że plik ma jakikolwiek wpływ.

2. Użyj czterolinijowego streszczenia zadania

Dłuższe instrukcje nie są automatycznie lepsze. Niezawodny krótki format składa się z czterech części:

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.

Działa to, ponieważ rozwiązuje cztery powszechne niejednoznaczności: co musi ulec zmianie, gdzie szukać, co musi pozostać stabilne oraz co oznacza „zrobione”.

W przypadku pracy ryzykownej dodaj jeszcze jedną linię:

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

W przypadku zadań rutynowych pomiń formalności i poproś bezpośrednio o różnicę. Rozmiar zapytania powinien odpowiadać poziomowi ryzyka.

3. Utrzymuj wąski kontekst i oddzielne wątki

Dodawanie zbyt dużo kontekstu może pogorszyć odpowiedź, jeśli większość z niego nie ma związku z pytaniem. Gdy wystarczy informacji do rozważenia zmiany, dołącz ViewModel, model stanu, umowę repozytorium oraz pobliskie testy, pomijając resztę aplikacji. Android Studio umożliwia bezpośrednie dołączenie plików projektu do zapytania.

Utrzymuj oddzielne wątki dla różnych zadań, takich jak:

• błąd w odtwarzaniu
• migracja zależności
• wytwarzanie testów
• praca nad interfejsem Compose

Gemini pamięta historię rozmów. Google zaznacza, że osobne wątki mogą poprawić jakość odpowiedzi poprzez ograniczenie kontekstu do bieżącego tematu, a usunięcie przestarzałej historii pomaga, gdy rozmowa zboczyła z kursu. Zobacz Rozmowa z Gemini. Prosta zasada: jeśli twój następny prompt wymaga frazy „ignoruj wszystko powyżej”, otwórz nowy wątek.

4. Pozwól funkcji Next Edit Prediction wykonać nużące poprawki

Funkcja autodopowiadania działa w miejscu kursora. Next Edit Prediction idzie o krok dalej i przewiduje odpowiednie zmiany w innej części pliku lub projektu. Jest szczególnie przydatna po takich zmianach:

• nowa właściwość stanu interfejsu
• przenazwana instancja klasy zamkniętej
• zmodyfikowana sygnatura funkcji
• jeden z gałęzi powtarzającego się mapowania, który właśnie zaktualizowałeś
• ta sama kontrola obronna potrzebna w sąsiednim miejscu

Gdy edytor wyświetli napis Tab to move, pierwszy nacisk klawisza Tab przeniesie Cię do zasugerowanej zmiany, a drugi ją zastosuje. Jeśli przypuszczenie jest błędne, naciśnij Esc. Przewidywania można wstrzymać, a opóźnienie przed wysłaniem żądania można dostosować w ustawieniach edytora AI, co wyjaśnia strona Next Edit Prediction.

Automatyczne akceptowanie sugestii to zła przyzwyczajenie. Jedna szybka, błędna edycja przeniesiona do różnych plików nadal stanowi regresję.

5. Pytaj na podstawie informacji o błędach

Gdy synchronizacja Gradle się nie udaje lub aplikacja się zawiesza, IDE posiada już ustrukturyzowany kontekst. Użyj w tym momencie funkcji Ask Gemini zamiast wklejać niepotrzebne informacje do czatu.

Wewnątrz Logcat Gemini może otrzymać wspomniany ślad stosu i odpowiedzieć streszczeniem w prostym języku, prawdopodobnymi przyczynami oraz zalecanymi rozwiązaniami. Dokumentacja dotycząca integracji z Logcat omawia to zagadnienie. Skutecznie funkcjonuje również pytanie następcze kwestionujące udzieloną odpowiedź:

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.

To ostateczne polecenie zapobiega dwóm częstym skutkom typu „budowa w zielony sposób, ale kiepska naprawa”.

W przypadku niepowodzeń podczas budowy Gemini potrafi odróżnić główny błąd od całego łańcucha powstałych problemów. Naprawa pierwszego istotnego błędu jest zwykle szybsza niż analiza 40 kolejnych komunikatów błędowych.

6. Generowanie testów na podstawie zachowania, a nie implementacji

Klasy testów jednostkowych napisane w Kotlin lub Java, zawierające kod konfiguracyjny, mocki oraz poszczególne przypadki testowe, są w zasięgu Gemini, które dostosowuje je do aktualnej konfiguracji projektu. Google nadal określa cały ten proces jako wersję wstępną i dokumentuje go dla Android Studio Panda 4 Canary 3 lub nowszych wersji. Szczegóły znajdują się na stronie dotyczącej generowania testów jednostkowych.

Słaby wniosek wygląda w ten sposób:

Write tests for PlaybackViewModel.

Korzystny przykład wygląda tak:

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.

Przeczytaj dokładnie to, co jest napisane. Zapytaj, czy każdy test może zawieść z właściwego powodu. Częstymi problemami są zbyt łagodne mocki, twierdzenia odpowiadające ustawieniom początkowym, rzeczywiste opóźnienia, brak obsługi anulowania oraz testy powiązane z prywatnymi detalami implementacji.

Sztuczna inteligencja doskonale radzi sobie z eliminacją przeszkód wynikających z nadmiernych struktur pomocniczych, ale nie decyduje o twojej strategii testowania.

7. Generowanie wstępnych prezentacji Compose przed uruchomieniem emulatora

Wstępne prezentacje to tani sposób na uzyskanie informacji zwrotnych w Compose, ale tworzenie wiarygodnych danych do tych prezentacji to monotonna praca. Gemini stworzy prezentację dla pojedynczego komponentu Composable lub dla każdego z nich w pliku, zawierającym mockowe dane do parametrów prezentacji. Wynik otrzymujesz w formie różnic, które możesz zaakceptować lub odrzucić. Zobacz sekcję „Generowanie wstępnych prezentacji Compose”.

Sam „szczęśliwy scenariusz” niewiele dowodzi, dlatego poproś o zwięzłą macierz stanów:

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.

Przeglądy pełnią wtedy rolę tanich testów projektowych. Założenia dotyczące układu często zawodzą przy bardzo długich tytułach, pustym treści, obsłudze fokusa oraz dużych ekranach.

Dla Android TV należy wyraźnie poprosić o wersje z fokusem i bez niego. Układ, który dobrze funkcjonuje przy dotyku, może się rozpaść, gdy ktoś będzie nim poruszać za pomocą przycisków D-pad na pilocie.

8. Ustaw tryb Agenta na ograniczony pionowy fragment

W trybie Agenta Gemini może opracować plan złożonego zadania, edytować kilka plików jednocześnie, uruchamiać narzędzia, budować projekt i próbować ponownie w razie błędu. Możliwe jest również prowadzenie kilku rozmów równocześnie, jak opisano w dokumentacji do trybu Agenta.

Optymalnym rozwiązaniem jest ograniczony pionowy fragment, a nie „modernizacja aplikacji”. Na przykład:

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.

Zadanie takie jest na tyle duże, by przynieść korzyści z pracy między plikami, a na tyle małe, by można je było przejrzeć dokładnie.

Rozpoczynaj równoległe rozmowy tylko w przypadku niezależnych zadań, takich jak generowanie testów w jednym wątku, podczas gdy inny bada ostrzeżenie związane z budową aplikacji, które nie ma z tym związku. Dwa agenty pracujące nad nakładającymi się plikami mogą prowadzić do sprzecznych założeń.

9. Spraw, aby agent udowodnił zmianę w interfejsie użytkownika na urządzeniu

Różnica w kodzie nie dowodzi, że funkcja interfejsu użytkownika działa poprawnie.

Agent w Android Studio może wysłać zbudowaną wersję aplikacji na podłączone urządzenie, spojrzeć na ekran, zrobić zrzuty ekranu, przeczytać informacje z Logcat oraz sterować urządzeniem za pomocą narzędzi wejściowych. Po naprawie interfejsu użytkownika taka prośba o weryfikację zamknie cały proces:

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.

Zawsze angażuj osobę odpowiedzialną za zatwierdzanie w przypadku wszelkich działań związanych z logowaniem, zakupami, działaniami destrukcyjnymi lub danymi rzeczywistych użytkowników. Dostęp do urządzenia zwiększa możliwości agenta, ale to nie oznacza, że jest on godny zaufania.

10. Traktuj dane z awarii w środowisku produkcyjnym jako punkt wyjścia

W narzędziu App Quality Insights można poprosić Gemini o streszczenie awarii, wskazanie pliku, w którym się ona rozpoczęła, opisanie prawdopodobnej przyczyny oraz przygotowanie projektu zmiany w kodzie. Przewodnik Google dotyczący analizy awarii szczegółowo to omawia.

Dobre pytania do dalszych pytań to:

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?

Zawieszenia w produkcji często ujawniają problemy z synchronizacją i stanem, których nie da się wyjaśnić jedynie dzięki śladowi wywołań. Streszczenie oszczędza czas na czytanie, ale hipoteza nadal wymaga weryfikacji.

11. Aktualizuj zależności po jednej ograniczonej grupie naraz

Proces aktualizacji zależności może znaleźć kompatybilne wersje, zmodyfikować projekt, uporać się z błędami kompilacji, przeprowadzić testy i podsumować wyniki raportem zawierającym różnice pomiędzy wersjami każdego pliku. Jest to opisane w rozdziale „Automatyzacja aktualizacji zależności”.

To bardzo potężne narzędzie, więc należy zmniejszyć jego wpływ:

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.

Unikaj jednego ogromnego przeglądu typu „aktualizuj wszystko”, który łączy w jedno AGP, Kotlin, Compose, serializację, DI oraz dwadzieścia bibliotek. Różnice mogą pojawić się w ciągu kilku minut, ale ktoś nadal musi je zrozumieć.

Zabezpiecz kontekst przed optymalizacją promptów

Gdy jest włączone udostępnianie kontekstu projektu, plik .aiexclude decyduje o tym, co Gemini może odczytać. Jego składnia jest identyczna jak w pliku .gitignore, a każde zasadnicie odnosi się do folderu zawierającego ten plik oraz do wszystkich plików w nim znajdujących się. Funkcje AI nie mogą widzieć nic poza otwartym projektem i jego powiązanymi korzeniami systemu kontroli wersji, ale wrażliwe pliki w tych granicach powinny nadal być wykluczane na podstawie nazwy. Na stronie konfiguracji .aiexclude znajdują się instrukcje krok po kroku.

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

Te dwa pliki nie są wzajemnie zamienialne, więc nie traktuj ich w ten sposób. Dowiedz się, co dozwala twoja organizacja, zanim kod własnościowy lub dane produkcyjne trafią gdziekolwiek indziej. Na poziomie indywidualnym zasady ochrony prywatności Google stanowią, że prompty, wyniki, szczegóły użycia oraz opinie mogą być zbierane i przeglądane przez ludzkich recenzentów, a firma zaleca unikanie wprowadzania informacji poufnych lub osobistych. Warunki umów biznesowych mogą się różnić, więc przeczytaj zasady dotyczące twojego konta.

Zasada 60 sekund przy sprawdzaniu zmian w AI

Zanim zaakceptujesz różnicę w Gemini, zadaj sześć pytań:

1. Czy różnica dotyczy wyłącznie tego, o co prosiłeś?
2. Czy granice modułów i architektury są nienaruszone?
3. Czy została stworzona nowa API, zależność lub konwencja?
4. Czy błędy są rzeczywiście radzone sobie z nimi, czy jedynie ignorowane?
5. Czy nowe testy zawiodłyby, gdyby zachowanie się zmieniło?

Czy po zastosowaniu zmiany powinno się ponownie wykonać budowanie, testy oraz sprawdzenie na urządzeniu?

Jeśli odpowiedzi nie przychodzą szybko, zmiana jest zbyt duża, więc należy ją podzielić.

Proces pracy, który się kumuluje

Najlepiej sprawdza się prosty cykl:

Wyjaśnienie → planowanie → edycja → testowanie → uruchomienie → inspekcja → podsumowanie.

Gemini najbardziej pomaga, gdy skraca ten cykl w Android Studio. Najmniej pomaga, gdy dostarcza duży fragment kodu w Kotlinie, który nikt nie umieścił w repozytorium ani nie uruchomił.

Szybsze pisanie to nie źródło produktywności. Wiara przychodzi wcześniej: ślad wywołań, który w końcu ma sens, test, który się kompiluje, wizualizacja Compose z realistycznymi danymi, zrzut ekranu z urządzenia oraz różnica wystarczająco mała, by ją przeczytać.

Niech Gemini zajmie się aspektami technicznymi pomiędzy zamysłem a dowodem na to, że rozwiązanie funkcjonuje. Architektura, kompromisy i odpowiedzialność pozostają zadaniem inżyniera.