The cross fade function of DragView tries to match the shapes of the fade-in and fade-out views. However, ImageView (the fade-in view) by default only tries to match at least one axis between the content (the final view) and the bound (the ImageView bounding box). We need to make sure that the content fully fills the bound to exactly match the shapes.
Test: Manual
Fix: 221496442
Change-Id: I7c142d52b7bfbd0e266a917c27cbd40691fbf3c2
Ex) for tablets.. the nav bar height is really the height of the taskbar.
Thats why we add the current padding of the work toggle button to the
taskbar size.
As of patchset 3.. I reverted mDevice.getInsets().bottom because it caused
the button to be higher than it should be on landscape.
Bug: 235053326
Test: Manual (pictures in bug thread)
Change-Id: I2f77d759ae060311d049182e8347dede590cd0b0
- Also listen for config chagne in FloatingHeaderView
Fix: 218500759
Test: Change screen size between phone and tablet, header protection is only enabled for phone
Change-Id: I65120080641ea75ae58c010c4a27fe2b1539e0b5
Running the following commands should change your connected
device display:
adb root
adb shell setprop ro.test_harness 1
adb shell pm enable --user 0 com.google.android.apps.nexuslauncher/com.android.launcher3.testing.TestInformationProvider
adb shell content call --uri content://com.google.android.apps.nexuslauncher.TestInfo --method emulate-display --extra device:s:pixel5 --extra grid:s:crazy_big
adb shell setprop ro.test_harness 0
Alternative method for this is using
./display_emulator.py emulate --device pixel5
I hooked up the existing DisplayEmulator into a content
provider. Doing this has a couple advantages to the previous method
of calling the emulator inside of a test. The biggest one is
that running the emulation doesn't restarts the Launcher3,
and because of that the previous method could leave the user in a
fake emulation where it looks like the device is being emulated but
is not 100% accurate.
Test: Run the command lines described above.
Fix: 229666646
Change-Id: Ia039fbaf4c7330d6bdf469633127f58d2466a1bf
Fix: 234847755
Test: With a modified local build, when changing display config to swap between same grid:
- When dbFile is same but device type is different, no migration is performed
- When both dbFile and device type are different, migration is performed properly
Test: Grid migration through Wallpaper & Styles still works properly
Change-Id: Ie7429a7d59c135ba47061cae21c40b8d8af7188a
This reverts commit d3e8cc40b4.
Reason for revert: b/231312158 is fixed, log is no longer needed
Fix: 231851651
Change-Id: I3ea8b9d14e7eb6f8f9c794c5d15cdfc94153d392
Also using itemType instead of item object for widget size cache
Bug: 234008165
Test: Verified on device
Change-Id: Ia4b4a00a11627c0c454e4a699570e8ab1667a390
- Added a QSB to taskbar to be animated between inline QSB and taskbar
- Passed endValue of taskbar animator to TaskbarController to have aniamtion variation between home -> app and app -> home
- Tuned duartion of taskbar animation and also stagger animation when taskbar is present
- Disabled scaling down of taskbar and inline QSB for home -> app
- Disabled stagger animation of taskbar and inline QSB for app -> home
Bug: 220733187
Test: manual
Change-Id: I4aac0bbc343b992a0472298595770e2bf2a55990
* Previously TaskView was closing task menu view, but
that got removed since launcher was doing that on
state transition.
* Only 1P launcher was doing that and not 3P launcher,
moved call to remove open views to parent class
Test: Invoking split on 3P launcher doesn't result in a crash
Bug: 199342537
Change-Id: I6afbe7640ede362a677e15a33409a7cabdb8cca9
Currently by design when launcher enters the background, it stops
listening to updates in widgets. This eventually causes the dilemma
for launcher when it resumes, before the update can be returned from
the system process via IPC, launcher could do one of the following
to fill the gap:
1. show a deferred widget view -- a placeholder that renders the shape
of the widget -- to let the user know widget is being reloaded.
2. show whichever widget view that was previously displayed to the
user that may now contain stale content.
There is a descrepancy here since in some edge cases we are showing the
former while in most other cases we are showing the later. This CL added
a short-term fix to address the descrepancy and favors the later where
possible.
Bug: 218067434
Test: manual
Change-Id: I6cd2cd704186267227e2ec47f2581843fd526fa0
I root caused the two areas causing the flicker:
A. If page scrolls aren't initialized when we get onActivityInit(), the first scroll even after linkRecentsViewScroll() will jump based on min scroll (due to Clear all button). Fix is to defer linking until page scrolls are initialized.
B. If page scrolls aren't initialized when the gesture starts, RecentsView can jump to the min scroll when calling showCurrentTask(), since that calls setCurrentPage(getRunningTaskIndex()) which might be out of bounds. Fix is to defer that setCurrentPage() until page scrolls are initialized.
Test: open a random app that hasn't been opened in a while, touch down
on nav handle and see if RecentsView scrolls partially or fully
offscreen; repeat 20 times to be sure
Fixes: 233112195
Change-Id: I000960775f8735920d97c87942065a430c9dce0c
Test: open a random app that hasn't been opened in a while, touch down
on nav handle and see if RecentsView scrolls partially or fully
offscreen; repeat 20 times to be sure
Bug: 233112195
Fixes: 235369468
Change-Id: Ie8b3dbea7c4826af037edf22360946105ab22134
Sihua Ma
Brandon Dayauon
Sunny Goyal
Alex Chau
Sebastian Franco
TreeHugger Robot
Sukesh Ram
Ronish Kalia
Luca Zuccarini
Thales Lima
Vinit Nayak
Pinyao Ting
Tony Wickham
Hyunyoung Song
Becky Qiu