11 Gemini-Workflows für Android Studio: Tests, Previews, Agent Mode und Abstürze

Android-Entwickler brauchen selten noch eine Liste cleverer KI-Prompts. Was wirklich hilft, sind weniger Kontextwechsel, schnellere Feedbackschleifen und weniger Zeit für mechanische Fleißarbeit. Genau da verdient sich Gemini in Android Studio seinen Platz.

Behandeln Sie es nicht wie einen Kollegen, dem man ein Feature überlässt und dann geht. Sehen Sie es eher als schnellen Pair-Programming-Partner in der IDE. Es erkundet unbekannten Code gut, entwirft repetitive Arbeit, liest unübersichtliche Fehlermeldungen und verkettet mehrere kleine Schritte zu einem Diff, den Sie prüfen können.

Der Unterschied liegt in der Präzision. Eine Anfrage wie "bau dieses Feature" ist zu vage, um damit zu arbeiten. Wer Gemini dagegen bittet, einem State-Flow zu folgen, den kleinsten Fix vorzuschlagen, die passenden Tests laufen zu lassen und den Diff zu zeigen, beschreibt echte Engineering-Arbeit.

Stand September 2026 arbeitet Gemini in Android Studio im Agent Mode über mehrere Dateien hinweg, führt parallele Unterhaltungen, generiert Unit-Tests und Compose-Previews, hilft bei Build- und Logcat-Fehlern, untersucht Abstürze aus App Quality Insights, aktualisiert Abhängigkeiten und kann sogar auf ein verbundenes Gerät deployen und damit interagieren. Das sind dokumentierte Produktfunktionen, keine spekulativen Demos, und die Gemini-Funktionsübersicht listet sie auf. Die praktische Frage ist, wie man sie nutzt, ohne mehr Review-Aufwand zu erzeugen, als sie einsparen.

Die folgenden Workflows zahlen sich im Android-Alltag immer wieder aus.

1. Geben Sie Gemini einmal eine Projektkarte

Der Prompt mit dem größten Ertrag ist oft gar kein Prompt, sondern eine kurze AGENTS.md-Datei, die neben dem Code eingecheckt ist.

Gemini liest AGENTS.md-Dateien im Arbeitsverzeichnis und in jedem übergeordneten Verzeichnis. So können allgemeine Regeln ins Repository-Root und engere Vorgaben in einzelne Module. Weil die Datei neben dem Code liegt, bekommt das ganze Team über die Versionsverwaltung dieselben Anweisungen. Details stehen in der Dokumentation zu 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.

In einer Multi-Modul-App legen Sie lokale Dateien überall dort an, wo die Regeln abweichen:

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

Kürze ist hier entscheidend. Hinein gehören Architekturentscheidungen, der Einstiegspunkt jedes Moduls, bevorzugte Testbibliotheken und die Bereiche, die niemand anfassen soll. Ein Manifest mit 200 Zeilen wird schnell zu veraltetem Kontext.

Prüfen Sie ein Versionsdetail. Google dokumentiert die Unterstützung für AGENTS.md ab Android Studio Narwhal 4 Feature Drop Canary 4, während der Narwhal 3 Feature Drop eine einzelne AGENT.md erwartete. Schauen Sie auf Ihre IDE-Version, bevor Sie annehmen, dass die Datei überhaupt wirkt.

2. Nutzen Sie ein Aufgabenbriefing in vier Zeilen

Längere Prompts sind nicht automatisch besser. Ein verlässliches Kurzformat hat vier Teile:

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.

Es funktioniert, weil es vier typische Unklarheiten ausräumt: was sich ändern muss, wo man suchen soll, was stabil bleiben muss und was "fertig" bedeutet.

Bei riskanter Arbeit kommt eine Zeile dazu:

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

Bei Routineaufgaben lassen Sie die Zeremonie weg und fragen direkt nach dem Diff. Die Größe des Prompts sollte zum Risiko passen.

