Removes code that was intended for a now-deprecated layout style in Overview. See ag/18386646 for an example of an issue caused by this.
Bug: 232298587
Test: Manual on 3 devices
Change-Id: Icfd40e1e5a99cf5821b1c46357db58a31daaa835
This applies to phones only for the one-off transition (Home gesture or
swipe back. See before and after videos in the bug.
Bug: 234359814
Test: manual
Change-Id: I8f4fc9ec40687b641a721bd28b32fcf50514861f
- TaskbarDraglayer.width isn't initialize when Taskbar is recreated before layout, so use DeviceProfile.widthPx instead
- Also listen for DeviceProfile change in TaskbarInsetsController to update Taskbar touchableRegion
Fix: 233316713
Test: Switch to 3 button, nav button works. Swtich to gesture nav, taskbar icon can be tapped
Test: Rotate deice, whole Taskbar should still be touchable
Change-Id: I29ff86fd8616a620f98d9b5438cc586bd69fac33
* If the starting point is greater than that of the current
device's width (in either positive or negative direction),
reset the starting rect to be fullscreen task bounds
* More details at b/228829958#comment12
Fixes: 228829958
Test: Reboot device and swipe up from home immediately,
app doesn't fling from the side.
Tested with portrait and landscape launcher.
Tested with fake landscape launcher.
Change-Id: I6ea24e30e9de5716b7830f487b2ed63f56598c50
We want to scale down the DeviceProfile for taskbar, but the all apps
window should rely on the original DeviceProfile.
Test: Manual
Fix: 232907361
Change-Id: Ia09f674ada9e445c1d7278fa94c536ea9de13ef9
Merged-In: Ia09f674ada9e445c1d7278fa94c536ea9de13ef9
(cherry picked from commit a9a78117c7)
Fixes an issue where the user would not be able to take a screenshot through the Overview menu when:
1) the task thumbnail was in LiveTile mode and
2) the phone was in fake landscape.
The issue arose because all Overview menu items, upon selection, were forcing LiveTile to end immediately, even before running the onClick method of each menu item. In the case of screenshots, this resulted in the onClick method being unable to take a screenshot because LiveTile was already ended.
This fix prevents Overview menu items from always forcing LiveTile to end, instead allowing each onClick method to determine its own order of operations and end LiveTile when appropriate. The functionality of all other current menu items (Select, Split, etc) should not be affected by this change.
Fixes: 231047451
Test: Manual
Change-Id: Ibfc79a114718fc4674dc434a907044184c7f5dd0
We want to scale down the DeviceProfile for taskbar, but the all apps
window should rely on the original DeviceProfile.
Test: Manual
Fix: 232907361
Change-Id: Ia09f674ada9e445c1d7278fa94c536ea9de13ef9
Merged-In: Ia09f674ada9e445c1d7278fa94c536ea9de13ef9
Preloading the Launcher activity once the user reaches the SUW All Set app allows for a smoother first reveal transition. Refactored TIS and TISBinder to make this possible.
Fixes: 226726244
Test: factory reset and flashed a build onto a pixel 6 pro
Change-Id: I1be3383bafdde17b951329de4c7d6b87affd210c
- Apply additional translation on TaskbarView to account for difference between taskbar icon to bottom spacing compared to hotseat icon to bottom spacing
- Call updateIconAlignment outside of synchronizeNextDraw's then block, which get run after the synchronization
Bug: 204850744
Test: manual
Change-Id: Id65842f506eb342105082649446eb694cd5c33a4
(cherry picked from commit 51da219869)
Merged-In: Id65842f506eb342105082649446eb694cd5c33a4
When device is locked and going to finish the recents animation,
instead of start home activity, calling
finishRunningRecentsAnimation directly so core and shell does not need
to handle another transition.
Bug: 230582311
Test: enable shell transition. Start showWhenLocked activity while
keyguard showing. Scroll up to dismiss the activity and verify the
activity and home shall be stopped and only keyguard remains on the
screen.
Also verify entering recents works fine when device is unlocked.
Change-Id: Ic76f81efcaa8ed00d5af1475259ec16659f6b568
This avoids the error when the transaction is created after
the surface is released. In case the surface is released after
transaction object is created, the apply() call simply ignores
that error, whereas previously the transactionCreation will throw
an error
Bug: 231889963
Test: Verified by manually releasing the surface that there is no crash
Change-Id: I9a4b9ca0be2ed687b2fc692570415256e3e479f7
Bug: 206905515
Test: Manually verified b/230648542 did not resurface. Tested
on phone and tablet with and without work profile.
Change-Id: If724f635286b9dff2c64255f9ece3568a5cb4ea9