Implements the composable functions for scene placeholders and the scene
container, which itself, is a placeholder. Instead of handling true
swipes and real UI, the placeholders have buttons for triggering a swipe
event and no transition animations between scenes. This entire system is
meant purely for testing the scene switching logic in previous CLs in
the Compose Gallery playground app.
Bug: 279501596
Test: Manually verified all scene transitions using the testbed app.
Change-Id: I4b81988b2ea6ef5388714674718e2f742dd1b3a4
When we declare android:configChanges="orientation" in the manifest, the
pager state is in a weird state after configuration change.
Reset pager state to work around this issue after configuration change.
TODO: Remove this work around after the Compose Foundation 1.5.0-alpha04
updated in the platform.
Bug: 281928661
Test: Manually with Gallery
Test: Manually with Settings
Change-Id: I8fa1a9603f67147cdacb0e0ab1a3f8a67286a995
MODE_DEFAULT if the permission flags for the USE_FULL_SCREEN_INTENT
permission does not have USER_SET.
Bug: 279213931
Test: atest AppOpsUpgradeTest
Merged-In: I08415b0198d1c7ac88676832fb0a003336af6881
Change-Id: I08415b0198d1c7ac88676832fb0a003336af6881
ConfigurationChangeListener can be out of sync with theme so
instead use ComponentCallbacks listener. For this to work, it needs
to be registered with a window context.
Updates tests to use the window context bubble controller creates.
Adds a new test to ensure component callback is added / removed
appropriately.
Updates SysuiTestableContext to create a window context, this
ensures that registered recievers for bubbles get tracked.
Test: atest BubblesTest
Test: manual - have a bubble, expand it, change the theme, check
that the manage button & contents is in correct theme
along with the overflow button & contents and flyout
- repeat above with font size, display size, density,
and RTL and verify bubble UI elements update for those
changes
Bug: 281748524
Change-Id: Ibdcb680e64bbe81af72ec04318f091941da5fe89
If a SecurityException occurs when invoking
DeviceStateManager#requestState (e.g. if not the caller is not
in foreground, or if it does not have the required permissions),
we should first clean up our local state before re-throwing the
SecurityException to the caller. Otherwise, subsequent attempts
to startRearDisplayPresentationSession will always fail.
Bug: 270671994
Test: atest ExtensionRearDisplayPresentationKeyguardTest
Change-Id: Ie102b03b722f018dc093ef9ab8c5c41b141a5bd0
In addition to checking if the app is on top, we should also
check if the app is in foreground. An app may be on top, but
can be hidden by keyguard.
Also note that we are doing both checks, becuase for example
in multi-window mode, multiple apps may be in the foreground.
However, only one of those is considered "top".
Bug: 270671994
Test: android.server.wm.jetpack.area.ExtensionRearDisplayPresentationKeyguardTest#testStartRearDisplayPresentation_whenKeyguardLocked_withoutShowWhenLocked
Change-Id: Iae4d67e55612e9df895a494bb1b891b546c262b9
If the hint session sends too many LOAD_RESET signals without an actual
workload happening, stop sending LOAD_RESET until something actually
happens.
Bug: 232329572
Test: manual
Change-Id: I8fb34a2ee0ff028c83e955a0283396cd69e52361
PCC Detection feature should only be enabled if both conditions are satisfied.
1. flag:pcc_classification_enabled is enabled
2. Device has config: config_defaultFieldClassificationService defined.
In the absence of either of the above, PCC feature should be turned off.
Test: atest CtsAutoFillServiceTestCases
The above 'atest CtsAutoFillServiceTestCases' was ran in two cases
1. config_defaultFieldClassificationService not present on device.
2. config_defaultFieldClassificationService defined on the device.
Also, ran through Autofill usecase manually.
Bug: 279610519
Merged-In: I92f509b150586f7ad35580240a2981c1d31f10a9
Change-Id: I92f509b150586f7ad35580240a2981c1d31f10a9
We fix this slightly mysterious issue by using a good old
android handler instead of the fancy coroutine stuff.
Bug: 280075104
Test: Exercised existing KeyguardPreviewRenderer use cases
Change-Id: I56b818c7b13e238bad025cab76139f5a0c7ffe7b
Keyguard transitions absolutely must not fail because Keyguard, not
being a window itself (more like a mode for SystemUI views), uses the
signal from the transition system to control its visibility.
We're putting a KeyguardTransitionHandler at the top of the list of
handlers so that it has the first opportunity to run anything related
to occlusion or keyguard-going-away flags.
As of now the KeyguardViewMediator is still using the IRemoteTransition
interface to keep the change small and safe-ish. This can be improved.
For example, there's no real need for both sides to have a special
concept of "occludeByDream".
Test: atest ShellTransitionTests
Bug: 274954192
Change-Id: I54e4ab66840c47e686071cab3c22f4c351dc875e
