Also remove CdmaEriInformation class, since it's not necessary to expose
the entire class.
Test: atest TelephonyManagerTest
Bug: 170421676
Change-Id: I810a492330e82f47949826a4b127164a5b950702
Merged-In: I810a492330e82f47949826a4b127164a5b950702
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Exempt-From-Owner-Approval: Cherry-pick of no-op refactor into another branch
Merged-In: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
Change-Id: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
(cherry picked from commit 4697f76edd)
Before this change, we were relying on the ProximitySensor class
to circle back and tell the ProximityCheck class about null results.
When the ProximitySensor class changed, this broke ProxCheck. The
ProxCheck class now directly alerts its listeners when it times out.
A test has been added to cover this case now.
Fixes: 162205584
Test: atest SystemUiTests && Manual
Change-Id: Ie48589a54daae3e29defde9ed2300f3c7e2b88ae
`NotificationEntryManager#hasActiveNotifications` used to be in 1:1
correspondence with the visible notifications in the shade, and as such
was suitable for code that needs to do things like calculate the height
of the shade. However if there is a bubble, it's still backed by a
notification but is suppressed from the shade.
This CL is unfortunately hacky because the API for
NotificationEntryManager doesn't have the concept of "a notification
which exists but is not in the shade" and therefore the correct fix
actually would involve creating the correct api and updating all call
sites with the correct semantics.
Test: manual
Bug: 161461739
Change-Id: I9b0fc0f48609b64371d3cb7677228b4bb1fa6aef
Merged-In: I9b0fc0f48609b64371d3cb7677228b4bb1fa6aef
Do not animate the padlock opening when unlocking with fingerprint,
the animation duration is too long, and overlaps with the activity
transition.
Fixes: 161656850
Test: manual, on crosshatch
Test: atest BiometricsUnlockControllerTest
Change-Id: If99d5b20d0f69491d38cfdbc21dfa8d2fe2d0edb
Merged-In: If99d5b20d0f69491d38cfdbc21dfa8d2fe2d0edb
This did not need to be bound in the
ExpandableNotificationRowComponent as it was already injectable
globally. This silences a dagger warning that would have eventually
become an error:
Bug: 160781930
Test: manual && atest SystemUITests
Change-Id: I4286dc4d8f1bd431da35d2243006e263d5c1362f
Merged-In: I4286dc4d8f1bd431da35d2243006e263d5c1362f
(cherry picked from commit c9ae1ad981)
We now expect one more section, given that media controls are always
enabled.
Test: atest NotificationSectionsFeatureManagerTest
Fixes: 161202319
Change-Id: I6d801d15789a1366e448b6a9b2cf372d7c43064c
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
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
