Google turns Android Studio into a local AI agent IDE

Google's Gemma 4 burst looks like three announcements if you skim and one plan if you do not. Android Studio gets Gemma 4 as a local Agent Mode model. AICore Developer Preview puts Gemma 4 on supported phones. Gemini Nano 4 later this year becomes the likely deployment target.

The interesting part is the connection. Google is trying to make local AI feel like one route from IDE to device, not a pile of mismatched parts. Android Studio opened to local and remote model choice in January. Now Google has a house local model for Android coding and a phone-side preview path for the same family. I keep coming back to the same point: this is less a benchmark story than a distribution story. It rhymes with our earlier take on Google AI Studio's full-stack distribution play, just with local inference instead of hosted app plumbing.

Android Studio Gemma 4 turns Agent Mode into a local coding surface

According to Google's Android Studio post, Gemma 4 can run locally for AI coding assistance without an internet connection or an API key for its core operations. That is the headline developers with privacy rules, unreliable connectivity, or quota fatigue will care about first. Your code stays on your machine. Your bill does not suddenly develop a personality.

Google is also explicit about what Gemma 4 is meant to do inside Agent Mode. The examples are practical, not mystical: build a feature, refactor a codebase, extract strings into strings.xml, or keep fixing a broken build until it passes. Real developer tooling should solve the chores that quietly eat an afternoon, not just produce a demo that gets applause and then vanishes behind a pricing page.

There is still real hardware gravity here. Android Studio recommends the 26B MoE variant for app developers with the minimum supported setup, and Google says the total RAM requirement includes both Android Studio and the model. The published guidance is 8 GB RAM and 2 GB storage for Gemma E2B, 12 GB and 4 GB for E4B, and 24 GB plus 17 GB of storage for the 26B MoE. So yes, it is local. No, it is not magic. Your old laptop from the "please just survive one more semester" era may file a formal complaint.

How local Gemma 4 in Android Studio really works

This part is worth being precise about, because "local" gets abused faster than the office coffee machine.

Android Studio is not bundling Gemma 4 directly as a one-click internal model. Developers still need a local provider such as LM Studio or Ollama, then connect that provider under Settings > Tools > AI > Model Providers. In other words, Google built the rail and picked a favored train, but you still bring the engine.

That is why the packaging matters. January's Android Studio update opened the surface to local models. April's Gemma 4 update drops a Google-backed option into that exact path. So the real move is not "surprise, local models exist." It is that Google now has a house model for the local route and can point Android developers toward it with a straight face.

If you want the broader Gemma 4 model family breakdown, our piece on Gemma 4 models, hardware, and benchmarks covers where E2B, E4B, 26B A4B, and 31B actually fit. This article is about why Google wants those choices to land inside Android workflows, not just on a leaderboard screenshot.

AICore Developer Preview brings Gemma 4 onto Android devices

The second half of the plan sits on the phone side. Google's AICore Developer Preview gives developers early access to Gemma 4 E2B and E4B on supported devices through the ML Kit GenAI Prompt API. The company says code written against Gemma 4 today will work on Gemini Nano 4-enabled devices later this year, which is a very tidy way of telling developers not to treat the preview as a toy.

But this is still a preview. Google says the current period is for refining prompt accuracy and exploring use cases, while support for tool calling, structured output, system prompts, and thinking mode in Prompt API is still coming. That caveat matters. The Android Studio side is already leaning hard into agentic tool use. The AICore side is clearly headed there, but it is not all there yet.

Hardware constraints matter here too. Preview models run best on AICore-enabled devices using recent AI accelerators from Google, MediaTek, and Qualcomm. On other devices, Google says the models may run on CPU in a way that does not represent final production performance. First inference can take about a minute while the model loads, and the docs warn that preview models may be slower, less accurate, and rougher on stability. This is a developer preview, not a magic trick in a trench coat.

If a device is not AICore-enabled, Google points people to AI Edge Gallery, which now markets Gemma 4 support, Agent Skills, thinking mode, and fully offline use on mobile hardware. That makes the larger Gemma 4 story look even more deliberate. We already covered the open-stack angle in Gemma 4 as Google's Apache 2.0 on-device agent stack. What changed this week is how tightly Google is threading that stack through Android-specific surfaces.

Gemini Nano 4 gives Google a future deployment target

Google's Android team says Gemma 4 is the base model for Gemini Nano 4, the version planned for new flagship Android devices later this year. The company claims Gemini Nano 4 will be up to four times faster than the previous version while using up to 60 percent less battery. Treat that as Google's performance framing until broader device testing arrives, but the strategic meaning is clear enough already.

Developers are being invited to prototype on the same model family they may deploy against later. That cuts down the usual handoff pain where the thing that helps you build is completely different from the thing that actually ships. I would not call it seamless yet. I would call it very intentional.

And that is the point. If Google's Gemini API tool-combination update and the broader Gemini 3.1 Flash agent rail were about keeping hosted agent workflows inside Google's orbit, this Android move looks like the local version of the same instinct.

Why Google wants one model family from IDE to runtime

Google is not just shipping another open model and hoping developers do arts and crafts with it. It wants Android Studio to be where local agent work starts, AICore to be where on-device behavior gets tested, and Gemini Nano 4 phones to be where that work lands at scale.

That does not guarantee adoption. It does explain the packaging. The company is trying to reduce the distance between "I built this with local AI" and "this now runs on an Android device" while keeping both steps inside Google's stack. For developers, that could be genuinely useful. For Google, it is also a neat way to turn one model family into an IDE feature, a runtime preview, and a future distribution channel all at once.

Neat little trick.