During each app launch, a new `MyDepthController` is instantiated, which
registers two of its methods as listeners for cross window blur and
opaqueness. This controller's usefulness spans that specific animation
only, but the listeners are never unregistered. This creates conflicts
when an opaqueness signal happens, which cause the background to flicker
(see videos).
Bug: 283335820
Test: manual, see videos in the bug
Flag: not needed, bug fix
Change-Id: I3dcb0b8ff0aa77bf3183a926889d0131b17bcaa4
Showing the animation leash of appearedTaskTargets if there need to
play the reveal animation behind splash screen view.
Pausing applyDepthAndBlur while playing splash screen exit animation
from launcher side, otherwise the app window would be blurred.
Bug: 277704255
Test: manual, do quickswitch to start the app behind splash screen
view, verify no flicker or blur happen when playing reveal animation.
Change-Id: I83604ceeaeb54ab2100fdabf45a1624644b85e37
- Made BaseDepthController.setDepth/mDepth private, all get/set should be done through STATE_DEPTH or WIDGET_DEPTH
- Generified ClampedDepthProperty into Utilities.ClampedProperty to apply on STATE_DEPTH
Bug: 240580498
Test: Go to walppaper&style, set new wallpaper, then go to widget picker, wallpaper depth should transition smoothly
Change-Id: I53cdedf970fd7ffba6a952c4edf4b34251b01f07
Bug: 242746421
Test: manual
TL;DR;;
setState toState= NORMAL called when locking screen on ALLAPPS screen
but mSurface==null
hence depth is not reset to NORMAL state
Change-Id: I26a37f7de8b0ecd481b36eebf07e1b79f8b0035c
Separating the depth controller logic into a base
class so that different controllers can be used
for different surfaces
Bug: 236780815
Test: Verified locally
Change-Id: I2bd7ed50438453d6e41c73c8001a0d6a73091653
An accidental horizontal touch, due to vertical fling on the -1 screen
could lead to imperceptible change in zoom, and send a frame to client
composition. This CL adds extra padding to overlay scroll amount, to
avoid these accidental gestures.
Bug: 211245940
Test: https://ui.perfetto.dev/#!/viewer?trace_id=3260c116-c578-6dad-e047-0a327b7d346c
Change-Id: Id05e482c79c1dcc2e1ba73baf8a4a4101797bbd2
A request to set a new depth is ignored if the surface is currently
invalid. We should cache what was the requested value, so it will be
applied once the surface is valid again.
Test: manual
Fixes: 209028986
Change-Id: I812816da4b0139c7ea7b53a9fb00f11265ecdea8
- This can prevent the layered content behind to not be visible (and
since launcher draws a cutout and the wallpaper isn't shown, may
result in a black rect. We only specialize for this case while
Launcher is in Overview.
- Also don't need to defer updating drawsBelowRecents, this can result
in the state not being reflected since it runs after the last update
of the transform params
Bug: 205789573
Test: Swipe up from app and ensure behind layers are visible (also
ensure this doesn't affect blur during the swipe or optimizations
after you leave overview)
Change-Id: I07689b3d9b65708797576e5fbefe12fb1f544119
When entering BACKGROUND_APP, it's possible that the blur radius will be
lost. We need to dispatch it on the first possible frame, otherwise
Overview won't have blurs.
Fixes: 196828055
Test: enter overview multiple times
Test: pull up all apps
Test: open app from home or all apps
Change-Id: I5920e1b28e2d23421863ecd59845e902040d126c
The app window is now on top of the scrims, so we can just mark the
window as opaque and keep blurring.
Bug: 196828055
Test: atest OutputUpdateAndWriteCompositionStateTest
Test: systrace on all app, and overview
Change-Id: I128d3b4722060c0bb72a218bf01ba26dabaddacf
Until now the SurfaceControl transaction was being applied
asynchronously, which could lead to it being executed out of sync with
launcher drawing.
This became an issue at higher refresh rates, where frames are produced
at a much faster pace.
In order to fix this issue, we can use BLAST transactions, which are
annotated with a frame number.
Test: record video, go through it manually
Fixes: 194320152
Change-Id: I1636a1ded4f9dd84c54ba12239e3549b92ed7567
The scrim visibility drives whether the launcher window is opaque or
not. We should track it and apply the flag instead of trying to catch it
through other Launcher life cycles.
Fixes: 195365607
Test: tap on home button while launching app from overview
Change-Id: I2a00b86b602b5dd12c901433b92adcf0170be15e
Otherwise events won't be dispatched properly and window opacity will be
wrong.
Test: manual
Fixes: 191149025
Change-Id: Ice7ea86252282c7dc1cb5925dd1bdb8cade89c08
We'd like to be able to disable blurs during app launch, but without
disabling zooms as well. The previous sysprop would set the depth of
BackgroundAppState to 0, when what we want is to conserve wallpaper
zoom.
Bug: 191969790
Test: adb shell setprop ro.launcher.blur.appLaunch false
Change-Id: Ie4b26096f6ac723c3981bba2829557e6cc6c733b
We need to update mDepth even when the surface is null, otherwise
events will be ignored and mDepth will have the wrong value when
waking up from screen-off.
Test: pull up app drawer, screen off, unlock
Test: go to overview, screen off, unlock
Test: launch app, observe blurs and zoom
Fixes: 191153501
Change-Id: I33f5d84a50e24f05a09769b1f7f3c27969f847cd
The App window will be under Launcher, so we can't actually blur
launcher at that time, otherwise the live window will also be blurred.
Test: manual
Bug: 189207458
Change-Id: Ie07449d29d3b0dc60d3787b6d32aa9e46e0bb613
This will help with overdraw, because we don't need to draw the
wallpaper.
Test: manual
Test: adb shell dumpsys SurfaceFlinger --timestats -dump
Bug: 187703092
Change-Id: I2ebae94725578e5f4d640cd6b45da3f4d1f21a20
- Also no longer resets depth on surface change, as depth is independent
from blur.
This fixes the bug where depth is not accurately reflected.
Bug: 185680609
Bug: 185189176
Test: launch app and swipe home multiple times
launch app and back gesture to home
Change-Id: I5e2f4ce08b8bf84b7356fbd080ae732875c5e04e
- Remove PLAY_ATOMIC_OVERVIEW_SCALE and PLAY_ATOMIC_OVERVIEW_PEEK
- Remove complicated parallel atomic animation support from
AbstractStateChangeTouchController and subclasses
- Remove some code related to going between Overview <-> AllApps
Test: Swipe between states in all 3 navigation modes
Bug: 175137718
Change-Id: Ice314d46946c3a983cdc6ccf1a67effb5da9156e
This is a workaround until we can support app transitions when starting
an activity in mw mode.
Bug: 158613217
Change-Id: I843d6669722c543728ab532e1c4fbd4643f6f135
This "fixes" the bug where wallpaper zoom does not reset to 0 when
screen turns off since we no longer require a valid surface to set the depth
when blur is disabled.
Note that the bug still exists when blur is enabled, which will need to be
fixed in a follow up CL.
Bug: 157946272
Change-Id: I43179435885c95eb2ecf406fa5c291badf5a1ed3
Overview comes in and workspace goes out at overshoot(1.2), so
the wallpaper depth/blur should match that speed.
Test: go to overview from home in 3 button or 0 button mode,
ensure wallpaper scales down at the same rate as other elements
Bug: 154637581
Change-Id: I03254fa3fdf19f468852bed8aab7ba21203c429a
This is caused because we use mDepth for depth comparisons, but there are
cases where we set mDepth but we do not pass that value to WallpaperManager
(ie. surface is null or not valid) and that leads us into
inconsistent states.
Bug: 155780358
Change-Id: I3faf14416d5783ad472892425eb0bd37dd469a46
We use this flag to prevent the depth from being immediately set to 0 when
preparing to animate home.
Bug: 152327671
Change-Id: I614c6ae08b9f9e56ecb94fb51748791a38504583
