When exiting PiP to fullscreen, SysUI compares the initial rotation
with the screen rotation and skips the animation if they are different,
with the intention that the app should get back to its state prior to PiP.
This generally works well except that app may request
setRequestedOrientation after entering PiP and the initial rotation
SysUI gets in onTaskAppeared would be obsoleted.
This is fixed in this CL by
- Adding a requestedOrientation field in TaskInfo to pass this
information to SysUI, in both onTaskAppeared and onTaskInfoChanged
callbacks
- Sync with the requested orientation as well as display rotation on PiP
exit. Moves also the information we need into PipWindowConfigurationCompact
Video: http://rcll/aaaaaabFQoRHlzixHdtY/gOPXfx5KO9krmzeor49DgG
Bug: 163218295
Test: See video
Change-Id: Idd0b9412dfdfd6fd293a800cded7c7a6b94cafde
Adaptive connectivity is a feature to manage 5G connectivity
for better battery life.
Bug: 162871294
Test: compile
Change-Id: I719e44a29a54ee886e5d3a7180fd3ad9a7dff599
Merged-In: I719e44a29a54ee886e5d3a7180fd3ad9a7dff599
The previous logic restores the system bar as long as its insets source
is visible. There can be a timing issue that if the user swipes to show
transient bars while an immersive app just becomes the control target
but the hide-bar info haven't sent to WM yet, WM will re-show the bar
incorrectly.
This CL uses the requested visibility and the behavior to decide if we
should restore the postion and the visibility.
This CL also refines and caches the arguments of showTransient. In this
way, we don't have to create the array every time while invoking that
method.
Fix: 161247175
Test: atest InsetsPolicyTest
Merged-In: Idef314dfe6625399b88b3dacb4c74c7071453497
Change-Id: Idef314dfe6625399b88b3dacb4c74c7071453497
(cherry picked from commit 533682ebb3)
When there is an insets animation, we will stop updating insets source
frames until the animation is done. The previous logic didn't update the
frames within the requested state while the animation is done. And the
frames was relied by InsetsPolicy while playing transient bar animation.
If the frames don't match the display, the insets would be wrong, and
the animation wouldn't be played correctly.
Fix: 161134197
Test: atest InsetsControllerTest
Merged-In: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Change-Id: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Previous logic in onStateChanged notifies insetsChanged based on the
change of mLastDispatchedState, which can make us dispatch redundant
insets changes to the app.
In this CL, we only notifies insetsChanged if mState is really changed
in onStateChanged -- we use the final mState (after updateState and
applyLocalVisibilityOverride) to compare with the one before changing.
Fix: 161924448
Test: atest InsetsControllerTest WindowInsetsControllerTests
Test: Swipe up to home while IME open and see if there is any jank
Merged-In: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
Change-Id: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
The package verifier performs some system critical work that the user
doesn't need to be explicitly aware of. This adds a mechanism for the
verifier to indicate which foreground service notifications should be
hidden, if possible.
Bug: 164440539
Test: use test app to confirm requested fgs notifications are hidden
Change-Id: Ib3eb0b71cc676c145557ade9def98a363e5abebb
The previous logic restores the system bar as long as its insets source
is visible. There can be a timing issue that if the user swipes to show
transient bars while an immersive app just becomes the control target
but the hide-bar info haven't sent to WM yet, WM will re-show the bar
incorrectly.
This CL uses the requested visibility and the behavior to decide if we
should restore the postion and the visibility.
This CL also refines and caches the arguments of showTransient. In this
way, we don't have to create the array every time while invoking that
method.
Fix: 161247175
Test: atest InsetsPolicyTest
Merged-In: Idef314dfe6625399b88b3dacb4c74c7071453497
Change-Id: Idef314dfe6625399b88b3dacb4c74c7071453497
This adds a setting which stores a list of packages that will be
prevented from persisting in QS as resumable media controls, even when
resumption is enabled. If the user adds a new package to this list when
it already has a resume control, that control will be removed.
Bug: 161813143
Test: manual, atest
Change-Id: I8c85bc937aeaf366954f2669eba8f6954640fe4c
Merged-In: I8c85bc937aeaf366954f2669eba8f6954640fe4c
When there is an insets animation, we will stop updating insets source
frames until the animation is done. The previous logic didn't update the
frames within the requested state while the animation is done. And the
frames was relied by InsetsPolicy while playing transient bar animation.
If the frames don't match the display, the insets would be wrong, and
the animation wouldn't be played correctly.
Fix: 161134197
Test: atest InsetsControllerTest
Change-Id: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Currently, getAllCollapsedRatTypes is used to retrieve
all RAT types which will be recorded into NetworkStatsService.
However, there is a missing part that 5G NSA virtual RAT type
is not added into this list. This makes callers such as statsd
do not aware of 5G NSA RAT type and missed to collect data
usage of it.
Test: atest NetworkStatsSubscriptionsMonitorTest#test5g
Test: adb shell cmd stats pull-source 10082
Test: ./out/host/linux-x86/bin/statsd_testdrive 10082
Test: atest UidAtomTests#testMobileBytesTransfer \
UidAtomTests#testMobileBytesTransferByFgBg \
UidAtomTests#testDataUsageBytesTransfer
Bug: 163021464
Change-Id: I0faeda20f0506a48ac1131b234c5fc40d95dfbe0
Merged-In: I0faeda20f0506a48ac1131b234c5fc40d95dfbe0
Previous logic in onStateChanged notifies insetsChanged based on the
change of mLastDispatchedState, which can make us dispatch redundant
insets changes to the app.
In this CL, we only notifies insetsChanged if mState is really changed
in onStateChanged -- we use the final mState (after updateState and
applyLocalVisibilityOverride) to compare with the one before changing.
Fix: 161924448
Test: atest InsetsControllerTest WindowInsetsControllerTests
Test: Swipe up to home while IME open and see if there is any jank
Change-Id: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
This was intended to fix a reparent issue when preserving
surfaces before the app was closed. That is no longer happening
so this change is no longer needed.
The reason this causes the flicker is it waits to reparent until
next frame. However, the frame can be submitted before WM gets a
chance to show the new Surface since that request is sent to WM.
Therefore, the SurfaceView can end up getting reparented to the
new SurfaceControl before the new SurfaceControl is visible,
causing it to be hidden for a few frames.
This reverts commit c1dcac9568.
Reason for revert: b/162377855
Fixes: 162377855
Test: Split screen with SurfaceView doesn't flicker
Change-Id: Ic7a209b7aa66e278b99a526d8427f140b31de0f6
The dedupuing logic was already in place, but there was a race
due to managin the list of devices from different threads.
Test: using wear app ensure dup device reproduses without CL, and not with it
Fixes: 160870456
Change-Id: I1526199e8e4fb4b8f7d7f306e9e676359cdca516
If a device has an active proximity wakelocks while proximity
is in the "near" state, a press of the power button will temporarily
ignore proximity sensor allowing the screen to turn back on.
It will stop being ignored where there is a change to the
proximity sensor state.
Bug: 162443904
Test: atest PowerManagerServiceTests, atest DisplayManagerTests
Change-Id: I2656cca3e643e278cd5e5fedc2d74d9cbca82c2b
