When a notification becomes lifetime-extended, NotificationEntryManager
was holding onto the RankingMap that was passed at the time of removal
of _that_ notification, and using it again in the
NotificationSafeToRemoveCallback. The problem here is that when
onSafeToRemove gets called, it was passing that same stale ranking map
to removeNotification, which caused any notification that arrived in the
intervening time to get improperly ranked.
This fixes an issue where any notification that arrives while another is
lifetime-extended can get the wrong ranking applied to it, causing
trouble later in time such as mis-ranking and mis-sorting until the next
update from system server.
Bug: 146046016
Bug: 119041698
Test: atest SystemUITests
Test: manual - Post a FGS notification and immediately cancel, then post
a regular notification and wait for the FGS notification to dismiss.
Note that the regular notification keeps showing in the status bar.
Change-Id: I3df1279f13c424fcedd878bae2095fadc75d61b4
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
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
Since we're using the pulsing state for docking, the icons would now
become clipped while pulsing.
Fixes: 139096431
Test: dock, observe notification icons showing
Change-Id: If251e6b18c03b2824b4d3ea4dab82d4a403565f1
Merged-In: I8f7bd7a6a0562942ed3e12f28705043722d177e8
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)
When clicking on a notification with an activity that
wouldn't start an opening animation, the panel could
remain open. We're now closing it in that case.
Fixes: 138468703
Test: follow test on bug and observe normal closing
Change-Id: I0b867302d616c017d82f944ee983d4ba4356701a
Previously the notification would be hidden so if the user would pull
out the phone from the pocket, they might not see what notification
actually alerted.
Bug: 138336424
Test: add notification while on AOD, block prox sensor, see icon
Change-Id: I101640c9d0226948e44a4bf36a7ca91dd135fe66
Merged-In: I8f7bd7a6a0562942ed3e12f28705043722d177e8
We only need support ambient mode on specified devices but we currently
enable this attribute on all devices, that means we need redraw every
time when ambient mode changes. However, we can just show / hide
wallpaper window on the devices which not support ambient transition.
In addition, always use portrait dimension as scissor area since we only
do transition in portrait.
Bug: 138021396
Bug: 137962047
Test: Manually test on F2, C1, B4, S4 and walleye.
Test: Set an image wallpaper, switch between home, aod and lockscreen.
Test: Also use finger print to unlock from aod to home directly.
Test: Rotate to landscape, set a new image wallpaper.
Test: Switch between home, aod and lockscreen.
Change-Id: I36dd49363e81df5a260b10695d90aa9d8c70a45a
The BrightLineFalsingManager should not be able to start a session
when it's already in a session. Primarily, this caused the
FalsingManager to hang onto extra registrations to the Proximity
Sensor, per the bug.
Bug: 138220274
Test: atest SystemUITests and manual.
Change-Id: Id10d2697a96524e98c87aaa87702209d1752fe68
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 is a CP of http://ag/8687829
Bug: 138308096
Test: atest SystemUITests
Change-Id: I9e2b22b157c45da1606466acdfff3c5de7f182e1
Merged-In: I9fa4d1344bb184dea00f92f8d265667f0be11466
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
When the FalsingManager gets reloaded (due to plugins) it can
leak its listeners and callbacks. This change fixes that.
This is a CP of http://ag/8668802.
Bug: 136351609
Test: manual
Change-Id: I7ea8384678b60e78ed384e19bbd7932722fe2b9c
Merged-In: I2b52d018d478dbcad4ecb7d8a5b361638d5c5877
The position of the background could be 0 and therefore the
background could fly over the whole screen.
We're now positioning the top section at the start
of the first visible section.
Fixes: 137885070
Test: atest SystemUiTests
Change-Id: I6720b570f5cd209249b90681cdf6c6a56cf0194e
Prox can be noisy and should only be used as a fallback when a more
robust sensor implementation is not available.
Test: manually cover prox sensor
Test: breakpoint
Test: dumpsys
Fixes: 137451005
Change-Id: If0fca42aca36546942930ce76be1353129fc91fc
Since the headsUpManager is calling out in various places to
its listeners, the callbacks may query the headsupmanager
in an internally inconsistent state, such that the pinned mode is
true but there is no topEntry. Let's add a null-check for
safety here.
Bug: 137804505
Test: atest SystemUITests
Change-Id: Ibae76b555ca51ccf676228b034a614d59a8b4e8e
HeadsUpManagerPhone handles adding extra touchable region for the
display cutout. When this changed to use Rects, the extra touch region
was applied to the entire phone width because Rect#union() will cause
the resulting Rect to grow in every dimension. The fix is to use a
Region instead so we can properly union only the space under the notch
Fixes: 135487528
Test: manual
Change-Id: I1d39785087cc3378fc42363df170b81b84420a8e
There is a race condition between window visibility and wallpaper
transition, so wallpaper window might become visible before background
thread has done its rendering work and a flicker happens.
This solution just lets main thread wait for background thread to
synchronize window visibility and wallpaper transition.
Bug: 136643341
Test: atest SystemUITests
Test: Screen off Launcher/APP -> AOD : No extra transition by design,
The duration between press Power Key and AOD show should be same.
Test: Screen on AOD -> Launcher : Face unlock work without flickr
Test: Screen off Keyguard -> AOD : Either Panel or background transition without flickr
Test: Screen on AOD -> Keyguard : Either Panel or background transition without flickr
Test: Reach in AOD -> Keyguard : Either Panel or background transition without flickr
Test: Reach out Keyguard -> AOD : Either Panel or background transition without flickr
Test: Manually operate and observe log.
Change-Id: Iebfdac18972569864c047bc2c4a33d7791940896
