GitHub Copilot with Android Studio

Android Studio occupies an unusual position. It is built on the JetBrains platform, so the Copilot plugin applies — but it is Google’s IDE, it ships Google’s own AI assistant, and that assistant has a feature called “Agent Mode” which is not the Copilot feature of the same name.

That combination generates a lot of confusion, so this lesson starts with what is actually verifiable rather than what can be inferred.

Verifying support rather than assuming it

Android Studio is based on IntelliJ IDEA, so it is tempting to reason that anything working in IntelliJ works here. That inference is usually right and is not evidence. Google maintains its own fork with its own release cadence, its own platform version numbers and its own bundled tooling, and support could reasonably have diverged.

So it was checked directly, from two sources that do not depend on each other.

GitHub’s own compatibility list. GitHub’s documentation of which JetBrains IDEs the Copilot extension supports names Android Studio explicitly — second in the list, immediately after IntelliJ IDEA.

The JetBrains Marketplace. The compatible-products endpoint for the GitHub Copilot plugin (plugin ID 17718, published by GitHub) returns ANDROID_STUDIO first in its list of product codes.

What “supported” means here

There is no Android-specific Copilot implementation. Android Studio installs the same plugin as IntelliJ, PyCharm and the rest, which has three consequences worth being explicit about.

Feature support matches JetBrains exactly. Agent mode, edit mode, checkpoints, code review, MCP and indexing are fully supported. Custom instructions, prompt files, custom agents, agent skills, next edit suggestions, vision and BYOK are in public preview — here as everywhere else in the family.

There are no Android-specific Copilot features. No Gradle-aware agent, no Compose-specific commands, no emulator integration. Copilot does not know what a Fragment is beyond what it has read.

Everything in the JetBrains lesson applies. Installation, the device-code sign-in, slash commands, key bindings and preview caveats are identical.

Installing

1. In Android Studio, open Settings (or Preferences on macOS) and go to Plugins.
2. Select the Marketplace tab and search for GitHub Copilot.
3. Confirm the publisher is GitHub before installing — the name is common enough to be worth a glance.
4. Click Install, then Restart IDE.
5. After restarting, go to Tools → GitHub Copilot → Login to GitHub.
6. Click Copy and Open, paste the device code into the page that opens, click Continue, and authorise.

Copilot and Gemini side by side

Android Studio ships Gemini as its built-in AI assistant. It is not a plugin you chose, it is part of the IDE, and it does several things Copilot does not: generating Compose previews, explaining build errors with Android context, assisting with resource files, and integrating with Android-specific tooling.

Gemini also has a feature Google calls Agent Mode.

Running both is entirely possible. Two rules make it comfortable.

Pick one for inline completion. Two assistants offering grey-text suggestions in the same editor is genuinely confusing — suggestions appear from two sources with different accept behaviour, and you stop being able to predict what Tab does. Disable one, in that plugin’s own settings.

Choose per task rather than per allegiance. Gemini is tightly integrated with Android tooling and knows the platform’s own conventions. Copilot connects to the rest of the GitHub platform — the same instructions, the same custom agents, the same review workflow you use elsewhere — and is the same assistant you have in your other editors. Those are different strengths.

Android-specific context that helps

Copilot has no Android awareness beyond what it reads, so what you keep open matters more than usual.

build.gradle.kts (module-level). Android builds are configuration-heavy: compileSdk, minSdk, build variants, dependency versions. Without it, answers drift towards whatever SDK level is most common in training data — which for Android is a moving target with a long tail of obsolete guidance.

The XML resources you are referencing. Layouts, strings, styles and navigation graphs are referenced by generated identifiers. A file that does not show the resource leaves the model to invent an ID that will not resolve.

Both sides of a Compose boundary. When asking about a composable, have its state holder or view model open. Compose questions are usually questions about state, and state usually lives elsewhere.

Where generated Android code most often goes wrong

Four patterns worth watching for specifically, because all four compile.

Deprecated APIs. Android’s API surface has changed repeatedly, and the model has read all of it. AsyncTask, the old permissions flow, pre-Compose view patterns — all appear fluently. Lint catches much of this; read the warnings.

Lifecycle and scope. Coroutines launched in the wrong scope leak or get cancelled at the wrong moment. viewModelScope, lifecycleScope and a rememberCoroutineScope are not interchangeable, and the correct choice depends on what should happen when the screen goes away — a question about your intent, not about the code.

Permissions. Generated code that touches location, camera or storage may omit the runtime permission request, the manifest entry, or the modern flow. All three are needed and none of them is in the file you were looking at.

