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
> Adding retry to fallback recents tests
> Fixing provider test after provider name change
> Fixing AllApps icon detection when there is no more scroll available
Bug: 141390432
Bug: 141523101
Bug: 141517004
Bug: 141524555
Bug: 141522764
Change-Id: I425638d20c053206134835dabde819f16160f035
Now getting diags though the test process that has right permissions.
This doesn't fix other failures in fallback tests.
Bug: 141517004
Change-Id: Ibba5f0471a83525a64544c62dbe82ab3e11712cd
Merged-in: Ibba5f0471a83525a64544c62dbe82ab3e11712cd
Now getting diags though the test process that has right permissions.
This doesn't fix other failures in fallback tests.
Bug: 141517004
Change-Id: Ibba5f0471a83525a64544c62dbe82ab3e11712cd
