Moves the various broadcast receivers out of GlobalScreenshot and
adds unit tests for them, along with some other changes to make
them more easily testable:
- ScreenshotSmartActions is now a stateless injectable class,
instead of a collection of static methods
- DeleteImageInBackgroundTask removed, in favor of just calling
a background executor directly
- remove the TargetChosenReceiver (used to remove notifications
after a share target is chosen) since we're not using
notifications anymore
Bug: 160325487
Test: atest SystemUITests, plus manually checked that screenshots
continue to function as expected
Change-Id: I1c054dddd76404f385e59f7ab7317beaafde1106
Fingerprint authentication should not expose accept/reject/lockout
when the user is encrypted or locked out. This is possible with
IBiometricsFingerprint@2.1 since lockout is controlled by the framework.
IBiometricsFace@1.0 does not support this since lockout is controlled
in the HAL (or lower).
Bug: 79776455
Test: On fingerprint device, during encrypted or lockdown, any finger
works, lockout never occurs
Test: BiometricPromptDemo, normal path is run (e.g. incorrect fingers
are rejected)
Test: Test no effect on face device
Test: atest KeyguardUpdateMonitorTest
Change-Id: I9ded8efd80d4f8b92ce054262e721853703c6437
Merged-In: I6c9717d1f8ed3e844b3d92727396e2ce2e7fd94f
Fade out the PiP window when PipTaskOrganizer#removePip is called, which
covers the following scenarios:
- Tap on the close button
- Drag the PiP window to close area
- Disable PiP via settings
Note that when dragging to remove, we spring also the window off screen
and therefore, the fade out animation does not really appealing in that
case.
Video is taken with 10x normal duration.
Video: http://rcll/aaaaaabFQoRHlzixHdtY/gZfSf7SaGKepwiqvXA15dx
Bug: 159805747
Test: see video
Change-Id: Icc26c81711bae69bd00a2812661c00fd93055a92
ag/12048551 exposed some issues running these tests with mocks.
1. Once UserDetailItemView was created from the mocked convertView, it
returned null from getResources. Fix by calling getResources through
Context instead.
2. CircleFramedDrawable needs a real bitmap to work. Using a mock ended
up in a native crash somewhere in libhwui.
Bug: 160794744
Test: atest UserDetailViewAdapterTest
Change-Id: I85a84dbd454ebb1627e4ded21e6708c7fedac11c
Fixes: 160256461
Test: manual - Play Spotify. Dismiss app in overview. Open app in
launcher and select a cast device. Start playing again and check media
player in QS. Verify that a cast icon appears in upper right corner.
Change-Id: If830239f8753d35f3c4d9f3a234d00ee4d89a054
Bug: 160245891
Bug: 160036959
Test: manual - cast from Simple Radio a few times and verify there is
not more than 2 media objects in QS.
Change-Id: Ic2efab1774a79afca84188e42db9db4d44d35403
Since the notification shade has been separated from status bar
to another window where the keyguard resides. It won't be visible
until KeyguardViewMediator receives system ready.
By making the visibility of notification shade consistent with the
initial state of keyguard when attaching the window, window manager
won't miss to wait for it. That avoids dismissing boot animation
too early. The windows of notification shade and wallpaper can also
be drawn earlier, that reduces the total waiting time of drawn
windows by about 50~100ms on a mid-end device.
The logic of wait-for-visible-not-drawn-window is restored to be
the same as Q. The isVisible considers the independent visibility
of wallpaper and visibility of the insets client. The isDrawnLw
accepts READY_TO_SHOW so even keyguard decides not to use wallpaper,
the procedure won't wait until timeout.
Bug: 160271169
Bug: 158144185
Bug: 157746100
Bug: 157281833
Test: atest DisplayContentTests# \
testShouldWaitForSystemDecorWindowsOnBoot_OnDefaultDisplay
NotificationShadeWindowControllerTest#attach_visibleWithWallpaper
Test: Boot with enable/disable keyguard/wallpaper, there is no timeout
and black screen or flickering.
Change-Id: I2f979055e89ae5e40af05e469741bb89e2e24ce6
Merged-In: I2f979055e89ae5e40af05e469741bb89e2e24ce6
When a mouse click happens, a HOVER_EXIT prceeds a BUTTON_PRESS
MotionEvent. This ends up causing the menu to fade away. We will check
for whether there's a BUTTON_PRESS event immediately afterward, and only
run hideMenu() after a certain timeout.
Bug: 160245414
Test: Clicking on items on the PIP menu works again
Change-Id: If06e9b51d2fa47735472f48314a9d5b4b146157b
Disabling MediaNotificationProcessor when the new media experience is
enabled. The notification views that are inflated won't be shown anyway
so it is just a waste of time and memory.
Fixes: 157732475
Test: manual - heap_profile systemui while SoundCloud is playing. Verify
that flame graph doesn't show a hotspot for MediaNotificationProcessor.processNotification
Change-Id: I252697255ce2b30c99d244acd4e30cd56eb0416d
Following up on ag/12037671 - MediaDataFilter uses getData when the user
changes, to get a list of all their previous media controls, so we need to put
the device data back too
Test: atest MediaDataCombineLatestTest
Test: manual, switch users and see output chip has device info
Bug: 12037671
Change-Id: I28e2d15919978e84e3205d2ddccb5024e4010247
Adds a new step MediaDataFilter in the pipeline, after MediaDataCombineLatest,
which will only pass on media control loaded / removed events if they are for
the current user
If the user is switched, removes all existing controls for the old user and
then adds back any old controls for the new user
Fixes: 159958740
Test: atest com.android.systemui.media
Test: manual, switch users and observe controls updated correctly
Change-Id: Ia07180432df1ce031c42a6225d52160f83ef677e
When registering new media players for timeouts, we should schedule
their timeouts but not trigger the listeners yet. Otherwise we would
end up on states where listeners would be ask to update players that
were not initialized yet.
One exception is when a playing is migrating from "resumable" to active.
We'll then delay the state to the next Looper loop.
Test: atest MediaTimeoutListenerTest
Test: manually expire players
Bug: 160036959
Change-Id: I9302dee6190e08c0e845b6f28dfcc249b636d90d
This reverts commit d7302549d6.
Reason for revert: Adding separate workaround for this change
Bug: 156669445
Change-Id: I3ccc857bf6ecf5509e5594ff913d3c575fcb5ad7
It appears that NoMan sometimes fails to send onNotificationPosted
events for some notifications (possibly due to the notification limit?).
It's possible to still receive onNotificationRemoved events for those
notifications, so we ignore those events for now (long-term we should
figure out if this is indeed a problem in NoMan).
Bug: 159652654
Test: atest
Change-Id: Ib15320f537e31a675d2766ba458b7bd019764c73
updateVisibility would normally be called during init, but a display or
font size change will have the same visibility before and after, so it
was being skipped. Instead let's just call it explicitly when the view
is attached
Fixes: 159646762
Test: atest KeyguardMediaControllerTest
Test: manual, change font size and observe no gap
Change-Id: Idad51d804c3e08ff673bea61924214a7ff6c0ccd
Ensures that KeyguardUpdateMonitor#setKeyguardGoingAway(boolean) is
never called on a background thread by dispatching a message to be
handled by KeyguardUpdateMonitor on the main thread.
Test: Manually on Pixel 4 XL
Test: atest com.android.systemui.keyguard
Fixes: 159778563
Change-Id: I48512c0dffba6082f62e70d169f1374c36eead8b
