The API 37 preview E2E job (e2e-preview in ci.yml; the nonstandard google_apis_ps16k image) flakes on emulator boot — it has failed twice recently (#285, #333, both otherwise-green JVM-only PRs) with nothing but ::warning::API 37 emulator did not boot within 300s. We have zero visibility into why (KVM/accel? GPU swiftshader? bad image? kernel panic?), so re-running is shooting in the dark.
Goal
Make a boot failure self-explanatory: capture rich diagnostics by default so the next flake reveals its root cause without a re-run.
Scope
.github/workflows/ci.yml — the API 37 e2e-preview "Boot emulator and run E2E" step. Mirror the same into .claude/skills/preflight/api37_e2e.py (CLAUDE.md keeps the local preview run and CI in parity).
Verbose/debug emulator logging on by default: add -verbose -debug init,avd_config,kernel (or -debug all if not too noisy) to the emulator launch; keep redirecting to $EMU_LOG.
Always upload the emulator log as an artifact (actions/upload-artifact with if: always()) so it survives a cancelled/timed-out job.
Capture logcat + system state: start adb logcat -v time > logcat.txt & once the device registers; on boot-timeout, dump the tail of $EMU_LOG, adb devices, emulator -accel-check, /dev/kvm availability, GPU mode, free mem/disk, and the AVD config.ini — upload them too.
Print a concise failure summary to the step log on timeout (last ~50 lines of $EMU_LOG + accel/KVM status) so the cause is visible in the run output without downloading artifacts.
Keep the existing 2-attempt boot retry; the diagnostics apply per attempt.
Done when
A boot failure produces an uploaded emulator log + logcat + accel/KVM/config dump and a failure summary in the step output — root cause diagnosable without re-running. (This is diagnostics only; the actual flakiness fix is a follow-up informed by what these logs show.)
## Problem
The API 37 preview E2E job (`e2e-preview` in `ci.yml`; the nonstandard `google_apis_ps16k` image) flakes on emulator **boot** — it has failed twice recently (#285, #333, both otherwise-green JVM-only PRs) with nothing but `::warning::API 37 emulator did not boot within 300s`. We have zero visibility into *why* (KVM/accel? GPU swiftshader? bad image? kernel panic?), so re-running is shooting in the dark.
## Goal
Make a boot failure self-explanatory: capture rich diagnostics **by default** so the next flake reveals its root cause without a re-run.
## Scope
`.github/workflows/ci.yml` — the API 37 `e2e-preview` "Boot emulator and run E2E" step. **Mirror the same into `.claude/skills/preflight/api37_e2e.py`** (CLAUDE.md keeps the local preview run and CI in parity).
1. **Verbose/debug emulator logging on by default:** add `-verbose -debug init,avd_config,kernel` (or `-debug all` if not too noisy) to the emulator launch; keep redirecting to `$EMU_LOG`.
2. **Always upload the emulator log as an artifact** (`actions/upload-artifact` with `if: always()`) so it survives a cancelled/timed-out job.
3. **Capture logcat + system state:** start `adb logcat -v time > logcat.txt &` once the device registers; on boot-timeout, dump the tail of `$EMU_LOG`, `adb devices`, `emulator -accel-check`, `/dev/kvm` availability, GPU mode, free mem/disk, and the AVD `config.ini` — upload them too.
4. **Print a concise failure summary** to the step log on timeout (last ~50 lines of `$EMU_LOG` + accel/KVM status) so the cause is visible in the run output without downloading artifacts.
5. Keep the existing 2-attempt boot retry; the diagnostics apply per attempt.
## Done when
A boot failure produces an uploaded emulator log + logcat + accel/KVM/config dump **and** a failure summary in the step output — root cause diagnosable without re-running. (This is diagnostics only; the actual flakiness fix is a follow-up informed by what these logs show.)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The API 37 preview E2E job (
e2e-previewinci.yml; the nonstandardgoogle_apis_ps16kimage) flakes on emulator boot — it has failed twice recently (#285, #333, both otherwise-green JVM-only PRs) with nothing but::warning::API 37 emulator did not boot within 300s. We have zero visibility into why (KVM/accel? GPU swiftshader? bad image? kernel panic?), so re-running is shooting in the dark.Goal
Make a boot failure self-explanatory: capture rich diagnostics by default so the next flake reveals its root cause without a re-run.
Scope
.github/workflows/ci.yml— the API 37e2e-preview"Boot emulator and run E2E" step. Mirror the same into.claude/skills/preflight/api37_e2e.py(CLAUDE.md keeps the local preview run and CI in parity).-verbose -debug init,avd_config,kernel(or-debug allif not too noisy) to the emulator launch; keep redirecting to$EMU_LOG.actions/upload-artifactwithif: always()) so it survives a cancelled/timed-out job.adb logcat -v time > logcat.txt &once the device registers; on boot-timeout, dump the tail of$EMU_LOG,adb devices,emulator -accel-check,/dev/kvmavailability, GPU mode, free mem/disk, and the AVDconfig.ini— upload them too.$EMU_LOG+ accel/KVM status) so the cause is visible in the run output without downloading artifacts.Done when
A boot failure produces an uploaded emulator log + logcat + accel/KVM/config dump and a failure summary in the step output — root cause diagnosable without re-running. (This is diagnostics only; the actual flakiness fix is a follow-up informed by what these logs show.)