fix(ci): harden Android NativeAOT instrumentation test scripts against transient failures

[agneszitte]

Summary

Fixes transient CI flakiness in the Android+Skia+NativeAOT Instrumentation Test pipeline introduced by #1245.

Three flakiness modes were observed:

1. sdkmanager --install dying at "33% Unzipping" — exits with code 1 on transient network/IO issues, and set -euxo pipefail aborts the entire pipeline immediately with no retry. First observed in CI build 204968.
2. Emulator ANR crashing the boot-wait script — adb shell input keyevent returns exit 255 while dismissing an "Application Not Responding: system" dialog during emulator boot, and set -e kills the script. First observed in canary build 205041 (Attempt 1).
3. Job never reaching adb shell am instrument — adb install can fail transiently right after emulator boot, again aborting due to set -e.

Changes

Fix 1 — sdkmanager_install() retry wrapper (android-sdk-emu.inc.sh)

• Wraps all sdkmanager --install calls in a function that retries up to 3 times with increasing back-off (1 s, 2 s).
• Addresses the "33% Unzipping" flakiness observed in CI build 204968.

Fix 2 — Stop downloading unused API-36 system image (android-sdk-emu.inc.sh)

• install_android_sdk 36 was downloading the full system-images;android-36;google_apis_playstore;x86_64 (~1.5 GB), but the emulator AVD is always created with API-34.
• Now only installs platforms;android-36 (needed for build-tools/apkanalyzer), saving ~1.5 GB of download and reducing the window for transient failures.

Fix 3 — adb install retry (android-test-run.sh)

• Adds a 3-attempt retry loop with back-off around adb install -r, since the emulator may be transiently unresponsive right after boot.

Fix 4 — Guard adb keyevent calls against transient exit 255 (android-uitest-wait-systemui.sh)

• Appends || true to all non-critical adb shell input keyevent and adb shell calls in the emulator boot-wait loop and post-boot setup.
• Under set -e, a transient exit 255 from adb shell input keyevent KEYCODE_ENTER (while dismissing an ANR dialog) was killing the entire script. The loop can now retry on the next iteration instead of aborting.
• Directly addresses the emulator ANR failure in canary build 205041 (Attempt 1).

Related

• Follow-up to feat: Test Android+Skia+NativeAOT on CI #1245 (feat: Test Android+Skia+NativeAOT on CI)
• Related to fix: Load explicitly mentioned assemblies, don't probe uno#22834 (NativeAOT startup fix)

Note: No related issue (CI maintenance).

[Copilot]

Pull request overview

This PR reduces Android NativeAOT instrumentation test flakiness in CI by adding retry logic around known transient failure points and by avoiding downloading an unused Android system image.

Changes:

• Add a sdkmanager --install retry wrapper with back-off to handle transient install/unzip failures.
• Stop downloading the unused API-36 emulator system image; install only the API-36 platform package.
• Add retry logic for adb install -r during emulator startup.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
build/scripts/android-sdk-emu.inc.sh	Adds sdkmanager_install() retry helper and skips downloading API-36 system image while still installing API-36 platform.
build/scripts/android-test-run.sh	Adds retry loop around adb install -r to tolerate transient emulator unresponsiveness.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Xiaoy312]

maybe 10x that value, 1~3s might not be enough to escape the same fate as previous attempt(s)
in grand scheme of things, 10~30s(1min total) is really nothing IF we can move forward

[jonpryor]

The problem is that we don't understand why it's failing in the first place. It just up and dies, with nothing in the log files. This makes it slightly annoying to reason about.