SysUI status bar updates currently happen upon receiving either the
CONNECTIVITY_ACTION broadcast (which is deprecated) and
INET_CONDITION_ACTION broadcast (which is sent upon validation state
change of networks only).
This leads to status bar showing stale connectivity state. The correct
fix for this is to listen to changes in network state by registering
NetworkCallbacks (see more details in http://b/79286300#comment9).
In the P timeframe, not listening to the broadcasts completely is out of
scope. So this CL just listens for changing network capabilities of the
default data network, which should fix all the cases where the
broadcasts are not getting sent.
Later, when we stop relying on the broadcasts, we will also have to
override onAvailable and onLost (and perhaps the other callbacks too).
Test: runtest --path frameworks/base/packages/SystemUI/tests/src/com/android/systemui/statusbar/policy/
Bug: 71904788
Change-Id: I2e58b9cfceb9937a0b54874dee116ead5339b37b
KeyguardUpdateMonitor's Handler runs on the main looper by design,
we need to ensure that whenever we're processing messages, that
they will also be received on the main looper.
Also unregistered a broadcast listener to avoid a possible race
condition
Test: atest packages/SystemUI/tests/src/com/android/keyguard/KeyguardUpdateMonitorTest.java
Bug: 79550837
Change-Id: I14a319da5c6bc46fd32675ae205e14a6228efaa4
Bind no longer logs unnecessarily - log was moved over to the manager
already.
Test: Ran test
Fixes: 79533793
Change-Id: I1d893935fa93ff7dbb91e922ae2444c4ac42b046
Width overflows if we both remeasure due
to failing to squeeze and due to padding
changes.
Bug: 79225896
Test: atest SmartReplyViewTest
Test: manual - recieve notification from Inbox check reply buttons.
Change-Id: I8ef306bbb7e3732b433830f856257fbfedeb89c0
User experience improvement that alleviates the current bouncer bug with
the blocking helper (where users can't swipe after interacting with the
blocking helper).
Bug: 78222122
Test: Added test case, verified on device with lock screen pin + helper
Change-Id: I54806df8b960ea305b120aef6217a6b90f30590b
Marked the test as flaky. Additionally, changed how mocks are created.
This may or may not affect the test's passing rate. Also updated the
double spy horribleness.
Bug: 79444334
Test: Ran atest, no functional changes
Change-Id: Ieb901a1702ab15bdf98f37cb4b37d5068882162d
Gets rid of Floating Notification Syndrome™
The easiest way to see this is launching SUW or pinned-task mode with
debug.layout set to true, and see that there is no box containing the
clock in these modes
Test: visual;
Change-Id: I518bc04d2dca2fb56f13e0cebc475929edaf2c48
Fixes: 77630482
Some notifications are exempt from DND visual suppression,
like foreground services. If a notification is tagged as a
category that's explicitly mentioned in DND settings (like calls),
exempt that notification from DND exemption, or, hide it.
Test: atest SystemUITests
Change-Id: I661e6d99d09adcb381aef04cccdf93c9810d19b2
Fixes: 78908945
Add the Uri as an extra to the Intent broadcast in the relay.
Test: runtest systemui
Bug: 70622039
Change-Id: I4942ecc9780a7814e3ac436e80034f76cb7bc6db
We didn't have any tests that guarantee that the keyguard casting flow
wouldn't be broken by updates on KeyguardStatusView.
Such test was created
Test: atest packages/SystemUI/tests/src/com/android/systemui/statusbar/phone/KeyguardPresentationTest.java
Change-Id: I44f66be770ea2263fbf183bc438d1cedaa6f589a
Fixes: 71696859
Currently when the user taps on a smart reply button from a locked
screen, we ask for a pattern/password and then close the notification
shade. This is inconsistent with the unlocked case and with how inline
replies are handled.
Set mLeaveOpenOnKeyguardHide to true when handling smart reply clicks.
Also simplify and rename the method in KeyguardDismissHandler to make
this new behaviour clearer.
Bug: 77841506
Test: Tap on a smart reply from the lockscreen, then unlock.
Change-Id: If1dab2a4b0d93a512c27e6d8a870289f64c7b63d
