* changes:
DO NOT MERGE Revert "[2/n] Camera Compat UI: Add interfaces for client-server..."
DO NOT MERGE Revert "[3/n] Camera Compat UI: Add a camera compat control."
DO NOT MERGE Revert "Log the CameraCompatControlEventReported atom."
Revert submission 16468379
Reason for revert: Feature development is moving to T.
Reverted Changes:
Id9b9a8930:[3/n] Camera Compat UI: Add a camera compat contro...
Id6be4a954:Enable a camera app compat control on Large screen...
I083aa6718:[2/n] Camera Compat UI: Add interfaces for client-...
Bug: 206602997
Change-Id: I9ad876043fd61f708a8f468fffd1ef371bfa0866
Revert submission 16468379
Reason for revert: Feature development is moving to T.
Reverted Changes:
Id9b9a8930:[3/n] Camera Compat UI: Add a camera compat contro...
Id6be4a954:Enable a camera app compat control on Large screen...
I083aa6718:[2/n] Camera Compat UI: Add interfaces for client-...
Bug: 206602997
Change-Id: I318b89b87cd3b05a3f3dcd428e3d80fe81465011
Without this cl, we always override animation as long as there is any
organzied TaskFragment. And users may see different animation on the
same small screen before and after they have unfold and fold.
The idea is to only register the remote handler if the app currently has
at least one split rule that can fit the current Task bounds.
When there can be split, we want to always override the animation to
make it consistent.
When there won't be any split, we want to allow app to override
animation, so they can still provide the same experience as normal phone
on small screen.
Fix: 207804116
Fix: 196173550
Test: manual test with fold/unfold
Change-Id: I3ae194f89b35afc5734338fd3bb350e0cd364c85
Without this cl, the app will crash if a TaskFragment is closing when
the new top TaskFragment doesn't contain any non-finishing activity
(which should be closed later as well).
Before, when #cleanupContainer(), we will also update the new top active
container, but we didn't check if it contain any non finishing activity.
Fix: 212355346
Test: test with Settings with three finger click
Change-Id: I26538b85f1cf8e618a3f1ee6abada5a9f77f2b16
- In the off chance that the controller is already invalidated (due to
service reconnection to launcher for example), then any calls through
the previous binder should just return an empty task list.
Bug: 206648922
Test: Manual (haven't been able to repro)
Change-Id: Iff6193fa89c2baecc527e589f17ae41b82575a48
Task topActivityInfo is nullable, we should check it is null or
not before access it.
Bug: 213894166
Test: pass existing tests
Change-Id: Iedda57145586b6d5c2e151308ddca1e2e36035c0
- If init() is called multiple times, the previous magnetized targets
can cause the wrong target position to be calculated when trying (or
not trying) to dismiss
Bug: 213348722
Test: Manual
Change-Id: Ic1f972cc60eafca2302ad168065c974c8a0ee924
While split pair switching, split remain as active so it might
record new bounds with old top task pair unexpectly.
Fix this by set flag to false on startTasksWithLegacyTransition
and reset to true after remote animation finished.
Fix: 213128767
Test: manual
Test: pass existing tests
Change-Id: I42b4c79558467dec23b789a3b5cc2f8f38cd1c36
Merged-In: I42b4c79558467dec23b789a3b5cc2f8f38cd1c36
After fold animation finished, it will always set null bounds crop
to surface and cause root task surface bounds abnormal.
Fix by ignoring root task surface in StageTaskUnfoldController
because it would not effect animation.
Fix: 211132158
Test: manual
Test: pass existing tests
Change-Id: Iece8f7e7d437bdff1cf9e738df3acc075729b993
Fix laucher crash while swipe up in split screen. This issue caused
by launcher will request 3 runningTaskInfos to do some action,
however, it cannot ensure 3 info actually include both splits because
only one got focused. Fix this by WA on RunningTasks, update the
adjacent task of the focus one too to make sure both split task
will be top two while calling getTasks.
Correct some split behavior while startTasksWithLegacyTransition
too.
Bug: 211716649
Test: pass existing tests.
Test: Make many split pair then swipe up
Change-Id: I2e6deb2ac607b454ca8fc760f0399135a1e8e901
Merged-In: I2e6deb2ac607b454ca8fc760f0399135a1e8e901
Before this change, margin between a hint and a camera compat control was smaller than required 8 dp while for a size compat control it was bigger than 8dp (since ag/16420818). This change makes them consistent and also simplifies layout definition for the size compat button by declaring margings explicitly rather than including them in width and height implicitly.
Test: manual
Bug: 206602997
Change-Id: I09839e764d2c8904954a594433888bfdc21d56ba
Fix divider target should pass to remote animation runner and add
mIsDividerRemoteAnimating flag to eusure launcher side controlling
the divider surface and shell side do not controll until remote
animation finished.
Bug: 202914644
Test: manual
Test: pass existing tests
Merged-In: I6411a609268274355a38c72fcb5d628b76b2340c
Change-Id: I6411a609268274355a38c72fcb5d628b76b2340c
Changes:
- Listens to changes from the client coming through IActivityClientController#requestCompatCameraControl to ActivityRecord#updateCameraCompatState
- ActivityRecord#updateCameraCompatState sends updated state via TaskInfo to WM Shell
- ITaskOrganizerController#updateCameraCompatControlState to dispatch the user interactions with the control from WM Shell triggers callback to ActivityRecord#updateCameraCompatStateFromUser
- ActivityRecord#updateCameraCompatStateFromUser remembers the user's choice and asks client to apply treatment through ICompatCameraControlCallback
Feature is guarded with config_isCameraCompatControlForStretchedIssuesEnabled
Test: atest WMShellUnitTests:ShellTaskOrganizerTests, atest WmTests:ActivityRecordTests
Bug: 206602997
Change-Id: I083aa6718bd67456bedd9444e9b78740c041f870
I've never been able to reproduce this and the stack traces I have
of it don't match existing code, but looking at the code paths I think
this could still happen, there are a couple of places where the
mMagnetizedBubbleDraggingOut gets nulled out (e.g. on child removed)
I've tried to repro by:
- canceling the bubbles in the middle of dragging to dismiss
- trying to snap the bubble back and then drag it again to dismiss
(snap back also nulls it)
I see a recent stack of it in pitot so I think it's worth adding the
null check.
Test: atest ExpandedAnimationControllerTest
Bug: 201866808
Change-Id: Ib9425a2b63410c95fddaaea59761dfd18557ed54
Navigation bar is only created and used when taskbar is not available.
When taskbar is available, we will use TaskbarDelegate to be the one
responsible to update pip exclusion bounds as PiP moves.
Bug: 210038947
Test: Unfold, enter PiP, stash - PiP can be yanked out
Change-Id: I8f789d3b603e41c3d15494afdadce2cddc4d4b9c
The dropzones were always split exactly in half on the screen
which looks weird if you adjust the split to a different size
and then drag new apps into split.
This adjusts the dropzones to match the size of the existing
split.
It also fixes a bug where the existing split bounds weren't
being properly calculated in the policy so the drag and drop
highlight wouldn't switch to the correct side until you
passed through the middle instead of where the divider
actually is.
Bug: 209504662
Test: manual - 1) have apps in split
2) adjust the divider
3) start dragging a new app into split, pass
across the divider
=> the highlight should immediately switch
=> the highlight should match the size of the
existing split
4) test in landscape & portrait
Change-Id: I3c7a288625ad766d0c467d713a451fe8bfc1d669
Previously this was grabbing the top two tasks from the
task list, but this isn't guaranteed to be what's on the
screen. Instead, when already in split, use the taskInfo
from the split controller.
Test: manual - 1) have stuff in split
2) keep dragging different apps into split
=> verify the app icon shown in the non
highlighted side matches the app on that
side
Bug: 209504662
Change-Id: Ib959f44bc9eaebfb5e3f640d69cb6f3ddccedfcf
First CL in the chain that will add a camera compat UI control which will be used to correct stretched issues in TextureView and SurfaceView cause by apps not handling mismatch between camera buffers and view size correctly.
This change is necessary because right now there are 2 instances of WindowlessWindowManager (SizeCompatUIWindowManager) in SizeCompatUILayout: for a hint and for a restart button. They are also positioned relatively by computing offsets in java code rather than by specifying layout with XML. This code structure will cause issues since with upcoming camera changes there will be a need to coordinate relative position of 4 UI elements (2 buttons and 2 hints).
What is changing in this CL:
- Majority of changes are simple renaming from "size compat UI" to "compat UI" since, starting from the next change, two different compat controls will be supported.
- Merging 2 instances of SizeCompatUIWindowManager into one (CompatUIWindowManager) and for that create a joint layout in compat_ui_layout.xml
- Merge SizeCompatLayout logic into CompatUIWindowManager since in absence of 2 instances of WindowlessWindowManager there is no good reason to keep them separate.
- Merging and renaming tests to follow refactoring of the implementation.
Test: atest WMShellUnitTests (the same set of tests should be sufficient since this refactoring just reorganized the structure of the implementation)
Bug: 206602997
Change-Id: I7141c69b7ba4742c5b7b2018329b91a1b37b45bc
Ensure the shell root accessibility window is set to null when PiP menu
state is NONE (invisible).
Bug: 208880253
Test: manual, ensure SwitchAccess and TalkBack can access PiP menu
Change-Id: I404ea74069ca9052f165198a8d7f9abdd55dbdb2
Before this CL, Activity was only blocked from finishing if it is the
last Activity in th Task to start lock task mode.
However, it may make half of screen black if the finishing Activity is
in one of adjacent TaskFragments.
This CL considers the scenario that two adjacent TaskFragments side-by-side.
If a finishing Activity leads to TaskFragment empty, and also make the
adjacent TaskFragment finish, block the Activity from finishing.
Bug: 205813709
Test: manual - use Settings in task pinning mode
Change-Id: I6116d644aeccc13460d302fe3b40953fa67dca6c
