update to reflect the new usage of the extra in forcing platform side
provisioning.
Bug: 236597525
Test: n/a
Change-Id: Ie98e9aaa790d1c0bd4b2d5e2b85a81bd8e3c92e3
In some cases, the device/route name could change without also updating
the ID. This updates the check to include all fields of MediaDeviceData except
for the icon (which can change reference more frequently than is necessary
to reload). Now if the name, status, or intent has changed, listeners
will be updated to have the new info.
Bug: 235627592
Test: manual
Test: atest MediaDataManagerTest
Change-Id: Iefd7ce0e8859b89db2bc75c243b3a04a0cb3915d
Merged-In: Iefd7ce0e8859b89db2bc75c243b3a04a0cb3915d
Bug: 230563819
Test: Manually toggle RBC, and observe that brightness nits change, with
no change in the brightness percentage.
Change-Id: Icb2bff98479cc44aa773ab6e2a828bb281dedbc1
Without this change, it may throw ClassNotFoundException when OEMs
define their own DisplayAreaPolicy.Provider.
Fix: 235942308
Test: verify with a customized provider
Change-Id: I397f4fc05ecd5732e3ebb417de3a66c280f678b3
We'll see if it helps with test isolation against the problem with slow broadcasts.
Bug: 202567877, 235268992
Test: various
Change-Id: I5c42ddc615fe0aed8322f5fa890c60bc8084f670
When transitioning to a transparent or semi-transparent drawable,
TransitionDrawable.setCrossFade must be enabled so that the previous
album art transitions away as expected.
Bug: 235677371
Test: Manual
Change-Id: I4fac5f866354b7f05161b32621a030589b123958
The notifications would disappear with the shade fully expands because the shade calculation uses the expanded state if it's not 0 or 1, so when expansion becomes 1 the 'fraction' falls back to using the doze amount, which is 1, causing notifications to disappear. This was only happening because of a bug where the dozeAmount was left as 1.0 while the device was unlocked during the screen off animation.
The core fix here is to clear the dozeAmount when cancelling screen off.
Fixes: 234979264
Test: enable aod & rear/side fingerprint auth; go to launcher; tap power to turn screen off; unlock with finger during the animation; pull shade to see notifications
Change-Id: If781da0cf941d3560be8bd6b27429e1d94448576
Before this CL, minimum dimensions of Activity wasn't respected,
that said, an Activity could be embedded in a TaskFragment of which
bounds are smaller its minimum dimensions.
This CL add the minimum dimensions on several places:
WM core:
1. Verify minimum dimension requirement before adding an Activity to
a TaskFragment. It'll be early return if the requirement is not
satisfied.
2. Propagate the minimum dimensions to the client side through
TaskFragmentInfo to notify the requirement.
3. If TaskFragmentOrganizer tries to shrink a TaskFragment to
the bounds that smaller than minimum dimensions of its children
Activity, switch to match the parent bounds.
AndroidX Window extensions:
1. Early return if TaskFragment is resized to the bounds that smaller
than minimum dimensions which dispatched from the server side.
2. When organizer tries to show Activities side-by-side, verify if
minimum dimensions requirement of the primary Activiy. If the
requirement is not satisfied, show Activities in fullscreen
instead.
TODO: Add an API to check if an Activity intent is allowed to embed
in a TaskFragment.
Bug: 232871351
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest TaskFragmentOrganizerPolicyTest
Test: atest SplitActivityLifecycleTest
Test: atest CtsWindowManagerJetpackTestCases
Test: atest WmJetpackUnitTests
Merged-In: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Specifically, dump() the state tracked within the provider, and log when
the notif pipeline is invalidated due to a state change from the
provider (as well as what exactly changed).
Bug: 234824085
Test: manual
Change-Id: I608b857c9796ed37ba75ca51d8ab0d95df754fa4
Merged-In: I608b857c9796ed37ba75ca51d8ab0d95df754fa4
Consider a transferStartingWindow use case that a trampoline activity
with unspecified orientation to start another activity with fixed
landcape orientation,
As AR#setInsetsFrozen(true) will be invoked when the trampoline activity
is leaving, and then calling AR#transferStartingWindow if the
trampoline activity is finishing. If we don't clear the frozen insets
state when transferring the starting window to the new target activity,
it may end up seeing a flicker that the starting window being clipped
because computeWindowFrames took the wrong frozen insets state and leads
to the starting window frame size wrong.
Ensure to call clearFrozenInsetsState for the starting window when
transfering to the new activity for fixing this flicker case.
Bug: 235440740
Test: atest ActivityRecordTests#\
testTryTransferStartingWindowFromHiddenAboveToken
Change-Id: I78d59308c6353e841ca8ba2f60428063094c5d25
The host visibility was always invisible while making an Activity
window active because the host visibility was updated afterward
(in ActivityThread#handleStartActivity). Therefore, #relayoutWindow
could be skipped and not recreating Surface if the view visibility is
not changed since last traversal.
Bug: 226324982
Test: repro steps on the bug
Change-Id: Id677a375bc2f75b055a9d35c8b8488e97c24eae9
