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 391f372726)
(cherry picked from commit 166f263128)
Merged-In:I2d72e166fb8de1e503415b5441c03f0685de9573
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)
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 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
