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
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
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
With this change, we can also render folders in preview. It's built on top of part 1.
Test: Go to grid options, choose a different grid option, and see user's workspace rendered in the preview
Bug: 144052839
Change-Id: Iaf6d8af6b909ece4147ea250d95dec3d2c0019d3
Starts by showing a notification, which will open a dialog
with options for users to keep their hotseat layout or fully
migrate to hybrid hotseat
Bug:142753423
Test:Manual
Change-Id: I178de612837ec8551f6776fa7c6fb6111bc7431d
Presumably, the flake was fixed when I added waiting for model load
before the test body starts.
Bug: 138729456
Change-Id: Ie921ebd40e42a7d73884c19949ca5f0129afc96e
FolderIcon#mDotInfo is stored per instance, but not kept up to date
when re-binding on rotation.
Bug: 144369875
Change-Id: Ia429e4b4039eb02fb4587f54e33a0717408e4ac2
> Adding multi-thread support
> Simulating actual loader loading flow
> Moving some android tests to robolectic
Change-Id: Ie17a448f20e8a4b1f18ecc33d22054bbf9e18729
Also don't update distance dragged until drag actually starts
(otherwise we add a lot of motion before deep press triggers).
Bug: 146146413
Change-Id: I28bd23707a9be53c709d7a4e779e84b9a0be9ce2
Two changes for the latest Compose prototype:
1. Pass the identity of the underlying app to the Overscroll plugin.
2. Enable the Compose gesture over an app when there's a Recents extra
card plugin active (otherwise the current app won't count as the
rightmost one).
Some changes to the gesture:
- Angle decreased from 35° to 25° to remove overlap with
Assistant gesture
- Distance increased from 8 to 110 dp. 110 dp is 2x the Assistant
gesture and roughly the same as scrubbing into an app from Home.
- Fling detection added; uses same distance threshold, 110 dp.
- If a touch was recognized as another gesture, the touch will not be
reinterpreted as a Compose gesture, no matter what touch movement occurs
- Fixes issue where Assistant + Compose could both be triggered
- Fixes issue where scrubbing apps to the left, then back to the right,
would bring in Compose. i.e. if a touch down + touch movement starts
bringing in Assistant UI elements, then, the user moves their touch
below the Assistant angle, the Compose gesture will not start
being recognized
- Gesture length required for fling lowered from 110 dp to 40 dp, per
tuning with PM.
Bug: b/146508473
Change-Id: I414573d1a92684d1d992837a5f1df522346ec211
Even though ActivityTaskManager already logs intents, logging this will
simplify flake/error investigations that are considered to be too
time-consuming.
Also, this will make it possible in future to programmatically detect
whether the bug is introduced by the system or Launcher.
Bug: 133010698
Change-Id: I7dcadd95baa23f29bb661d6b42280bd2a2f0e099
