This is required for the go/t-activity-transitions where we want to allow apps to fade to a clear background color and fade back in from the background to another activity
Test: atest FlickerTests
Bug: 202844659
Change-Id: Iea18a8e7d32a63da55ab3430c47f903da5cff807
As CL[1] introduced WindowTokenClient for WindowProviderService (aka the
parent class of InputMethodService starts from CL[2]) as a token that
IME context can associate with the windowContainer of
the InputMethod window in server side. Like the activity context,
IME context can adopt configuration/resources update when the IME
window changed by display/window changes.
And, the IME context caller can also create another type of context
with wrapping IME context (i.e. calling createDisplayContext to create
a display context), that makes this context can be mixed the window
token of WindowProviderService since it's the base context.
However, the finalization of the context mixed WindowTokenClient
will detach the token when the attached context type is non-window
context, this action will mis-detach the token when it managed by
WindowProviderService.
So like SoftKeyboard previously using
createDisplayContext in CL[3] to workaround context resources issues,
will in-directly expose this mis-detach token issue as the above.
Beside, the handling of WindowTokenClient#{onConfigurationChange,
onWindowTokenRemoved} does not thread-safe since this is called from
IPC.
As the result, the fix is to ignore the check in ContextImpl#finalize
to not detach the token when it managed by WindowProviderService,
also make sure to post to the main handler when received
onConfigurationChanged/onWindowTokenRemoved in WindowTokenClient.
Note that this fix could help to resolve "The Window Context should
have been attached to a DisplayArea." exception if the token has been
detached as the above case that happens before the next
WindowProviderService#attachToWindowToken invoked.
[1]: I64a1614f32d097785915f6105b1813a929e0fe32
[2]: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
[3]: Ic592a1d2fb2da149220c8b503b522b3e864bcc77
Bug: 213118079
Bug: 211062619
Test: manual as steps:
1) adb install -r EditTextVariations.apk
2) adb install -r SoftKeyboard.apk
3) adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
4) adb shell ime set com.example.android.softkeyboard/.SoftKeyboard5
5) Enable screen auto-rotation
6) Launch EditTextVariations from launcher's shortcut
7) Tap the first EditText field to show IME
8) Rotate the device to the landscape mode
9) Expect the IME should not be shrunk
Change-Id: I7beb7a122af93e596239a36db62073233cea0726
Ask the policy controller whether an activity can be displayed on the
virtual display when it is going to launch or reparent.
Also notify the policy controller the activity changes on the virtual
display.
Bug: 201712607
Test: atest DisplayWindowPolicyControllerHelperTests
atest ActivityRecordTests
atest ActivityTaskSupervisorTests
atest TaskTests
atest TaskFragmentTest
atest WindowManagerServiceTests
Change-Id: I11fcc38782b21ccb2f0474777242dbf5901c59e1
Revert submission 16468379
Reason for revert: Feature development is moving to T.
Reverted Changes:
Id9b9a8930:[3/n] Camera Compat UI: Add a camera compat contro...
Id6be4a954:Enable a camera app compat control on Large screen...
I083aa6718:[2/n] Camera Compat UI: Add interfaces for client-...
Bug: 206602997
Change-Id: I9ad876043fd61f708a8f468fffd1ef371bfa0866
Allow developer to control the splash screen style when the option is
used for cold or warm launch an activity.
Bug: 203497083
Test: atest SplashscreenTests#testLaunchFromLauncherWithEmptyIconOptions
Test: atest SplashscreenTests#testLaunchAppWithIconOptions
Change-Id: I9c4ccca2470df5dbac96da2d4a96b616b6670688
Test: Make sure apps with custom animations set using WindowAnimationStyle actually use the custom animation when shell is enabled
Bug: 206960607
Change-Id: I1d982870837d67c74f76dd0a90aa5260d9441aba
Changes:
- Listens to changes from the client coming through IActivityClientController#requestCompatCameraControl to ActivityRecord#updateCameraCompatState
- ActivityRecord#updateCameraCompatState sends updated state via TaskInfo to WM Shell
- ITaskOrganizerController#updateCameraCompatControlState to dispatch the user interactions with the control from WM Shell triggers callback to ActivityRecord#updateCameraCompatStateFromUser
- ActivityRecord#updateCameraCompatStateFromUser remembers the user's choice and asks client to apply treatment through ICompatCameraControlCallback
Feature is guarded with config_isCameraCompatControlForStretchedIssuesEnabled
Test: atest WMShellUnitTests:ShellTaskOrganizerTests, atest WmTests:ActivityRecordTests
Bug: 206602997
Change-Id: I083aa6718bd67456bedd9444e9b78740c041f870
A direct display rotation goes through requestStartTransition
instead of "remote rotation". As a result, we need to hook-up
the handleRequest to shell's displayChangeController so that
other shell components (like task organizers) have a chance
to calculate new bounds for their organized windows.
Bug: 206872147
Test: via logging, ensure that shell DisplayChangingListener
is fired during a display rotation.
Change-Id: I839ebd28d4947ed3ec41d48724702d035f726f11
The displayInfo contains information about transform and display size.
This info was not being passed to the WindowInfosListener, making it
difficult to get coordinates on screen.
Send the displayInfo through JNI to the Java side listener
Test: WindowInfosListener gets displayInfo
Bug: 188792659
Change-Id: Ib4fdb6f0c27bd4276421c4a5235c5112514b32f3
The SizeConfigurationBuckets was used to avoid activity relaunch
by insignificant configuration change. Because WindowTokenClient
doesn't have relaunch operation, it is unnecessary to use it.
Especially Resources#getSizeConfigurations() is a heavy invocation,
which may create hundreds of temporal Configuration when calling it
in system server.
Also fix leakage of SystemUiContext if it is detached, e.g. the
associated display is removed.
Bug: 207620458
Test: atest WindowContextControllerTest
Change-Id: I8388a2ab25f3deed2e29eb5636c4b2130f4f1b87
- Do not bring split to top on entering PiP
When swiping up to home (or other cases) triggers one of the
split-screen children enters PiP, do not try to bring the other task
to top since the pair should be considered invisible.
- When entering PiP from split screen or non-auto PiP case, use the
alpha information in PictureInPictureSurfaceTransaction to hide the
task which would later be turned back on to avoid flicker.
Bug: 190855091
Bug: 205894095
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/42RWtayanp2qG0mHSf4Q5
Test: manual, enter PiP from split-screen, see Video
Change-Id: I1559748cd583c20d79ee458822d66e7801733d3a
Some shell actions require the ability to launch a shortcut either
in a transaction and/or with other window operations (eg. Bubbles
and Split-screen).
This required changes to LauncherAppsService to support forwarding
the caller information internally from systemserver.
Bug: 209073176
Test: existing LauncherAppsService tests still pass
Change-Id: I11893abca24cab0b899c3385af0ca46932bcc9e3
Adds an interal method to check if an activity is being organized
by any process. This can be used by WM Jetpack Extensions APIs to
inform apps about their activities being embedded.
Bug: 204399167
Test: Manual, using demo app
Change-Id: I3a0ad021ad43c97bf9b92df05e9858aae143f62b
In multi-window split, if one of the adjacent task are moved to front,
we need to move another one forward to ensure all the other tasks will
be occluded by these adjacent tasks as expectedly. Add a flag to
distinguish whether to move the adjacent tasks together when setting
adjacent tasks.
Fix: 204130085
Test: atest TaskTests
Test: atest WMShellUnitTests
Change-Id: I34ccd2633b23425a978bd3df4acc50f17323de21
Previous the splash screen style can either be EMPTY or ICON, and need
to be set by new hidden API #setSplashscreenStyle, so the flag will
always be "EMPTY" for those 3rd party Launcher Apps which may have not
upgrade to targetSDK 31.
To correct the default behaivor for Launcher Apps, create a new
UNDEFINED style as default value for splashScreenStyle, and if the
value is UNDEFINED, determine the style by checking the launch source.
Test: Verify no change when default home is NexusLauncher.
Test: Set 3rd-party Launcher as default home, verify the splash screen
style should be ICON when launch app from Launcher.
Test: atest SplashscreenTests
Bug: 206746601
Change-Id: I105e2fcfc7a6ee8de7f442931cbeb4b6e517850d
Merged-In: I105e2fcfc7a6ee8de7f442931cbeb4b6e517850d
Since there are some system flags we care about, add mSystemWindowFlag
for DWPC determination.
Bug: 201712607
Test: manual
Change-Id: I7dd75e612cacfe91d340324083705e80ce9bd112
Previous the splash screen style can either be EMPTY or ICON, and need
to be set by new hidden API #setSplashscreenStyle, so the flag will
always be "EMPTY" for those 3rd party Launcher Apps which may have not
upgrade to targetSDK 31.
To correct the default behaivor for Launcher Apps, create a new
UNDEFINED style as default value for splashScreenStyle, and if the
value is UNDEFINED, determine the style by checking the launch source.
Test: Verify no change when default home is NexusLauncher.
Test: Set 3rd-party Launcher as default home, verify the splash screen
style should be ICON style when launch app from Launcher.
Test: atest SplashscreenTests
Bug: 206746601
Change-Id: I105e2fcfc7a6ee8de7f442931cbeb4b6e517850d
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Bug: 205859784
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Test: atest NexusLauncherTests
Change-Id: I64a1614f32d097785915f6105b1813a929e0fe32
A controller to control the policies of the windows that can be
displayed on the virtual display.
Also migrate task event callbacks.
Bug: 201712607
Test: manual
Change-Id: I4accd76beda6829cd1b33ad50c0860405ae10678
We don't really have any use case to manipulate TaskFragment leash, and
removing it can reduce chance for related security issue.
Fix: 207061678
Test: pass existing
Change-Id: I24617228991f030335ba74ce7c2ee48b9c33b9d6
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Bug: 205859784
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Test: atest NexusLauncherTests
Change-Id: I64a1614f32d097785915f6105b1813a929e0fe32
Add FEATURE_IME as unique id for ImeContainer to organize it from
WmShell.
Disable automatic ImeContainer surface and container reparenting when
it is organized.
These changes enable vendors to control where the IMEs are positioned
and implement custom UX rules (e.g. for foldable devices - place the
IME on the bottom screen while the focused app is on the top one).
Manual test:
Organize FEATURE_IME from WmShell.
Set its bounds, appBounds, screenSizeDp and setSmallestScreenWidthDp.
Outcome:
* The IME receives onConfigurationChanges.
* The IME is updated on the screen.
* The IME is not reparented from its default parent.
Test: atest WmTests:WindowProcessControllerTests
Test: atest WmTests:DisplayContentTests
Test: atest WmTests:WindowContainerTests
Test: atest WmTests:DisplayAreaTest
Test: atest WmTests:DualDisplayAreaGroupPolicyTest
Bug: 188038793
Change-Id: I438253e9647ceab5b7847b8db66db8399271723f
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Change-Id: Idd74da965c18bdbf8912bd45e89be21f652dcf93
