Now failures can be automatically directed to the correct buganizer components and forwarded directly to the correct assignees, instead of being all created into the Winscope for further triage
Test: check owners file
Change-Id: I6876a702b4f46443328aab027f7fee994b2bb819
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 391f372726af62c6d9ba9b221508003c37e8ff8a)
(cherry picked from commit 166f263128010f6a885efa17a5ebc3aa94d3b3d6)
Merged-In:I2d72e166fb8de1e503415b5441c03f0685de9573
mRootTaskInfo can be null, so make sure to check it before
accessing in AppPair dump method.
Bug: 206007135
Test: N/A
Change-Id: If012dedd80607af7a1e48512ddd4eaf2bebdc2bf
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 278e944fd5192b578bc9769323bd46105cddd822)
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
(cherry picked from commit 27da5b04d44e76e884f8148684eb36311923c651)
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
