This causes nondescript diags "Test failed to run to completion.
Reason: 'Instrumentation run failed due to 'Process crashed.''. Check
device logcat for details"
Now quietly skipping all consequent tests after such failure.
Change-Id: I3747cda1a3094bfe82e27eae39ba9e9dfd4af9b6
Logcat may return records before the time requested via -t.
Filtering them out.
Also using year in date, to avoid failing during new year night.
Change-Id: I3c84d5fdf7882b3f551a1d430aa906fe1ae67aa7
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
This will catch cases, for example, when the platform stops delivering
injected events to Launcher, or injects unexpected events, like Back
Button.
Also optimizing and fixing incorrect behavior of calculating the start
time for the event collection.
Change-Id: I2ba0108e6bfa112f2905a05bcb327b148ec08f77
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
It often takes a long time to fix a flake; meanwhile it takes a lot of
time for sheriffs to identify whether to register a new flake for a
failure.
This CL adds automatic identifies identification of one know flake type.
Once identified, it rewrites the error so that:
1. Flakes clustering tool that has only rudimentary clustering, places
all flakes of this kind in the same cluster (not multiple ones like
now). This is a step towards using clustering tool for monitoring
flakes;
2. Sheriff immediately sees that the issue is known.
Change-Id: I86a0762665cb21434289e1be00b60bd76fec4142
There is some unknown to me logic in Launcher that sometimes duplicates
the long-press event . This causes flakes whenTAPL expects one long
press, but the actual sequence is 2 events.
That duplication logic seems to be related to race conditions is is hard
to repro. For now, just removing long-press verification. I'll start
with more deterministic events.
Bug: 147806932
Change-Id: I03841131bf8cae88011824f660f2c7b1906592f4
Getting events is an expensive operation involving reading logcat. We
did this al least twice even if the number of events was already
sufficient. Fixing this.
Change-Id: I5bfb57e3b573c4fc3f0327512327750dbb35af2f
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
I suspect that when the test starts, launcher package may be
com.google.android.setupwizard
Bug: 145935261
Change-Id: Ibf5e9785cd73762cbf2cdc8569482d77db782897
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
In scenarios like: atest NexusLauncherOutOfProcTests against the
platform built from command line, and Launcher from the platform, we are
not failing now, and @Stability treats it as a PLATFORM_POSTSUBMIT run.
Change-Id: Ia504216d238e58b2786f3749b737dfb95a2ede96
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
> Adding multi-thread support
> Simulating actual loader loading flow
> Moving some android tests to robolectic
Change-Id: Ie17a448f20e8a4b1f18ecc33d22054bbf9e18729
In a879f9c481, the ub-launcher-aosp-tapl
was switched from current to system_current. Since Launcher3Tests links
against this library, we require it to use the system stubs as well.
But I broke the check in the build system while doing some cleanup, so
we never noticed. I'm fixing the check in:
https://android-review.googlesource.com/c/platform/build/+/1156840
Bug: 143748700
Test: treehugger
Change-Id: Ifcf47b19f7ed8f907e437325b4fd6a599fcca4cf
(cherry picked from commit 981ec8b789)
AS installs tests in such a way that they don't get necessary
permissions; the result is a long message starting with "Failed to get
system health diags" when a test fails.
While I'm looking for a good solution, removing this annoyance.
Change-Id: I9e439c3aefb9dd365c841c98d530b9346d7ccd10
I suspect that some tests using TAPL run under pressure (mem or CPU,
created either intentionally or as a result of a leak somewhere)
where test process may generate a pause between DOWN and MOVE events
enough to be recognized as a long tap, which opens a context menu
instead of swiping.
While the clean solution is b/140252325, this is a workaround.
Bug: 144853809
Change-Id: I135eaee608270b7e60bb072cb360632763cbe5c5
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
Updating various static objects to use a standard pattern so that
it is easier to track and cleanup those objects
Bug: 141376165
Change-Id: Ia539cbfa338d544dddad771c5027b6748762768b
> Changing the lifecycle to follow other static objects in Launcher
> Removing compat interface and inlining everything to helpers
Bug: 141376165
Change-Id: I82bd5db1969101de9a7eac77f32728d70195bb35
I suspect that sometimes APIs return versions that are different from
ones in the bugreport. We want to see them before possible non-match
failures.
Bug: 145935261
Change-Id: Ia1a9208de111368245eac9147ae4a189db823105
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
Also keep the 3P launcher's alpha at 0 during the gesture, and
don't send the home intent if user touches during the transition.
Bug: 139682945
Change-Id: Ie758f0b337bb173b34f5585ec1915b7ea1145094
Not the last row. This fixes tests broken after some assumption broke in
platform at an unknown moment.
Since the gesture distance became smaller in some cases, the speed of
the gesture became slower, and on some devices, the scroll gesture
triggers icon dragging.
To prevent this, I reduced the number of steps in the gesture to 10, but
added a slow-down at the end of the gesture to avoid inertia.
Also made some names and calculations clearer.
Bug: 144180777
Change-Id: Ie6c5776606ecff64d553fa836bdb3d90f32c5d9e
Clicking an icon within its padding area is ignored by Launcher. Hence,
ensuring that the whole icon is visible.
Bug: 141770616
Change-Id: I19e3ba7cfa25de75a47202845d0838bea46af92c
Not the last row.
Also scrolling in the middle of All Apps, not at the top, because
otherwise the scroll can start on search box.
Bug: 144180777
Change-Id: I219faec165b8b403530a9c09d419cc453aea6039
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
This will allow subclassing BitmapInfo to support custom icon/dynamic
icons which can be loaded on the background thread instead of going
through IconFactory which runs on UiThread
Change-Id: Ieced6e91330bdff1b505826d097a8df711dfe967
- Regression from ag/9592395, bump the time of scrolling to the
last visible row slightly to prevent a fling
Bug: 141484300
Change-Id: I41c041fe591aceebc63b7e869a705164babb09ea
Existing clients now use the SingleAxisSwipeDetector subclass. A
followup CL will add BothAxesSwipeDetector, whose first client will be
the quick switch from home controller.
Bug: 126596417
Change-Id: I54c71088cfe99ff28cdc719a1eb7a7d06ac95d2d
Merged-In: I54c71088cfe99ff28cdc719a1eb7a7d06ac95d2d
Existing clients now use the SingleAxisSwipeDetector subclass. A
followup CL will add BothAxesSwipeDetector, whose first client will be
the quick switch from home controller.
Bug: 126596417
Change-Id: I54c71088cfe99ff28cdc719a1eb7a7d06ac95d2d
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
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
Merged-In: Ie137261ce65bfd3dd39df78d57784854a026e967
- All apps swipe up 1s -> 200ms (doesn't matter if it's a fling)
- Scroll to last visible row 2.5s -> 1.25s (seems sufficient to not be a fling)
- Drag icon to workspace 2s -> 500ms (seems sufficient to not be a fling)
- This changes the total frames produced for the jank tests, but should not
change the jank proportion or the individual frame drawing times
Bug: 141484300
Change-Id: I9f2e647ebc2c27c6269238daa4c3e6ad314c8161
Signed-off-by: Winson Chung <winsonc@google.com>
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
It was temporarily raised to 60 sec.
https://googleplex-android-review.git.corp.google.com/9563509
should've fixed some problems with loading time, but likely not all.
We need to observe whether this test starts flaking again.
testDragIcon will run only in Launcher postsubmit, and won't block
merges to platform if it fails.
Bug: 142514365
Change-Id: I2b9a9d043346ebda721221cefd6118a1a799501f
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
- Adding trace tokens since we can be starting/ending traces out of order
- Fixing issue with draw hitting twice causing the trace stack to be
popped twice
- Fix issue with endFlagOverrides not removing from the stack
Bug: 142803200
Change-Id: I8649b94249910a352f00f2f2c2459c355d2bab00
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
The test case testDragCustomShortcut was created initially to prevent future regression on custom shortcut (b/141568904), which was caused by ag/9342399.
Some times after ag/9342399 was reverted on ub-launcher3-master, a different error is causing custom shortcut to not working intermittently (b/141528961). Since this is different from b/141568904, it should not be a blocker to merging to master.
Bug: 141568904
Change-Id: Ia11e1ae44d0ef86c16876c002954aa662f1edbc8
- 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
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Change-Id: I9a3b0f67ee874b5ec4ad67f41a46ec7876d19082
Merged-in: I9a3b0f67ee874b5ec4ad67f41a46ec7876d19082
this integration test help us catching app crashes when adding shortcut
widgets to the workplace. see b/141568904 for more context.
Bug: 141934188
Change-Id: I4d33d6127793efe2071d0d146aef24db6b676360
It is now organized as follows:
- private constants
- public constants
- private final fields
- private variable fields
- constructors
- public methods
- private methods
- public interface/abstract class
This is intended to be a functional no-op.
Bug: 141939911
Change-Id: Iad5a9b3b73b35641f8a4f1d52ada6adef3825c47
Tested: Built and sanity checked manually.
Not doing this seems to have caused flakes.
Bug: 141770616
Change-Id: Ia9caf20e4a2d93298adf4249ca815ad79bced802
Merged-in: Ia9caf20e4a2d93298adf4249ca815ad79bced802
> 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
- Whitelist specific binder calls when handling touch during swipe up
gestures
- Only track binding for touch handling and certain launcher lifecycle
changes for now
Bug: 140246642
Change-Id: I6ba30280dd17da358662870f8719ae851536ad8b
vadimt