4 Commits

Author SHA1 Message Date
SoftwareApp b72847b822 Record the first complete benchmark run, and what its numbers are not
With the install watcher answering MIUI's dialog, all four tests ran and three produced numbers: coldStart 574.17 ms P50 (553.95-730.19), opening a 1000-file folder 14 frames P50 (13-17), scrolling it with four swipes 98 frames P50 (93-100). The search benchmark still fails, on the app bar's search action not being in the accessibility tree after twenty seconds - the setup wait is raised from ten to twenty now that the folder render is known to be the slow step.

The frame counts are labelled as frame counts and not as jank, because this phone reports no frame durations at all: the same results file contains frameCount and nothing else, so 14 frames says the interaction is short and says nothing about whether a frame was slow. The doc also keeps the measurements that explain the watcher's shape - the dialog is FLAG_SECURE, its lifetime varies between under a second and 8.5 s, and pm install from an app uid fails earlier with MIUI's XSpace SecurityException - along with the honest cost: MIUI keeps mCurrentFocus on the installer after the window is gone, so a coordinate tap can land on the home screen, which it did. The watcher no longer reuses a saved position at all and refuses to tap within two seconds of the previous tap.
2026-10-17 15:26:59 +02:00
SoftwareApp 456884a4d0 Stop the install watcher from dying quietly mid-run
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.
2026-10-17 15:00:24 +02:00
SoftwareApp 904b74773d Answer install dialogs without ever tapping a closed one
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.
2026-10-17 14:23:55 +02:00
SoftwareApp 08b48f53fc Watch for MIUI's install dialog and answer it only when its button is on screen
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.
2026-10-17 13:56:39 +02:00