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
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
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
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
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
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
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
This basically ties applicationthread binder token to remote
transitions. Shell is first boosted (to run the shell transition
logic) and if it then delegates to a remotetransition, it will
then request that process also be boosted.
Bug: 183993977
Test: add logging in WPC.setRunningRemoteAnimation and verify calls
during transitions
Change-Id: I94babc327e935ea81271942287a83b948dd11f8b
Add jank instrument support for splash screen avd and exit animation.
Bug: 195736656
Test: see trace in comment
Change-Id: I1fdb9e14145bcf519eea99e440de74238e3c765c
It was done by WMS#startFreezingDisplay~stopFreezingDisplayLocked.
The duration is measured from rotation change to start animation.
Add a remote callback to know when the rotation animation is started.
So WM core can have the paired begin/end of trace that matches the
latency exactly.
The added ITransitionMetricsReporter is available for any processes.
So in the future it can also report the metrics from remote animator.
This change focuses on the rotation animation handled by shell.
Bug: 199836343
Test: adb shell setprop persist.debug.shell_transit 1; reboot
Rotate display and check trace "L<ACTION_ROTATE_SCREEN>".
Change-Id: I180d2fe1a77e98b6427ba831a2db2593739376bd
Follow latest split screen UX model, it should only reparent
the top task to split for app-pair model.
Fix: 201480664
Bug: 202740040
Test: manual
Test: pass existing tests
Change-Id: I4b360a31ce8e7366a77216a94b5f1b19bba848e9
Use applyTransactionOnDraw to ensure all transaction happen
during the same frame, including
- hide the starting window.
- reparent the remote SurfaceView to client.
Bug: 198593932
Test: continues launch test app several times then verify with winscope
to ensure there is no flicker anymore.
Merged-In: I03c600afdc477ca0c8064b215f2b361468db9f3c
Change-Id: I03c600afdc477ca0c8064b215f2b361468db9f3c
The tasksnapshot starting window could stuck on task if the task never
gain focus, this could happen when launch multiple tasks to front, e.g.
split screen, or add snapshot starting window to a pip task.
As using task focus to judge the task snapshot removal may error-prone.
(i.e. unexpected window focus in/lost, non-focusable task window..)
To ensure the tasksnapshot removal works stable, extanding
MAX_DELAY_REMOVAL_TIME_IME_VISIBLE timeout from 450ms to 600ms and also
reference mayImeShowOnLaunchingActivity to know whether IME showing on
this activity.
Bug: 199377815
Bug: 201264769
Bug: 200778734
Test: atest ActivityRecordTests StartingSurfaceDrawerTests
SplashscreenTests
Test: manual launch apps with IME from Recents.
Test: enter pip, power on/off, verify starting window is removed.
Test: manual enter split screen, verify starting window is removed.
Change-Id: I81b048a655124923a5f19e7f236511502bbf4c91
(cherry picked from commit a4f760bee7)
This CL aims to optimize the previous CL[1] to schedule removing
tasksnapshot after a fixed timeout according the tasksnapshot:
- With IME snapshot: 350ms
- Without IME snapshot: 100ms
As the previous approach has some cons espically when the tasksnapshot
has IME shown:
1) It lacks a signal or callback to notify WmShell to dismiss
tasksnapshot when IME is actually drawn on the task and always
dismissed after the timeout.
2) The timing to schedule tasksnapsit removal is when
ActivityRecord#onWindowFirstDrawn, which is much eariler than the
window focused (about 100-150ms), and it may easier to see flickering
when the task is showing IME.
The reason is that IME is drawn after window focused and started input
connection. Also, starts from R, IME insets visiblity
is handled by the app's UI thread, so if the schedule removal timing
been triggered too early and if IME / App takes more time to handle IME
surface layout, then user might aware the app task flickering when
tasksnapshot dismissed, since IME is not yet be drawn and then it
show up again when the next layout finished.
In this CL, we made the following changes to improve the above cons
- Postpone the schedule removing tasksnapshot (with IME) timing to
after the app task has focused.
- Modify the tasksnapshot removal timeout (with IME) from 350ms to
450ms (with renaming to MAX_DELAY_REMOVAL_TIME_IME_VISIBLE),
in case some edge cases may take longer time to process IME layout.
- add ITaskOrganizer#onImeDrawnOnTask(taskId) to notify the shell
task organizer to properly remove the tasksnapshot without waiting
until the max timeout.
[1]: I7865e17b57961e12a0cdcf068e412195123a6ec7
Fix: 192065018
Test: ateset StartingSurfaceDrawerTests#\
testRemoveTaskSnapshotWithImeSurfaceWhenOnImeDrawn
Test: manual tests by
1) launching Android Message with focusing an editor
2) swiping out to home and launch another apps (e.g. chrome)
3) swiping up to overview, tapping Android Message task
4) verify if IME is flickering after switched back.
Change-Id: I81031f64966b1aeb55cc09f381d4d83ec3460dc9
(cherry picked from commit 278e944fd5)
This change make the snapshot starting window holds the requested
visibilities when created from the task. Such that, when the window get
back from the background, the insets state in the window state can have
the correct visibilities.
Test: check getInsetsStateWithVisibilityOverride as described in the bug.
Bug: 196637509
Bug: 185729224
Change-Id: I54ab0791b169331c22cd89f7e6da640322bf7dd3
WindowContext relies on WindowTokenClient#onConfigurationChanged after
calling WMS#attachWindowContextToDisplayArea.
However, it took some time to wait for onConfigurationChanged callback
from the server side so that we may get a stale value right after
creating WindowContext.
This confuses developers especially when the foreground activity is in
size compat mode or freeform because the process config is overridden
by activity's config.
This CL makes #attachWindowContextToDisplayArea return DA's configuration
and applies to WindowContext direcly.
It also benefits WindowProviderService because it can obtain DA's
configuration before onCreate() based on [1] and this CL.
Bug: 190019118
Bug: 190745506
Bug: 198298520
Test: manual - 1. launch an Activity in size compat mode
2. create a WindowContext and verify if WindowMetrics
matches DA bounds.
Test: atest WindowContextTest WindowContextTests
Test: atest WindowContextControllerTest ContextGetDisplayTest
[1]: dd4a748af0
Change-Id: I8dd3987b731662502bc01e9d2ed67e718ada5f46
This CL aims to optimize the previous CL[1] to schedule removing
tasksnapshot after a fixed timeout according the tasksnapshot:
- With IME snapshot: 350ms
- Without IME snapshot: 100ms
As the previous approach has some cons espically when the tasksnapshot
has IME shown:
1) It lacks a signal or callback to notify WmShell to dismiss
tasksnapshot when IME is actually drawn on the task and always
dismissed after the timeout.
2) The timing to schedule tasksnapsit removal is when
ActivityRecord#onWindowFirstDrawn, which is much eariler than the
window focused (about 100-150ms), and it may easier to see flickering
when the task is showing IME.
The reason is that IME is drawn after window focused and started input
connection. Also, starts from R, IME insets visiblity
is handled by the app's UI thread, so if the schedule removal timing
been triggered too early and if IME / App takes more time to handle IME
surface layout, then user might aware the app task flickering when
tasksnapshot dismissed, since IME is not yet be drawn and then it
show up again when the next layout finished.
In this CL, we made the following changes to improve the above cons
- Postpone the schedule removing tasksnapshot (with IME) timing to
after the app task has focused.
- Modify the tasksnapshot removal timeout (with IME) from 350ms to
450ms (with renaming to MAX_DELAY_REMOVAL_TIME_IME_VISIBLE),
in case some edge cases may take longer time to process IME layout.
- add ITaskOrganizer#onImeDrawnOnTask(taskId) to notify the shell
task organizer to properly remove the tasksnapshot without waiting
until the max timeout.
[1]: I5fb0fa3a1e6a5e6210d3baf400a84c5892bd2e34
Fix: 192065018
Test: ateset StartingSurfaceDrawerTests#\
testRemoveTaskSnapshotWithImeSurfaceWhenOnImeDrawn
Test: manual tests by
1) launching Android Message with focusing an editor
2) swiping out to home and launch another apps (e.g. chrome)
3) swiping up to overview, tapping Android Message task
4) verify if IME is flickering after switched back.
Change-Id: I81031f64966b1aeb55cc09f381d4d83ec3460dc9
This CL aims to optimize the previous CL[1] to schedule removing
tasksnapshot after a fixed timeout according the tasksnapshot:
- With IME snapshot: 350ms
- Without IME snapshot: 100ms
As the previous approach has some cons espically when the tasksnapshot
has IME shown:
1) It lacks a signal or callback to notify WmShell to dismiss
tasksnapshot when IME is actually drawn on the task and always
dismissed after the timeout.
2) The timing to schedule tasksnapsit removal is when
ActivityRecord#onWindowFirstDrawn, which is much eariler than the
window focused (about 100-150ms), and it may easier to see flickering
when the task is showing IME.
The reason is that IME is drawn after window focused and started input
connection. Also, starts from R, IME insets visiblity
is handled by the app's UI thread, so if the schedule removal timing
been triggered too early and if IME / App takes more time to handle IME
surface layout, then user might aware the app task flickering when
tasksnapshot dismissed, since IME is not yet be drawn and then it
show up again when the next layout finished.
In this CL, we made the following changes to improve the above cons
- Postpone the schedule removing tasksnapshot (with IME) timing to
after the app task has focused.
- Modify the tasksnapshot removal timeout (with IME) from 350ms to
450ms (with renaming to MAX_DELAY_REMOVAL_TIME_IME_VISIBLE),
in case some edge cases may take longer time to process IME layout.
- add ITaskOrganizer#onImeDrawnOnTask(taskId) to notify the shell
task organizer to properly remove the tasksnapshot without waiting
until the max timeout.
[1]: I7865e17b57961e12a0cdcf068e412195123a6ec7
Fix: 192065018
Test: ateset StartingSurfaceDrawerTests#\
testRemoveTaskSnapshotWithImeSurfaceWhenOnImeDrawn
Test: manual tests by
1) launching Android Message with focusing an editor
2) swiping out to home and launch another apps (e.g. chrome)
3) swiping up to overview, tapping Android Message task
4) verify if IME is flickering after switched back.
Change-Id: I81031f64966b1aeb55cc09f381d4d83ec3460dc9
Also rename TaskFragmentAdjacentOptions to TaskFragmentAdjacentParams to
make metalava happy.
Test: build & run
Bug: 192442647
Change-Id: Iab256ce8c745635a51834f44e72493e204224f36
Placeholder activity was finished while starting the
task root activity from launcher because the task
root activity was set as singleTask launch mode.
Meanwhile, the primary TaskFragment was also removed
because of the split-rule finishPrimaryWithSecondary.
Sending the information of whether the last activity
on the TaskFragment was finished due to launch other
activity to client. So that the organizer can decide
whether the primary TaskFragment should removed.
Bug: 196179714
Test: relaunch singleTask activity with placeholder
Change-Id: I9a0369285adfbdef1edc5a7f2af944ec5b434566
The SurfaceView of the AVD icon should be create on splash screen
thread instead of worker thread, this can guarantee that the first
frame of the FrameLayout and AVD will be draw at the same frame.
And it also become faster by combining two view in same traversal
together.
Also stop the AVD animation after splash screen window removed.
Bug: 195736516
Test: verify no more Choreographer#doFrame on splash screen thread
after splash screen window removed.
Change-Id: I5942db8974f1272d9c26ac19b164312e4424be66
The FrameLayout and SplashScreenView are only used as container in
StartingSurfaceDrawer, so they do not need to be inflated by app's
context, which could be affected by app's resources.
Bug: 197936273
Test: cold launch test app and show splash screen.
Test: launch several apps to verify that everything is fine.
Test: atest StartingSurfaceDrawerTests
Change-Id: I6de444546b5dfba23fc1d7c9c4deb12787d667c5
This is in preparation for attaching some extra meta information
to remote transitions (eg. process token). Most of this refactor
just replaces references to the raw interface with references
to the wrapper class.
There is also a small refactor in RemoteTransitionHandler to
better-manage death-recipients. It is possible to have >1 filter
and >1 pendings referencing the same remote simultaneously, so
this arrangement properly handles the 1-to-many possibility.
Bug: 183993977
Test: refactor, so existing tests pass
Change-Id: Icae8f2128e0ffdf7aee51284cba106963450e3e7
Merged-In: Icae8f2128e0ffdf7aee51284cba106963450e3e7
When finishing a placeholder activity, the secondary container was
clean up, and the primary activity was also finished. However, the
primary container didn't remove and therefore was expanded to
fullscreen before the activity within completely being removed.
Which resulted in TRANSIT_OLD_TASK_FRAGMENT_CHANGE transition
after commit 118428b merged.
Bug: 198228078
Test: finishing placeholder activity and back to launcher
Change-Id: I3d55f0be8c7f6ab3970450d7b90dd95f3cfdd463
When all windows in the transition is belong to organized TaskFragments,
have the TaskFragmentOrganizer to control the animation on client side.
Bug: 196173550
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Test: atest WmTests:AppTransitionControllerTest
Change-Id: I835467e23863286a5bd34380424cc9eca2c7372f
The embedded activity was destroyed immediately when being
finished because the next top activity was on the adjacent
TaskFragment and was already visible. Therefore, the finishing
animation was played before the organizer requested to
finish the activity on the adjacent TaskFragment.
Prevent the last activity of the embedded TaskFragment to
be removed immediately if the organizer requested to.
Bug: 189386466
Test: finish both activities on separate TaskFragments
Change-Id: I916eddc4dcf0de3bc7ed7264296f441d1b7bb726
