This will prevent bouncer interactions from showing up in
screenrecords or screenshots.
Fixes: 215005011
Test: atest StatusBarWindowControllerTest && take screenshot
with bouncer up
Merged-In: I3f59df865dc2dd13d4b9ac54bb2dacb7b23f0aa1
Change-Id: I8df2258863b8cede5ba112331e0446f534267ba2
This adds a force flag, which we will use when turning the screen off to make sure that all UI components are reset to the SHADE state regardless.
Bug: 189575031
Test: make a call; lock screen; pull down shade
Merged-In: I79baeb71ac5d1ed45602ac55cdca996b3bed0ac3
Change-Id: I79baeb71ac5d1ed45602ac55cdca996b3bed0ac3
The previous size was causing some apps to crash which otherwise worked
fine. This more closely matches the hard limit in RecordingCanvas
(which we need to stay below to prevent SystemUI from crashing).
Fixes: 182891864
Fixes: 182232777
Bug: 169255797
Test: atest StatusBarIconViewTest
Test: manual - posting notifications with different drawable sizes
Change-Id: I8deacc651e05a202ec980eeb8bcdf4f92daea8eb
(cherry picked from commit 5cd7976f7d)
Notifications which have interruped the UI (usually a HUN) can safely
bypass FGS lifetime extension because the system has done the best it
can to show the user this notification.
This valve is important in particular for things like a dialer which
might want to interrupt a user but need to do so again on the same
channel, for instance when getting multiple phone calls quickly in
succession.
Bug: 155594347
Bug: 119041698
Test: atest ForegroundServiceNotificationListenerTest
Change-Id: Id80fba3191cc133d1e73ca04015f9cbed62fc086
`StatusBarManager#onNotificationClick` and
`StatusBarManager#onNotificationActionClick` are signals we send to
system server about notification clicks. This CL adds a shim so that we
can have an in-process callback about the exact same events.
This CL also adds NotificationInteractionTracker, which basically just
merges the NotificationClickNotifier callbacks with the notification
collection and will be able to answer the question "has the user
interacted with this notification"
Lastly, this modifies the logic in ForegroundServiceLifetimeExtender
which now checks the interaction flag for notifications. So if a user
tapped on a notification action (for instance) which _then_ triggers a
notification cancel, it will succeed. It _does not_ as of yet release
the notification from lifetime extension upon interaction. So if a
notification is canceled and then interacted with, it will still live
the full amount of time.
Test: atest SystemUITests
Bug: 144324894
Bug: 119041698
Change-Id: I42201d6e7b7ffe9ad4f19c774b638a36a51750ef
(cherry picked from commit 9b2a480ceb)
We can't rely on status bar state changes to update the notification
list. The current user might not be set yet, causing wrong notifications
to become visible.
Fixes: 145135488
Test: manual
Test: atest NotificationStackScrollLayoutTest
Change-Id: I34d1d5f9a751c1d7680a5a5941c39b9fe33a473b
Merged-In: I34d1d5f9a751c1d7680a5a5941c39b9fe33a473b
If a package starts a particular appop both as active and noted, once
one of them is finished (usually noted after 5s), a message will be sent
to callbacks indicating the end of the use. However, the app op may
still be active. This could result in the removal of indicators
prematurely from notifications.
This change prevents that from happening by checking if the app op is
still in use by that combination uid/package (either active or noted)
and not notifying listeners if that's the case.
Test: atest AppOpsControllerTest
Test: use app from bug report. Observe that notification does not lose
the microphone indicator
Bug: 144092031
Merged-In: I180e7c257e6171e7686ba7eda9bf02249358ed0
Change-Id: I94473c3ccf1318dac29f067dade91e540e20285e
It's possible for a service to do a start/stop foreground and cause a
couple of things to happen:
NotificationManagerService will enqueue a EnqueueNotificationRunnable,
post a PostNotificationRunnable (for the startForeground), and then also
enqueue a CancelNotificationRunnable. There is some racy behavior here
in that the cancel runnable can get triggered in between enqueue and
post runnables. If the cancel happens first, then
NotificationListenerServices will never get the message.
This behavior is technically allowed, however for foreground services we
want to ensure that there is a minmum amount of time that notification
listeners are aware of the foreground service so that (for instance) the
FGS notification can be shown.
This CL does two things to mitigate this problem:
1. Introduce checking in the CancelNotificationRunnable such that it
will not cancel until after PostNotificationRunnable has finished
executing.
2. Introduce a NotificationLifetimeExtender method that will allow a
lifetime extender to manage the lifetime of a notification that has been
enqueued but not inflated yet.
Bug: 119041698
Test: atest NotificationManagerServiceTest
Test: atest ForegroundServiceNotificationListenerTest
Change-Id: I0680034ed9315aa2c05282524d48faaed066ebd0
Merged-In: I0680034ed9315aa2c05282524d48faaed066ebd0
It's possible for a service to do a start/stop foreground and cause a
couple of things to happen:
NotificationManagerService will enqueue a EnqueueNotificationRunnable,
post a PostNotificationRunnable (for the startForeground), and then also
enqueue a CancelNotificationRunnable. There is some racy behavior here
in that the cancel runnable can get triggered in between enqueue and
post runnables. If the cancel happens first, then
NotificationListenerServices will never get the message.
This behavior is technically allowed, however for foreground services we
want to ensure that there is a minmum amount of time that notification
listeners are aware of the foreground service so that (for instance) the
FGS notification can be shown.
This CL does two things to mitigate this problem:
1. Introduce checking in the CancelNotificationRunnable such that it
will not cancel until after PostNotificationRunnable has finished
executing.
2. Introduce a NotificationLifetimeExtender method that will allow a
lifetime extender to manage the lifetime of a notification that has been
enqueued but not inflated yet.
Bug: 119041698
Test: atest NotificationManagerServiceTest
Test: atest ForegroundServiceLifetimeExtenderTest
Change-Id: I0680034ed9315aa2c05282524d48faaed066ebd0
Merged-In: I0680034ed9315aa2c05282524d48faaed066ebd0
KeyguardMonitor#canSkipBouncer was not updated properly when the phone
was unlocked using fingerprint.
This CL removes that method and changes UserSwitcherController to query
UnlockMethodCache directly, as it was KeyguardMonitor's only client for
that method.
Test: manual unlocking with FP and with pattern
Test: no automated test yet
Bug: 140486529
Merged-In: Idbff4fbabca962c632ff5d78b25418c0502db9a7
Change-Id: Idbff4fbabca962c632ff5d78b25418c0502db9a7
My descendants will vilify this CL for generations to come. We'll
clean it up for R, but this is our last, best hope for fixing things
in Q.
Bug: 138775282
Test: manual
Change-Id: I615b2f7fddca30dae67dbaab0e5d54a824a4c441
Merged-In: I615b2f7fddca30dae67dbaab0e5d54a824a4c441
(cherry picked from commit 2d35980e72)
Sys UI runs in the primary user. This means that TextView components
such as RemoteInputView and KeyguardPasswordView running in it could
leak data across users.
This CL disables the TextClassifier for RemoteInputView.
It also logs when fixed issue is "potentially" exercised.
There is no need to explicitly disable the TextClassifier for
KeyguardPasswordView. It is a password field
(TYPE_CLASS_TEXT | TYPE_TEXT_VARIATION_PASSWORD) and the
TextClassifier does not run for such fields.
Test: manually attempt to excercise the bug.
See the bug in 123232892 for more information.
Bug: 136483597
Bug: 123232892
Change-Id: Ia1e4843d1505e204f2e78d2459da198c9988f7f2
Previous code assumed that "isHighPriority" == "is in top section",
which is not always true. Media notifs and some other notifs can appear
in the top section even if they're not high priority. Because we detect
section boundaries by iterating through the list until we find the first
notif where isHighPriority == false, we were sometimes drawing the
section boundary way too high. This change creates a new propery,
isInTopSection() that accurately tracks this state.
Setting this value in the proper location would require some seriously
destabilizing refactors, so instead we set it in the list comparator,
which is awful but here are.
Test: manual
Bug: 138320173
Change-Id: I19223720bac534ab92219a2962169097819e8efb
Merged-In: I19223720bac534ab92219a2962169097819e8efb
(cherry picked from commit 8c1b763dcf)
This change stops the animation because there isn't a
transition from the no-header state to the music header
state when turning the screen off (to AOD). Since there
isn't a transition, there isn't an animation.
This assumes that there isn't a transition from unlocked to
lock screen. If there is, then there would be an animation
of the music going away while arriving at the lock screen.
Fixes: 137383007
Test: Checked repro steps in bug, clock doesn't animate.
Test: Also checked repro steps when audio is paused, clock doesn't
animate.
Test: atest KeyguardSliceProviderTest.java
Change-Id: If39777340b72bc623d6690bc4f784c7f5c26ea8d
Merged-In: If39777340b72bc623d6690bc4f784c7f5c26ea8d
NVHM.onDynamicPrivacyChanged() both calls updateNotificationViews() and
could be called by updateNotificationViews(), resulting in very-bad,
no-good re-entrant behavior. It's too late to try to rearchitect the
entire shade to avoid this relationship, so instead we delay a frame
before applying the update.
Bug: 135018709
Test: atest, manual
Change-Id: I0b17d5ba16e272015b10be182a07cae6b29270e6
* changes:
Refactor BrightLineClassifier tests to use significantly less memory.
Turn off BrightLineClassifier tests until memory leaks can be identified.
Stop relying so heavily on mockito when it's not necessary. This also
makes tests run significantly faster. Memory usage is now basically flat.
Bug: 135715570
Test: atest SystemUITests
Change-Id: Ifd71e092b19068817600631b5b98a4a8e80a0126
The ContentProvider might be recreated by the system, so we it's
not necessarily a singleton. We need to cleanup listener registration
and alarms before reattributing the static variable.
Change-Id: I07aec96e77c67d96d31c7e38c85f5ce6f5ef2216
Merged-In: I9bc993f372a8c05258f1778eb3d415af04544714
Fixes: 135344397
Fixes: 135582651
Test: bind and unbind slice various times
Test: atest KeyguardSliceProviderTest
The ContentProvider might be recreated by the system, so we it's
not necessarily a singleton. We need to cleanup listener registration
and alarms before reattributing the static variable.
Change-Id: I227842d7272d1edeaa67d776950f369aedb01a91
Merged-In: I227842d7272d1edeaa67d776950f369aedb01a91
Fixes: 135344397
Fixes: 135582651
Test: bind and unbind slice various times
Test: atest KeyguardSliceProviderTest
In PagedTileLayout:
* Make sure that each page displays at least 1 tile (never 0).
* Make sure that there's at least one page (even if it's empty)
In QSTileHost:
* If the new value of sysui_qs_tiles produces no tiles (but it's not set
to empty), set the tile set to the empty default
@string/quick_settings_tiles
Test: adb shell settings put secure sysui_qs_tiles not-a-valid-tile-spec
Test: atest QSTileHostTest
Fixes: 135023694
Fixes: 135677464
Change-Id: I1e5cf4d2688370001ecae87fc0272acecd48af73
We're seeing crashes due to view hierarchy violations that shouldn't be
possible. Adding some guards to make sure we aren't running into
off-thread hierarchy manipulation or re-entrant calls to the update
code.
Test: manual
Bug: 135018709
Change-Id: I4b1f2bd7e3a6f80384486d59b9f56fc3713537cf
* changes:
Add ZigZagClassifier to the BrightLineFalsingManager.
Add ProximityClassifier to the BrightLineFalsingManager
Add DistanceClassifier to the BrightLineFalsingManager
Add DiagonalClassifier to the BrightLineFalsingManager.
Add TypeClassifier to the BrightLineFalsingManager.
Add PointerCountClassifier to the BrightLineFalsingManager.
Add base class for new falsing manager and classifiers.
This rejects swipes that wiggle around too much. Swipes
should be mostly straight.
Bug: 111394067
Test: atest SystemUITests
Change-Id: I43aa1cc62abb47ce43423c3c7c8e58c14dc0db03
This requires swipes to travel a minimum distance and/or
fling a minimum distance.
Bug: 111394067
Test: atest SystemUITests
Change-Id: Id7586011a30fdcd9dfef7c937f22c33564829307
This requires swipes to travel a minimum distance and/or
fling a minimum distance.
Bug: 111394067
Test: atest SystemUITests
Change-Id: Iec90bb73b4108ce803f9247ebc30046e8c1a6a2d
This matches an existing falsing classifier that ensure
the general direction of a swipe matches the intended action
(i.e. dismissing a notification should be side to side.)
Bug: 111394067
Test: atest SystemUITests
Change-Id: I861ff0443df6051561991808a760250a68b588fd
False on the lock screen if more than one pointer is detected.
Bug: 111394067
Test: atest SystemUITests
Change-Id: Ibffc78d024644adfcfa2713083b03795a11cecb6
This adds no functional changes. It merely adds the framework
for a new FalsingManager.
Change-Id: I7f0e3b1363c847fa1eefa54bf7793508fefd1926
Test: manual.
Bug: 111394067
