When entering PiP from GMM with Morris overlay enabled, there will be a
display change callback caused by ui mode change that tend to shift the
PiP window. For PiP, such ui mode change from app is not quite relevant
and we can simply ignore in PipController.
Bug: 201589034
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/dmI3KCeKPAH118BRqnhgNO
Test: enter PiP from GMM with Morris overlay, see video
Merged-In: I2d72e166fb8de1e503415b5441c03f0685de9573
Change-Id: I2d72e166fb8de1e503415b5441c03f0685de9573
(cherry picked from commit 391f372726)
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
Merged-In: I6de444546b5dfba23fc1d7c9c4deb12787d667c5
(cherry picked from commit c86f1eb19e)
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 in this stage, extanding
MAX_DELAY_REMOVAL_TIME_IME_VISIBLE timeout from 450ms to 600ms
(Includes the worst time perviod from tasksnapshot drawn to the task window
focused around 150ms) would be safer and keeps the behavior of original
fixed Bug 192065018.
Bug: 201264769
Test: atest ActivityRecordTests
Test: manual launch apps from Recents.
Test: enter pip, power on/off, verify starting window is removed.
Test: manual enter split screen, verify starting window is removed.
Merged-In: Ieb5a5e781f5da4228cfc493031b4ad17f2d31a77
Change-Id: Ieb5a5e781f5da4228cfc493031b4ad17f2d31a77
As code review in CL[1] from sc-dev, we should preserve the previous
logic to remove home task snapshot immediately, in order to show latest
content as soon as possible for unlocking to home.
Note that this CL is to sync the logic CL[1] in sc-dev for the
downstream branch (qpr1 and v2, and internal master)
[1] I81031f64966b1aeb55cc09f381d4d83ec3460dc9 (sc-dev)
Bug: 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: Ic0cb07504acc11707327360051612df9cce565bd
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 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
When one-handed mode disabled
1. Turn on the shortcut of the OHM with hold volume keys
2. Hold the volume keys
Should trigger one-anded mode
Due to S/W & H/W shortcut keys are mapping to different settings
S/W : ACCESSIBILITY_BUTTON_TARGETS
H/W : ACCESSIBILITY_SHORTCUT_TARGET_SERVICE
We should check both status of the them.
Bug: 193411296
Bug: 198739184
Test: atest WMShellUnitTests
Change-Id: I3994ab89fd6163c283969cc3175877e29b44c67a
Merged-Id: I3994ab89fd6163c283969cc3175877e29b44c67a
Before, the leash might have been released while the update surface
position runnable was in queue. Now, we make sure the leash is valid
before update position.
Fix: 196942784
Test: manual
Change-Id: I2d052bf46b12a2441dbc0aa1aabf5dfe9be2fa45
From code flow, when onConfigurationChanged() by rotating
OneHandedBackgroundPanelOrganizer#showBackgroundPanelLayer()
will be invoked and then create one-handed-background-panel
even though OHM is not activated.
Besides, this could introduce overhead on SF.
Test: manual rotate and dumpsys check HWC layers
Test: atest WMShellUnitTests
Bug: 196306312
Change-Id: Ia766078d5c76b08ab5b24e0ce965ad1d085e4686
In stack animation controller only one target would ever
be added so when the target is re-created after rotating
then it wouldn't be used.
Test: - have some bubbles, drag them around, rotate device, try to
dismiss them => they can be dismissed in landscape
- get more bubbles, rotate back to portrait, try to dismiss
them => they can be dismissed in portrait
- drag the stack around the edges of the screen and verify that
the only magnetic spot is where the dismiss target is
Fixes: 193008696
Change-Id: I6b24b1f9d301d37749dc67c95392fd6c8451df00
Merged-In: I6b24b1f9d301d37749dc67c95392fd6c8451df00
Root cause:
1. Design change "tap app to exit" -> always being true, and settings
remove this option.
2. Tuning performance, due to 1, no longer listens to the key change,
so we remove the listener.
Solution:
Change getSettingsTapsAppToExit() API to return default TRUE.
Bug: 195629000
Test: Build ROM and factory-reset to test
Test: atest WMShellUnitTests
Change-Id: Id3c265258ed28f7e0aa54505c339671885d28fa7
1. Fix bug in the legacy code flow
- Obtain color from contextThemeWrapper Theme_DeviceDefault_DayNight
- In OneHandedDisplayAreaOrganizer#finishOffset()
Remove redundant call "cb.onStartTransition" due to
ambugiuous.
2. Improve performance
- Remove redundunt callbacks.
- Avoid create/remove leash on each start/end cycle.
- Dispatch Transaction to bkg leash through onAnimationUpdate()
bkg leash apply the same Transaction of display area.
- Adjust animation duration of Tutorial panel.
- Move bkg leash depend on yPos value to reduce SF
componsition overhead.
3. Improve code readibility
- Code flow : Register -> onStart() -> show background ->
detach background -> Unregister -> remove leash.
- Remove redundant synchronization due to wmshell already
guarantee thread safe.
- Move getTranslationFraction to SettingsUtil.
- Move getTransitionDuration to SettingsUtil.
Bug: 194507756
Bug: 193589897
Test: Local verify when changing dark theme and wallpaper theme.
Test: atest WMShellUnitTests
Change-Id: Ib55753be9e9f4665c20ad34437f86bf80cc9f3b4
The top activity in TaskActivitiesReport can be filter out if the state
of top activity is INITIALIZING, this doesn't make sense for splash
screen, because the state of the top activity do can be INITIALIZING.
Create a filed targetActivityInfo in StartingWindowInfo to specify the
starting activity info.
Bug: 193459277
Test: atest SplashscreenTests StartingSurfaceDrawerTests
Change-Id: Ifec7aff644013a0426e0622162ab24f6b9fb3d8f
Filter out the translucent pixels when compute the foreground colors
of an adaptive icon, which should make sense because the translucent
pixels on icon should only used for decoration, do not let it affect
the opaque pixels, also with this filter we won't drop down the
performance when using palette.
Bug: 193304878
Test: manual launch single color background apps.
Change-Id: Ia9873cf907d30bb7f30318a289a54159d0a51ee3
