Before, we call Activity#finish() to finish activities when removing
TaskFragment. This may start a CLOSE transition before the organizer has
a chance to request the actual transition type.
Now, we allow the organizer to finish activities through WCT so that the
operation is atomic and the organizer can request the correct transition
type.
Bug: 240519866
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Test: atest CtsWindowManagerDeviceTestCases:TaskFragmentOrganizerTest
Change-Id: I54671fb2dd34dca952468305429a90d89953de69
Adds new requestBaseStateOverride on DeviceStateManager
to be used for testing, to provide a similar behavior
to changing the physical configuration of the device.
This is necessary now that the requestState API is being
used for features now, we need a test API that will
be a closer simulation to physical device changes.
Bug: 234336979
Test: DeviceStateManagerGlobalTest
Change-Id: I6ad9e799329f16521aa3c13b248eed762fe0b121
DreamManager#startDream has been updated on QPR and master which removes
the unnecessary component name parameter, but it breaks TM CTS tests.
The interim api added in this change will prevent breakage on TM, and
should not be merged downstream.
Test: atest DreamManagerServiceTests
Fix: 245223722
Fix: 245058392
Fix: 245070240
Change-Id: Id9e8cc67003da9fc3e03bffd6ec50643d10652b5
The callback handling is moved to SplitController#onTransactionReady, no
longer need those TestApi.
This is different from the merged-in cl for CTS compatibility in the
current release.
Bug: 240519866
Test: pass existing
Change-Id: I66ddd51c94003254001436ff0505dde3b26d0437
Merged-In: I66ddd51c94003254001436ff0505dde3b26d0437
This change
- adds a new private API in dream manager that allows a client with
write dream permission to set a system dream component, which takes
precedence over user configured dream
- fixes startDream() API in DreamManager which shouldn't take in a
component name
Test: atest SystemDreamTest
Bug: 222529147
Change-Id: Iee9a0af1071e5ed57fa5bd4b0d06d8178118116e
Added removeTask HierarchyOp so that CaptionWIndowDecorModel now uses WindowContainerTransaction to remove task rather than IActivityTaskManager#removeTask(int)
Bug: 242094334
Test: Manual testing using acloud and unit testing (atest WmTests:WindowContainerTransactionTests)
Change-Id: I9e2f1946a517bdba6a75b7049f00943d729045f0
So that we can verify the API in CTS.
Bug: 232476698
Test: CtsWindowManagerDeviceTestCases:TaskFragmentOrganizerPolicyTest
Change-Id: I0e064f8cae48cc0281a0b462b8d072baceeeca9f
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
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
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
Notifications can be non-blockable if their app has the
permission fixed or if the app holds certain roles.
Calculate that on device boot and role change, and use the same
source of truth for all UIs. As a bonus, we can remove some
systemui binder calls.
Test: SystemUiTests & FrameworkUiServicesTests
TesT: verify that 'usb debugging connected' notifs are non blockable
but magnification ones are, in systemui and settings
Fixes: 231662091
Change-Id: I980718ab61196901d976f9ea8ee035eafc021fc8
This should be final clean patch, remove legacy split screen
package and its windowing modes
Bug: 199236198
Test: build pass
Test: pass existing tests
Ignore-AOSP-First: remove whole package
Change-Id: Ib2af42834938032bf525b8c16b1046b4c898b8d5
And the related obsolete code.
Test: SystemUITests, framework services tests, NotificationManagerTest
Fixes: 231344755
Change-Id: Id14941f82305b0216f2a12221d4195f8afcc65ab
We currently close the IME by having the target application forward KEYCODE_BACK to the IME process through InputMethodManager#dispatchInputEvent and having the IME handle the keycode in InputMethodService#onKeyDown. When apps opt in to OnBackInvokedDispatcher API, we will not dispatch KEYCODE_BACK to apps anymore. Thus we need to migrate IME to the new API for it to close on back invocation.
This implementation forwards OnBackInvokedCallbacks from the IME process
to the app process. This is necessary because all callbacks need to
exist in the app process for them to be considered by hardware back keys. While back gestures go through WM to resolve callbacks from the focused window, hw keys are directly sent to the focused window's ViewRootImpl, bypassing server side back nav logic.
Bug: 228358882
Test: atest CtsInputMethodTestCases:KeyboardVisibilityControlTest
Test: atest CtsInputMethodTestCases:InputMethodServiceTest
Test: atest CtsInputMethodTestCases
Change-Id: Ie207b63b11a56c9b2173f26b734a27b13ebccc60
A user can be created with an explicitly null name, as happens in tests.
But getUserName claims to never return null. So we must do a null-check
here to prevent it.
Bug: 227624966
Test: atest UserManagerTest
Change-Id: Iea0e7b6292c6dd49df1bebc5467091a82ddaedb5
update the lint baselines for the new SDK
Bug: 225745567
Test: Build
Change-Id: Ifcc86b065ce770561a391a84d8bb81c2b72307cd
Merged-In: Ifcc86b065ce770561a391a84d8bb81c2b72307cd
