It also turned out that Pilfer event seems to come in a
non-deterministic order relative to the events from the Main and TIS
sequences. So I moved it to its own sequence.
Change-Id: I5851aafb6d04398c5727712eaf8561916a30c4c5
The flake had disappeared, perhaps because of this logging, or,
hopefully, for some other reason.
Bug: 148313079
Change-Id: I636783d5fc71474dd443c143289c3ff74651835e
Activity tracker is accessed on a non-UI thread, which can cause a non-initialized
Launcher to be treated as initialized
Bug: 149022794
Change-Id: I6634a6aff891592369c16469bbe95a9ea611819c
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
When ENABLE_OVERVIEW_ACTIONS flag is enabled, swiping up from the nav
bar goes to overview if you hold, or the first home screen if you don't.
- Added NoButtonNavBarToOverviewTouchController, which extends
FlingAndHoldTouchController but only works if you start from the nav
bar. Otherwise it falls back to PortraitStatesTouchController to
handle normal state transition to all apps.
- Added HintState. This is where the workspace/hotseat/qsb scale down
when you swipe up from the nav bar, to hint that you're about to
either go to overview or the first home screen.
- Added getQsbScaleAndTranslation() to allow Overview and Hint states
to treat it as part of the hotseat.
- Since Overview needs to show above the QSB as it's animating, bring
Overview to the front and update OverviewScrim to handle the case
where there's no view above Overview to draw the scrim beneath.
- ENABLE_OVERVIEW_ACTIONS is always false in 2-button mode, since the
shelf is crucial to that mode.
Bug: 143361609
Change-Id: I743481bb239dc77f7024dc98ba68a43534da2637
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
