Replace preinstalled cmdline-tools older than revision 23

[matanbaruch]

The bundled cmdline-tools install is gated on the cmdline-tools directory being absent, so on GitHub-hosted runners that already ship one (ubuntu-24.04 ships revision 12.0) the download never runs and the stale revision goes on PATH. Revision 12.0 cannot parse a dotted API level such as 37.1: avdmanager exits 0 and writes a correct image.sysdir.1, but puts target=android-0 in the AVD ini, which mis-configures gfxstream and makes the guest abort in mapper.ranchu.so (Assertion failed: !rcEnc->featureInfo()->hasReadColorBufferDma), crash-looping SurfaceFlinger and several system_server threads. The action already bundles 23.0, which parses those levels correctly.

The fix: read Pkg.Revision from cmdline-tools/latest/source.properties and install the bundled package when that revision is missing or older than 23, removing the stale latest before extracting so the new package replaces it in place. No new input and no change to action.yml. It is a no-op for integer API levels, where both revisions write target=android-36.

Worth fixing in the action rather than leaving to users: the user-side workaround runs sdkmanager --install "cmdline-tools;latest", which cannot replace the directory it runs from and lands in a sibling latest-2 that the action then ignores, because the action puts cmdline-tools/latest/bin on PATH and calls a bare avdmanager. The action downloads and extracts the zip itself, so it can replace latest correctly.

Related: #482 (closed, but only a user-side workaround was posted, the action itself was never changed), actions/runner-images#14484 (still open), issuetracker.google.com/issues/546200928 (Google's triage identified the tooling cause).

Abort counts on identical system images and emulator flags, cmdline-tools 12.0 vs 23.0:

API level and target	12.0	23.0
37.0;google_apis	8	0
37.1;ps16k	11	0
37.2;ps16k	11-33	0

[matanbaruch]

@ychescale9 I think intel cache wasn't warm. Can you re-run?

[matanbaruch]

The macos-15-intel failure is a timeout, not a regression from this PR. I pushed a commit that gives that one job 20 minutes and leaves everything else at 15.

What happened in run 33638038969:

1. Cache not found for input keys: avd-31-macos-15-intel-default-x86_64. The caches from the last main run (Aug 26) had aged out, so the job took the cold path and had to generate the snapshot.
2. assembleAndroidTest took 4m44s against an empty Gradle home, the SDK install 2m20s, and the first boot of API 31 4m59s. The emulator did come up, Emulator booted. at 23:57:39, and the snapshot step finished.
3. The second emulator started from that snapshot in 11s, and the job was cancelled at 15m17s in the middle of the connected test.

For comparison, the last cold-cache run on main (32577705281, Aug 22) did the same work in 10m46s with a 3m17s first boot. So 15 minutes covers the cold path only when the runner is on the fast end. Warm-cache runs on that image finish in 6 to 8.

One cost that is on this PR: once the preinstalled cmdline-tools is replaced (revision 16 on that image), sdkmanager delegates to the new Android CLI and downloads it on first use, so the SDK install step is about a minute more expensive on macOS than it is today. Real, but not what blew the budget.

Let me know if you would rather have 20 everywhere, or the workflow left alone and the job just re-run.

[matanbaruch]

@ychescale9 the run from that push is sitting in action_required and needs your approval again (Main workflow 33824784975).

It carries the 20 minute timeout on macos-15-intel, and the AVD cache is still cold there, so it should show whether 20 is actually enough or just closer.