Lower the background opacity when the window loses focus
while the view still has focus, in order to prevent user
confusion in a multi-window environment.
Bug: 230355625
Test: atest RippleDrawableTest
Change-Id: I59cd7faf35f05a12451f015f8ef2da47077b1bf2
As per more API council feedback, ENCRYPTION_STATUS_ACTIVATING should in
fact be deprecated, given that it has never actually been used.
Bug: 233801960
Change-Id: I6f8da12f291d1238008eb2d928547fda70ca9402
The interface of `isOatArtifactDeletionEnabled` is only available on internal system server. As request from ART service, it should be an open API available in system apps, for logic of `canOptimizePackage` and other purposes.
Bug: 229203212
Test: atest AppHibernationIntegrationTest
Change-Id: I195fdddcce2451e230414ce1a02202e9f8c6af19
Using the standard format for describing the UserHandleAware situation
of this API (e.g. same as isCredentialSharableWithParent has).
Test: N/A. Just javadoc.
Change-Id: I3b9f79af286ac1f4628824899db04fc0a454486a
Remove the divider bar z-ordering logic since the divider bar is
attached to a single-top root task for split screen now. Remove
split anchor too because it is for legacy split screen using.
Also removed corresponding tests which are no longer needed after
this patch.
Bug: 199236198
Test: pass existing tests
Change-Id: I3435a3c81de78804c8110eb38bbacd0a23b391ef
TV PiP repositioning in response to keep clear area changes will be
debounced in SystemUI, so the client side delay in setting a keep clear
area with focus becomes obsolete.
Instead the config is turned into a flag for whether focused views
should automatically be marked as keep clear areas.
Bug: 231309309
Test: atest KeepClearRectsTests
Change-Id: I0ac61e671bb75e22a95b400c9bd8d84004379e43
Merged-In: I0ac61e671bb75e22a95b400c9bd8d84004379e43
TV PiP repositioning in response to keep clear area changes will be
debounced in SystemUI, so the client side delay in setting a keep clear
area with focus becomes obsolete.
Instead the config is turned into a flag for whether focused views
should automatically be marked as keep clear areas.
Bug: 231309309
Test: atest KeepClearRectsTests
Change-Id: I0ac61e671bb75e22a95b400c9bd8d84004379e43
This change adds a static method which can be called to disable the
default behavior of pausing infinite animators when an app's windows
are all in the background. This could potentially be used for
global behavior of a system property to disable this behavior system
wide.
Bug: 232937493
Test: Added new cts test to AnimatorLeakTest to verify behavior
Change-Id: Idf4957e3968253228096671fde89f820311883e3
We use a timestamp to know when is the last transition
of the window. With the value, devlopers could define
the meaning of a stable window.
Bug: 215487047
Test: atest AccessibilityWindowQueryTest AccessibilityWindowInfoTest
manual test
Change-Id: I3ea1c6f4ff135e9ded0a016a6b8a61eb1f754ed7
The API council doesn't want these constants to be deprecated. This is
a partial revert of http://ag/18171342, which keeps and revises the text
that was added to the documentation.
Bug: 208476087
Bug: 232310299
Change-Id: Ia5112416bcccf4dac2fa8f17ebe39dab0a8177f3
The API council doesn't want this constant be deprecated. This is a
partial revert of http://ag/17812636, which keeps and revises the text
that was added to the documentation.
Bug: 208476087
Bug: 232310299
Change-Id: I16b8c15288963d7c3318e8c614f0f7f0b091c221
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
