Support Android 17 (target=37, api_level=37) in build + integration tests

[guylis-ironsrc]

Summary

Unblocks the Android integration-tests workflow for Android 17 / target=37 / api_level=37 across both matrix jobs (Kotlin + Java). Verified end-to-end green on GHA: run 30366238885 — Kotlin ~4:40, Java ~4:38.

Three commits, each isolating a distinct required piece — deltas kept minimal:

1. a067e20 — Map api_level=37 in the workflow to api-level: "37.0" + target: "google_apis" when calling reactivecircus/android-emulator-runner@v2. Older api-levels pass through unchanged with target: default.
2. 8414d01 — Bump AGP 8.2.2 → 9.1.1 and Gradle 8.2 → 9.3.1 in both projects, plus the coupled AGP 9 requirements (proguard-optimize, drop kotlin-android plugin, kotlin { compilerOptions {} } block).
3. 6221e8b — Add a pre-emulator step that upgrades $ANDROID_HOME/cmdline-tools/latest to build 15859902 (cmdline-tools 22.0). Runs only when api_level == '37'.

Why each piece is required (verified empirically)

Google switched Android 17 to a feature-drop release model. Only versioned variants of the SDK packages exist:

• ❌ platforms;android-37 — not published
• ✅ platforms;android-37.0, platforms;android-37.1 — published
• ❌ system-images;android-37;<tag>;<abi> — not published
• ✅ system-images;android-37.0;google_apis;<abi> — published (no default tag exists at API 37)

