- When EDIT_MODE was introduced, it added a wrong condition to make it always return DEFAULT_PAGE_TRANSLATION_PROVIDER
Bug: 294228521
Test: manual
Change-Id: If970949c8ab55bc67f98f987a7654ec2db89cdfb
(cherry picked from commit c325c686c7)
Currently if we open an app, unfold the device and then go to home
screen we will start the unfold animation preemptively in Launcher
because Launcher activity will receive updated configuration change
(where isTablet = true) only after going back to home screen, not
when unfolding the device.
This causes a problem because SystemUI won't send the unfold animation
events after going back home as the animation has already run, so we
end up with wrongly started animation in Launcher.
This CL fixes the issues by checking if SystemUI has finished the
animation (or if it is currently running) to avoid preemptive animation
start in this case. This is done by subscribing to the original
unfold transition progress provider which emits progress events
sent through IPC from SystemUI.
Bug: 285150685
Bug: 293131586
Test: open an app on folded screen, unfold, go to home screen =>
check that icons are not squished
Test: fold/unfold when launcher is open
Change-Id: Ic437ff4d19cbd5764635f3007d99880622150f5b
Merged-In: Ic437ff4d19cbd5764635f3007d99880622150f5b
(cherry picked from commit 6d756970e7)
The functionality should go back to the same as with phones.
There shouldn't be issues with the reorder or similar behavior since we
are switching form using the MultipageCellLayout to the regular
CellLayout.
The things we need to pay attention to is the the behavior of having two
panels like adding the right number of panels when loading (folding, unfolding and rotating).
Bug: 291822492
Change-Id: I903873e32f35c5ee9e0f3da8581a37d4087d021f
Test: ReorderWidgets
Merged-In: I903873e32f35c5ee9e0f3da8581a37d4087d021f
- The second start activity was causing issues with 3p launchers which
may not expect another new intent (ie. if it handles gestures at
the bottom of the screen). We can't completely remove this logic
because for button navigation we don't want to fall through to the
launch-next-task animation below, but we can can continue to
finish the recents animation immediately.
- With shell transitions, leashes for opening apps are always hidden
by default so when transitioning to a 3p launcher from
RecentsActivity we also need to show the surface if we want to
animate it in
Bug: 289609734
Test: Set 3p Launcher as default, in both gesture & button navigation
- Go from 3p home -> overview, then overview -> 3p home
- Go from app -> 3p home
- Go from app -> overview, then overview -> 3p home
- Quickswitch from app
Change-Id: I6875083931de63a8097d23d180553885ed7cfb01
Signed-off-by: Winson Chung <winsonc@google.com>
On ag/21680045 I copy the previous mOccupied but the right thing to do is to
create a new one with all the views information.
Some test stoped running inadvertently that's why we didn't catch this issue.
There is a separate cl with the test to ensure we can catch it later on.
Fix: 289584301
Test: ReorderWidgets
Change-Id: I27b5a6e38a556d1c73ff8fbbdd552da6045e5b64
(cherry picked from commit 1c5514b566)
Fix: 289960317
Test: Verify in unfolded felix that going from 2 icon folder and dragging 2nd icon out of folder lets you open the app that remains where the folder was
Test: Verify in unfolded felix that going from 2 icon folder and dragging 2nd icon into remove droptarget removes the folder and turns it into a single clickable icon
flag: no flag
Change-Id: I26138ee9f8e7cdb45cafe2446dc4d1e3d6d8347f
(cherry picked from commit 5a7ea3069b)
- There are flows where the shared taskbar state is updated prior
to being destroyed, and not updated to the latest values when
the taskbar is recreated.
ie.
unfolded -> lock screen -> LauncherTaskbarUiController's
mTaskbarInAppDisplayProgress[SYSUI_SURFACE_PROGRESS_INDEX]
is set to 1 due to the notif shade (lockscreen) showing.
This is written into TaskbarSharedState's sysuiStateFlags
and inAppDisplayProgressMultiPropValues.
fold -> TaskbarActivityContext is destroyed
unlock -> TaskbarManager and TaskbarSharedState's
sysuiStateFlags are updated while the device is folded
unfold -> TaskbarActivityContext is recreated and initialized
which restores from the shared state's
inAppDisplayProgressMultiPropValues. It also tries to reapply
the shared state's sysuiStateFlags, but this doesn't update
inAppDisplayProgressMultiPropValues because the state's
"enabled" state is not updated (default is no flag set, and
lockscreen sysui state is not set anymore).
-> The restored inAppDisplayProgressMultiPropValues value
results in the wrong translation.
- Note that after the above, the NavbarButtonsViewController state
is actually correct and reflects the SysUI state, but the
LauncherTaskbarUiController state is wrong. This CL tries to
manually update the ui controller to the correct state when it
is recreated.
- CL also fixes a separate issue where LauncherTaskbarUIController
could potentially overwrite the saved state progresses while
restoring them due to the state callback being called
Bug: 283346744
Test: Unfold -> Lockscreen -> Fold -> Unlock -> Unfold and ensure
the buttons are translated correctly
Change-Id: I43e473faf4fa2a493b9705506e3755df8f6264e7
Signed-off-by: Winson Chung <winsonc@google.com>
For any view files applying the WidgetConatinerTheme via widgetsTheme they were incorrectly inheriting themes and skipping the AppTheme provided but only in light mode. In dark mode the WidgetContainerTheme.Dark was correctly inheriting the theme.
To avoid a risky theme update for all widgetsThemes we just modify the color accessor to use @color instead of ?attr as these colors should not be attributes AFAIKT
Bug: b/289305591
Test: Follow repro steps on the bug for smartspace
Change-Id: I26cc3239763f8eac3dfe5f094c6757692f46d1bc
- In the case where Launcher calls startRecentsTransition while there
are no other visible tasks, we should not be continuing with the
transition as there are no tasks for Launcher to control. This was
previously handled in RecentsAnimationController in legacy
transitions, but the safer fix is to ignore it on the Launcher
side for this release.
Bug: 289175232
Test: Manually trigger empty targets and verify no issues
Change-Id: I3657c000cbc8c14c9ac989c2a57715515c96edb6
If the onRecentsAnimationStart callback runs after the user lifts their finger and onFlingFinished runs, then onFlingFinished never has another chance to run, leaving the user trapped in a state where the launcher is not started and the AllSetActivity is still present but invisible. Reverted to allow onFlingFinished to run onRecentsAnimationStart to handle this edge case.
Flag: not needed
Fixes: 285194839
Test: Ran AllSetActivty with a delay in onRecentsAnimationStart
Change-Id: I33ce5c1d4955b34d4b77d3b740dc599621bd4ed1
Merged-In: I33ce5c1d4955b34d4b77d3b740dc599621bd4ed1
- If a task is already visible, then startActivity is a no-op and the
remote transition that launcher expects to run is not started. As a
workaround (until restarts are an actual transition), listen for
the case where a task is restarted and invoke the end callbacks
Fixes: 286016555
Test: Repro steps on the bug
Change-Id: Iec3ab97c8817a5e95399cec90f891d65f369d234
Includes WINDOWING_MODE_MULTI_WINDOW closing target to the condition of
playing fallback animation. So the remaining splitting task won't be
play with iconview animation when home-key to auto-pip consumed another
splitting task in pip transition handler.
Bug: 281476331
Test: repro steps of the bug
Test: pass existing tests
Video: http://recall/-/fLARJNt42LVxc3tt86SneW/eelqATeE1REoOtOEDxeDVR
Change-Id: If05d8841a6a940e61f71683422ef1a3d4e3597c7
It reports its size through SystemUiProxy and this tag causes it to
report the region twice. Additionally upon screen rotation the value
is getting updated with a delay, so for a moment two keep clear areas
for Launcher are present - one from the previous orientation (on the
side), and one from the current orientation (matching the proxy value
in unrestrictedKeepClearAreas).
Bug: 285242520
Test: before http://recall/-/ekEuGtt9d9HWqkUtAzpHx8/cLtiXGYUyItm2kNCCEkkWA
Test: after http://recall/-/ekEuGtt9d9HWqkUtAzpHx8/iPs6fwdSXG3TE0IERmxA8
Change-Id: I40dfe08680c944f2be5db0f6b15515492f409565
- The remote animation factory needs to be strongly referenced since
the only other reference is a weakly held one from
LauncherAnimationRunner, and if a gc happens in between starting
the animation and the onAnimationStart() callback, then the
animation will not play.
Fixes: 284106887
Test: Force a gc after creating a remote app launch animation and ensure
that the runner still exists when the animation starts
Change-Id: I5f584451b41c666916801b8ea0cb470c7ab9fc51