Add an Android CLI multi-run snapshot job - #27
Merged
Conversation
Runs the same four-cycle snapshot experiment as emulator-preview-multirun, but driven entirely by the Android CLI: emulator start/stop, run, screen capture and layout. `android emulator start` uses the SDK's emulator package and cannot target emulators/latest, so this exercises the canary emulator -- the two jobs together show how the same experiment behaves on each. Prototyped locally first. What that established: - `android emulator stop` writes the default_boot snapshot and a plain `android emulator start` loads it. Confirmed by "Loading snapshot 'default_boot'" in the emulator log and by start times of ~5s against ~20s for the initial cold boot. - No --cold is needed anywhere: a freshly created AVD boots cold by itself, and every later cycle must load the snapshot. - A Vulkan app might not always survive on snapshot load before emulator 37.2.x; it depends on which Vulkan features are in use. The job therefore never relaunches the app after a restore -- doing so would hide what is being measured -- and only drives input while the app is actually running, so it cannot tap a home screen at random. - `android layout` returns an empty tree for a NativeActivity, which has no view hierarchy. It is still captured, because it is the liveness signal intended for View/Compose apps, where it does return a full tree. The job logs an explicit "app survived restore: YES/NO" per cycle and greps the emulator log for snapshot activity, so the outcome is readable from the job log rather than inferred from screenshots. Non-blocking, like the other emulator experiments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The same four-cycle snapshot experiment as
emulator-preview-multirun, driven entirely by the Android CLI —emulator start/stop,run,screen capture,layout.android emulator startuses the SDK's emulator package and cannot targetemulators/latest, so this exercises the canary emulator. That is the point: the two multi-run jobs together show how the same experiment behaves on each emulator. It's an add, not a replacement.Prototyped locally first
Four cycles on this machine before writing any YAML. What that established:
android emulator stopwrites thedefault_bootsnapshot and a plainandroid emulator startloads it. Confirmed byLoading snapshot 'default_boot'...in the emulator log, and by start times of ~5s for cycles 2-4 against ~20s for the initial cold boot.--coldis needed anywhere. A freshly created AVD boots cold by itself, and every later cycle must load the snapshot.android layoutreturns an empty tree for aNativeActivity, which has no view hierarchy. It's captured anyway, because it's the liveness signal intended for the View/Compose apps — and it did return a full tree for the launcher, so the command works, just not against a raw Vulkan surface.Output
Each cycle logs
app survived restore: YES/NO, and the run ends by grepping the emulator log for snapshot activity — so the outcome is readable from the job log rather than inferred from images. Screenshots (entry and exit per cycle), layout dumps, logcat and the emulator log are uploaded.Runs headless under Xvfb, as the existing CLI job does — which also keeps stray host input out of the guest.
Non-blocking, like the other emulator experiments.