3. Halten Sie den Kontext schmal und Threads getrennt

Mehr Kontext kann eine Antwort verschlechtern, wenn das meiste davon mit der Frage nichts zu tun hat. Wenn es reicht, um über die Änderung nachzudenken, hängen Sie das ViewModel, das State-Modell, den Repository-Vertrag und die benachbarten Tests an und lassen den Rest der App weg. Android Studio erlaubt es, Projektdateien direkt an eine Anfrage anzuhängen.

Führen Sie getrennte Threads für getrennte Aufgaben, etwa:

• einen Playback-Bug
• eine Abhängigkeitsmigration
• Testgenerierung
• Compose-UI-Arbeit

Gemini merkt sich den Gesprächsverlauf. Google weist darauf hin, dass getrennte Threads die Antwortqualität verbessern können, weil der Kontext auf das aktuelle Thema beschränkt bleibt, und dass es hilft, veralteten Verlauf zu löschen, wenn ein Chat abgedriftet ist. Siehe Chat with Gemini. Eine einfache Regel: Wenn Ihr nächster Prompt "ignoriere alles oben" enthalten müsste, öffnen Sie einen neuen Thread.

4. Überlassen Sie die lästige Folgeänderung der Next Edit Prediction

Autovervollständigung arbeitet an der Cursorposition. Next Edit Prediction geht einen Schritt weiter und errät die zugehörige Änderung an anderer Stelle in der Datei oder im Projekt. Besonders stark ist sie direkt nach Änderungen wie diesen:

• eine neue Property in einem UI-State
• ein umbenannter Fall einer Sealed Class
• eine geänderte Funktionssignatur
• ein Zweig eines wiederholten Mappings, den Sie gerade angepasst haben
• dieselbe defensive Prüfung, die an einer benachbarten Stelle nötig ist

Sobald der Editor Tab to move anzeigt, springt ein erstes Tab zur vorgeschlagenen Änderung und ein zweites übernimmt sie. Liegt die Vorhersage daneben, drücken Sie Esc. Vorhersagen lassen sich pausieren, und die Verzögerung bis zur Anfrage ist in den Einstellungen des KI-Editors einstellbar; die Seite zu Next Edit Prediction erklärt das.

Vorschläge reflexartig anzunehmen ist eine schlechte Angewohnheit. Eine schnelle, falsche Änderung, die über mehrere Dateien kopiert wird, bleibt eine Regression.

5. Fragen Sie direkt an der Fehlerstelle

Wenn der Gradle-Sync fehlschlägt oder die App abstürzt, hat die IDE bereits strukturierten Kontext. Nutzen Sie dort die Aktion Ask Gemini, statt Rauschen in einen Chat zu kopieren.

In Logcat kann Gemini den betreffenden Stacktrace erhalten und mit einer verständlichen Zusammenfassung, wahrscheinlichen Ursachen und Lösungsvorschlägen antworten. Die Doku zur Logcat-Integration beschreibt das. Gut funktioniert eine Nachfrage, die die Antwort hinterfragt:

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.

Die letzte Anweisung verhindert zwei häufige Ergebnisse nach dem Muster "Build grün, Fix schlecht".

Bei Build-Fehlern lassen Sie Gemini den eigentlichen Fehler von der Kette der Folgefehler trennen. Den frühesten aussagekräftigen Fehler zu beheben geht normalerweise schneller, als 40 Folgemeldungen hinterherzujagen.

6. Generieren Sie Tests aus Verhalten, nicht aus Implementierung

Vollständige Unit-Test-Klassen in Kotlin oder Java mit Setup-Code, Mocks und einzelnen Fällen liegen in Geminis Reichweite, und es passt sie an die bestehende Projektkonfiguration an. Google bezeichnet den gesamten Ablauf allerdings noch als Preview und dokumentiert ihn für Android Studio Panda 4 Canary 3 oder neuer. Details stehen auf der Seite zur Unit-Test-Generierung.

