cleanup.
This ensures the memory is properly cleaned up if an exception is thrown
while building the DreamMetadata object.
Bug: 234343900
Test: locally on device
Change-Id: I29b2bed30c216d5e353fa0a8b0da74579b33cecb
The force-relayout was added in [1] for the side effect of [2].
Since the preserve-surface has been completely removed in [3].
So [1] can be restored to avoid unnecessary cost.
WallpaperService always calls relayout with View.VISIBLE, so
unless it requests to remove the wallpaper window, its surface
should not be removed. Though currently there might be no such
cases, add a log in case something goes wrong.
[1]: I79f97df61696eea325183e9b9057cbb10ce8cc66
[2]: Iea8ed86a9c4a7674804152aa44df7ef3d6341768
[3]: I4574ac0d3b8a63b13ac44846e729b73ca0f88f23
Bug: 233599092
Test: No additional relayout from wallpaper when turning on screen,
swiping/closing up to home.
Test: Toggle overview from wallpaper picker while using live wallpaper.
The wallpaper won't disappear.
Change-Id: I6673e458b5577f780be17a51cf5de1d6493ab5ca
Because animators are not tied to the lifecycle of any UI
elements, it is possible for an app to go into the background
and for the animators to continue running. Ideally, the app would
track the lifecycle of the activity/etc and pause or disable the
animators, but it is common for this to not happen, causing the
animators to continue spinning when the app does not need them.
The animators are not causing as much work as for a foreground
activity (since they do not cause any re-rendering), but they cause
work nonetheless by keeping Choreographer awake to continue pulsing
frames.
The ideal fix would be to introduce new API for animators that
tied them to lifecycle concepts (View, Activity, etc). But that kind
of fix would only be available for future versions of the platform,
and does not address existing app code. A workaround for the current
situation is to address the most egregious problems; infinite animators
running on backgrounded apps.
The fix here is exactly that: when an app's visible surface (either an
activity or, for Wallpapers, a WallpaperService) is backgrounded,
a request is sent to pause animators for that surface. When that surface
comes to the foreground, a request is sent to resume those animators.
Since all animators are handled on the same thread for the same process,
in AnimationHandler, we should only ever pause animators when *all*
surfaces for a process are not visible (and resume them when *any*
surface becomes visible). Also, to mitigate any issues with thrashing
animator state for apps which become only transiently backgrounded,
we delay pausing for some time.
Bug: 228598053
Test: new AnimatorLeak CTS test, plus manual testing for activities
and wallpapers
Change-Id: I8b9f841cc80babb972244c724968a5c085a06b69
updateSurfaceDimming().
Reduce jank by removing notifyColorsChanged() on updateSurface() which
caused notifyColorsChanged() to be called multiple times successively.
Test: manual, atest WallpaperManagerTest
Bug: 229715857
Change-Id: I552a6956648250cd36787b7ddd79758422ea7f68
By the behavior, the interactor of assistant needs to call the
startRecognition function again after hotword event is triggered.
Otherwise it will not receive the result of detection.
Currently when security exception occurs during onDetected, we
won't inform the interactor of assistant about the hotword event.
It will cause the interactor still to wait the hotword event and
doesn't call startRecognition function again.
After syncing with assistant, we should use onError() callback
to inform interactor.
The behavior of onError() in the interactor:
For both of DSP and Software, assistant will call startRecognition
function.
The behavior of onRejected() in the interactor:
Only for DSP, assistant will call startRecognition function.
For Software, assistant doesn't expect to get onRejected()
Bug: 230738063
Test: atest HotwordDetectionServiceBasicTest
Change-Id: I3083fd5a4a78ad9d2f35acd7fa1a4f2036cf64de
Merged-In: Ideb210d4364d4c48c747d66268d77a2f5b017186
By the behavior, the interactor of assistant needs to call the
startRecognition function again after hotword event is triggered.
Otherwise it will not receive the result of detection.
Currently when security exception occurs during onDetected, we
won't inform the interactor of assistant about the hotword event.
It will cause the interactor still to wait the hotword event and
doesn't call startRecognition function again.
After syncing with assistant, we should use onError() callback
to inform interactor.
The behavior of onError() in the interactor:
For both of DSP and Software, assistant will call startRecognition
function.
The behavior of onRejected() in the interactor:
Only for DSP, assistant will call startRecognition function.
For Software, assistant doesn't expect to get onRejected()
Bug: 230738063
Change-Id: Ideb210d4364d4c48c747d66268d77a2f5b017186
Test: atest HotwordDetectionServiceBasicTest
This reverts commit 9c4b4e14a0.
Reason for revert: Causes increased memory as reported in b/231834913
Change-Id: I95884e6f8b8416a6b8c85637dab5540f09eb89e1
One of the tests contained therein takes more than a minute to run, so these belong in presubmit-large
Change-Id: I2f216badf1e79fc7339098bad0157f76cc2fd73f
Test: atest CtsQuickAccessWalletTestCases
Fixes: 225066814
This change adds two WM transit types for opening and closing dream
activities, which allows the system to define transition in and out of
dreams, that are currently being overriden by other transitions.
Set the priority to be just below keyguard transit. The keyguard
occlude/unocclude already correctly handles the dream open/close
animation.
Bug: 222507937
Bug: 220311554
Test: atest WmTests:AppTransitionControllerTest
Test: manually on device by entering and exiting dreams over keyguard,
launcher, and settings. observed animation and relevant types of WM logs.
Change-Id: Iedfa279d56cd9d4c4679cb3b697ee74a98ef727b
