BXUP Track progress & test yourself — free
Frontend & Mobile · Playbook · Core · ~5 min read
FRONTEND & MOBILE · PLAYBOOK · CORE

Gemini in Android Studio as a Daily Instrument

Gemini in Android Studio is no longer autocomplete with a chat window — Agent Mode plans and executes multi-file changes, Compose-specific assists live in the editor, and you can bring your own model. The teams that win with it are the ones with explicit rules for what agent output must pass before merge.

Tier: Core · Workflow area: Mobile engineering & release

This playbook sets up the daily operating rhythm: which mode for which job, how to scope Agent Mode so it helps instead of thrashing, and the acceptance bar every AI-authored change must clear.

When to use

  • You build Android apps in Android Studio (Narwhal or later) and want AI assistance that understands Gradle, Compose and the Android SDK — not a generic chat pasted beside the IDE.
  • Multi-file features and refactors where an agent that can read the project, edit files and iterate on build errors beats copy-paste.
  • Teams standardizing one assistant so review rules and prompts are shareable.

Skip Agent Mode for one-line edits — inline completion and Transform are faster — and for architecture decisions, which stay human.

Prerequisites

  • Android Studio Narwhal+ with Gemini enabled (default assistant), signed into an account your org allows; on managed setups confirm whether code-context sharing is permitted.
  • A project that builds green from a clean checkout — Agent Mode iterates against the build, so a broken baseline breaks the loop.
  • Optional for LLM flexibility: a Gemini API key for higher-tier models, or an OpenAI-compatible local endpoint (Ollama / LM Studio) configured under Gemini settings for bring-your-own-model.
  • A team rules note (see step 5) checked into the repo.

The workflow

  1. Map the three modes to the three job sizes. Make this deliberate, not vibes:

    • Inline completion and single-file chat — micro edits, idiom questions, "why is this deprecated".
    • Transform / in-editor actions — mechanical rewrites scoped to a selection: convert callbacks to coroutines, XML view to Compose, add a parameter everywhere.
    • Agent Mode — multi-file tasks with a verifiable outcome: "add a settings screen persisted with DataStore", "migrate this module's Hilt bindings", "fix all deprecation warnings in :feature-profile".
  2. Scope Agent Mode like a ticket, not a wish. Agent Mode plans, edits multiple files, and iterates on compile errors. Its failure mode is over-scoping. Prompt with boundaries:

    Add a notification-preferences screen to :feature-settings.
    Constraints:
    - Compose only, using our DesignSystem components (see ui/theme and
      ui/components for the canon).
    - Persist via the existing UserPrefsRepository (DataStore) - do not
      add a new persistence mechanism.
    - Follow the ViewModel + UiState pattern used in SettingsViewModel.
    - Do not touch Gradle files or any module outside :feature-settings.
    Show me the plan before executing.
    

    Review the plan, trim it, then let it run. Reject any step that edits files outside the stated boundary.

  3. Use the Compose-specific assists where they are strongest. Ask Gemini to generate @Preview variants for the states you have not rendered (loading, error, empty, dark theme, large font); use the preview-generation assist on composables missing previews entirely; and when a recomposition feels heavy, paste the composable and ask for stability problems — unstable lambdas, missing remember, lists without keys — then verify with Layout Inspector's recomposition counts, not the model's word.

  4. Wire the feedback loop the agent iterates against. Agent Mode fixes what it can see. Make it see more: keep the build fast enough to run per iteration, and end every agent task with the same closing instruction:

    Before declaring done: build the project, run the unit tests for the
    touched module, and fix anything that fails. List every file you
    changed and why in one line each.
    
  5. Adopt team rules for what agent output must pass. Write them down in the repo (for example docs/ai-rules.md) and enforce in review:

    • Builds and tests green — agent-authored PRs get zero leniency on CI.
    • On-system UI only — design-system components and tokens; raw Color(0xFF...) or ad-hoc padding scales are an automatic change request.
    • States enumerated — any new screen ships loading, error and empty states plus previews for each.
    • No new dependencies without a human decision — agents love adding libraries; Gradle diffs are reviewed line-by-line.
    • Provenance declared — the PR description says which parts were agent-generated so reviewers calibrate attention.
Key Takeaway:

Agent Mode is a fast junior with perfect stamina: give it ticket-sized scope, a build-and-test loop to iterate against, and a written acceptance bar. The rules file — not the model choice — is what makes AI output mergeable.

Tool variants

  • Gemini tiers: the default no-key tier is fine for chat and Transform; attach a Gemini API key to unlock stronger models for Agent Mode planning on gnarly refactors.
  • Local model (LLM flexibility): point Android Studio at an OpenAI-compatible endpoint (Ollama, LM Studio) when code cannot leave the machine. Expect weaker multi-file planning — shrink tasks to Transform-sized chunks.
  • Claude Code alongside the IDE: for repo-wide loops (version-catalog migrations, mass deprecation sweeps) a terminal agent complements Agent Mode; keep the same rules file for both.

Verification

  • Every agent-touched module builds and its unit tests pass locally before the PR opens.
  • New screens: previews exist for default, loading, error, empty and dark-theme states, and you clicked through each on a device or emulator.
  • Recomposition or performance claims were confirmed with Layout Inspector or a Macrobenchmark, not accepted from the chat.
  • The PR lists agent-generated portions and the Gradle diff contains no surprise dependencies.

Pitfalls

  • Letting Agent Mode roam. Unscoped prompts ("improve the settings flow") produce 40-file diffs nobody can review. Boundaries in, plan reviewed, then execute.
  • Trusting SDK claims without checking versions. Models confuse API levels, Compose BOM versions and deprecated-vs-removed status; verify against the official docs for your exact versions.
  • Off-system UI. Generated composables default to Material defaults, not your design system; the rules file plus exemplar files in the prompt context fix most of it.
  • Skipping the plan review. The plan is where you catch scope creep for free; skipping it converts a 2-minute read into a 40-minute diff review.
  • Assuming privacy defaults. Check your org's data-sharing settings before pasting proprietary code into any tier of the assistant.

Restricted-environment variant

Where policy blocks Google-hosted inference: use the bring-your-own-model path with a local endpoint for chat and Transform-sized work, keep Agent Mode off, and run multi-file changes as a human-driven sequence of scoped Transforms. The team rules file applies unchanged — it governs output, not provider.

Note

The assistant's data-handling terms differ between the free tier, paid tiers and enterprise agreements. Confirm which one your team is actually on before the first proprietary prompt — not after.

Success criteria

  • Agent Mode handles ticket-sized features with plans you approve in minutes, and its PRs pass CI at the same rate as human PRs.
  • Zero merged agent PRs with off-system UI, missing states or surprise dependencies in the last month.
  • New teammates produce on-system Compose from week one because the rules file and exemplar prompts do the calibration.
  • You can name, per task type, which mode you reach for — and inline-vs-Transform-vs-Agent no longer costs a decision.
This is the free reading view. Open BXUP to track your progress, run the hands-on labs, and prove it with original, exam-pattern assessments.
© Anvi Innovate · BXUP — Be Exponentially Upskilled · BXUP is an independent learning platform, not affiliated with or endorsed by AWS, Microsoft, Google, NVIDIA, IBM, Salesforce, Databricks, Oracle or Anthropic. All trademarks belong to their respective owners. · bxup.in