Preview multi-run: never relaunch the app, and bound the adb polls - #28
Merged
Conversation
Two problems, both in the preview multi-run job.
The job issued `am start` unconditionally on every cycle, including after a
snapshot restore. Whether the app comes back by itself is the question this
job exists to answer, so launching it there answers it for the emulator. It
happened to be invisible because the preview emulator does restore the app,
so the launch was a no-op ("Activity not started, intent has been delivered
to currently running top-most instance") -- but had a restore ever dropped
the app, the relaunch would have produced a healthy-looking screenshot and
hidden it. Now only cycle 1 launches; later cycles report
"app survived restore: YES/NO" and are left alone, matching the Android CLI
multi-run job so the two are directly comparable. Input is only driven while
the app is actually running, so a dead app cannot leave taps landing on the
home screen.
The polling loops also called adb without a timeout. adb blocks indefinitely
against a wedged device, so the loops never iterated, the nominal 180s and
480s budgets never applied, and the "boot timeout" branch never ran. One run
sat silent for 23 minutes after "Snapshot 'default_boot' loaded" and was then
killed by the step timeout with no diagnostics. Each adb call is now bounded
and the failure paths dump the tail of the emulator log, so a hang reports
within its budget and says something useful.
The hang itself looks intermittent -- twelve runs of this job passed before
it and the run straight after it passed too -- and is not addressed here.
The new tap guard reads the app pid to decide whether to drive input, but a single pidof query races the launch and can come back empty while the process is still starting. That suppressed the taps in cycle 1, so the game stayed on the TITLE screen -- auto-play only pilots during PLAYING -- and the cycle played ~6s against ~25s for the others. Poll for the pid the way the Android CLI multi-run job already does.
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.
1. The app is never relaunched after a restore
The job issued
am startunconditionally on every cycle, including after a snapshot restore. Whether the app comes back by itself is the question this job exists to answer — launching it there answers it for the emulator.It was invisible because the preview emulator does restore the app, so the launch was a no-op:
But had a restore ever dropped the app, that same line would have relaunched it and produced a healthy-looking exit screenshot, hiding the failure entirely.
Now only cycle 1 launches. Later cycles report
app survived restore: YES/NOand are left alone — matching the Android CLI multi-run job, so the two are directly comparable: same measurement, different emulator. Input is only driven while the app is actually running, so a dead app cannot leave taps landing on the home screen.2. The adb polls are bounded
The polling loops called
adbwithout a timeout.adbblocks indefinitely against a wedged device, so the loops never iterated — the nominal 180s and 480s budgets never applied and theboot timeoutbranch never ran.That is why the previous run sat silent for 23 minutes after
Snapshot 'default_boot' loaded in 2488 msand was killed by the 25-minute step timeout with no diagnostics at all.Every adb call in the loops is now wrapped in
timeout, and the failure paths dump the tail of the emulator log. A hang now reports within its budget and says something useful.On the hang itself
Not addressed here, and it does not appear to be caused by any recent change: the
emulator-preview-multirunjob passed 12 consecutive runs before this failure, the job and the composite action were byte-identical to the previous passing commit, and themainrun immediately after passed as well. It looks intermittent. This PR makes it diagnosable rather than silent, which is the prerequisite for chasing it if it recurs.