This reverts commit 7789ce9d.

Reason for revert: It breaks desktop wallpaper activity presentation as WMCore doesn't add desktop wallpaper activity as no-op

Change-Id: I247cdb8f50a019fb16dddb86fbf11a2b44e790af

* Launching Desktop wallpaper activity alongside other apps would reset their `mCurrentLaunchCanTurnScreenOn` flag.
* Launch options flag added to prevent desktop wallpaper activity stack from moving to front

More info: go/pending-intent-resets-turn-screen-on-flag

Bug: 343450217
Test: atest CtsWindowManagerDeviceActivity:ActivityVisibilityTests
Flag: ACONFIG com.android.window.flags.enable_desktop_windowing_wallpaper_activity DEVELOPMENT
Change-Id: I2044185bb259eab5606bd22f86858ad5e708d01b

Some desktop files are not formatted correctly according to ktfmt
plugin. This cl fixes the formatting problems that exist in these files.
This cl is generated using hte following steps.

1) Install ktfmt pluging for ASFP.
2) Enable ktfmt and set the codestyle as `kotlinlang`.
3) Format the whole file.

Bug: 342572787
Test: none
Change-Id: Ibaac47fa96fba32b00c45b58950193519a7e5d1a

Bug: 339440390
Flag: com.android.window.flags.predictive_back_system_anims NEXTFOOD
Test: Manual, i.e. testing different custom animation specs with various durations
Change-Id: I06f0570518aa20b2ced0c88acd9ad206ccd3db4f

The case happens when a pip is entering in previous rotation and then
display updates. The transition type can be either TRANSIT_CHANGE or
TRANSIT_PIP:
 PipTask CHANGE
   sb=Rect(0, 0 - 1080, 2340)
   eb=Rect(0, 0 - 2340, 1080) r=0->3
 Display CHANGE
   sb=Rect(0, 0 - 1080, 2340)
   eb=Rect(0, 0 - 2340, 1080) r=0->3

The destination pip bounds should be calculated from (2340, 1080).
Because a display snapshot should have covered the screen, the pip
should go to the end state immediately and only animate the display
rotation animation.

This also merges [1] and [2].
[1]: I110d1c11f3d3fdcfb83698e5cf1ec4efb062bd10
[2]: Ia9c78105f4a9782c156744e6cb38681f265955a0

Bug: 340367710
Test: Enable auto rotation and home rotation.
      Swipe up (do not release touch) an auto pip activity in portrait.
      Rotate the device to landscape.
      Continue the swipe up to enter pip.
      The display should show a rotation animation and
      the pip can show on correct landscape position,

Merged-In: Ia1e5e8c7edb8c2a078a66b587d5d26a495166de2
Change-Id: Ia1e5e8c7edb8c2a078a66b587d5d26a495166de2
(cherry picked from commit 6373912c)

Annotate FromSplitScreenEnterPipOnUserLeaveHintTest#entireScreenCovered
as flaky while we investigating the case.

Seem like that, half of the display where the will-pip app was becomes
empty at the beginning of the transition.

Bug: 336510055
Test: atest WMShellFlickerTestsPip1
Change-Id: I36ed7c3b41f21dd8d6a76601e471d4e5551923ae

Change-Id: I88604367f78115bdee4d81405cc7ffbcc6541085
Bug: 278084491

This will prevent the trace from being aborted if the buffer is exhausted, which seems to be happening in CTS tests.

Mitigations to b/340892563.

Bug: 340892563
Bug: 341076876
Change-Id: I9659f1e293ff065df28979401281d33fdc6aa0e6

Auto-generated-cl: translation import
Change-Id: Ied6b23ac2d6909b5f938443e10771df56d4aad0f

* StageCoordinator wasns't handling the case where one of the
splits goes into Pip but doesn't break the split
* We now preemptively guess that an enter transition will
occur when we get the transition that Pip's one of the split tasks
and opens another.
* This is done because Pipping a task out of split results in
2 manual transitions being created in MixedTransitionHelper and
running through StageCoordinator's startAnimation() call again

Bug: 326869501
Test: Repro steps in bug don't break split.
Regular split to pip still works

Change-Id: Ifa115f551e0ee69471c5e81dd11757f429f9c1be
(cherry picked from commit 4f9643bc)
Merged-In: I2717b1e25d5ac84f77a7a7dc56cee51dcfa08683

