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
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)
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
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
The stack trace in b/194344478 and b/194280568 is actually from the
preceding ActivityThreadTest test, which does not fail but does crash
certain test cases after that.
Since we may set a start delay on the content overlay fading out
animation, there is chance that onTaskVanished happens before it is
actually started. It's also possible that onTaskVanished happens during
the content overlay fadeout. This CL should have addressed both cases.
Bug: 194344478
Bug: 194280568
Test: atest --iteration 5 \
ActivityThreadTest#testHandlePictureInPictureRequested_overriddenToEnter \
ScreenshotTests#testScreenshotSecureLayers \
TaskStackChangedListenerTest#testTaskChangeCallBacks
Change-Id: I81c0622966df32e02db7cb5aa3cd42d7c4af735e
Merged-In: I81c0622966df32e02db7cb5aa3cd42d7c4af735e
the top of One-handed mode
1. Implement the Dynamic color theme at the top Tutorial area
but the color should not be the same as the recents UI.
2. Do not translate Tutorial icon & text vertically, then provide
quick subtle fade-in effect for Tutorial window.
3. Apply new icon for tutorial.
Bug: 193126258
Bug: 193589897
Test: Local verify when changing dark theme and wallpaper theme.
Test: Local verify Tutorial icon & text fade-in effect.
Test: atest SystemUITests
Test: atest WMShellTests
Test: Perfetto check enter & exit performance
Change-Id: I60f4e7a709f3a27fe6c7f480f1012caccdbbe5ec
Use the shared launcher library to draw legacy icon.
Bug: 193780874
Test: launch app which still using legacy icon from Launcher.
Change-Id: Id8ccb5b6c532880ff207526fd754e92fdd08e284
Included in this CL
- when there is no source rect hint, use a content overlay during the transition
- otherwise, take account the display cutout to offset/inset the source
rect hint
Test with following variants when entering PiP in button nav
- from 0 / 90 / 270 rotation
- with or without source rect hint
- display cutout mode set to default or shortEdge
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/cxk4vy8VenQPSv83vHEs22
Bug: 191310680
Test: manual, see the test cases listed and video above
Change-Id: Ie54a54de6e55397e25024373ea4e2855fde2d9f7
Merged-In: Ie54a54de6e55397e25024373ea4e2855fde2d9f7
SystemUI does not need to re-calculate background color of starting
window because Shell library is bound to SystemUI, so status bar can
get background color directly, also this can support to get the
background color from snapshot starting window.
Also fix the starting window listener did not receiveing background
color successful because makeSplashScreenContentView is execute on
another background thread, so there should block the splash screen
thread until the background color is estimated.
Bug: 192213918
Bug: 192659309
Test: manual launch apps from Notification and Launcher, ensure the
color is correctly send to SystemUI or Launcher.
Change-Id: I626cb23d7aebfe4e032fad285bfad374c0e11cea
Previously, we tried to tuning boottime of SysUI
See go/systemuiboottiming_ohm
- Reduce access setting provide at SysUI start-up
- Remove unused obervers
1. Timeout
2. TapAppExit
- Update mShortcutEnabled state at ctor
Test: manual enable OHM shortcut, rebot
make sure shortcut function works
Test: atest WMShellUnitTests
Test: asit/perf/boottime_test
Bug: 193225130
Change-Id: I2753f8b1e47622c00b9c6d2f4cd319c6e43634ea
- Always show tutorial for user to know device state
is in One-handed mode.
- Clean the redundant params from ctor
Test: manual trigger OHM
Test: atest WMShellUnitTests
Bug: 192648901
Change-Id: I10c3f3f29190b672fb88471df3cf374a994cdaa7
This reverts commit 76370b6fe6.
Reason for revert: Fix the merge break in ShellTaskOrganizerTests.java
Fix: 193069342
Test: atest WMShellUnitTests:ShellTaskOrganizerTests
Change-Id: I02c4bddc407eaac0ebb7cd5abb0b394f242d4d6e
Fix race condition in SystemUIBootTiming issue.
1. Avoid updateOneHandedEnabled() called twice during init
a. [O] come from setOneHandedEnabled()
b. [X] come from setSwipeToNotificationEnabled()
2. Passively waiting shortcut enabled changed callback, and then
query setting ACCESSIBILITY_BUTTON_TARGETS status.
3. Add a new flag isShortcutEnabled to cache shortcut enabled
state.
4. By new OHM Settings UX design setSwipeToNotificationEnabled()
should NOT setEnabledGesturalOverlay().
5. Remove redundant auto enabled Toast and print in log instead.
(In general case, user is not able to see the Toast)
Test: atest google/perf/boottime/boottime-test
Test: atest SystemUITests
Test: atest WMShellTests
Test: manual factory reboot, OHM should disabled by default
Bug: 192612924
Change-Id: I8b24c99bc8bd5bfb17c73a6bb8494109d9a8170d
Security report shows that this can cause leak token of different app.
Replace the functionality with a callback to the TaskOrganizerController
to restart activity when size compat restart button is clicked.
Bug: 186776724
Test: manually verify the restart button still works
Change-Id: I097b9f02e8435e6765695b9d5a531a4e165bac66
Merged-In: I097b9f02e8435e6765695b9d5a531a4e165bac66
