You called this one: the watcher was not running any more, and the reason was mine. It ran under set -euo pipefail, and two helpers ended in a pipeline to head -1; when head exits first sed takes a SIGPIPE, pipefail turns that into a failed assignment and -e turns that into an exit. So the script answered the first dialog or two and then vanished without a word, which is exactly what a run that stops after its first install looks like. It now runs without -e, the helper pipelines end in || true, and it prints a heartbeat every thirty seconds so is it still running can be answered from the log.
Measured after the fix: two consecutive uninstall/install cycles both succeeded, the script stayed alive through a 75 s watch, and in a full benchmark run it was still alive at the end with two dialogs answered. That run lasted 1m29s instead of the previous 35s and one test got as far as driving the app, so the installs do sometimes get through now. One was still refused, and the run still failed overall.
Three things went wrong in this script and are fixed here, each with the run that showed it. It remembered a button position and tapped it without re-checking the dialog was still there, so a tap landed on the Telegram icon on the home screen behind a dialog that had already closed; it refused to answer a second dialog because it compared window tokens, and every dialog gets a new one, so the third install in a run was skipped; and its idle poll was so slow that a pair of installs could not both be caught. Now: the position is only used while an installer window is focused, re-checked immediately before the tap; a newer dialog with the same installer activity is answered rather than skipped; and after every dialog the script watches at 0.4 s for the follow-up install. Verified with two consecutive uninstall/install cycles, the second answered from the measured position five seconds after the first, and by installing the release APK with only the watcher running. The benchmark's own reinstall is still refused - two dialogs answered during one run, both with the installer focused, and pm install still returned Install canceled by user, because MIUI closes the dialog when the session is over.
macrobenchmark installs its target before measuring it, and on this phone MIUI puts that install behind com.miui.securitycenter/.permcenter.install.AdbInstallActivity. The test cannot answer it: CompilationMode.installPackageFromPaths runs `pm install -t ...` through Shell.executeScriptCaptureStdout, so the call blocks until the child exits and no test code is running while the dialog is up. This script runs beside the Gradle run and taps the Install button instead.
It never taps blindly. Every five seconds it asks who has focus; if that is the installer, it reads the screen and taps the bounds of a button whose label is an install word - or, failing that, MIUI's own button2 id - and if no such button appears within ten seconds it taps nothing and says so. The first version guessed at the dialog's layout when the screen could not be read, which is what made it click whatever happened to be at the guessed coordinates; that code is gone. Reading the screen costs three to four seconds per dialog, which is the price of never pressing the wrong thing.
Measured limits, in the script's own comment: for an install started from adb the dialog appears after 1.7 s and counts down from about ten, so a five second poll leaves time to read and tap; for the install macrobenchmark starts inside the test, the window is focused for under a second and is FLAG_SECURE (a screencap of the focused dialog shows the home screen behind it), so that dialog cannot be answered by this script or by a human. The durable fix is the MIUI developer option the dialog is named after, Install via USB.
SoftwareApp