Eine schwache Anfrage sieht so aus:

Write tests for PlaybackViewModel.

Eine nützliche sieht so aus:

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.

Prüfen Sie alles, was es schreibt. Fragen Sie, ob jeder Test aus dem richtigen Grund fehlschlagen könnte. Typische Probleme sind zu lockere Mocks, Assertions, die nur das Setup wiederholen, echte Verzögerungen, fehlende Abdeckung von Abbruch und Tests, die fest an private Implementierungsdetails geschweißt sind.

KI nimmt Ihnen die Reibung beim Gerüstbau hervorragend ab, aber Ihre Teststrategie gehört ihr nicht.

7. Generieren Sie Compose-Previews, bevor Sie den Emulator öffnen

Previews sind ein günstiger Weg zu Feedback in Compose, aber glaubwürdige Preview-Daten zu schreiben ist mühsam. Gemini erstellt eine Preview für ein einzelnes Composable oder für jedes geeignete in einer Datei, inklusive Mock-Daten für die Preview-Parameter. Das Ergebnis sehen Sie als Diff, den Sie annehmen oder ablehnen können. Siehe Generate Compose previews.

Der Happy Path allein beweist wenig, also fordern Sie eine kompakte Matrix von Zuständen an:

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.

Previews werden so zu günstigen Designtests. Layout-Annahmen brechen meist bei sehr langen Titeln, leerem Inhalt, Fokusverhalten und großen Bildschirmen.

Für Android TV fragen Sie ausdrücklich nach fokussierten und nicht fokussierten Varianten. Ein Layout, das per Touch einwandfrei funktioniert, kann zerfallen, sobald jemand mit dem D-Pad der Fernbedienung navigiert.

8. Richten Sie den Agent Mode auf einen begrenzten vertikalen Ausschnitt

Im Agent Mode kann Gemini einen Plan für eine mehrstufige Aufgabe entwerfen, mehrere Dateien bearbeiten, Tools ausführen, das Projekt bauen und es bei Fehlern erneut versuchen. Auch mehrere Unterhaltungen nebeneinander sind möglich, wie die Agent-Mode-Dokumentation beschreibt.

Der ideale Einsatz ist ein begrenzter vertikaler Ausschnitt, niemals "modernisiere die App". Zum Beispiel:

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.

Eine solche Aufgabe ist groß genug, um von dateiübergreifender Arbeit zu profitieren, und klein genug für ein Review.

Parallele Unterhaltungen nur für unabhängige Aufgaben: etwa Tests in einem Thread generieren, während ein anderer einer unabhängigen Build-Warnung nachgeht. Zwei Agenten an überlappenden Dateien laden zu widersprüchlichen Annahmen ein.

9. Lassen Sie den Agenten eine UI-Änderung auf dem Gerät belegen

Ein Code-Diff beweist nicht, dass ein UI-Feature funktioniert.

Der Agent in Android Studio kann einen Build auf ein verbundenes Gerät spielen, den Bildschirm betrachten, Screenshots machen, Logcat lesen und das Gerät über Eingabe-Tools bedienen. Nach einem UI-Fix schließt ein Verifizierungs-Prompt wie dieser die Schleife:

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.

Bei allem, was Anmeldung, Käufe, destruktive Aktionen oder echte Nutzerdaten betrifft, bleibt ein Mensch in der Freigabeschleife. Gerätezugriff macht den Agenten fähiger, aber nicht vertrauenswürdiger.

10. Betrachten Sie Absturzdaten aus der Produktion als Ausgangspunkt

In App Quality Insights kann Gemini einen Absturz zusammenfassen, die Datei benennen, in der er begann, die wahrscheinliche Ursache beschreiben und eine Codeänderung entwerfen. Googles Leitfaden zur Absturzanalyse geht das durch.

Gute Nachfragen sind zum Beispiel:

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?

