build-and-test

Building, testing, and measuring coverage with Gradle

These tools run on the host, not on a device. Only run_instrumented_tests and build_and_run need a booted device. project_dir must be the directory holding the Gradle wrapper (gradlew), not a module inside it.

Pin project_dir once instead of repeating it on every call:

session_set_defaults {project_dir: "/path/to/project"}

Every Gradle tool below then takes it from there. An explicit project_dir on a single call still wins.

If a build fails with "SDK location not found", the server could not resolve an Android SDK to hand Gradle. Run doctor — it prints the location it resolved and flags a path with no platform-tools/ in it. The fix is on the client side: set ANDROID_HOME, or launch the server with --sdk /path/to/sdk.

Map the project before you build it

The single biggest time-waster is guessing a task name. Two calls remove the guessing:

list_gradle_projects   → :app, :core, :feature:login   (empty = single-module)
list_gradle_variants   → debug, release, prodDebug, …

In a multi-module build the root project usually has no variants of its own — the Android plugin is applied in :app, not at the root. list_gradle_variants with no arguments will tell you it found none and to point at the module that builds APKs. That is not an error to route around; it means scope the call:

list_gradle_variants {task: ":app:tasks"}

The same applies to list_gradle_tasks, which lists the root project's tasks by default. Anywhere you can name a task you can qualify it with a module path: :app:assembleDebug, :feature:login:testDebugUnitTest.

Build

gradle_build                             → assembleDebug
gradle_build {task: "assembleRelease"}   → a specific variant
gradle_build {background: true}          → returns a job id at once; poll build_status
build_and_run {package: "com.example"}   → build → install → launch, one call

gradle_build returns a summary, not Gradle's output: status, duration, error count, the first few errors, the APKs under build/outputs (newest first, so a stale one from an earlier build can be in the list), and the path of the full log. Read the log file only if the summary does not explain the failure. Credential-shaped values (passwords, tokens, user:pass@ URLs) are redacted from both the summary and the log, so a --info run is safe to read.