We were updating the text field color only during some code paths,
which is error prone and doesn't handle visibility events well.
Also, the color of the field on AOD should never be red, according to UX
guidance.
Fixes: 149891226
Test: manual
Test: atest KeyguardIndicationControllerTest
Change-Id: I6e244786e72d90f00b0b733bdcb00c3e8e03582f
The navigation bar dismissal animation caused by "activity finish"
should be invoked in some cases immediately when the user
cancels authentication. Add a "early user cancel" message
for ConfirmDeviceCredentialActivity to subscribe to. This
message is sent immediately when the user invokes a back gesture or
cancels authentication.
Bug: 148273355
Test: Set up work profile with separate password and biometric
Unlock work profile
Lock screen
Open work profile app
Cancel authentication at various states in various ways
Notice no navigation bar jank
Test: atest com.android.systemui.biometrics
Change-Id: I89c5b5e2782339cae15f936268e6e7b8ad4e5359
Stateful controls returned from applications will have their status
flag set to indicate the state of the Control. For all non STATUS_OK
states, assume the control information isn't meant to be persisted and
do not store it.
Bug: 152525430
Test: atest ControlsControllerImplTest
Change-Id: I70c7a8f180561fff281a641b8d547af7cef17520
Before we were only announcing when inflation ends, but we won't
inflate it every time it becomes visible.
Test: manual
Test: atest KeyguardBouncerTest
Fixes: 145172036
Change-Id: Iafbce10738a0906b251721a4ce4483e503ad6d91
User unlock states should be cleared whenever user switches. Otherwise,
it's possible for the following sequence of events
1) Unlock first user via biometrics
2) Do not dismiss keyguard, switch to second user
3) Switch back to first user - can unlock without authenticating
Fixes: 151906507
Test: Repeat steps above, does not occur anymore
Test: atest KeyguardUpdateMonitorTest
Change-Id: I1d8e5867a18a680e85be8c335f09d4cb4209612e
Removed controls should have as much cached information as possible.
This adds structure name and subtitle.
Also, if the structure is not set it would cause issues (as empty
structure is a valid structure).
Fixes: 151089232
Test: atest ControlsControllerImplTest
Test: manual
Change-Id: I6cf5f285fe85ddc78ae59133dcf406793293a3f7
The benefit is that icon colors and icon scaling can be performed on a
background thread and then all of the views updated on the main thread.
Bug: 150454272
Test: atest KeyguardMediaPlayerTest.kt
Test: manual - play music and look at lock screen controls
Change-Id: I2423233f1ddeb081ab420053964c2b1cb2185514
AsyncTask is deprecated so we use main handler instead to
return callback, onWindowMagnifierBoundsChanged.
And this change also add a null protection and unregister
OnLayoutChangeListener when window magnification is disabled.
And it can prevent null pointer exception.
Bug: 151394161
Bug: 151571627
Test: manual test, atest WindowMagnificationTest
WindowMagnificationControllerTest
Change-Id: I421424582d8bad9e58fe5aca11feb75a31bd5b35
Previously it was being lumped in with the keyguard filter, which made
it difficult to tell in logs why something was being filtered.
Bug: 112656837
Test: atest
Change-Id: Ibfbfa017811952cd5a873419d3e003b70b65763e
This animation was being mapped directly to the alpha of the dialog,
which makes it a bit stiff. I'm now using a physics based spring
animation, sharing logic with the shade.
Fixes: 149792636
Test: atest NotificationShadeDepthControllerTest
Change-Id: Iad8835b8040d1aedc13f0e323fc747e4ab4813e9
The addition of a second round of filtering introduced a bug that would
cause the system to log false filter and section changes for all notifs
on every run of the pipeline.
Previously, we had logic like the following:
(assume that, in the previous run, entryA was filtered out by filter1
during the pre-finalized stage)
1. preGroupFilters run, nothing returns true. Set
entryA.mExcludingFilter to null. It changed! Log it.
2. preFinalizeFilters run, filter1 returns true. Set
entryA.mExcludingFilter to it. It changed! Log it.
NotifSections had a similar bug that would null out their assigned
section every time they were filtered out.
To solve this, we introduce an mPreviousExcludingFilter field on
NotificationEntry that will allow us to determine whether the filter
actually changed as compared to the previous run. We also move that
logging logic to the end of the pipeline.
To solve the sectioning issue, we just don't null out sections when the
entry is filtered out. Long-term, we should move to a system similar to
the one above, but that's more complicated.
Test: atest
Bug: 112656837
Change-Id: Ib78dbbb0346947210cc1b6b49547595895e9fce5
This moves the final remaining pieces into
LockscreenIconController.
Test: manual
Fixes: 150393918
Change-Id: I6ce57905bdfcf832b92d5f2e4ce46054ff067851
