Android Studio brings Gemma 4 coding agents on-device

Google has added native Gemma 4 support to Android Studio, giving developers a local model for Agent Mode. After downloading the model, developers can generate code, call IDE tools, and refactor multiple files without an internet connection, API key, usage quota, or remote inference service.

The integration addresses three recurring constraints of cloud coding assistants: source code leaves the development machine, requests may incur fees or hit rate limits, and network access becomes a dependency. Local inference keeps Agent Mode prompts and source context on the developer’s hardware.

Agent Mode leaves the cloud

Android Studio now includes an inference engine that runs Gemma 4 inside the IDE. Previous local setups required a separate runtime such as Ollama or LM Studio. Those providers remain available for developers who want custom model configurations or a shared setup across editors.

Gemma 4 supports agentic tool calls, allowing the model to inspect files, edit code, invoke builds, read errors, and apply follow-up fixes. A single request can therefore produce coordinated changes across an Android project instead of isolated code completions.

The model must initially be downloaded over the internet. Android Studio then stores, verifies, and updates the weights. Once installed, local Agent Mode requests can run offline.

Setup stays inside the IDE

Developers can enable the provider through either of these paths:

1. Open the Agent model selector, choose Gemma, and select a model to download.
2. Open Settings > Tools > AI > Model Providers > Gemma, then choose and install a model.

The Gemma option requires an Android Studio release that includes the native provider. Developers who do not see it should update Android Studio and check the model-provider settings again.

Memory sets the ceiling

Model size determines whether local inference remains practical alongside Android Studio, Gradle, an emulator, and other development tools. The smallest variants can run on machines with 12 GB of RAM, while systems with 32 GB or more provide more room for larger models and active Android projects.

These figures describe approximate quantized model footprints, not complete system requirements. INT8 models use roughly twice the memory of INT4 variants, and FP16 models roughly double the INT8 requirement. Android Studio commonly consumes another 4 to 8 GB before accounting for Gradle, emulators, browsers, and the operating system.

A machine with exactly 16 GB of total memory is poorly suited to the 26B model because the model footprint leaves almost no capacity for the IDE or build tools. The E4B variant is the more practical choice at that tier. Systems with unified memory also share the same pool between CPU and GPU workloads.

Android training shapes the output

Google trained Gemma 4 for Android development and agentic tool use. Its domain coverage includes Kotlin conventions, Jetpack Compose, Android project structure, and common build workflows.

Agent Mode can apply that training to several project-level tasks:

• Feature generation: Create screens or complete features using Kotlin and Jetpack Compose.
• Build repair: Run a build, inspect compiler errors, locate the affected code, and iterate on fixes.
• Multi-file refactoring: Update related classes, resources, tests, and configuration files in one plan.
• Offline assistance: Continue coding and refactoring without access to a model endpoint.

Local inference has clear limits

Local Gemma models generally provide weaker reasoning and completion quality than Google’s cloud-based Gemini models, particularly on ambiguous architecture decisions or tasks requiring a large amount of project context. Performance also depends on available memory, hardware acceleration, model size, and quantization.

The built-in provider exposes fewer tuning controls than specialist tools. Continue, for example, supports JSON configuration for context length, debounce timing, and per-task model routing. Android Studio’s native panel favors a managed setup with fewer adjustable parameters.

Teams can keep both configurations available. Native Agent Mode suits Android-specific tool use, while an Ollama or Continue setup can provide consistent models and settings across multiple IDEs.

Local processing applies to model inference and Agent Mode requests. Organizations with strict security requirements should still review IDE telemetry, plugins, dependency downloads, build services, and any other tools that communicate with external systems.

Where local models fit

The native provider is best suited to workloads constrained by privacy, connectivity, or cloud usage limits:

1. Regulated and proprietary codebases: Prompts and source context remain on the development machine during local inference.
2. Unreliable connectivity: Installed models continue working during travel, outages, and restricted-network sessions.
3. High-volume agent runs: Local requests avoid service quotas and per-token charges, with hardware capacity setting the practical limit.
4. Repeatable development environments: Teams can standardize a downloaded model without distributing API credentials.

A bridge to on-device Android AI

Gemma 4 also underpins the next generation of Gemini Nano, which Google is optimizing for on-device Android workloads. Using the same model family in Android Studio gives developers experience with the memory, latency, and quality tradeoffs that shape AI features running directly on phones and other edge devices.

For Android developers, the immediate change is concrete: Agent Mode can now operate as a self-contained local tool. Cloud Gemini remains available for tasks that require stronger reasoning, while Gemma 4 provides an offline path for private, quota-free coding workflows.