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
After PUK unlock, multiple calls to
KeyguardSecurityContainerController#dismiss() were being called from
the KeyguardSimPukViewController, which begins the transition to the
next security screen, if any. At the same time, other parts of the
system, also listening to SIM events, recognize the PUK unlock and
call KeyguardSecurityContainer#showSecurityScreen, which updates which
security method comes next. After boot, this should be one of PIN,
Password, Pattern, assuming they have a security method. If one of the
first dismiss() calls comes AFTER the security method changes, this is
incorrectly recognized by the code as a successful
PIN/pattern/password unlock. This causes the keyguard to be marked as
done, causing screen flickers and incorrect system state.
The solution: every call to dismiss() should include a new parameter
for the security method used. If there is a difference between this
parameter and the current value in KeyguardSecurityContainerCallback,
ignore the request, as the system state has changed.
Bug: 218500036
Test: atest KeyguardSecurityContainerTest
Merged-In: I7c8714a177bc85fbce92f6e8fe911f74ca2ac243
Change-Id: I30226bc7b5eda9480d471b35fe81e106b0491ff8
The dependent change was validated on qt-dev and rvc-dev, but not explicitly on qt-qpr1-dev.
- In qt-dev, we didn't have this check that the footer view was initialized, but hasActiveClearableNotifications did not call into the mDynamicPrivacyController (it didn't exist), so there was no initialization-time NPE.
- In rvc-dev this footer view check existed, so updateFooter never did any work until setFooterView was called, which is strictly after mDynamicPrivacyController is initialized, so there was no crash.
- In qt-qpr1-dev, mDynamicPrivacyController was added and is checked within updateFooter, but updateFooter didn't have the view check to short circuit before doing that on initialization.
Bug: 193149550
Fixes: 206344625
Test: manually run qt-qpr1-dev with and without fix
Depends-On: I49e2b8bcec7b2ce0a9776ff30a64c07f24949da7
Change-Id: If6e99b5fbe3d2a9d9274223c35d23c30f5524229
This line was removed in O, S, & P, but somehow survived in the Q and R branches.
Bug: 193444889
Merged-In: I56589865427b10e2eab68e1ed2e7c290572a9edc
Change-Id: I56589865427b10e2eab68e1ed2e7c290572a9edc
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
Fixes a p0 security bug. We already have the plugin permission
defined in our manifest. Ensure that senders of the DISABLE_PLUGIN
broadcast have that permission.
Bug: 193444889
Test: manual
Change-Id: Iebaba435c17c5644c5357c0683858447f5ffb897
Merged-In: Iebaba435c17c5644c5357c0683858447f5ffb897
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)
Tried to put a clever kotlin-ism there, but then the interaction tracker
was returning `true` for every notification because it only checked if
the key existed
Test: manual
Bug: 144324894
Bug: 119041698
Change-Id: Ie2f489acca973c0aebbd8e7d8fc7fbef2bac793f
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)
Mutable pending intents are a security risk. This change adds the
IMMUTABLE flag to all PendingIntents created in GlobalScreenshot.
Bug: 162738636
Test: manual
Change-Id: I1044b6aaf2b1650ff91d9a72181684d2aaea9a62
Mutable pending intents are a security risk. This change adds the
IMMUTABLE flag to all PendingIntents created in GlobalScreenshot.
Bug: 162738636
Test: manual
Change-Id: I1044b6aaf2b1650ff91d9a72181684d2aaea9a62
SlicePermissionActivity reads provider_pkg from intent, which can be
modified at will. As a result user might see incorrect package name in
the dialog granting slice permission.
Bug: 159145361
Test: manual
Merged-In: I8b66c02786df4096dad74b7e76255d5ddd1d609d
Change-Id: I8b66c02786df4096dad74b7e76255d5ddd1d609d
(cherry picked from commit 0ad32a2d70)
SlicePermissionActivity reads provider_pkg from intent, which can be
modified at will. As a result user might see incorrect package name in
the dialog granting slice permission.
Bug: 159145361
Test: manual
Merged-In: I8b66c02786df4096dad74b7e76255d5ddd1d609d
Change-Id: I8b66c02786df4096dad74b7e76255d5ddd1d609d
(cherry picked from commit 0ad32a2d70)
ImageWallpaper may fail at either uploading texture or computing the
histogram of the bitmap, we catch the unexpected exceptions to avoid
crashing the whole process. In addition, we also take wide gamut into
account while computing the histogram.
Bug: 156087409
Test: Set 1.jpg of #34 in the bug as wallpaper.
Test: The symptom should not happen.
Change-Id: I931912ece0f7cdfcb388efc8e61799f0087c5199
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
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
Root cause: systemui run as user 0 service to handle all of users'
notifications. And, the users can user the copy/cut/paste
functionality.
Solution: To crate @hide API in TextView let SystemUI to mark the
TextView instance should check if the power of
INTERACT_ACROSS_USER_FULL is needed to be restricted.
e.x. Keyguard password textview/Notificaiton entries
Bug: 123232892
Test: manual test
Reference: I6d11e4d6a84570bc2991a8552349e8b216b0d139
Reference: Ibabe13e5b85e5bb91f9f8af6ec07c395c25c4393
Reference: I975baa748c821538e5a733bb98a33ac609bf40a7
Change-Id: I6d11e4d6a84570bc2991a8552349e8b216b0d139
Merged-In: Ie3daecd1e8fc2f7fdf37baeb5979da9f2e0b3937
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
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)
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
