Now doing this before branching points, thus avoiding flakes when the
execution can go to an unexpected branch and not produce an event.
Bug: 153824894
Change-Id: If117da0498eaf2d94c9610552724981be34c6569
On the Launcher side, moving setLayoutFrozen from the posted action to
avoid a possible short scrollable period just after the view is shown.
Bug: 152354290
Change-Id: I7319236d8a6e49a7e017fd54d593ee131dff10a9
Also avoiding scrolling widgets horizontally when the gesture could
happen in the lower system gesture area.
Change-Id: I80192db7e407f8c1715aad3b96178c00b5710e71
Slight revert of ag/10668129 with adjustment
of disabling it for tests.
Fixes: 151456795
Test: Ran the labtest command for OOP
tests for crosshatch (where this issue
was first detected)
Change-Id: I315d138c2e4a6d4068304e9b5fb2e1b7feb34e63
Also fixing duplicate long press events resulting from both framework
and Launcher own detection reporting long presses.
Change-Id: Ib46de5bd60850f1c5578992c8c1172ddbc0961f3
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: Ie4ea5865afd900bebbd8287dad2372c94dce8ad5
Unlocking the device at the beginning
of the test does help, but perhaps we should prevent
locking during the test execution.
Some failures still remain.
Bug: 151613234
This is a workaround for the infra not unlocking
the device properly.
I don't have access to may machine, so
I've created this CL in Gerrit editor, didn't test,
but it should work.
Bug: 151613234
- hide overlay icon in landscape mode
- don't show edu if user has already seen legacy work profile edu
- make sure personal tab is highlighted when work profile is reinstalled
- always go home after a work profile is added or removed
- add tests for work edu flow
Bug: 150122946
Test: Manual
Change-Id: I8f80ac763acf03ca31a534464f4ddfd84528d329
Makes use of there being a single instance of OverviewActionsView
rather than each Task having it's own.
Change-Id: I881121f84de99cade3cd8f07fa8510a557b28f57
This replaces PendingAppWidgetHostView with configured widget view when
OPTION_APPWIDGET_RESTORE_COMPLETED is set to True by a widget provider.
Bug: 63667276
Test: Manual
Change-Id: Ide21f5e9a7dac7e3d6a745660a38ad0b951b47d3
Can do this via API with the exact heap state that triggered the
callback because using API allows to avoid deadlock that we'd have in
main thread if we used shell command.
checkDetectedLeaks() is still needed, as I'll add throwing an
exception there soon.
Bug: 139137636
Change-Id: I3c8670071b058c5c146ac58bb16152c980553065
This is perhaps not a leak, but it conflicts with how StrictMode
activity leak detection works.
Bug: 139137636
Change-Id: I1608e348d8b238142c42ed81ae125fd07ef6b673
WM is making changes which allows apps to maintain
their orientation independent of the orientation of
the foreground app. This allows recents to always start
in portrait even when the app currently running is in
landscape. This means we have to give the illusion of
a landscape oriented overview when user swipes up in
gesterual nav when launcher is started in portrait
configuration.
PagedOrientationHandler abstracts all coordinate specific
logic from Paged/RecentsView primarily, but also all
other dynamic calculations throughout launcher.
PagedViewOrientationState is the single point of exposure
to other classes that depend on those changes. The goal
is to also minimize holding state to allow for default
implementations of PagedOrientationHandler for all the
3p/Fallback classes. PagedViewOrientationState also
holds other data around rotation that isn't
specifically tied to view logic.
The fake landscape overview can be toggled with:
adb shell settings put global forced_rotation [0/1]
Fixes: 146176182
Change-Id: I65d8d4e9f92b93931cbe0053ccaf0cda8d2ffd6c
It's a supplemental method, and mysterious glitches that happen during
its work shouldn't cause the whole test to crash.
Example:
java.lang.NullPointerException: Attempt to read from field 'com.android.server.appwidget.AppWidgetServiceImpl$ProviderId com.android.server.appwidget.AppWidgetServiceImpl$Provider.id' on a null object reference
at android.os.Parcel.createExceptionOrNull(Parcel.java:2291)
at android.os.Parcel.createException(Parcel.java:2269)
at android.os.Parcel.readException(Parcel.java:2252)
at android.os.Parcel.readException(Parcel.java:2194)
at android.accessibilityservice.IAccessibilityServiceConnection$Stub$Proxy.findAccessibilityNodeInfoByAccessibilityId(IAccessibilityServiceConnection.java:875)
at android.view.accessibility.AccessibilityInteractionClient.findAccessibilityNodeInfoByAccessibilityId(AccessibilityInteractionClient.java:430)
at android.view.accessibility.AccessibilityInteractionClient.getRootInActiveWindow(AccessibilityInteractionClient.java:214)
at android.app.UiAutomation.getRootInActiveWindow(UiAutomation.java:607)
at androidx.test.uiautomator.UiDevice.getWindowRoots(UiDevice.java:1102)
at androidx.test.uiautomator.UiDevice.findObject(UiDevice.java:150)
at com.android.launcher3.tapl.LauncherInstrumentation.getSystemAnomalyMessage(LauncherInstrumentation.java:334)
at com.android.launcher3.tapl.LauncherInstrumentation.getAnomalyMessage(LauncherInstrumentation.java:359)
at com.android.launcher3.tapl.LauncherInstrumentation.checkForAnomaly(LauncherInstrumentation.java:369)
at com.android.launcher3.tapl.LauncherInstrumentation.lambda$eventsCheck$11(LauncherInstrumentation.java:1269)
at com.android.launcher3.tapl.LauncherInstrumentation.lambda$eventsCheck$11$LauncherInstrumentation(Unknown Source:0)
at com.android.launcher3.tapl.-$$Lambda$LauncherInstrumentation$3iFY1gd72Tm3mPf31PMij-eBaBk.close(Unknown Source:2)
at com.android.launcher3.tapl.AddToHomeScreenPrompt.addAutomatically(AddToHomeScreenPrompt.java:53)
at com.android.launcher3.ui.widget.RequestPinItemTest.runTest(RequestPinItemTest.java:163)
at com.android.launcher3.ui.widget.RequestPinItemTest.testPinWidgetNoConfig_customPreview(RequestPinItemTest.java:95)
at java.lang.reflect.Method.invoke(Native Method)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:52)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:148)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:142)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:923)
Caused by: android.os.RemoteException: Remote stack trace:
at com.android.server.appwidget.AppWidgetServiceImpl$AppWidgetManagerLocal.getHostedWidgetPackages(AppWidgetServiceImpl.java:4887)
at com.android.server.accessibility.AccessibilitySecurityPolicy.computeValidReportedPackages(AccessibilitySecurityPolicy.java:229)
at com.android.server.accessibility.AbstractAccessibilityServiceConnection.findAccessibilityNodeInfoByAccessibilityId(AbstractAccessibilityServiceConnection.java:621)
at android.accessibilityservice.IAccessibilityServiceConnection$Stub.onTransact(IAccessibilityServiceConnection.java:372)
at android.os.Binder.execTransactInternal(Binder.java:1138)
Change-Id: If7ae23d07b69d524c3f300607f0866cce6405416
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
I'll check whether the tests are still flaky and assign to the test
owner if they are.
Bug: 148867106
Change-Id: Ic850abc862b0f266b100aa6bfff4e89b3802e50d
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
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
In the development environment, the device may stay for long time
without reboot, and the logcat size may turn to be long enough to
overflow the memory.
Suppressing OOM exceptions.
Change-Id: I562e2c03312e88f669d9cb660af6e8849dc0c8ef
Creating RecentsViewHolder to be contain LauncherRecentsView in OverviewPanel so Overview Actions View can be created only once.
Change-Id: I111f88903d2ff80275cc2e07b761577260073c17
Start a thread to read logcat synchronusly instead
of back-tracking at the end of the test
Also:
* Reusing the same logcat process for all checks. This eliminates
reading the log from its start for every gesture. We don’t kill that
process at the end, and don’t stop the thread. I’ve verified that
“am instrument” doesn’t hang, and the logcat process gets automatically
killed after the test process exits.
* Not using mStarted latch, as there is no need to wait until the reader
reaches the start mark.
Bug: 149422395
Change-Id: Ide4ed19ad8d099c41918f38c2b073b8b2e143b69
This reverts commit c2842d8f4a.
Reason for revert: CL broke TaplTestsLauncher3.testDevicePressMenu in 2-button mode
Change-Id: Idebda69a36b94686415434e8e3f158a8a7abc5bb
This is a temporary attempt to solve the supposed unreliability of the
"-t" parameter of logcat while the permanent solution (ag/10290062) is
being reviewed.
Bug: 149422395
Change-Id: I327a94de4349bb6cea32f9b8f66bb6e292725b8f
* Adds additional fields to launcher_log.proto to capture smart folder related information.
* Uses ProtoLite to generate log object using builder pattern and converts to nano version before writing to clearcut. Hence not making drastic change to existing logging pattern.
Change-Id: I89b10da8d4e35e3abc7ddb553046946f91b43445
I saw flakes when logcat didn't return records that are 300ms after the
specified time. I hope that moving the start time 1 sec back will
workaround this.
Change-Id: I6a4b66094d38f555d10284f19a71152a8be47b2e
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
Assuming that the nav mode state needs to "settle", adding waiting for
this.
This might be a temporary solution.
Bug: 149024111
Change-Id: Ifbd874546a4cb6b07ad3d3825c95d19bc5836b38
Also switching investigator to logs starting with the system reboot, as
SysUI crashes before the tests start.
Change-Id: Ifab835c1ab3c1ce3495f012c6a522fae6e44a9ff
* 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
There's a lot of resistance, but feels better than nothing
responding to your movement.
Bug: 143361609
Change-Id: I9d7e06279ebdbaa0317909ce96d6f001dbe9699a
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
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
Vinit Nayak