E2E jobs fail frequently at the Set up Android SDK step (the android-actions/setup-android action), BEFORE the emulator starts:
Wrong version in preinstalled sdkmanager
Warning: ... preparing SDK package Android Emulator: Error reading Zip content from a SeekableByteChannel.
Error: The process '.../sdkmanager' failed with exit code 1
Seen on E2E (31) + E2E (35) (PR #375 run) and a #388 preview shard (that time the "SDK Tools" package). It is a corrupt/truncated SDK-package download and/or a preinstalled-sdkmanager version mismatch on the runner image. Because it is upstream of the emulator, #388's boot diagnostics cannot catch it. This is the dominant flake blocking merges right now.
Fix
Retry the SDK/emulator setup so a corrupt download re-fetches instead of failing the job.
Cache the SDK packages so they are not re-downloaded (and re-corrupted) every run.
Resolve the "Wrong version in preinstalled sdkmanager" path (pin cmdline-tools and/or the setup-android action version; investigate whether a newer action version fixes it).
Apply across every job that sets up the Android SDK/emulator (the e2e matrix + e2e-preview; check debug-build/unit-tests/static-analysis too).
Acceptance
A transient corrupt-zip no longer fails the job outright — the SDK step self-heals (retry) and/or uses a cached SDK. Validated by the PR's own CI going green.
Relates to #387/#388 (diagnostics — this is the "make it stop" complement).
## Problem
E2E jobs fail frequently at the **Set up Android SDK** step (the `android-actions/setup-android` action), BEFORE the emulator starts:
```
Wrong version in preinstalled sdkmanager
Warning: ... preparing SDK package Android Emulator: Error reading Zip content from a SeekableByteChannel.
Error: The process '.../sdkmanager' failed with exit code 1
```
Seen on E2E (31) + E2E (35) (PR #375 run) and a #388 preview shard (that time the "SDK Tools" package). It is a corrupt/truncated SDK-package download and/or a preinstalled-sdkmanager version mismatch on the runner image. Because it is upstream of the emulator, #388's boot diagnostics cannot catch it. This is the dominant flake blocking merges right now.
## Fix
- **Retry** the SDK/emulator setup so a corrupt download re-fetches instead of failing the job.
- **Cache** the SDK packages so they are not re-downloaded (and re-corrupted) every run.
- Resolve the **"Wrong version in preinstalled sdkmanager"** path (pin cmdline-tools and/or the `setup-android` action version; investigate whether a newer action version fixes it).
- Apply across every job that sets up the Android SDK/emulator (the `e2e` matrix + `e2e-preview`; check debug-build/unit-tests/static-analysis too).
## Acceptance
A transient corrupt-zip no longer fails the job outright — the SDK step self-heals (retry) and/or uses a cached SDK. Validated by the PR's own CI going green.
Relates to #387/#388 (diagnostics — this is the "make it stop" complement).
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
E2E jobs fail frequently at the Set up Android SDK step (the
android-actions/setup-androidaction), BEFORE the emulator starts:Seen on E2E (31) + E2E (35) (PR #375 run) and a #388 preview shard (that time the "SDK Tools" package). It is a corrupt/truncated SDK-package download and/or a preinstalled-sdkmanager version mismatch on the runner image. Because it is upstream of the emulator, #388's boot diagnostics cannot catch it. This is the dominant flake blocking merges right now.
Fix
setup-androidaction version; investigate whether a newer action version fixes it).e2ematrix +e2e-preview; check debug-build/unit-tests/static-analysis too).Acceptance
A transient corrupt-zip no longer fails the job outright — the SDK step self-heals (retry) and/or uses a cached SDK. Validated by the PR's own CI going green.
Relates to #387/#388 (diagnostics — this is the "make it stop" complement).
Completed via PR #391 (merged). Closing + moving the board item to Done — it was left stuck In Progress.