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
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
Presumably, the flake was fixed when I added waiting for model load
before the test body starts.
Bug: 138729456
Change-Id: Ie921ebd40e42a7d73884c19949ca5f0129afc96e
Adding it permanently. System tests using TAPL sometimes run into
mysterious hard-to-diagnose problems (like, a menu opens for no apparent
reason), so we'll need to keep diags like this forever.
Change-Id: I25fcab94931fa4f6e1bda34d5705de5dd411188a
Clicking an icon within its padding area is ignored by Launcher. Hence,
ensuring that the whole icon is visible.
Bug: 141770616
Change-Id: I19e3ba7cfa25de75a47202845d0838bea46af92c
- There are two issues:
1) Currently the system does not add the task to the task list until
the activity starting the task has been resumed (to be fixed in a
follow up platform CL). When the three activities are started in
sequence, it's possible for one of the activities to not reach the
resumed state leading to an unexpected number of recent tasks the
next time it's fetched.
2) When swiping up, it may take time for getTasks to return and call
applyLoadPlan, so try and wait until the task views have had a
chance to be applied before continuing.
3) Use the launcher activity tracker instead of activity rule since it
will return the same activity even after the activity is destroyed
- Move the margin handling to the caller instead of the scroll method
Bug: 141580748
Change-Id: I2b7634f5ac6869ba4b369b3bd60e0f63747c0f0b
This CL adds a very low risk because most (but not all) changes affect
only Launcher behavior during the test.
This should fix a lab-only flake when all apps keeps changing while
the test is working with it.
Example: test figures out which icon to click, by the moment it clicks
there, there is another icon there, or the icon is under the search box,
and clicking opens IME.
Switching test devices to airplane mode didn't help. The earlier change
that prevents popup menu cancellation is not general enough.
Now the tests are given an API to explicitly freeze and unfreeze
all-apps, which should be a final solution.
Bug: 132900132
Bug: 133765434
Change-Id: I8b81cc9be004482beb6cdcdd05406e2d9b4c7629
This time, Launcher doesn't send a completion event upon switching from
Home to all apps.
Bug: 133867119
Change-Id: I3738cf10a14ea288df2dfda387aafda022beb349