Produktionsabstürze zeigen oft Timing- und State-Probleme, die ein einzelner Stacktrace nicht erklären kann. Die Zusammenfassung spart Lesezeit, aber die Hypothese muss trotzdem validiert werden.

11. Aktualisieren Sie Abhängigkeiten in jeweils einer begrenzten Gruppe

Der Abhängigkeits-Workflow findet kompatible Updates, ändert das Projekt, arbeitet die daraus folgenden Build-Fehler ab, führt die Tests aus und liefert am Ende einen Bericht mit Diffs pro Datei. Beschrieben ist das unter Automate dependency updates.

Das ist mächtig, also verkleinern Sie den Wirkungsradius:

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.

Vermeiden Sie ein riesiges "alles aktualisieren"-Review, das AGP, Kotlin, Compose, Serialisierung, DI und zwanzig Bibliotheken zusammenwirft. Der Diff ist vielleicht in Minuten da, aber irgendwer muss ihn noch verstehen.

Schützen Sie den Kontext, bevor Sie Prompts optimieren

Ist das Teilen von Projektkontext aktiviert, bestimmt eine .aiexclude-Datei, was Gemini lesen darf. Die Syntax entspricht .gitignore, und jede Regel gilt für den Ordner mit der Datei und alles darunter. Die KI-Funktionen sehen nichts außerhalb des geöffneten Projekts und seiner angehängten VCS-Roots, aber sensible Dateien innerhalb dieser Grenzen sollten trotzdem namentlich ausgeschlossen werden. Die Schritte stehen auf der Einrichtungsseite für .aiexclude.

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

Die beiden Dateien sind nicht austauschbar, also behandeln Sie sie auch nicht so. Klären Sie, was Ihre Organisation erlaubt, bevor proprietärer Code oder Produktionsdaten irgendwohin gehen. Für den Einzeltarif sagt Googles Datenschutzhinweis, dass Prompts, Ausgaben, Nutzungsdaten und Feedback erfasst und von menschlichen Prüfern gelesen werden können, und rät davon ab, vertrauliche oder persönliche Informationen einzugeben. Geschäftsverträge können abweichen, also lesen Sie die Bedingungen, die für Ihr Konto gelten.

Eine 60-Sekunden-Regel für das Review von KI-Änderungen

Bevor Sie einen Gemini-Diff annehmen, stellen Sie sechs Fragen:

1. Beschränkt sich der Diff auf das, worum Sie gebeten haben?
2. Sind Modul- und Architekturgrenzen intakt?
3. Hat es eine API, eine Abhängigkeit oder eine Konvention erfunden?
4. Werden Fehler wirklich behandelt oder nur verschluckt?
5. Würden die neuen Tests fehlschlagen, wenn das Verhalten kaputtginge?
6. Stützen Build, Testlauf und Geräteprüfung die Änderung?

Kommen diese Antworten nicht schnell, ist die Änderung zu groß. Teilen Sie sie auf.

Der Workflow, der sich aufsummiert

Am besten funktioniert eine einfache Schleife:

Erklären → planen → bearbeiten → testen → ausführen → prüfen → zusammenfassen.

Gemini hilft am meisten, wenn es diese Schleife innerhalb von Android Studio verkürzt. Am wenigsten hilft es, wenn es einen großen Block plausibel aussehenden Kotlin-Codes liefert, den niemand im Repository verankert oder ausgeführt hat.

Die Produktivität kommt nicht vom schnelleren Tippen. Vertrauen stellt sich früher ein: ein Stacktrace, der endlich Sinn ergibt, ein Test, der kompiliert, eine Compose-Preview mit realistischen Daten, ein Screenshot vom Gerät und ein Diff, der klein genug zum Lesen ist.

Lassen Sie Gemini die mechanische Strecke zwischen Absicht und dem Nachweis, dass es funktioniert, übernehmen. Architektur, Abwägungen und Verantwortung bleiben Aufgabe des Engineers.