Piece	What fails without it	Verified failing run
AGP 9.1.1 + Gradle 9.3.1	Build fails: Failed to find Platform SDK with path: platforms;android-37 (AGP 8.2.2 can't map compileSdk = 37 to the on-disk platforms/android-37.0/)	run 30365216456
api-level: "37.0"	Build succeeds, then reactivecircus fails: Warning: Failed to find package 'platforms;android-37'	run 30362466493
target: "google_apis"	reactivecircus fails at next step: Warning: Failed to find package 'system-images;android-37.0;default;x86_64'	run 30364151515
cmdline-tools 22.0 upgrade	reactivecircus's install steps warn SDK XML file of version 4 was encountered; avdmanager writes target=android-0 into AVD config.ini; emulator boot never completes and reactivecircus times out at 600s	run 30365450517 (cancelled at ~5 min stuck in adb-poll loop)

All 4 pieces present ⇒ end-to-end green: run 30366238885.

Behavior for older API levels

Unchanged. The workflow-input mapping only rewrites api_level=37; anything else passes through as before. The cmdline-tools upgrade step has if: ${{ steps.args.outputs.api_level == '37' }} and is a no-op otherwise. Runs at default api_level=29 are byte-identical to before this PR.

Removes when

Both upstream PRs land and we bump the reactivecircus action pin:

• ReactiveCircus/android-emulator-runner#477 — action-side feature-drop naming support (WIP by maintainer ychescale9)
• ReactiveCircus/android-emulator-runner#483 — bundled cmdline-tools bump to 22.0 (community PR, maintainer engaged)

Once those release in a fresh @v2 or @v3, the workflow mappings and cmdline-tools install step can be removed and the reactivecircus block goes back to the original 4-line form. The AGP + Gradle bump stays (it's an inherent AGP requirement for compileSdk = 37, unrelated to the action).

Supersedes

Replaces PR #52, which had the same fix mixed with two dead-end experiment commits (manual emulator setup) that aren't needed.

Test plan

• Local ./gradlew assembleDebug (default target 34) passes on both projects.
• Local ./gradlew assembleDebug -PtargetSdkVersion=37 -PcompileSdkVersion=37 passes on both projects, aapt2 dump badging confirms targetSdkVersion:'37'.
• Local ./gradlew connectedDebugAndroidTest -PtargetSdkVersion=37 -PcompileSdkVersion=37 — 6/6 tests pass on an API 37 arm64-v8a emulator (Kotlin + Java).
• GHA workflow_dispatch sdk_version=9.5.0 api_level=37 target_sdk_version=37 — run 30366238885, both matrix jobs green.
• Verify a default-args PR run (api_level=29, target_sdk_version=34) still passes on this branch, to confirm no regression for older api-levels.

🤖 Generated with Claude Code

[Gal-Yedidovich-iSrc]

Review

CI + build config only, so nothing to check against a ticket. The diff is small (+43/-12) and the reasoning is unusually well evidenced.

I verified the two claims the description presents as "coupled AGP 9 requirements" — both are genuinely forced, not discretionary:

• AGP 9.0+ enables built-in Kotlin by default and fails the build if kotlin-android is applied (AGP 9 release notes, JetBrains migration guide)
• AGP 9 dropped proguard-android.txt because of its -dontoptimize (migration notes)

Also checked the one unchecked test-plan box: it's satisfied. This PR touches Android/**, so the pull_request trigger ran the workflow with default args (api_level=29, target_sdk_version=34) — integration-tests (Java) and (Kotlin) both pass in run 30366855506 (~3m24s each). The no-regression claim for older API levels is empirically confirmed; that box can be ticked.

Overall: approve with comments. Nothing blocks merge. One security hardening item and one workflow-robustness item are worth fixing now; the publisher-facing impact of the AGP bump deserves an explicit decision.

Strengths

• Per-piece failing-run links proving each of the four changes is individually necessary — this is the standard CI changes should be held to and rarely are.
• Workflow comments record the exact error strings (SDK XML file of version 4, target=android-0) rather than restating the code. Correct call for a temporary workaround.
• Guarded so older API levels are untouched: the mapping only rewrites 37, and the new step is if-gated.
• Documented removal criteria with links to both upstream PRs, plus a note on which part (AGP/Gradle) is permanent. Makes the workaround reversible instead of load-bearing forever.
• Supersedes Bump AGP 8.2.2 → 9.1.1 + Gradle 9.3.1 for compileSdk=37 support #52 with the dead-end experiment commits dropped.

---

🟡 1. cmdline-tools zip is downloaded and executed with no integrity check

.github/workflows/android-integration-tests.yml — "Upgrade cmdline-tools to 22.0" step

The job has PRIVATE_MAVEN_USERNAME / PRIVATE_MAVEN_PASSWORD in env, and this step fetches a 180 MB archive over the network and then runs a binary out of it. -f catches HTTP errors but nothing verifies content. Google publishes a SHA-1 for this exact build in repository2-3.xml:

curl -sfLO https://dl.google.com/android/repository/commandlinetools-linux-15859902_latest.zip
echo "040d3996a65543d22ec4bf73e4c37aa37a8d4af4  commandlinetools-linux-15859902_latest.zip" | sha1sum -c -

Cheap, and it also turns a silently corrupt/truncated download into a clear failure instead of a confusing avdmanager error later.

Consider working-directory: /tmp for this step too — right now the zip lands in the checkout root and is cleaned up by a trailing rm; using /tmp removes the need for that line and can't dirty the workspace if the step aborts midway.

🟡 2. The "is this API 37" decision is encoded twice and can drift

The shell block computes EMU_API_LEVEL/EMU_TARGET from [ "$API_LEVEL" = "37" ], and the step gate separately re-tests steps.args.outputs.api_level == '37'. Two sources of truth for one condition. Emit it once:

if [ "$API_LEVEL" = "37" ]; then
  EMU_API_LEVEL="37.0"
  EMU_TARGET="google_apis"
  NEEDS_CMDLINE_UPGRADE="true"
fi
...
echo "needs_cmdline_upgrade=${NEEDS_CMDLINE_UPGRADE:-false}" >> $GITHUB_OUTPUT

Related, and the reason I'd fix this now rather than later: api_level=37.0 silently takes the non-37 path. Given this entire PR is about 37.0 being the real package name, someone will plausibly type 37.0 into the dispatch form. They'd get target=default and no cmdline-tools upgrade — i.e. exactly the 600s emulator-boot hang this PR fixes, with nothing in the log explaining why. Either normalize 37.0/37.1 into the same branch, or fail fast on an unsupported value.

🔵 3. buildToolsVersion '34.0.0' is now inconsistent with a compileSdk that can be 37

Android/{Java,Kotlin}/app/build.gradle

Untouched by this PR and the build is green, so not blocking. But an explicit 34.0.0 pin next to a parameterized compileSdk that can be 37 is misleading in a reference app. AGP picks a correct default if the line is simply deleted.

🔵 4. Cosmetic leftovers from the kotlinOptions move

Android/Kotlin/app/build.gradle — the android { } block now ends with a stray blank line, and org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_1_8 is fully qualified inline. Works, but in a file publishers read as a template, an import reads better.

---

The one thing worth an explicit decision

These are demo apps publishers copy verbatim, and the description frames the AGP/Gradle bump purely as a CI necessity without noting its publisher-facing consequence. Concretely, after this PR:

• The Kotlin demo has 11 .kt files (DemoActivity.kt, 3 androidTest classes, …) and no Kotlin plugin applied anywhere — Kotlin compilation now depends entirely on AGP 9's built-in support. A publisher still on AGP 8.x who copies Android/Kotlin gets a project whose Kotlin sources are never compiled. The demo has gone from "works on AGP 8" to "requires AGP 9".
• The demo now requires Gradle 9.3.1 and JDK 17+.
• The Kotlin language version is no longer pinned — ext.kotlin_version = '2.1.0' is gone, so it's whatever AGP 9.1.1 bundles.

Note the committed default is still compileSdk = 34, which AGP 8.2.2 handled fine; compileSdk = 37 only appears on manual workflow_dispatch. So the demo's published baseline moved to satisfy a capability exercised only in dispatch runs.

Not asking for a reversal — pinning AGP per-job is genuinely awkward, and AGP 9 is where the ecosystem is heading. But it should be a stated choice rather than a side effect, and the README (which currently documents no version requirements at all) is the natural place for a one-line "requires AGP 9.x / Gradle 9.x / JDK 17+" note, since publishers hitting the AGP 8 incompatibility have no other signal.