Fixed bug where certain focusable windows are reported to accessibility out of z order.
It is possible to have a window that is focusable but not touchable.
This was initially addressed with the fix in b/15432989, with the informative commit message:
"The APIs for introspecting interactive windows were reporting only
the touchable windows but were missing the focused window. The user
can interact with the latter by typing, hence it should always be
reported. Also this was breaking backwards compatibility as if the
focused window is covered by a modal one, the focused window was not
reporeted and this was putting the active window in a bad state as
the latter is either the focused window or the one the user is touching."
But the focusable window was added after all of the other windows were added, so that broke the expectation that the reported windows are in z-order.
I can imagine beyond the test this probably also incorrectly reported a situation where a touchable window was obscured by a focusable one.
So now we add it in the correct order, and we update the unaccounted regions appropriately.
The reason that this broke the test is that the overlay is displayed ABOVE the the installer, but it is reported as BELOW the installer.
This only broke on certain devices because the relative screen bounds of those two windows differed, in some situations the installer window obscured the overlay window.
Also, make this a little cleaner.
Fix: 115739549
Test: atest CtsPackageInstallerTapjackingTestCases, atest CtsAccessibilityServiceTestCases, atest CtsUiAutomationTestCases
Change-Id: Ia3b7ae01a7f8ef76eec79e6f1640c3464c4fe89a
1 file changed