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
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
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
Prevent the host app from crashing if systemui crashes while binding to
it. Instead, just return null and let the new systemui process bind
again, as the service will be unbound.
Test: atest FrameworksCoreTests:TileServiceTest
Test: manual, tiles still work
Fixes: 168756844
Change-Id: I70e0e8a223a84874415f7e649106398a5e039097
Currently, DreamService#finish exits early if the window is not
attached. The unbind from the dream overlay service follows this
condition. As a result, it is possible that the service is not
unbound if the window was never attached. This changelist addresses
This potential connection leak by having the unbind precede the
check.
Fixed: 227498355
Test: manual
Change-Id: I7a73258cea5219bea96f4de3b90b4b5a66478fde
In practice, the value of this xml attribute is always going to a
function of whether or not getTargetActivityPendingIntent() is null--
when a QuickAccessWalletService sends us a PendingIntent, we will use
that instead of the SystemUI card switcher activity.
If the PendingIntent is null, we then fall back to our old behavior:
* If the wallet is not currently showing any cards, launch the activity
specified by getWalletIntent() (this is hardcoded in XML metadata).
* If the wallet is currently showing cards, launch the SysUI
switcher activity.
Test: atest CtsQuickAccessWalletTestCases --retry-any-failure
Test: atest QuickAccessWalletControllerTest
Fixes: 218860062
Change-Id: I62f7ca507ebce29b03d6ce76bccaa6d736720a86
Merged-In: I4cfaa5b6035499c47a0ed8b1a4a5f3e1f0f50860
