I spend a lot of my working day inside Android Studio.
And over the last year, one thing has changed significantly: Gemini has gone from being something I occasionally opened to something that is now part of my everyday Android development workflow.
I use it while starting projects, writing code, debugging builds, working with Compose, testing ideas, and researching unfamiliar APIs.
What I find interesting is that many Android developers have tried the Gemini chat inside Android Studio, but haven’t explored much beyond that.
There is a lot more there now.
Here are some of the Gemini features and workflows I find most useful.
1. Agent Mode handles a lot of my first draft
This is probably the biggest change in how I write Android code.
Instead of asking Gemini for one function, copying it into my project, fixing the imports, creating another file, and repeating the process, I can give Agent Mode a larger task.
For example:
Create a settings screen using Jetpack Compose with three sections: account, notifications, and appearance. Use a ViewModel for the state and add previews for the screen.
The important difference is that the agent can work across the project rather than treating every prompt as an isolated code snippet.
It can reason about the task, modify multiple files, and iterate on the implementation.
Google describes Agent Mode as one of the core AI capabilities available in Gemini in Android Studio.
I still review everything it generates.
But I increasingly treat Agent Mode as a first-draft engineer.
Let it create the initial implementation. Then I review the architecture, naming, state management, edge cases, and overall quality.
That is much faster than starting from an empty file.
2. I ask Gemini about errors before leaving Android Studio
This sounds simple, but it removes a surprising amount of friction.
When Gradle fails, sync breaks, or something ugly appears in Logcat, my old workflow looked something like this:
error → copy error → browser → search → Stack Overflow/GitHub → return to Android Studio
Now, Android Studio has Gemini integrated directly into places like build output and Logcat.
For build and sync errors, Gemini can help diagnose what went wrong. For runtime errors, you can use Ask Gemini directly from Logcat to get an explanation and possible next steps.
For complicated architectural bugs, I still need to investigate.
But for things like dependency problems, incorrect APIs, configuration mistakes, exceptions, and other routine issues, this can shorten the debugging loop considerably.
The biggest advantage isn’t necessarily that AI always knows the answer.
It’s that I don’t have to leave the context of my project to start investigating it.
3. Prompt Library means I don’t keep writing the same prompts
After using AI coding tools for a while, I noticed something:
I was typing the same instructions again and again.
Things like:
Write unit tests for the selected class. Cover success, error, loading, and edge cases.
Or:
Review this Composable for recomposition issues, state-hoisting problems, accessibility, and unnecessary allocations.
Android Studio’s Prompt Library solves exactly this problem.
You can save prompts you use frequently and recall them directly from the IDE. Prompts can exist at the IDE level or project level, and templates can even reference selected code or files.
One particularly useful detail is project-level prompts.
They’re stored with the project, which means a team can maintain useful AI prompts alongside the codebase.
So instead of everyone inventing their own:
“Please review this code…”
you can create repeatable prompts for things like:
- Compose reviews
- unit tests
- documentation
- code reviews
- architecture checks
- accessibility checks
There are also Rules, which let you define preferences that Gemini should apply across prompts — for example, preferred libraries, coding conventions, or “provide all code examples in Kotlin.”
That makes Gemini considerably more useful on real projects.
4. Parallel Agent conversations are surprisingly useful
I didn’t think I needed this until I started using it.
Android development rarely involves solving exactly one problem from beginning to end.
I might be:
- fixing a UI issue,
- investigating an API,
- refactoring a ViewModel,
- and experimenting with a different implementation
all during the same coding session.
Android Studio supports running multiple Agent Mode conversations in parallel.
So I can have one conversation working on:
Why is this Compose screen recomposing so frequently?
while another explores:
Refactor this repository to use Flow.
The conversations remain separate instead of turning one chat into a giant mixture of unrelated context.
It’s a small feature, but once you start using agents for larger tasks, it becomes very useful.
5. I occasionally check the metrics to see whether AI is actually helping
There’s a lot of discussion about whether AI makes developers 10%, 30%, or 10x more productive.
I’m less interested in guessing.
I like looking at actual usage.
For supported business environments, Gemini provides productivity metrics that can help teams understand things such as usage and acceptance of code recommendations. Google also provides Gemini Code Assist metrics through its Cloud tooling.
The goal isn’t:
“How can I make AI write 100% of my code?”
That’s the wrong metric.
What I want to understand is:
Where is AI actually removing work from my development process?
Maybe it is excellent at tests and boilerplate but doesn’t help much with architecture.
Maybe generated Compose code gets accepted frequently while business logic requires heavy editing.
Those are useful signals.
AI adoption becomes much more interesting when you measure where it helps instead of simply saying you’re “using AI.”
Reference: Google’s guide to measuring Gemini Code Assist adoption and impact.
6. Starting a project with AI removes the least interesting part
I build a lot of small Android projects.
Demos. Experiments. Conference examples. SDK prototypes. Random weekend ideas.
And starting another empty project gets repetitive.
Gemini in Android Studio can help create a new project from an idea, taking you from a description toward an initial app prototype. Google currently lists “Create a new project” as an Agent Mode capability.
Instead of:
New Project → Empty Activity → create packages → create screens → configure dependencies → create navigation → finally start building
I can start by describing what I actually want.
For example:
Build an Android app using Kotlin and Jetpack Compose that records short voice notes, displays them in a list, and has a detail screen. Use Material 3 and a simple repository architecture.
The generated project isn’t necessarily the architecture I will ship.
That’s fine.
I don’t need AI to make every architectural decision.
I want it to get me from:
idea → something running
as quickly as possible.
7. Gems are useful when I want the same Gemini “developer” again
This one isn’t Android Studio-specific, but it has become useful alongside my Android workflow.
Gems are customized versions of Gemini that you can configure for recurring tasks or areas of expertise.
Think of it as saving more than a prompt.
For example, you could create an Android Code Reviewer Gem and tell it:
- prefer Kotlin
- follow modern Android architecture guidance
- prefer Jetpack Compose
- check state hoisting
- look for lifecycle problems
- flag unnecessary recompositions
- check accessibility
- explain recommendations before rewriting code
Then, whenever you need that kind of review, you don’t have to reconstruct all of those instructions.
I find this especially useful for tasks where I want Gemini to behave consistently rather than just answer one question.
8. Gemini Notebook has become my second brain for technical research
Another tool that increasingly sits next to Android Studio for me is Gemini Notebook, previously known as NotebookLM.
Google renamed NotebookLM to Gemini Notebook in July 2026, while keeping it as a standalone research-focused product.
This is where I put the things that don’t belong inside my codebase.
For example:
- API documentation
- SDK documentation
- PDFs
- architecture notes
- meeting notes
- research material
- reference articles
- talk preparation
Instead of repeatedly searching through ten documents, I can create a notebook around the topic and ask questions grounded in those sources.
This becomes particularly useful when learning a large SDK.
I’ll load the relevant material into a notebook and use it as a research layer while the actual implementation happens inside Android Studio.
For me, the combination looks roughly like:
Gemini Notebook → understand the domain
Android Studio + Gemini → implement it
That’s a much better workflow than keeping 27 browser tabs open.
9. Journeys with Gemini changes how I think about UI testing
This is one of the Android-specific AI features I’m most interested in.
Journeys with Gemini lets you describe an end-to-end test using natural language.
Gemini then converts those steps into actions it performs against your app.
Instead of beginning with test implementation details, you can describe the user journey.
For example:
Launch the app.
Tap “Sign in.”
Enter a valid email and password.
Tap Continue.
Verify that the Home screen appears.
Open Settings.
Verify that the signed-in user’s email is displayed.
That description is much closer to how we naturally think about product behavior.
Google currently makes Journeys available through Studio Labs in supported Android Studio releases.
I’m not suggesting that this eliminates traditional testing.
What interests me is that AI can reduce the distance between:
“This is how the feature should behave”
and
“Let’s actually run that behavior against the app.”
For Android teams, that could make end-to-end testing much more approachable.
One more thing: use /plan before large changes
This has become another useful habit.
When the task is sufficiently complicated, I don’t immediately ask the agent to start editing files.
I ask it to plan first.
Recent Android Studio releases include improvements to Planning Mode, and you can explicitly invoke it with:
/plan
or simply ask the agent to generate a plan before implementation.
For example:
/plan Migrate this screen from LiveData + XML to StateFlow + Jetpack Compose. Preserve the existing ViewModel behavior and don’t change the repository API.
I can review the approach first.
Then let the agent implement it.
For larger refactors, this gives me much more confidence than simply telling an agent:
“Convert this to Compose.”
The bigger shift
The interesting part isn’t any single Gemini feature.
It’s how they connect.
My Android workflow is increasingly becoming:
Idea → Agent Mode
Large change → Planning Mode
Repeated instruction → Prompt Library / Rules
Error → Gemini inside Build or Logcat
Research → Gemini Notebook
Specialized recurring task → Gem
User flow testing → Journeys
And I still write code manually all the time.
That’s an important point.
The goal isn’t to stop coding.
The goal is to spend less time on the parts of development that don’t require me to personally type every character.
A year ago, I mostly thought of Gemini as a chat box inside Android Studio.
Today, that description feels incomplete.
It is gradually becoming another layer of the Android development environment — one that can understand the project, modify code, investigate errors, generate UI, help with testing, and participate in much larger development tasks.
And Android Studio’s AI capabilities are still moving quickly. Google currently highlights Agent Mode, Compose UI generation and transformation, debugging integrations, Planning Mode, App Quality Insights, Journeys, MCP support, and other agentic capabilities across its Android AI tooling.
If you’re using Gemini in Android Studio only to ask:
“Write this Kotlin function for me”
you’re probably using the least interesting part of it.
Start experimenting with the rest of the workflow.
That’s where I’ve found the real productivity gains.
I Use Gemini Every Day as an Android Developer -Here Are My Favorite Tips and Tricks was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.