getActiveBubbles and getBubbles return the same list.
Remove getActiveBubbles that has only usage.

Bug: NA
Test: NA

Change-Id: I61ecaa5491d2ea6b9ffda94d09b68fdbdd6f9c50

Changes the background drawable of the app chip and the maximize and
close buttons in the app header to meet these requirements:
1. The clickable/hoverable bounds of the buttons must be as large as
   possible (40dp height - equal to the header height, 44dp width for
   the maximize/close buttons).
2. The visible background ripple drawable should be 32x32dp, which means
   the ripple must be inset since the view bounds are larger than that.
3. The ripple drawable color & opacity is updated to spec, for both
   hover and pressed states.
4. The maximize button ripple & progress bar are now the same size
   (32dp) and have updated colors / opacity.

Bug: 342266301
Test: hover/press on app chip, maximize, close buttons, check ripple
bounds are rounded and have a 2dp margin between itself and the header
edges and other buttons. Also check maximize button's progress bar is
exactly at the edge of the ripple.

Change-Id: I8340761541cdc9f0bdbf424579d5db7b256ed261

Flag: com.android.wm.shell.enable_bubble_anything
Bug: 342245211
Test: none
Change-Id: Iaffb2663eb8ceb6888653aeec53e2f1eb677063e

If a freeform task's visibility changes (and it's not a move between
displays), then WMShell signals it so launcher can listen and show the
information to the user.

Test: atest ShellTaskOrganizerTests
Test: atest RecentTasksControllerTest
Flag: com.android.window.flags.enable_desktop_windowing_taskbar_running_apps
Bug: 333872717
Change-Id: I229de5c1f297960e99319ccc0f7523219770cd3e

When the associated launching activity is from split container, we should
avoid to launch the overlay, and fallback to make the system determine
the launch target.

Bug: 339192249
Test: atest OverlayPresentationTest
Change-Id: I8f04b6fa795202594b7177467d92af39e3ee247e

This reverts commit 8ac93740.

Reason for revert: b/341921013

Change-Id: If91db88e0b9310753af5e3c2b4b791a828bafbac

This reverts commit fede529e.

Reason for revert: b/341921013

Change-Id: I461a546869a1d11113ee8b0c5698d7b8f60c52ef

Updates the dragged task radius to 28dp and the indicator's color to be
system based.

Bug: 331809027
Test: Manual
Change-Id: I32012dd843e93441c35d142e9b0e327796a2b890

This reverts commit 54c05cf2.

Reason for revert: DroidMonitor: Potential culprit for Bug b/342255815 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.

Change-Id: I706667420bee44da6e9dcfc31c1c5fb5468d2400

Bug: 336311050
Test: open maximize menu
Change-Id: Ia9a67064ef693e1f999c8ceb1a6cfe04e0ffbba7

If users haven't interacted with bubbles, stash them along the edge
of the screen to free up screen real-estate. There's a small overhang
for the bubble UI & the touch target is padded a bit so they can
still be grabbed.

The bubbles will unstash when a new bubble or update comes in.

Flag: com.android.wm.shell.enable_bubble_stashing
Bug: 341361249
Test: manual - enable flag, add a bubble, watch it stash

Change-Id: I402d4a672312a54dc6003b2e5367f20ee443370d

Flag: com.android.wm.shell.enable_tiny_taskbar
Test: None
Bug: 341784466
Change-Id: I5cc7e1f2eea42c30e0377e32b96b95ab4e3ff288

Bug: 341921089
Flag: ACONFIG com.android.window.flags.predictive_back_system_anims NEXTFOOD
Test: Manual, i.e. verifying on device that the color switch happens when the closing window passes the middle of the statusbar
Change-Id: I7116a3808880ed504f8d41b0ba97f16406992e8c

Bug: 339440390
Flag: ACONFIG com.android.window.flags.predictive_back_system_anims NEXTFOOD
Test: Manual, i.e. verifying closing window is moved towards the left (instead of middle) when performing custom predictive back animation
Change-Id: I755921dfad4f768f972cb963b511e68aad1b3370

When Bubbles cannot show a bubble notification, currently this is when
the IME is visible and bubbles are showing in the bar, show it as a HUN

