11 Gemini Workflows for Android Studio: Tests, Previews, Agent Mode and Crashes

Android developers rarely need one more list of clever AI prompts. What helps is fewer context switches, quicker feedback loops, and less time sunk into mechanical chores. That's where Gemini in Android Studio earns its place.

Don't treat it as a teammate who can own a feature while you walk away. Think of it as a fast pair programmer inside the IDE. It's good at exploring unfamiliar code, drafting repetitive work, reading noisy errors, and chaining several small steps into one diff you can review.

Precision is what separates the two. A request such as "build this feature" is too loose to act on, whereas asking Gemini to follow a state flow, suggest the smallest fix, run the relevant tests and show you the diff describes real engineering work.

As of September 2026, Gemini in Android Studio works across files in Agent Mode, runs parallel conversations, generates unit tests and Compose previews, helps with build and Logcat errors, inspects App Quality Insights crashes, updates dependencies, and can even deploy to a connected device and interact with it. These are documented product capabilities, not speculative demos, and the Gemini feature overview lists them. The practical question is how to use them without producing more review work than they save.

The workflows below are the ones that keep paying off in daily Android work.

1. Give Gemini a project map once

The highest-return prompt often isn't a prompt. It's a short AGENTS.md file committed alongside the code.

Gemini picks up AGENTS.md files in the working directory and in every parent above it. That lets you put general rules at the repository root and add narrower guidance inside single modules. Because the file is stored next to the code, your whole team gets the same instructions through version control. The agent files documentation has the details.

# 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 a multi-module app, add local files wherever the rules differ:

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

Brevity matters here. Worth including: architecture decisions, where each module starts, which test libraries you prefer, and the areas nobody should touch. A manifesto of 200 lines just becomes outdated context.

Check one version detail. Google documents AGENTS.md support from Android Studio Narwhal 4 Feature Drop Canary 4 onward, while the Narwhal 3 Feature Drop expected a singular AGENT.md. Look at your IDE version before assuming the file has any effect.

2. Use a four-line task brief

Longer prompts aren't automatically better. A dependable short format has four parts:

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.

It works because it clears up four common ambiguities: what has to change, where to look, what must stay stable, and what "done" means.

For risky work, add one more line:

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

For routine tasks, skip the ceremony and ask for the diff directly. The size of the prompt should match the risk.

3. Keep context narrow and threads separate

Piling on context can make an answer worse if most of it has nothing to do with the question. When it's enough to reason about the change, attach the ViewModel, the state model, the repository contract and nearby tests, and leave out the rest of the application. Android Studio lets you attach project files straight to a query.

Keep separate threads for separate tasks, such as:

• a playback bug
• a dependency migration
• test generation
• Compose UI work

Gemini remembers conversation history. Google notes that separate threads can raise response quality by limiting context to the current topic, and that clearing stale history helps once a chat has drifted. See Chat with Gemini. A simple rule: if your next prompt needs the phrase "ignore everything above," open a new thread.

4. Let Next Edit Prediction do the tedious follow-up edit

Autocomplete works at the cursor. Next Edit Prediction goes a step further and guesses the related change somewhere else in the file or the project. It shines right after changes like these:

• a new property on a UI state
• a renamed sealed-class case
• a modified function signature
• one branch of a repeated mapping that you just updated
• the same defensive check needed in a neighboring spot

Once the editor displays Tab to move, a first Tab takes you to the suggested change and a second one applies it. If the guess is wrong, press Esc. Predictions can be paused, and the delay before a request fires is adjustable in the AI editor settings, which the Next Edit Prediction page explains.

Accepting suggestions by reflex is a bad habit. One quick, wrong edit copied across files is still a regression.

5. Ask from the error surface

When Gradle sync fails or the app crashes, the IDE already holds structured context. Use the Ask Gemini action right there instead of pasting noise into a chat.

Inside Logcat, Gemini can receive the stack trace in question and reply with a summary in plain language, probable causes and suggested fixes. The Logcat integration docs cover it. A follow-up that questions the answer works well:

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.

That final instruction heads off two common "green build, bad fix" outcomes.

With build failures, have Gemini tell the root error apart from the chain of failures it caused. Fixing the earliest meaningful one is normally quicker than chasing 40 follow-on messages.

6. Generate tests from behavior, not implementation

Complete unit-test classes in Kotlin or Java, with setup code, mocks and individual cases, are within Gemini's reach, and it adapts them to how the project is already configured. Google still calls the whole flow a preview and documents it for Android Studio Panda 4 Canary 3 or newer. The unit test generation page has details.

