android/build.sh: VTESSE_ANDROID_IMAGE uses a ready image instead of building one

[compot-dev]

android/build.sh builds ci/Dockerfile.android as vtesse-android on every run. On a machine that already has a suitable Android image (JDK 17, SDK, NDK, CMake, gradle on PATH) this means a second 4.5 GB image for the same job.

VTESSE_ANDROID_IMAGE=<image> now skips docker build and runs Gradle in that image. Without the variable the script behaves exactly as before, so CI is unchanged. android/README.md documents the variable.

Tested:

• VTESSE_ANDROID_IMAGE=<image with SDK 35, NDK 27.2.12479018, CMake 3.22.1, Gradle 8.11.1> android/build.sh assembleDebug → app-debug.apk, vtesse-android not rebuilt (1 min 34 s from a cold Gradle cache);
• android/build.sh assembleDebug (no variable) → builds/uses vtesse-android as before, same APK;
• sh -n passes; shellcheck reports only the two notes the file already had (SC1091, SC2048).

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Allow Android builds to use an existing Docker image

✨ Enhancement 📝 Documentation 🕐 Less than 10 minutes

AI Description

• Let local Android builds use a ready image, avoiding a redundant Docker build.
• Preserve the default CI build path and document the image override.

Diagram

graph TD
  Script["Android build script"] --> Choice{"Image supplied?"} -->|Yes| Provided["Ready image"] --> Run["Run Gradle"] --> APK["Android APKs"]
  Choice -->|No| Default["Build default image"] --> Run

Loading

High-Level Assessment

The optional image override is appropriate: it avoids a redundant local build while leaving the existing default and CI behavior intact. Requiring all builds to use a prebuilt image would remove that reliable default.

Files changed (2) +11 / -2

Enhancement (1) +10 / -2

build.shSelect a supplied image or build the default +10/-2

Select a supplied image or build the default

• Uses VTESSE_ANDROID_IMAGE when set, skipping docker build. Otherwise, it builds and runs vtesse-android as before; comments describe the requirements for a supplied image.

android/build.sh

Documentation (1) +1 / -0

README.mdDocument the ready-image build option +1/-0

Document the ready-image build option

• Adds a build example showing how to set VTESSE_ANDROID_IMAGE to use an existing Android image.

android/README.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Ready images with entrypoints cannot build ✓ Resolved

Description

docker run leaves a supplied image's ENTRYPOINT in place for both the readiness check and the
Gradle invocation. If an otherwise suitable image has an entrypoint that does not forward those
arguments as commands, the check fails or Gradle never starts.

Code

android/build.sh[43]

+    docker run --rm "$IMAGE" sh -c 'command -v gradle >/dev/null && [ -n "${ANDROID_HOME:-}${ANDROID_SDK_ROOT:-}" ]' || {

Evidence

The ready-image requirements list tools and an SDK environment variable, but not an entrypoint
restriction. Both new uses pass a command after the image name without overriding its entrypoint, so
Docker supplies that command as arguments to any configured ENTRYPOINT.

android/build.sh[9-13]
android/build.sh[43-44]
android/build.sh[48-51]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A supplied image's ENTRYPOINT can intercept both the readiness check and the Gradle command, even when the image provides the documented tools.
## Fix Focus Areas
- android/build.sh[43-51]
## Recommended Fix
Explicitly select the intended executable for each container run when using a supplied image, so an image ENTRYPOINT cannot reinterpret the check or Gradle arguments.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Ready-image builds can miss the SDK ✓ Resolved

Description

The VTESSE_ANDROID_IMAGE path skips the repository image’s ANDROID_HOME and SDK-related PATH
setup while passing neither SDK location variable into the container. A ready image that has
gradle on PATH and contains the required SDK components but does not export ANDROID_HOME or
ANDROID_SDK_ROOT reaches the Android Gradle Plugin without an SDK location and fails during
configuration.

Code

android/build.sh[R36-40]

+IMAGE=${VTESSE_ANDROID_IMAGE:-}
+if [ -z "$IMAGE" ]; then
+    IMAGE=vtesse-android
+    docker build -q -t "$IMAGE" -f "$ROOT/ci/Dockerfile.android" "$ROOT/ci" >/dev/null
+fi

Evidence

The repository-built image sets ANDROID_HOME and appends SDK and Gradle directories to PATH. The
override skips that image build, while the docker run invocation only sets Gradle cache and home
variables; the Android project has no local.properties SDK override, so SDK discovery depends on
the replacement image’s environment.

ci/Dockerfile.android[12-15]
android/build.sh[36-46]
android/app/build.gradle.kts[20-49]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The ready-image branch bypasses `ci/Dockerfile.android`, which is the repository’s only place that sets `ANDROID_HOME=/opt/android-sdk` and adds Android tools to `PATH`. The documented ready-image requirements do not require an SDK environment variable, so an image can contain the required SDK and expose Gradle while Android Gradle Plugin configuration still cannot locate the SDK.
## Fix Focus Areas
- android/build.sh[36-46]
- ci/Dockerfile.android[12-15]
- android/README.md[67-69]
## Recommended Fix
Ensure SDK discovery is part of the ready-image contract: either pass a configurable `ANDROID_HOME`/`ANDROID_SDK_ROOT` value into `docker run` and document the required image layout, or explicitly require and document that the ready image exports the SDK location and Android tool paths. Keep the default built-image behavior unchanged.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can pick a display mode instead of tweaking every Display option by hand

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[compot-dev]

/review

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 0fec6e5

[compot-dev]

/review

[qodo-free-for-open-source-projects]

Code review by qodo was updated up to the latest commit 67e2aaa