Launcher tests will still perform checks upon every gesture completion.
All tests using tapl will still use events for diagnostics if the
gesture fails.
The benefit is that system health and other platform tests won't have to
use expensive logcat, and moreover, wait seconds for the events to
appear in logcat because of buffering in logcat.
Change-Id: I3b5a0965d9432144d0c4a8b40ebe2fa89b19a689
This will catch cases, for example, when the platform stops delivering
injected events to Launcher, or injects unexpected events, like Back
Button.
Also optimizing and fixing incorrect behavior of calculating the start
time for the event collection.
Change-Id: I2ba0108e6bfa112f2905a05bcb327b148ec08f77
Reshuffling the tests to make the investigator the outmost rule and run
the code that throws the original exception inside the investigator.
Change-Id: I714717a9b616862db5ce59116138ba7ea6ceb971
It often takes a long time to fix a flake; meanwhile it takes a lot of
time for sheriffs to identify whether to register a new flake for a
failure.
This CL adds automatic identifies identification of one know flake type.
Once identified, it rewrites the error so that:
1. Flakes clustering tool that has only rudimentary clustering, places
all flakes of this kind in the same cluster (not multiple ones like
now). This is a step towards using clustering tool for monitoring
flakes;
2. Sheriff immediately sees that the issue is known.
Change-Id: I86a0762665cb21434289e1be00b60bd76fec4142
There is some unknown to me logic in Launcher that sometimes duplicates
the long-press event . This causes flakes whenTAPL expects one long
press, but the actual sequence is 2 events.
That duplication logic seems to be related to race conditions is is hard
to repro. For now, just removing long-press verification. I'll start
with more deterministic events.
Bug: 147806932
Change-Id: I03841131bf8cae88011824f660f2c7b1906592f4
Getting events is an expensive operation involving reading logcat. We
did this al least twice even if the number of events was already
sufficient. Fixing this.
Change-Id: I5bfb57e3b573c4fc3f0327512327750dbb35af2f
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
I suspect that when the test starts, launcher package may be
com.google.android.setupwizard
Bug: 145935261
Change-Id: Ibf5e9785cd73762cbf2cdc8569482d77db782897
Clients of BaseSwipeDetector are required to call finishedScrolling(),
which calls setState(IDLE). An obvious place to call this is in
onDragEnd(), which itself is called from a setState(SETTLING). If the
client does this, then the SETTLING state actually clobbers the IDLE
state, leading to undefined behavior. The reason we don't see this in
practice is because we usually call finishedScrolling() after an
animation from onDragEnd() instead of calling it immediately.
To fix this, we add a simple queue such that any calls to setState()
while one is in progress have to wait and are executed in turn. This
ensures we get all the proper state callbacks and end in the correct
one.
Also fix an incorrect call in AbstractStateChangeTouchController which
was masked by this bug. We were calling setState(IDLE) in onDragStart(),
which only worked because the original setState(DRAGGING) incorrectly
clobbered this. Now we only setState(IDLE) (via finishedScrolling())
when we fully clear the state, i.e. when the interaction is finished.
Test: added testInterleavedSetState
Bug: 141939911
Change-Id: Iae630ee7101921b57a85d40646468cf19f59b674
In scenarios like: atest NexusLauncherOutOfProcTests against the
platform built from command line, and Launcher from the platform, we are
not failing now, and @Stability treats it as a PLATFORM_POSTSUBMIT run.
Change-Id: Ia504216d238e58b2786f3749b737dfb95a2ede96
compare pid of launcher process after test execution to verify launcher isn't crashed when running in oop test.
Bug: 147235759
Change-Id: Id13c47f5c4e388cc8e95b19d099e94a2e540bf3f
Test: fun flake locally
> Adding multi-thread support
> Simulating actual loader loading flow
> Moving some android tests to robolectic
Change-Id: Ie17a448f20e8a4b1f18ecc33d22054bbf9e18729
In a879f9c481, the ub-launcher-aosp-tapl
was switched from current to system_current. Since Launcher3Tests links
against this library, we require it to use the system stubs as well.
But I broke the check in the build system while doing some cleanup, so
we never noticed. I'm fixing the check in:
https://android-review.googlesource.com/c/platform/build/+/1156840
Bug: 143748700
Test: treehugger
Change-Id: Ifcf47b19f7ed8f907e437325b4fd6a599fcca4cf
(cherry picked from commit 981ec8b789)
AS installs tests in such a way that they don't get necessary
permissions; the result is a long message starting with "Failed to get
system health diags" when a test fails.
While I'm looking for a good solution, removing this annoyance.
Change-Id: I9e439c3aefb9dd365c841c98d530b9346d7ccd10
Vadim Tryshev
Sunny Goyal
TreeHugger Robot
Adam Cohen
Tony Wickham
Pinyao Ting
Dan Willemsen
Tracy Zhou