You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 15, 2026. It is now read-only.
In wa/workloads/geekbench/uiauto/app/src/main/java/com/arm/wa/uiauto/geekbench/UiAutomation.java method UiAutomation.waitForResultsv3onwards:
The method looks for the TextView containing the word Running which is on the test progress modal. Presumably in previous versions this simply said Running so the same TextView was present for the duration of the test, but in more recent versions the text is updated with the current test stage (e.g. Running file compression) and the "update" apparently happens by removing the previous TextView and creating a new one. This results in the UI automation detecting that the test has completed early (<1s on my Pixel 6).
A, possibly non-ideal, fix is to rewrite the function like this:
In
wa/workloads/geekbench/uiauto/app/src/main/java/com/arm/wa/uiauto/geekbench/UiAutomation.javamethodUiAutomation.waitForResultsv3onwards:The method looks for the
TextViewcontaining the wordRunningwhich is on the test progress modal. Presumably in previous versions this simply saidRunningso the sameTextViewwas present for the duration of the test, but in more recent versions the text is updated with the current test stage (e.g.Running file compression) and the "update" apparently happens by removing the previousTextViewand creating a new one. This results in the UI automation detecting that the test has completed early (<1s on my Pixel 6).A, possibly non-ideal, fix is to rewrite the function like this:
This will wait for the final
Runningto be removed.