Tests that check for all apps in overview mode were only checking for
actions being enabled. This isn't sufficient logic, two button mode also
uses all apps.
Centralize the check for all apps.
Test: local tapl tests
Change-Id: If1bf98019e6f1aea8f7967883aba6780743e9d6b
Overview actions removes the all apps from overview. Don't run the tests
that depend on these.
Ultimately need to add more tests for the actions.
Test: tapl local
Change-Id: I2471d10af7bc03a40a94f99aa16354b85bdb3ad7
It tests UiDevice.pressRecentApps(), which we don't use, so we don't
need to test it.
Bug: 131115533
Change-Id: I3a1b31f3b8368e3c848c888a5a27577faa940832
* changes:
Translate recents slightly while dragging after pausing
Two-zone model: swipe up from nav bar vs above it
Change LauncherState to Supplier<LauncherState> in tests
This prevents the test from statically initializing LauncherState and
all its static dependencies, which might lead to runtime exceptions in
out-of-proc tests.
Change-Id: I0e4e09dfb31a8b256c2c0c0b3d1d2ecd0cc92230
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
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
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
Logging assertion failures.
Modifying waits for condition to avoid timing out the whole test if the
iteration takes too long in favor of failing with an actionable diag.
Bug: 145985438
Change-Id: Ie32d93e1548ce6ec64c38449eb1be1287ff9cf56
Improving state events accounting hasn't completely solved flakiness.
I've noticed that swiping up in 0-button mode sometimes doesn't open
Overview.
Bug: 143488140
Change-Id: I660885ed556aa2953c17d491fde267734b95890b
Checking for events whenever Launcher sends them.
Checking for correct events (final events, not for events from
intermediate state changes).
This should simplify diagnosing of bugs involving TAPL.
This is also supposed to fix Fallback overview tests.
Bug: 143488140
Change-Id: If053ed808ec71bf2b652ab680be5bdfe9ff8cbb9
Even though they don't block presubmit, the fact that they are failing:
1. Causes sheriffs no not notice other issues;
2. Would block switching to 24hr fix-it policy and Quarterdeck.
Bug: 143488140
Change-Id: I95e3e15b69e0487946919f3f6889e286a1fae141
Now, for example, we won't diagnose a locked phone as a
"home button not showing in 3-button mode", even though it's technically
correct.
Change-Id: Ibdfa0741af7ff8545a811f6702dda74dc6c31c2e
Instead of starting getAppPackageName() and relying on it being our Test
Pin Item activity, instead launch our own test activities with the
FLAG_ACTIVITY_MULTIPLE_TASK and FLAG_ACTIVITY_NEW_DOCUMENT flags.
Test:
- Locally run testQuickSwitchFromApp() from Android Studio
- flake -oop -t com.android.quickstep.TaplTestsQuickstep#testQuickSwitchFromApp
Bug: 140252765
Change-Id: Ie137261ce65bfd3dd39df78d57784854a026e967
1. Skip all tests that fail in inproc mode on CF (this CL)
2. Observe postsubmit and make sure no inproc tests are failing or too
flaky on CF
3. Enable presubmit
4. Switch to skipping tests from step 1 only for inproc presubmit;
they'll start failing in postsubmit
5. Gradually make all tests pass and not flaky and enable them back on
presubmit
Bug: 142828227
Change-Id: I0092d6b92b0358866f8cbf9e00dbe3fabe23703d
The plan:
1. Skip all tests that fail in inproc mode on CF (this CL)
2. Observe postsubmit and make sure no inproc tests are failing or too
flaky on CF
3. Enable presubmit
4. Switch to skipping tests from step 1 only for inproc presubmit;
they'll start failing in postsubmit
5. Gradually make all tests pass and not flaky and enable them back on
presubmit
Bug: 142828227
Change-Id: I6ea3d53771503e8fd968555bb2e4cb1be10d83ef
It should swipe from the bottom right to top right when the nav bar is
on the right, rather than from the bottom left to bottom right.
For now, disable testQuickSwitchFromApp() because it seems to have
other failures as well.
Bug: 140252765
Change-Id: I1f4989f3ea5456c18bb9cbf42ea4b157cee500d7
Test is failing and blocking drop.
Only failing on TH, passing locally.
Tracked in b/141579810
Bug:141579810
Change-Id: Iadf8098cad22835b026984c0a9ea5122054b484b
- 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
- Workaround issue where instrumentation will fail to finish an activity
causing the activity to linger longer than expected (leading to issues
with ordering of static resources like the app widget host registration)
- Fix calculation for scrolling the screen, the previous calculation
would result in the gesture starting at the left gesture margin due
to rounding which can trigger a back action instead of the desired
scroll
Bug: 142351228
Change-Id: I34bdb471030518d2b983cac2badd4d8b0e7d571b
