ACTION_UP is always preceded by ACTION_DOWN which means when launcher
receives an UP events, down event is obviously sent.
In b/325377690 , we started seeing only in P9 devices the DOWN events didn't reach TAPL. I added InputDispatcher logs which shows both DOWN and UP events are sent by system_server to NexusLauncher.
However TAPL doesn't receive it. After spending lot of time debugging this, I think we are safe to remove DOWN event expectation in TAPL.
Bug: 325377690
Test: Manual, TAPL presubmits
Flag: NA
Change-Id: I6d3587c488d45e3dc53d2c1c4f3b6b49285eae94
Tests assert that input events come to Launcher only from tests, which
sets deviceId to 0. This way, we spot when a cable touches a lab device
and breaks the tests, in which case deviceId will be != -1.
But CANCEL event, which is programmatic, now can legitimately come from
device 0.
Bug: 308489875
Test: presubmit
Flag: N/A
Change-Id: I84ee9ed8e008043f83e82d57b17b64a10677ee8d
They are perceived to produce too much noise and maintenance.
Bug: 187761685
Test: presubmit
Flag: N/A
Change-Id: I062eb5670a92a2ccc7039108829b09ca9d9127ae
This variable is now mutable, making the uppercase format misleading.
For instance, users might assume they can use this value in other
immutable properties, when they really should be accessing the latest
value every time they need it.
Context: https://source.android.com/docs/setup/contribute/code-style#follow-field-naming-conventions
Test: Manual
Bug: 271160958
Change-Id: Iaaa51d9153cb8a7d686c72e1210b1948029dcfd5
This will help SysUI test team (who uses TAPL) to set up Gradle build for their tests.
Bug: 202567877, 234414088
Test: presubmit
Change-Id: I3d923ea4b54d1a4c3d2b345be09692727d30433e
There is a guaranteed order in which TIS events will be registered
relative to other TIS events. However, relative to the touch events
arriving to the activity, TIS events can come in any order.
Now the event checker verifies 2 independent ordered event sequences:
from TIS, and “the rest” (Main).
Change-Id: I5872e0e3b0b498050a91c67105fbe4a29411375a
Investigation of TAPL failures, especially flakes is complex, partially
because it’s hard to tell whether it’s Launcher who is wrong or the
system.
We need to introduce a framework that looks at Launcher interaction with
the system and reports when interactions deviate from the expected
course, and who made the first wrong step.
This is first, proof-of-concept CL.
It analyzes long-press events. We had multiple cases when long-presses
didn’t happen or happened unexpectedly.
Launcher registers the events, TAPL retrieves and compares against the
sequence of expected regular expressions. This diagnostic is used when
something fails and at the end of public methods.
Change-Id: I07aa3a027267c03422c99c73ccd8808445c55fe8
Anushree Ganjam
Vadim Tryshev
Brian Isganitis