A weak request looks like this:

Write tests for PlaybackViewModel.

A useful one looks like this:

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.

Review whatever it writes. Ask whether each test could fail for the right reason. Common problems are relaxed mocks, assertions that echo the setup, real delays, no coverage of cancellation, and tests welded to private implementation details.

AI is excellent at removing scaffolding friction, but it doesn't own your test strategy.

7. Generate Compose previews before opening the emulator

Previews are a cheap way to get feedback in Compose, but writing believable preview data is dull work. Gemini will create a preview for a single Composable or for each eligible one in a file, with mock data for the preview parameters included. You see the output as a diff that you can accept or reject. See Generate Compose previews.

The happy path alone proves little, so request a compact matrix of states:

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 then act as cheap design tests. Layout assumptions tend to crack on very long titles, empty content, focus handling and large screens.

For Android TV, explicitly ask for focused and unfocused variants. A layout that works fine by touch can fall apart once someone navigates it with a remote's D-pad.

8. Point Agent Mode at a bounded vertical slice

In Agent Mode, Gemini can draft a plan for a multi-step job, edit across several files, run tools, build the project and retry when something fails. Running several conversations side by side is possible too, as the Agent Mode documentation describes.

The sweet spot is a bounded vertical slice, never "modernize the app." For example:

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.

A task like that is big enough to benefit from cross-file work and small enough to review.

Run parallel conversations only for independent jobs, such as generating tests in one thread while another looks into an unrelated build warning. Two agents working on overlapping files invite conflicting assumptions.

9. Make the agent prove a UI change on a device

A code diff doesn't prove a UI feature works.

The agent in Android Studio can push a build to a connected device, look at the screen, capture screenshots, read Logcat and drive the device through input tools. After a UI fix, a verification prompt like this closes the loop:

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.

Keep a person in the approval loop for anything involving sign-in, purchases, destructive actions or real user data. Access to a device makes the agent more capable, and that is not the same as making it trustworthy.

10. Treat production crash data as a starting point

Inside App Quality Insights you can have Gemini summarize a crash, point to the file it started in, describe the likely cause and draft a code change. Google's crash analysis guide walks through it.

Good follow-up questions include:

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?

Production crashes often reveal timing and state problems that one stack trace can't explain. The summary saves reading time, but the hypothesis still needs validation.

11. Update dependencies one bounded group at a time

The dependency workflow can find compatible updates, modify the project, work through resulting build errors, run the tests and finish with a report that includes diffs per file. It is described in Automate dependency updates.

That's powerful, so shrink the blast radius:

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.

Avoid one giant "update everything" review that lumps AGP, Kotlin, Compose, serialization, DI and twenty libraries together. The diff may appear in minutes, but somebody still has to make sense of it.

Protect context before optimizing prompts

When project context sharing is on, a .aiexclude file decides what Gemini can read. Its syntax matches .gitignore, and each rule applies to the folder containing the file and everything beneath it. The AI features can't see anything outside the open project and its attached VCS roots, but sensitive files inside those limits should still be excluded by name. The .aiexclude setup page has the steps.

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

The two files aren't interchangeable, so don't treat them that way. Find out what your organization allows before proprietary code or production data goes anywhere. On the individual tier, Google's privacy notice says prompts, outputs, usage details and feedback can be collected and read by human reviewers, and it advises against entering confidential or personal information. Business agreements may differ, so read the terms that cover your account.

A 60-second rule for reviewing AI changes

Before accepting a Gemini diff, ask six questions:

1. Is the diff limited to what you asked for?
2. Are module and architecture boundaries intact?
3. Has it made up an API, a dependency or a convention?
4. Are errors truly handled, or merely swallowed?
5. Would the new tests fail if the behavior broke?
6. Do the build, the test run and the device check back up the change?

If those answers don't come quickly, the change is too big, so split it.

The workflow that compounds

A simple loop works best:

Explain → plan → edit → test → run → inspect → summarize.

Gemini helps most when it shortens that loop inside Android Studio. It helps least when it hands over a big block of plausible Kotlin that nobody has anchored in the repository or run.

Typing faster isn't where the productivity comes from. Trust arrives earlier: a stack trace that finally makes sense, a test that compiles, a Compose preview with realistic data, a screenshot from the device, and a diff small enough to read.

Let Gemini cover the mechanical stretch between an intention and the proof that it works. Architecture, trade-offs and accountability remain the engineer's job.