This is follow-up to ag/20411848 which fixed scrims showing up when going from expanded shade to keyguard with power double press.
The original CL missed the case of going to keyguard from SHADE_LOCKED state, so it's added here.
Fixes: 251025114
Test: NotificationPanelViewControllerTest
Change-Id: I95283f64bc43f2dc45a58cb4ff4b9fff5ffd1799
Currently, if the screenshot UI is dismissed before the screenshot
finishes saving, we'll get a spurious "SCREENSHOT_INTERACTION_TIMEOUT"
log. This is because the screenshot saving triggers
"showUiOnActionsReady", which updates the UI and resets the timeout.
Updating the UI is a no-op in this situation since the window/view
are no longer attached, but the timeout is reset, causing a
timeout log six seconds later.
It doesn't make any sense to try to show UI after dismissal, so we
should just do the same thing we do for the "old" screenshot during
successive screenshots and save silently.
Bug: 262242456
Fix: 262242456
Test: make statsd_testdrive && $ANDROID_HOST_OUT/bin/statsd_testdrive 90
Change-Id: I0de70d839502c7799da8a8b31e69cfbca0955bd4
This CL re-writes almost everything about how chipbar works,
unfortunately. I realized there were some bugs in the implementation of
handling multiple chipbars at once, and with the addition of priorities
it made it easier to just start from scratch.
Fixes: 261895766
Fixes: 258019006
Test: ttt chipbar then active unlock chipbar -> active unlock chipbar
shown, ttt chipbar re-shows after the active unlock chipbar disappears
Test: active unlock chipbar then ttt chipbar -> active unlock chipbar
still displayed, ttt chipbar shows up after active unlock disappears
Test: ttt flow from started -> triggered -> succeeded
Test: ttt flow works for multiple IDs
Test: ttt chipbar, then active unlock chipbar, then ttt chipbar with
updated info -> when active unlock chipbar disappears, ttt chipbar with
updated info *and updated timeout* is displayed
Test: atest TemporaryViewDisplayControllerTest
Change-Id: I7f077f7e05834c34cfd05ab72e307d2798a18ddf
Else, the UDFPS fingerDown state can be stale
and cause downstream bugs (ie: remaining in the screen on state
instead of transitioninf back to AoD since the DozeMachine
thinks that the user is still interacting with UDFPS).
Test: manually fail UDFPS from AoD, observe device goes back
into DOZE_AOD 5+ seconds after the fingerprint failure
Test: atest UdfpsControllerTest
Fixes: 261758656
Change-Id: Ied60ead5aae4f00e57d0e9457581bf3796392aca
Use new VpnTransportInfo with extra boolean to indicate whether
long-lived TCP connections are expensive in the VPN network.
Bug: 259000745
Test: atest FrameworksNetTests
Change-Id: If8b717a65a204b26e6fbffee698c17294ce64931
And from the AOD_PAUSING state.
So if users immediately attempt UDFPS right after
the prox sensor has become unblocked, the
authentication will still go through rather than
being dropped. The UDFPS longpress gesture is also
prox gated (by the sensor), so this is a safe change.
Test: programmatically set DOZE_AOD_PAUSED and see that UDFPS
longpress can still be triggered when prox isn't blocked
Test: atest DozeTriggersTest
Fixes: 244011650
Change-Id: Ic4f7956cb6082bec5c55d5177c8546e12b969378
Bug: 238425913
Test: manual: Verify wifi icon updates to be the same color as all the
other status bar icons (e.g. light vs dark mode)
Test: atest MobileStatusBarWifiViewTest
Change-Id: I132cc62a8f8b69fc750c5f0b34750f5a1151be76
Adding the following:
<proxSensor/>
to the DDC, will stop any fallback from being used, and allow the usage
of no sensor to be used for that display. This is useful for when a
display has no sensor and the fallback should not be used. If this is
not added to the ddc, the fallback will still only occur if the display
is the default display.
Bug: 202604469
Test: dumpsys display | grep mProximitySensor
Test: com.android.server.display
Change-Id: I018b334a443f6b9a36aaeca70c673bac86446402
Merged-In: I8508a191b7c7c5990929e4d020ffd144c7faeef7
generateCrop does some IO operations and could be responsible for some lock contention; it is useful to know how long it takes to run.
Test: treehugger
Bug: 247076432
Change-Id: I710641d3b15eeca7a34cf6a6b508e769b6604532
The new Engine of ImageWallpaper, a CanvasEngine, was enabled in droidFood under a flag. It has been tested for several weeks and is ready to be enabled by default, wihtout any flag.
The ImageWallpaperTest has been slightly refactored to fix all warnings and reintroduce two GL tests that were ignored.
A very small fix was added in ImageWallpaper.java: if the bitmap fails to load (which should not happen) for another user than USER_SYSTEM, it will be reset to default for this user and not for USER_SYSTEM.
Test: atest ImageWallpaperTest
Test: atest WallpaperLocalColorExtractorTest
Fixes: 243768810
Bug: 243402530
Bug: 254512923
Change-Id: I0bfbe9b6aee7a4da349b412399196504511b69f0
Merged-In: I0bfbe9b6aee7a4da349b412399196504511b69f0
Adds haptics effect when the animation is about
to end. The effect is played when the animation is
cancelled because of timeout or when the device
is unfolded quickly.
Bug: 200555479
Test: atest com.android.systemui.unfold.progress.PhysicsBasedUnfoldTransitionProgressProviderTest
Test: manual test
Change-Id: I0d6c8098b1c86e37547793644bf450d69c166c50
Apply new class MediaItem to store item in the list, this change will
not have impact on layout and functionality should remain the same.
This is first refactor stage of making OutputSwitcher support custom
item, which will be used to apply grouping devices by type request.
design: go/output-switcher-custom-items
Bug: 255124239
Test: atest MediaOutputAdapterTest MediaOutputControllerTest MediaOutputBaseDialogTest MediaOutputDialogTest
Change-Id: Ibda4f0af1204d9e9eb48a3137d50ab591a276319
This reverts commit 4db94a0a62.
Reason for revert: Performance regression found: b/261773357. I'll rework this with a completely separated thread.
Change-Id: I1ea65fdeeeb1693ba283f446dee9ba92d148442d
Fixes: 261773357
Update to check package name to determine whether it is launching the
same app adjacently or not instead of checking component name. This is
to cover more cases when the running task was started from a different
component with its app icon.
Bug: 255224696
Test: atest WMShellUnitTests
Test: check with the repro steps in bug.
Change-Id: I135d6cf518cda603484824dfae61290672f443c7
