Perhaps, due to a framework bug, events sometimes don't get delivered to
TIS; this doesn't seem to cause user-visible problems.
Later we'll need to investigate why this happens.
Bug: 154157191
Change-Id: I25f45ccab10f6c537c14610e40c2d02d2d3f28ad
-> Synchronize calls in LoaderTask.java
issue 156041043
-> Remove non system users on setup
If a work test crashes before getting to run its teardown - we might end up with a user profile that could throw off subsequent tests.
issue 156022161
Test: Manual
Change-Id: Ife708a3de01572f7cb2187078d592d8d570dd951
Test RequestPinItemTest.testPinShortcut doesn't wait for the add-to-home
prompt to disappear before proceeding to pressHome. So sometimes
pressHome still sees that prompt that disappears while pressHome is
executing.
Now waiting for the prompt to disappear.
Bug: 155926212
Change-Id: I2c7bfe26839ae406da592e81de8836666c373756
This call is relatively expensive. Perform only cheap launcher crash
test, and do anomaly only if there are problems.
Change-Id: If45567bcedf8d177970739e9de95cbb29add744c
They were not especially useful in investigations; besides, these events
can be sent by the system asynchronously for actions that happened
before entering TAPL, causing flakes.
Change-Id: I72b5aad5521c6c0969f5b657b3db3e4d855f1d64
This is tightening the makeshift strictmode criteria.
Starting with this moment, we will know that there is
no memory growth during tests execution, which is a big deal.
Big: 139137636
Change-Id: I5edc84524463bd1736d727496ad0fc031bb9624c
Strictmode leak detector is still a goal, but we might not be able to
achieve it in R. Strictmode has several framework-side bugs that perhaps
hide Launcher-side strictmode violations, while the time to fix
everything is limited, and new leaks get introduced all the time.
For now, implementing a check that is slightly more relaxed than
Strictmode, but still ensures the absence of leaks. I’ll keep
eliminating Strictmode violations as well as keep strengthening the
makeshift checker conditions until we’ll be able to enable Strictmode in
continuous testing.
I’m disabling Strictmode checks for now so that they don’t generate
unnecessary hprof dumps, but leaving the code dealing with strictmode.
Bug: 139137636
Change-Id: Ib10136b0d4e9892f70a19cd052ae5a54cf0a4efb
Now doing this before branching points, thus avoiding flakes when the
execution can go to an unexpected branch and not produce an event.
Bug: 153824894
Change-Id: If117da0498eaf2d94c9610552724981be34c6569
On the Launcher side, moving setLayoutFrozen from the posted action to
avoid a possible short scrollable period just after the view is shown.
Bug: 152354290
Change-Id: I7319236d8a6e49a7e017fd54d593ee131dff10a9
Also avoiding scrolling widgets horizontally when the gesture could
happen in the lower system gesture area.
Change-Id: I80192db7e407f8c1715aad3b96178c00b5710e71
Slight revert of ag/10668129 with adjustment
of disabling it for tests.
Fixes: 151456795
Test: Ran the labtest command for OOP
tests for crosshatch (where this issue
was first detected)
Change-Id: I315d138c2e4a6d4068304e9b5fb2e1b7feb34e63
Also fixing duplicate long press events resulting from both framework
and Launcher own detection reporting long presses.
Change-Id: Ib46de5bd60850f1c5578992c8c1172ddbc0961f3
