Before, when receive TaskFragment transaction, we apply changes in
multiple WindowContainerTransactions. Now, update to apply all changes
in one WCT for the whole TaskFragment transaction.
Bug: 240519866
Test: pass existing
Change-Id: I943d6232ff226ed6f67367fa9b7f73e1f861de64
Merged-In: I943d6232ff226ed6f67367fa9b7f73e1f861de64
So, the TaskFragmentOrganizer can know what exact operation was
failed and perform error handles if needed.
Removes the pending appeared activities when starting/reparenting
activity into a TaskFragment was failed.
Deprecating the #onTaskFragmentError method with another overloaded
version, but still making sure the deprecated one is called in order
to make it compatible with Android T CTS.
Bug: 236668365
Bug: 233989810
Test: atest TaskFragmentTest
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest
Test: atest TaskFragmentOrganizerPolicyTest
Change-Id: Id328d037536d32b3acb9c424d36052b6dca8628a
Merged-In: Id328d037536d32b3acb9c424d36052b6dca8628a
The API has been no-op for 2 releases.
https://r.android.com/1352354
We should officially deprecate the API.
Bug: 238895989
Test: atest CtsOsTestCases:android.os.cts.DebugTest
Change-Id: Ib1454b200a0ae0da557de02c49c482145deb97df
- Add new api in ActivityOptions for a caller to be able to specify
launch TaskDisplayArea in ActivityOptions.
- Add option to specify launch TaskDisplayArea featureId in
ActivityManagerShellCommand.
Bug: 234349363
Test: atest TaskLaunchParamsModifierTests
Change-Id: I092787ede5245d15774e01054c408533fe632b57
Bug: 216731966
Test: Compile and Test
Cherry-picked from tm-dev
Merged-In: Ic8e9c2db0743738b2b6649451c79a559c3b8edc5
Change-Id: Ic8e9c2db0743738b2b6649451c79a559c3b8edc5
We refactor setAdjacentRoots function on tm-qpr but cts suite is
still using tm branch and it lead to it cannot found previous
function. Add a temp function params same as old one on tm-qpr only
for pass tests.
Fix: 235169332
Test: atest MultiWindowTests on tm-dev codebase
Change-Id: I3eaea698089cec78ef7fcef17817317c55a7bfe6
The flag should be propagated to Parcelable.writeToParcel(). But since
it was hidden, we were not able to pass the flag to elements of the
list.
Bug: 215654054
Test: atest android.os.cts.ParcelTest
Change-Id: I72d419caa74c62d979c5102ebd8eba4338ec3e3b
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
Bug: 233391022
Test: Added new cts test to AnimatorLeakTest to verify behavior
Change-Id: Idf4957e3968253228096671fde89f820311883e3
Merged-In: Idf4957e3968253228096671fde89f820311883e3
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
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