before: http://recall/-/bJtug1HhvXkkeA4MQvIaiP/gI3Rp68E5HPdPZ9i8Izbxw
after: http://recall/-/bJtug1HhvXkkeA4MQvIaiP/fdvIzvlOTqOTVBDwIQyo3r

Flag: com.android.wm.shell.enable_bubble_bar
Fixes: 340532785
Test: atest NotificationInterruptStateProviderImplTest
Test: atest VisualInterruptionDecisionProviderImplTest
Test: manual with the visual interruption refactor flag on and off
Change-Id: Ib75f30cce94e0e7b846a58dfaccac9c2369a366f

- Propagate the drag flags used when starting the drag to the
  privileged drop target window so it can verify that
  DRAG_FLAG_START_INTENT_SENDER_ON_UNHANDLED_DRAG is specified
  before handling the drag to invoke split from a drag with a
  launch intent.

Fixes: 334934117
Test: atest DragDropControllerTests
Test: atest DragAndDropPolicyTest
Change-Id: I21f7ddf342f9db44676431accdacc2d5b6b871cd

Bug: 335850704
Test: atest WMShellUnitTests:ResizeHandleSizeProviderTests
Test: atest WMShellUnitTests:ResizeHandleSizeProviderParameterizedTests
Flag: com.android.window.flags.enable_windowing_edge_drag_resize
Change-Id: I4dc4b7f0db8fca79414c4010d0bc81b090d5bdc5

Bug: 341292615
Flag: com.android.window.flags.predictive_back_system_anims NEXTFOOD
Test: Manual, i.e. testing flings on device and analysing screen recordings
Change-Id: Iafcaa4999daa7323a3b458a2821a18822dc19bb4

InsetsSourceControl can be sent to client process through server push,
or client pull (IWindowSession#relayout).

We need to make sure they are sync'ed. Refactor to use the Array object
instead of raw array, so that we can add additional seqId to it later.

Bug: 339380439
Test: refactor only
Change-Id: Id765867794812a344ddf0f9292edf90b814f598a

- We should always cancel and notify the listener after the recents
  transition is started.  These are mainly edge cases where transition
  handling goes wrong or Launcher erroneously starts a recents
  transition while on the homescreen.

Bug: 329324086
Test: atest WMShellUnitTests
Change-Id: I36c61d9efd3157a84f31e969a9f10a13c3e77eb3

The case happens when a pip is entering in previous rotation and then
display updates. The transition type can be either TRANSIT_CHANGE or
TRANSIT_PIP:
 PipTask CHANGE
   sb=Rect(0, 0 - 1080, 2340)
   eb=Rect(0, 0 - 2340, 1080) r=0->3
 Display CHANGE
   sb=Rect(0, 0 - 1080, 2340)
   eb=Rect(0, 0 - 2340, 1080) r=0->3

The destination pip bounds should be calculated from (2340, 1080).
Because a display snapshot should have covered the screen, the pip
should go to the end state immediately and only animate the display
rotation animation.

Bug: 340367710
Test: Enable auto rotation and home rotation.
      Swipe up (do not release touch) an auto pip activity in portrait.
      Rotate the device to landscape.
      Continue the swipe up to enter pip.
      The display should show a rotation animation and
      the pip can show on correct landscape position,

Change-Id: Ia1e5e8c7edb8c2a078a66b587d5d26a495166de2

Explicitly call HomeTransitionObserver#notifyHomeVisibilityChanged when
exiting PiP to full-screen mode.

Video: http://recall/-/aaaaaabFQoRHlzixHdtY/bDCe5aL9ctHwQWlW9lMvAr
Bug: 340443311
Test: Enter and exit PiP in button navigation mode, tap Recents button
Change-Id: I47c948af54db22305f56e0c95df049e2f87abc3c
(cherry picked from commit 0634ed0d)

* StageCoordinator wasns't handling the case where one of the
splits goes into Pip but doesn't break the split
* We now preemptively guess that an enter transition will
occur when we get the transition that Pip's one of the split tasks
and opens another.
* This is done because Pipping a task out of split results in
2 manual transitions being created in MixedTransitionHelper and
running through StageCoordinator's startAnimation() call again

Bug: 326869501
Test: Repro steps in bug don't break split.
Regular split to pip still works

Change-Id: I2717b1e25d5ac84f77a7a7dc56cee51dcfa08683
(cherry picked from commit 4f9643bc)
Merged-In: I2717b1e25d5ac84f77a7a7dc56cee51dcfa08683

This will allow to build them more effectively.
This has no impact on the test execution itself.

Change-Id: Iac18defcb13e7c3d4ad9845bffcda04766dd06a8
Test: presubmit
Bug: 341947105

BitmapFactory.deocdeFileDescriptor works as-is on host Linux and host
Mac as they support F_DUPFD_CLOEXEC.

Test: ShadowNativeBitmapFactoryTest in Google3
Bug: 341805079
Change-Id: I00914606e6745681655fcad7090e7f49e9fffc05

Adds support for additional background and foreground color changes
based on system theme, app theme, focused state and default vs custom
headers. There are 16 different style variations to apply, so some
additional changes were made to make this possible and more readable.
Changes include:
1) Default header background drawable is now composed of two layers:
  backLayer - may be solid white, back or null. Black/white is needed
  when the frontLayer is semi transparent, to avoid showing app content
  behind it.
  fronLayer - usually a solid color (material token) with full opacity,
  but may have some transparency to differentiate between focused and
  unfocused windows that are all forced to use the inverse_surface color
  token, which happens when the system and app's light/dark theme do not
  match (e.g. dark app on light system theme)