Compose recomposition. Code that reads correct and recomposes far more than it should — unstable parameters, state read at the wrong level, work done in the composable body. This one does not show up as a warning; it shows up as jank.

A realistic session

Adding a screen to an existing Compose app, showing where each assistant belongs.

Start with the state, not the UI. Ask for the state model before the composable — what the screen can be in, what it needs from the data layer, what happens while loading and on failure. A sealed interface or a data class with the loading and error cases named is a better foundation than a composable written first and retrofitted.

Let the ViewModel come next. With the state type declared and Hilt already in the project, this is heavily constrained. The thing to check is scope: data work belongs in viewModelScope, and a suggestion using anything else is a bug that will not announce itself.

Write the composable signature yourself. Parameters, including the state and the callbacks. Stateless-by-default is a decision the model will not make for you unless the signature already reflects it, and the signature is two lines.

Use Gemini for the preview. This is the clearest division of labour available — Compose preview generation is a first-party Android Studio feature and Copilot has no equivalent.

Ask Copilot about recomposition. As above. It is the failure mode that will not appear in lint, in the compiler, or in a preview.

Run it on a device. Not an emulator screenshot in a chat response. Jank, lifecycle behaviour and permission flows are things you observe, and no assistant is reporting on them from the inside.

The useful pattern is that neither assistant covered the whole task, and the steps that mattered most — the state model, the scope choice, running it — were decisions rather than generation.

Repository instructions for an Android project

Custom instructions are in public preview in JetBrains, so keep them concrete:

# Copilot instructions

## Project
- Kotlin, Jetpack Compose, minSdk 26, targetSdk 36.
- Architecture: MVVM. UI state is exposed as StateFlow from the ViewModel.
- DI is Hilt. Do not construct dependencies manually in composables.

## Rules
- No AsyncTask, no LiveData in new code, no findViewById.
- Coroutines launch in viewModelScope for data work, never GlobalScope.
- Strings live in resources, not in Kotlin source.
- Composables are stateless where possible; hoist state to the caller.

Each line is checkable against the output. A GlobalScope or a hard-coded string is immediately visible as a violation, which is exactly what makes the instruction worth writing.

Versions and the review cadence

Android Studio’s release naming is its own. Stable releases carry animal names and a year-based version — the current stable line is Quail (2026.1.x) — and each maps to some IntelliJ platform version underneath, which is the number plugin compatibility is actually expressed in.

Because Android Studio, the Copilot plugin and Gemini all move independently, the facts on this page carry a 30-day review interval. Three things are worth re-checking if you are reading this well after the verified date: whether Android Studio is still on GitHub’s compatibility list, whether any JetBrains preview feature has reached general availability, and whether Gemini’s feature set has shifted the sensible division of labour.

Security

Where Copilot fits an Android team

A brief, practical framing for teams rather than individuals.

Android work splits roughly into platform work — lifecycle, Compose, permissions, build configuration — and ordinary application logic. Gemini is better positioned on the first, because it ships with the IDE and tracks the SDK. Copilot is stronger on the second, and on everything that touches the wider GitHub workflow: the same repository instructions your backend uses, the same review process, the same custom agents.

For a team already on GitHub, that argues for Copilot as the default assistant with Gemini kept for platform-specific help, rather than choosing one outright. The cost of running both is the inline-completion collision, which is a settings change, not an architectural problem.

Frequently asked questions

Is GitHub Copilot officially supported in Android Studio? Yes. GitHub’s own compatibility documentation lists it, and the JetBrains Marketplace lists ANDROID_STUDIO among the plugin’s compatible products. Both were verified on 20 August 2026.

Is there a separate Copilot for Android? No. It is the same JetBrains plugin used across the family.

Do I get Android-specific Copilot features? No. Feature support matches the JetBrains row of the matrix exactly.

Can I run Copilot and Gemini at the same time? Yes. Disable inline completion in one of them, or you will get suggestions from both.

Is Gemini’s “Agent Mode” the same as Copilot’s agent mode? No. Similar concept, different products, different behaviour. Instructions for one do not apply to the other.

The plugin will not install — why? Almost always an Android Studio build older than the plugin’s minimum. Update the IDE and install from the in-IDE Marketplace.

Which should I use for Android work? That depends on whether your work is Android-only. Gemini knows the platform better; Copilot connects to the rest of the GitHub workflow and follows you into other editors. Both is a legitimate answer.

Next steps

For the plugin itself — features, preview status, slash commands, key bindings — see GitHub Copilot with JetBrains IDEs. For the same plugin in a Kotlin context with deeper coverage of build tooling, see IntelliJ IDEA.

Next in this cluster: Eclipse, which has the most restricted Copilot support of any IDE covered here.