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
Before WindowProviderService, Service can add windows with several
window types. This is previously not allowed for WindowProviderService
because a context can only associate with a window container.
However, it may cause regressions because Service is used to add
windows with multiple types.
This CL allows WindowProviderService to do so, but WindowProviderService
can only associate with the window type returned by #getWindowType.
This CL also extracts some methods to WindowContext interface so that
WindowContext and WindowProviderService can reuse the same interface.
Test: atest WindowContextPolicyTests StrictModeTest
Test: atest ContextIsUiContextTest ContextGetDisplayTest
Test: atest WindowContextTest WindowContextTests
fixes: 191959013
Change-Id: Ie16916b370a4cbb8a17ccaec9870d47b4b089390
Before, when KEYGUARD_GOING_AWAY is called before WAKE starts,it will
not be passed to the keyguard service to dimiss keyguard. Now, we
merge the flags and add check for that.
Bug: 193564917
Test: check with/without sEnableRemoteKeyguardAnimation
Change-Id: I28d40664b4fbdc0ea199baa32ccefba7dea473f8
Currently, an activity is relaunched from a resize only if
the activity does not handle SCREEN_SIZE config changes and
the new activity size crosses a width, height, or smallest
width resource qualifier. A change in activity size may also
change an activity’s screen layout. However, an activity
is relaunched from a screen layout change if it does not
handle SCREEN_LAYOUT config changes even if the screen layout
did not cross a screen layout resource qualifier.
This CL does three things:
(1) Propogates screen layout qualifiers through the same
path as width, height, and smallest width qualifiers
in the AssetManager to make it available to the
WindowManager.
(2) Prevents an activity relaunch if the screen layout
has been changed but does not cross a screen layout
qualifier.
(3) Adds tests for SizeConfigurationBuckets for the new
screen layout logic as well as for existing logic.
Test: atest FrameworksMockingCoreTests:SizeConfigurationBucketsTest
Bug: b/192369163 b/187529743
Change-Id: I41d28e6492b76c4284c4dca2c1f3f5904fc5e91a
Shell owns the whole display rotation animation now. So, we
can just provide enough information for it to decide when
seamless is requested/appropriate. The default behavior (when
not explicitly animating) is already a jump-cut/seamless, so
just skip the rotation animation if we are doing seamless
Bug: 194693472
Test: atest SeamlessAppRotationTest ShellTransitionTests
Change-Id: I64748f5910c04784fd9818818b029fa5f1339c6c
Creates and registers remote transitions that deal with situations
where keyguard might be occluded/unoccluded.
Bug: 191799478
Test: atest KeyguardInputTests
Change-Id: I625a810aef915de7a01ded9ddbe3042f0e124b52
These are needed for keyguard transitions. The ones added are:
A NOT requirement which will reject transitions with a matching
change.
The ability to match containers that aren't independent.
Checks for global transition flags as well as individual change
flags.
Match only if container is a task.
Bug: 191799478
Test: atest ShellTransitionTests
Change-Id: I963c6c91cdfc0b71a75ba9656261bb0e237f11f1