2) New Header data class that holds the TaskInfo/System properties that
   have an effect on which style is applied.
3) New HeaderStyle data class, to represent the resulting
   background/foreground configuration calculated based on the Header
   and that will be applied to the view hierarchy.
4) Replaces the Maximize button's default background ripple with a
   custom RippleDrawable, to allow defining selector states with
   different color/alpha combinations.

Flag: com.android.window.flags.enable_themed_app_headers
Bug: 328668781
Bug: 336555032
Test: try all combinations of app states, verify styles
Change-Id: I5f08e66ecccb5909a6a714937af1370021a934fe

The window decor config should be created based on the type of caption
that will be drawn (handle vs header) because the density in the config
can be different for each type. Instead of passing in a config in the
ctor, always calculate it on relayout(), which is when the caption type
is known for the first time. The config isn't needed before relayout().

Bug: 332414819
Test: atest WMShellUnitTests
Change-Id: I9af8a483e648b9b94cddf7037a86bd27f595ed57

* Previously gesture was disabled when we started both apps
from launcher (overview, workspace, all apps etc)
* This handles the case when we start split from in-app taskbar,
in that case the transitions finishes much faster and launcher was
getting the disable flag turned off before the side animation finished.
* Now for enter transitions that are resizing, we delay turning the
disable flag off until after the animation completes
* Button nav version of this still needs to be handled (separate path
from sysui flags, I think?)

Bug: 290893291
Test: No longer able to swipe up after starting split from in-app
taskbar. Other swipe invocations are still disabled
Flag: EXEMPT bugfix

Change-Id: Ib489f2b63466c6552a4a2c9c13577844c4b71036

In PiP2, resizes are transitions, so we need
to make sure we do not schedule a no-op transition
that can be aborted. Hence we do the following:

For fling gestures: do not schedule a transition if
final motion bounds are invariant from the original bounds.

For pinch-resizing: if the final bounds are unvariant,
in order to have the animation after release
running as a part of a transition, use a trick where we offset
the destination bounds by 1 pixel away from the closes edge.

Also enable dump() callbacks in PiP2, for easier debugging and
state checks. Currently PipController and PipTouchHandler are
the entry points (since they are independent in PiP2).

Bug: 340883807
Test: atest WMShellUnitTests:PipTransitionStateTest
Test: enter PiP2, pinch resize to min bounds, and drag beyond bottom
right corner

Change-Id: I0ec15644d345bd8ca25aa42259ca938360ab54ad

Explicitly call HomeTransitionObserver#notifyHomeVisibilityChanged when
exiting PiP to full-screen mode.

Video: http://recall/-/aaaaaabFQoRHlzixHdtY/bDCe5aL9ctHwQWlW9lMvAr
Bug: 340443311
Test: Enter and exit PiP in button navigation mode, tap Recents button
Change-Id: I47c948af54db22305f56e0c95df049e2f87abc3c