- Context: With shell transitions, the launch of a new task is merged
into the same recents transition that is running, which means that it
does not run as its own independent transition (this probably needs
to be addressed in the transitions level somehow)
- Given the above, if there is somehow no running task id, then we still
need to rely on the next task appeared to trigger the flush of the
callback list (since the animation will not run to flush that callback)
Bug: b/255851262
Test: Manually simulate getRunningTaskViewId() == 1 and verify
Change-Id: I778f22fa59cb1620781f7aa442d244793352d74e
Signed-off-by: Winson Chung <winsonc@google.com>
This change will make the Escape key close floating panels in
Launcher.
Bug: 280801803
Test: Flashed on device, tried with physical keyboard and panels
will close.
Change-Id: Ie09e57716a7be74638037abe6272b47eec1b8a6c
This reverts commit 9ef41413e0.
Reason for revert: This was the only launcher CL during the time b/280669657 and 280680602 occurred
Change-Id: Id7107f0935f84908ca87e1ae4c62ab05efe41a24
...so reveal animation can blend with the launching target.
Bug: 279785569
Test: manual, rotate device, launch app from quick switch.
Verify launcher surface isn't opaque so app window can blend with
reveal animation.
Change-Id: I46b0652fd14ff66b681a9212608c13fe4ec50eb3
- we were checking the widget being valid and bound after we are accepting the config
- solution is to revert back to test before and check post result after be check if widget is valid and bound.
making sure that ShellCommandRule is checking for success,
refactor for AddConfigWidgetTest with extra launcher wait condition.
Test: none
Bug: 276794291
Flag: not needed
Change-Id: I4a6caf0851a947da03711b2a5d5bc9f736a47f95
1. Use kt stirng's $substitutions for StartupLatencyLogger
2. Add "otherwise =" for @VisibleForTesting
Bug: 278092752
Test: tested on phone, foldable and tablet, print latency logs in logcat
Change-Id: If56b90dafbff0e0b1f7ea076581d71a0b5271d71
Sandbox Mode for the gesture navigation tutorial is unused in both the
current and redesigned versions of the tutorial, and can therefore be
removed.
Flag: N/A
Fix: 280641779
Test: Manually went through both versions of the tutorial on handheld,
foldable, and tablet devices
Change-Id: I2f6db47df0fa39458d17221f24827eb43e2cae31
Removing default widget padding logic. Also widget padding it applied
at ShortcutAndWidgetContainer so that the widgetView always has the
correct size.
Bug: 274826296
Bug: 257589413
Test: Verified using screenshots
Flags: N/A
Change-Id: Id4b5e94db6ec7b2aa3dca87b1e9ccc831b608cac
For large scaling configurations, the tooltip height can exceed the
available space, which can truncate important content such as the "Done"
button. To mitigate this issue, we should attempt to increase the width
of the tooltip to hopefully free up some height due to the text taking
up fewer lines.
To support dynamic width, each EDU column gets an equal weight in the
ConstraintLayout, but the lottie animations are still constrained to
their original dimensions. If they fill the width, their aspect ratio
will be maintained and we will still have height issues.
Demo: https://screenshot.googleplex.com/6jV6geJFzCYtQ6v.png
Test: Manual (transient and persistent)
Fix: 278761297
Change-Id: I8cc0c4260caef747378954225d8635b2fb8eef52
Adding 100 different test cases for the ReorderAlgorithm.
The test cases are randomly generated using generateRandomTestCase()
the boards are generated once and then written in the file
reorder_algorithm_test_cases. I will leave the code to generate
the boards in the Test even though is not used anymore in case
we need to generate more boards later on.
Also, I found that the ReorderAlgorithm was not deterministic,
meaning that it could generate two different results with the same
inputs (views positions and view being drag positions), because
it was traversing a map whose has was the object id which is
random. So I sort the views before traversing them.
Bug: 229292911
Test: atest ReorderAlgorithmUnitTestCase
Change-Id: I196eb8f1dafcb57d5259969268c458129ae4f46b
overridden
Bug: 280585150
Test: flashed device, and verified along with other changes in this
topic
Flag: ENABLE_DREAM_TRANSITION
Change-Id: Ic62ab51e0b95253127aa0c4fc8a4ea613afafaa3
Starts unfold animation in Launcher right after receiving
configuration change for the unfolded screen.
This makes sure that before we unblock the screen we
have the first frame of the unfold animation ready
in Launcher (transformations are applied).
Bug: 271099882
Test: atest com.android.systemui.unfold.util.PreemptiveUnfoldTransitionProgressProviderTest
Test: manual testing fold/unfold, checking perfetto traces
Test: test with flag enabled/disabled
Change-Id: Icb8f91f9264248600d4bed14811445f50aac99c7
More details at "Log Startup Latency" section in go/launcher-startup-latency
Test: tested on phone, foldable and tablet, print latency logs in logcat
Bug: 278092752
Change-Id: Ibf269b0ecd6007d29b95e36f65ab6f02c45deb3a
This patch fixes a bug where the user could cause a crash by making a gesture during the Overview > OverviewSplitSelect animation.
Within Overview, the user is able to make an upward gesture from the bottom of screen to return to Home. However, if the gesture is very short, the user doesn't go back to Home and instead stays in Overview. Under normal situations this doesn't cause any problems. But if we are in the middle of an animation, the short gesture actually triggers an animation cancel followed by an immediate goToState() to the same state that it was already in. This causes problems with the OverviewSplitSelect transition because reset() is called in the middle, clearing important split select data and causing a crash.
Fixed by changing a conditional to detect if we are this type of situation, and allowing the animation to play out in these cases.
Fixes: 272793237
Test: Manual
Change-Id: I4426204b9c8fc55853cf7df31a336ccaee2f5885
