... and any other display that isn't considered a public presentation
display, as per Display.isPublicPresentation()
Bug: 141745510
Test: atest CtsWindowManagerDeviceTestCases:PresentationTest
Change-Id: I2aaab1903dee54190338f7b6e49888aa51437108
Fixes issues the app developers have raised with
the WindowInsetsAnimation API:
- it really makes more sense to have the Animation
as the outer class, and the Callback nested within
- it was not obvious previously that multiple animations
could be running at the same time. A new argument to
onProgress now makes this abundantly clear by passing
in the list of running animations.
- The dispatch mode really fits better as a final
property on the callback, rather than it being
queried once from a getter.
Also fixes lint warnings.
Fixes: 143556682
Test: make checkapi; atest WindowInsetsControllerTests
Change-Id: I8cd8faac70dd5a15d779d2c983f0a0ea5d6bbd8e
When the work profile is enabled or disabled
from anywhere on the device, the share sheet and
the intent picker will refresh to either show
the list of work targets or show the empty state
screen that the work profile is not enabled.
Showing that empty state screen also has a
button to enable the work profile. Pressing
it enables the work profile and also refreshes
the list.
Fixes: 149497248
Test: manually toggled the work profile from quick
settings, from the empty state screen button and
from launcher for both share sheet and intent picker.
Change-Id: I25e38b0cb5824ebdcf6255ed1959e9d7c6fac445
PackageManagerService#canForwardTo assumes the method is called
from a work profile. However, with the new changes in the intent
resolver and share sheet, we use this method from the personal
profile as well, in order to determine if an intent is
cross-profile or not. Without this null check, we get a NPE
when we call canForwardTo from the personal profile.
Test: CTS tests are not relevant in this case, as
PackageManagerService#canForwardTo is not a public API
and the only place it's called from is IntentForwarderActivity,
which does not have CTS coverage.
Fixes: 149311698
Change-Id: I172f572920c258723b6a51ac35f2abc0c3aabbf8
am skip reason: Change-Id I7122e45c45a646419b03242c99d90417a29da92a with SHA-1 b5f0e74302 is in history
Change-Id: I8e5bc44f0c45700465c5ed971f08e822249b8c7e
Make Settings UI feature flag's default value consistent with
default value of FUSE flag (as it is now on by default).
Test: Settings->Feature Flags->settings_fuse shows true (expected
default value)
Change-Id: I296063af08455fbcdf0442388fae566a1a0e6372
Move it to ViewRootImpl and rename it: mDispatchedSystemUiVisibility
with default value 0 in the new insets mode instead of -1. Because
mCompatibleVisibilityInfo.globalVisibility will always be updated in the
new insets mode, we don't need the -1 value to detect the change from
non-zero value to zero dispatched from the server.
Bug: 118118435
Test: atest LayoutTests
Change-Id: I45064bdcdca37b9a2b30d82bb9d9c84e45732029
1. Keep a strong reference to the contentCallback.
2. Make sure inflated() only allowed to be called once.
Bug: 146524826
Test: atest CtsInputMethodTestCases:android.view.\
inputmethod.cts.InlineSuggestionTest
Test: manual. Call inflate() twice and make sure the
behavior is expected.
Change-Id: Id9bd386269111d11a2b2c27e33832cac90061b61
There was a bug that waitAndGetRoutesWithManager returnes
a wrong list of routes that doesn't match the given features.
Test: atest mediaroutertest
Change-Id: Ibd01ba9d20fd5fa922d268998e10b497a88a3b45
