This reverts commit:
db407ef12d, and
d8aa7f7882.
Reason for revert:
The surface size would be reduced by mTranslator unexpectedly.
Fix: 233017734
Test: Open a legacy app which has CompatibilityInfo.SCALING_REQUIRED
and see if the app is cropped.
Change-Id: If830866328a5709cf6856fe840a804b304052003
The attached frame is the frame of the parent window that its child
attaches to, as long as the child is not
TYPE_APPLICATION_ATTACHED_DIALOG. It is a factor while computing the
window frame.
Previously, we let the child obtain the attached frame from its parent
view root. However, if the parent and the child are not in the same
process, it can be tricky.
This CL sends the attached frame from the server to the client via
ClientWindowFrames. In this way, the child can compute its window frame
without having to accessing the parent view root.
Bug: 161810301
Bug: 175861127
Test: atest ActivityRecordTests WindowLayoutTests
Change-Id: Ia844a4c927027e305a56114216eaee2bf7933b1f
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
Bug: 233391022
Test: new AnimatorLeak CTS test, plus manual testing for activities
and wallpapers
Change-Id: I8b9f841cc80babb972244c724968a5c085a06b69
Merged-In: 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
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
DreamService keeps a reference to its DreamActivity, and finishes it
when the dream stops. This reference is set when the DreamActivity
receives its onCreate lifecycle callback.
If a dream is stopped shortly after it started, before its DreamActivity
was created, the DreamActivity can be created after the dream is
supposed to be finished, and finish isn't called on the activity.
If another dream starts another DreamActivity, the reference to the old
DreamActivity is overwritten and lost, so that DreamService can no
longer finish the old DreamActivity.
This change tracks the DreamToken, unique to each dream, that an
activity was started for. If an activity is created for a dream that is
already finished, the activity is finished immediately.
Bug: 229561570
Test: manual, with adding delay before startDreamActivity to ease
reproduction
Change-Id: I0fca226855ee4e2317ac807a4c87c8656c72169b
If a dream is unbound before finish, unbinding from the overlay service
will not occur before onDestroy. This will result in an exception from
unbinding from a non registered service. This change ensures the dream
service unbinds from the overlay service when unbound.
Test: atest DreamManagerServiceTests#testForceStopStubbornDream
Fixed: 229824204
Change-Id: Id708b9119c5498bf9632b21a539c3ca7f5506737
This change adds a new theme to prevent
GameSessionTrampolineActivity from displaying
any UI, which in turn delegates the
decision of whether or not to show things
like the system bars to the delegate
activity. This change also disables
transition animations for the trampoline
activity, to prevent them from causing
flickering.
Bug: 229757156
Test: manual testing using GMS dashboard
Change-Id: I82e0ede2e9f0b334fd01e958eab0736042119e84
- The listener currently tracks session shown/hidden, but doesn't track
the visibility of the session window which can change on the client
side without the server knowing. In some cases, it's useful for SysUI
to be able to track the visibility of the session window to show/hide
bars appropriately.
Bug: 222308557
Test: Manual, launch the assistant and verify the calls are made
Change-Id: I9b4bb27c9497b2a828616caf72eaf345b072c294
This change is needed so that views will receive configuration
changes via link View#onConfigurationChanged.
Bug: 228343237
Test: Manual testing
Change-Id: Iccc09babb910867e0cd8b21ed750d67e87b944f9
