- If gesture starts and isLikelyToStartANewTask=true, we do not clamp
- If gesture starts and isLikelyToStartANewTask=false AND transient taskbar is not
already showing, we clamp the scrolling
Bug: 258851206
Test: swipe up to show taskbar, no x-axis movement
swipe left/right still works as expected
Change-Id: Iac194df63e03b4a28b49008983c88c165847aa31
> Removing some unused methods
> Moving some specialized methods to corresponding classes
> Removing GridProvider check as it is released
Bug: 257555083
Test: Presubmit
Change-Id: Ib0f8c673d018071d3f4b7d9247e0a35718ab009c
Merged-In: Ib0f8c673d018071d3f4b7d9247e0a35718ab009c
Similar to enableTransientTaskbar changes in
ag/Ifa929dca18437ae101cf3290feda4209790604d2
This method differs from enableManualTaskbarStashing in that we call it during setup/teardown and so in these cases TaskbarActivityContext
being null may be valid. For instance, as part of the teardown,
taskbar may have already been destroyed so enabling blocking timeout
may be a moot point — adding logs can help verify that assumption.
Bug: 259337908
Bug: 257549303
Test: TaplTestsTaskbar
Change-Id: I2eeb02573670a503687ca7aa364d14f3124cd0ef
This patch implements a new feature that allows the user to tap on the staged app rectangle in split staging mode. When the user does so, split selection will be canceled, and the staged app will animate out to fill the screen and launch in fullscreen.
Done by creating a new onClick listener on mFirstFloatingTaskView that sets up the screen-filling animation, and then calls a new RecentsView function, launchStagedTask(), that launches mSplitHiddenTaskView and cleans up RecentsView afterwards (similar to what happens when a split pair is selected, but only one app is launched).
Open issues:
- After the staged task animates out to fill the screen, the task itself loads instantly without animating in. Ideally, it should fade in, similar to what happens when two split tasks are loaded in.
Bug: 257513449
Test: Manual on tablet
Change-Id: I2ae8e13e1c9848aae1978a536766c370949fd08b
Instead using a poll method similar to other touch controllers
Bug: 259447608
Test: Verified on device
Change-Id: I5c29c7c1b87acb668ea93e9f44fb685379de54fb
This reverts commit c8c81a3425.
Reason for revert: fix tests by not auto stashing when ime comes up, but still allow taskbar to show if user initiaties it
Bug: 255818649
Change-Id: Id3ab27dcc205e5a72dbd0481e3eabc10b2e1b643
Test: pull up ime, swipe to reveal taskbar
* Don't close TaskbarAllApps once drag starts
(see comment in code regarding needing multiple shared drag
layers)
* Hide app menu split options for taskbar in overview
* One TODO is that the animation needs to be tweaked
because the scale of the icon when it's returned is too large.
* I think maybe we have to change the
TaskbarDragController#mDragIconSize since that gets directly
set from a resource. Unclear.
Test: Dragged in TaskbarAllApps in overivew and in split
select, app returned to original position and not taskbar
Bug: 251747761
Change-Id: I785f34b0bdb0b0abfc440450494074f8dfe7c31a
* Taskbar in overview allows second app to be
selected so user wouldn't be stuck in split
select state
Fixes: 258543259
Test: Tested w/ flag on and off
w/ one and multiple flags
w/ fullscreen and split single focused task
Change-Id: Ie588ad66fde4e012e08d8f5abbe1eef5a1a5db6b
Returning a runnable list that doesn't get run later causes the overview command to be added to the pending command queue, but never gets removed. This causes following overview (and home on tablets) commands not to respond.
Test: forcefully caused the error condition programmatically; checked the queue is cleared and the user is sent home.
Fixes: 255851262
Change-Id: I9d2f54960c54963b1e7480a597d05911201c152b
This reverts commit e7011d2b87.
Reason for revert: attempt to fix test issues
- Instead of using SharedPrefs which can be flaky anyways,
we pass along a boolean to test transient taskbar when
we are in the test harness
Bug: 257549303
Test: TaplTestsTaskbar
Change-Id: I7c15a97363adc377f29853c1fe60b1960c77bfc3
This patch makes it so that (when we enable Taskbar in Overview) users will be able to select their second app for splitscreen by tapping the Taskbar icon, or the icon in AllApps.
This was done by performing a check to SplitSelectStateController when a taskbar icon is hit. If we are currently in split select mode, Taskbar/AllApps icons will no longer launch their respective fullscreen apps, but instead confirm the split attempt. The confirmed app will either be an already-running instance of the app, or a fresh instance of the app (if none is currently running). The split confirmation function is located in TaskbarUIController, where it is accessible to both LauncherTaskbarUIController (for 1P Launcher) and FallbackTaskbarUIController (for 3P launchers).
Also cleans up ~2 lines of unused code from the old splitscreen instructions toast.
Outstanding issues:
- When selecting a second app from within AllApps, the AllApps shade does not animate away in a satisfying way
- When selecting a second app and launching a fresh instance of that app, the animation appears to come from the wrong location
- Intent + Intent splitting does not currently work
- If the selected app is already running with multiple instances, it picks the oldest instance. Ideally, the newest instance is preferred.
Bug: 251747761
Test: Manual testing with Taskbar in Overview flag enabled
Change-Id: I302dc092740bb880f9134ba8e2e587c4f2c29d01
This reverts commit d5a6b5f688.
Reason for revert: Breaks tests due to "SharedPreferences in credential encrypted storage are not available until after user is unlocked"
Bug: 258256906
Change-Id: I1de69249685f9d2e71183357cf3eda8d443c7d97
* Crop out taskbar from bottom thumbnail for vertical split
* TODO: Need to re-calculate thumbnail sizes if taskbar
is stashed. There's also a very slight rounding error
somewhere even in the unstashed case that needs to be
revisited
Bug: 219411750
Test: Start gesture animation in split in potrait
Change-Id: I35f2415e13af7467e0735ac8865cee0e3e3d27f8
Update LauncherInstrumentation taskbar visibility check to include assertions in fallback launcher using OverviewObject instead of LauncherObject.
Fix: 253042501
Test: manual
Change-Id: I9f2aa228e8aa97ef8ca1a4535b7f8fcded8a4572
