GitHub Copilot CLI (GitHub Copilot CLI) is a coding agent you start from an Android project folder with copilot. It reads Gradle files, Kotlin sources, and manifest resources directly, so it can implement features, run tests, and fix compile errors in the same workspace you use. For Kotlin and Android work, the key is giving it the right project instructions and a tight verification loop.
Where Copilot CLI fits into Android development
Android development is build-system heavy. The agent can run the same Gradle tasks you already trust: assembleDebug, testDebugUnitTest, lintDebug, and connectedDebugAndroidTest. That means it gets immediate compiler and test feedback instead of guessing. Kotlin and Jetpack Compose are also well suited to an agent that understands structured code: data classes, StateFlow ViewModels, and stateless composables map cleanly onto small, reviewable changes.
The agent is useful for repetitive Android work such as adding a ViewModel with UI state, converting a screen to collect StateFlow, updating Room entities and migrations, or writing JUnit tests with kotlinx-coroutines-test. It is less magical with resource merging, manifest quirks, and dependency resolution. Those areas need clear instructions and review.
Configuring Copilot CLI for your Gradle project
Place project instructions in .github/copilot-instructions.md or AGENTS.md at the repository root. The agent reads these files at the start of a session. For a Kotlin Android project, include exact build, test, and lint commands, the module layout, and Android-specific rules. A codebase map (Codebase map for AI agents: find code without grep) can help the agent locate source files, but the instructions file is the minimum.
Example:
# Copilot instructions for this Kotlin Android project
## Build and verification
- Debug build: ./gradlew assembleDebug
- Unit tests: ./gradlew testDebugUnitTest
- Instrumented tests: ./gradlew connectedDebugAndroidTest
- Lint: ./gradlew lintDebug
## Project layout
- Single app module at app/, feature modules under features/
- UI code in package com.example.app.<feature>.ui
- ViewModels in com.example.app.<feature>.viewmodel
- Repositories in com.example.app.<feature>.data
## Kotlin and Android rules
- Use Kotlin 2.x idioms; avoid raw types and platform types
- UI state is immutable data classes exposed as StateFlow
- Compose screens take state and callbacks as parameters; no ViewModel in previews
- Use version catalogs in gradle/libs.versions.toml; do not edit version catalog without asking
- Add no new dependencies unless the task explicitly requires it
- Match existing minSdk and targetSdk valuesKeep this file short and current. If your project has multiple modules, list each module’s package root and its build task so the agent does not guess. The agent will follow these rules when generating code, but it does not enforce them; you still review each diff.
An iterative loop for Kotlin changes
Start with a small, testable task. Ask the agent to inspect the relevant files and propose a plan before editing. After each change, have it run ./gradlew testDebugUnitTest. Review the diff with git diff before accepting. For complex multi-file features, a spec-driven approach (Spec-driven development with AI agents: a practical guide) keeps the agent from wandering.
Example prompts:
- “Add a LoginViewModel with email/password state, validation, and a login function that calls a suspend repository method. Include unit tests using coroutines-test.”
- “Convert the profile screen to collect UI state from a StateFlow ViewModel and add a @Preview composable.”
- “Fix the failing unit test in UserRepositoryTest by updating the fake to return the expected data class.”
- “Add a Room entity, DAO, and migration from version 1 to 2, then update the Database class and add a migration test.”
- “Run lintDebug and fix the performance and coroutine warnings in app/src/main/java without changing public behavior.”
Keep each turn focused. If the agent produces a large diff, ask it to split the change into smaller commits or describe which files matter.
Strengths and pitfalls in Kotlin Android work
The agent is strong at boilerplate and mechanical changes: creating data classes, ViewModels with StateFlow, repository interfaces, Compose screens, and JUnit tests. It can update Material 3 components, migrate LiveData to StateFlow, and add Room entities with matching DAOs. It can also add dependencies to your version catalog and sync the relevant Gradle files.
Watch it closely in these areas:
- Compose APIs: the agent may use older Modifier methods or experimental annotations. Check imports and deprecation warnings.
- Coroutines: generated tests sometimes call runBlocking where runTest is expected, or use Dispatchers.Main without a test dispatcher.
- Android resources: hardcoded strings, missing styles, or duplicate resource IDs can appear. Always run lintDebug.
- Manifest: exported flags, permissions, and package references can be wrong when the agent renames or moves components.
- Gradle: version catalog edits may introduce inconsistent library versions or unnecessary plugin changes. Review every build file change.
- Lifecycle: ViewModel scope can be misused when the agent mixes AndroidViewModel with plain ViewModel without need.
Test and verify Kotlin changes with the agent
Make the agent run unit tests after every implementation change: ./gradlew testDebugUnitTest. Do not accept a change that only compiles. Android lint is the next layer: ./gradlew lintDebug catches resource, manifest, and API level problems that Kotlin compilation misses. Instrumented tests with Espresso or Compose UI test rules should run only after unit tests and lint pass, because they require a connected device and are slower.
| Command | What it verifies | When to run |
|---|---|---|
| ./gradlew testDebugUnitTest | JUnit tests for ViewModels, repositories, and pure Kotlin logic | After every implementation step |
| ./gradlew lintDebug | Android lint issues: resources, manifest, API levels, performance | Before committing a feature |
| ./gradlew connectedDebugAndroidTest | Espresso and Compose UI tests on an emulator or device | Only after unit tests pass and a device is connected |
| ./gradlew assembleDebug | The debug APK builds without compilation errors | Quick check before deeper testing |
Ask the agent to inspect test reports under app/build/reports/tests/ if a unit test fails unexpectedly. For UI behavior, keep Espresso tests focused on one screen or flow and let the agent update them only when the UI contract changes.
Parallel agents with AgentVera on Kotlin projects
On larger Android projects, running several GitHub Copilot CLI agents through AgentVera helps because each agent can work in its own git worktree, so one can refactor Compose screens while another updates Room migrations without overwriting files. Automatic code review with file:line links catches Kotlin/Android mistakes such as stale Compose APIs or wrong coroutine dispatchers. Checkpoints are valuable when an agent experiments with Gradle dependency changes: you can undo a single turn instead of manually reverting. Token budgets cap long tasks and stop runaway build loops. This keeps parallel Android work reviewable and recoverable.
Final thoughts
GitHub Copilot CLI becomes a reliable Android pair when you give it exact Gradle commands, keep changes small, and enforce a unit-test-first loop. Review diffs in the areas where Android projects are brittle: Compose APIs, coroutines, resources, and Gradle files. For general workflow guidance, see How to use GitHub Copilot CLI: a step-by-step guide (How to use GitHub Copilot CLI: a step-by-step guide). With those habits, you can scale to parallel agents without losing control of the codebase.