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
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
In Wear OS, when the device enters ambient mode, we will switch the front activity to the background. When device exits ambient mode, the previous activity will be moved back to the front. If the activity hasn't been drawn yet when the device enters ambient mode, we want to show the splash window when it's brought back to the front.
Bug: 176837715
Bug: 199552234
Fix: 199552234
Test: manual test
Change-Id: I8275db9cb51575b61f5a4f04316b77e3f53ba220
(cherry picked from commit 3dc923bafc4454490935fd9e6b4b6602a91febaf)
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)
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.
Change-Id: I03c600afdc477ca0c8064b215f2b361468db9f3c
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
Description: Replaced `Parcel.readList()` call with empty classLoader.
Calling `Parcel.readList(,null)` could be dangerous as an attacker can
abuse the call to deserialize arbitrary parcelables. To avoid such an
attack vector, we should switch in using `Parcel.readTypedList()`
instead.
Test: atest CtsInstantAppTests
Test: atest CtsWindowManagerDeviceTestCases:MultiWindowTests
Test: atest RemoteTransitionTest
Test: Boot and observe systemUI works
Bug: 195622897
Change-Id: I7c8cb23f6f3d26b1d4d47696e70982797b5f0210
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
