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)
This avoids race condition that, KeyguardUpdateMonitor refreshes active
sub list however CarrierTextController filtered it based on stale active
data subId.
By move filterMobileSubscriptionInSameGroup into KeyguardUpdateMonitor,
it becomes the single source of truth about which carrier name should be
shown.
Bug: 138456731
Bug: 151600673
Test: manual and unittest
Change-Id: Ida3a90c5408b056cad7a79fbba84fe880ce1e5be
Merged-In: Ida3a90c5408b056cad7a79fbba84fe880ce1e5be
(cherry picked from commit 5c63b51d9e)
ALS latency is unpredictable and sometimes debounced. This means that it
might take at least 3 seconds for the display to wake-up, if it wakes-up
at all. We might also get stuck and never show HUNs if the event doesn't
arrive.
This is a bug that we had in the past, but was not as noticeable because
the padlock was below the scrims, now, users are reporting that the
padlock shows up, but the hun is not.
Test: manual
Fixes: 150852696
Change-Id: Iade5ebd4c33e7c9d668b09144964f1408ef529ad
Merged-In: Iade5ebd4c33e7c9d668b09144964f1408ef529ad
ConfigurationChangedReceiver is removed. Classes that want to be
notified of configuration changes should implement
ConfigurationController.ConfigurationListener instead and register
themselves with the ConfigurationController.
This CPs http://ag/9762349
Change-Id: I00c08a30b6d8dcac7e26230cb4354bc1fda74b10
Merged-In: Id2c3fe5ae2729b181769fb31b8050da264299d72
Bug: 150541820
Test: atest SystemUITests
Suppose vendors will customize rounded.xml with corresponding
multiple radius path and size, ScreenDecorations should not resize it
by rounded_corner_radius in case jagged edges problem
Test: atest SystemUITests
Test: atest ScreenDecorationsTest
Bug: 145707162
Bug: 148912090
Change-Id: Ie33526214072ad324ca00a10074ad212dfbf4258
The alignment status is reported from WLC-HAL level and runs
on another thread. It may cause CalledFromWrongThreadException,
if use that thread to update UI directly.
Bug: 146770234
Test: atest SystemUITests:KeyguardIndicationControllerTest
Change-Id: I89bf1c188d6ba094106e059f1590c9eaf3703bb8
(cherry picked from commit 0e72713fdf)
Merged-In: I89bf1c188d6ba094106e059f1590c9eaf3703bb8
When doze state changed from DOZE to DOZE_PULSING on devices not
supporting doze_brightness_sensor_type sensor, there would be no
sensor events to update the AoD front scrim. And due to the scrim was
set to opaque at DOZE state, most views on the statusbar will be
invisible. This patch change the scrim to transparent again at leaving
DOZE state.
Bug: 148129743
Test: atest DozeScreenBrightnessTest
Change-Id: I1cf9d02c9e35dcb3e94cbbc24fec483c51e372d9
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Change-Id: I2d15aaa7402e4e08f1630aa29892ad6cd68bd2b1
Merged-In: I34d1d5f9a751c1d7680a5a5941c39b9fe33a473b
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
Before this CL, TileQueryHelper would create CustomTile when creating
tiles for current tiles. This caused them to be destroyed after taking
the information and being removed from the maps in TileServices.
In this CL, current CustomTile are fixed to only being created by
addPackageTiles which knows what to do.
Fixes: 148002667
Fixes: 127508346
Test: manual
Test: atest TileQueryHelperTest
Change-Id: I2c4d3ce6c31449f20670982dad334019cc25469c
Merged-In: I2c4d3ce6c31449f20670982dad334019cc25469c
(cherry picked from commit 198b0b6ef1)
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
Do not show Bluetooth icon when A2DP, HFP and Hearing
aid profiles are connected but not active.
Other Bluetooth profile will retain the same behavior.
Bug: 144061558
Test: atest com.android.systemui.statusbar
Change-Id: Id0fab356f041e90a7654c8e18185c6aa15e2d4df
See CL with change id (I0680034ed9315aa2c05282524d48faaed066ebd0) for
the meaningful changes/description. This change was reverted in qt-qpr1-dev
in order to fix a bug but never got unreverted due to the qt-dev CL
having the same change-id as the reverted one.
Bug: 119041698
Test: atest NotificationManagerServiceTest
Test: atest ForegroundServiceNotificationListenerTest
Change-Id: I50f16072b0e56ab69aabf8010ffffd172ca7c05a
(cherry picked from commit aaf695366e)
Test: Took a screenshot and verified that AiAi gets notified for
share/edit/delete/smart action clicked and exceptions thrown.
Ran tests-
'atest ScreenshotNotificationSmartActionsTest'
'atest ScreenshotNotificationSmartActionsGoogleTest'
Bug: 141634285
Change-Id: Ief6400549b30cf1c0c8a374aa443cf6347f84875
Merged-In: Ief6400549b30cf1c0c8a374aa443cf6347f84875
Create a constant in ContentSuggestionsManager, which will
be used to pass a hardware bitmap to ContentSuggestionsService.
In the presence of this key in the request extras, we skip taking a
snapshot in ContentSuggestionsPerUserService.
Bitmap is extracted from reading this value from extras in
ContentSuggestionsService.
Create ScreenshotNotificationSmartActionsProvider, which is overridden
in GoogleSystemUI.
Calling AiAi is guarded by a device config flag created in cl/277143225.
(cherry picked from commit d2010f2628 and c45d86fc15)
Test: Manually tested the code in this CL and corresponding change in SystemUIGoogle.
Took a screenshot and verified that AiAi gets invoked and the screenshot notification
shows smart actions.
Ran new tests added in this CL
'atest ScreenshotNotificationSmartActionsTest'
'atest ContentSuggestionsPerUserServiceTest'
Bug: 141634285
Change-Id: I439a4be9aac53fb02b566ae4d438afe3edf2b37a
Merged-In: I439a4be9aac53fb02b566ae4d438afe3edf2b37a
This class is used for simplifying interaction with the device
configuration and for testing. The new name is more descriptive of its
intended purpose.
Test: Tested locally
BUG:143952102
Change-Id: I5d9edf518b92f48d73e2ed5d142a162d348d24ba
Merged-In: I5d9edf518b92f48d73e2ed5d142a162d348d24ba
"Swipe up to unlock" should only be visible when the screen is
interactive, even though it would last for 5sec otherwise.
Test: manual
Test: atest KeyguardIndicationControllerTest
Fixes: 139400542
Change-Id: If7290459a3ae28f689cf4c9e2311398e5f6bcf13
Merged-In: If7290459a3ae28f689cf4c9e2311398e5f6bcf13
[Cherrypicked from master]
Smart reply updates are not visually interruptive and bubbles should not
show flyout for them, since flyout text remains the same.
1) Modify NoMan.isVisuallyInterruptive to skip evaluation of fields
irrelevant to bubbles
2) Modify NotificationComparator to rank interruptive notifs higher
3) Pipe bool (isInterruptive) from system_process to SysUI
NoMan --- set bool on notif record and ranking
Ranking --- parcel bool for cross-process transport
SysUI notif entry --- get bool from ranking
SysUI bubble data --- on notif entry update, suppress flyout if isInterruptive=false
Considered adding "isInterruptive" bool to StatusBarNotification.
Did not because "visually-interruptive" is additional information that the
system figured out and SBNs should be limited to info from the app.
4) NoMan --- schedule ranking update if interruptive changes for bubble
Fixes: 138755533
Test: manual - send one sms => flyout appears once
Test: manual - send multiple sms in a row => flyout appears for each one
Test: atest FrameworksUiServicesTests
Test: atest NotificationComparatorTest
Test: atest SystemUITests
Change-Id: Id4b855054689ee73a109bb7cd18004531b41f28c
(cherry picked from commit 0dddc61824d091e48962e36939828cae3cde2aa9)
This reverts commit 9449cfc4a6.
This reverts commit 22fa97577f.
This reverts commit bde48202e7.
Bug: 141649119
Bug: 143195895 is also fixed on my taimen with the above.
Bug: 143185828
Test: atest SystemUITests
Change-Id: I225b10fef2f88d3436ef3a683c09717467b071ad
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
Previously those actions could linger around
and lead to a variety of bugs.
Also fixed an issue when gutsManager calls were overlapping
to protect against these issues
Fixes: 130885521
Test: atest SystemUITests
Test: see bug description
Change-Id: Iffe37e6d48bbc9c26ba92f362d7b67bf743c7c28
Previously we would finish way too early if any of the scrims
finished animation. Since some scrims almost never change, we
would have animations being terminated early.
Fixes: 141649119
Test: unlock with bypass, observe no lock icon change
Change-Id: I6aefd6a27ef315995d8e1ae62c27a5f33cc9e160
Battery saver was completely aborting the doze service, disabling
all interrupts. This is not ideal since it impacts the user journey,
especially when using face auth.
From now on the screen will still be off, but DozeService will be
retained, in order to receive sensor events.
Test: w/ battery saver: lift, tap, and observe aod being off
Test: w/ battery saver: receive notification, no HUN.
Test: w/o battery saver: lift, tap, and observe aod being on
Test: w/o battery saver: receive notification, HUN is received.
Fixes: 134157254
Change-Id: I9b713c78857c4e4c22d8d9bfff165b1b51dfd804
Merged-In: I9b713c78857c4e4c22d8d9bfff165b1b51dfd804
This CL implements a (somewhat hacky) way to enable HTML attributes in
the mobile data type content description strings. This way we can use
some basic styling in the Quick Settings cellular data tile which uses
it in a TextView.
We do this by assuming that the content description is valid, escaped
HTML, and send two separate CharSequences to all of the listeners, all
of which can then decide if they need the regular content description or
the prettified version.
Test: atest SystemUITests; system ui demo mode
Bug: 141177147
Change-Id: Idf387111b0cdc34ad3762eac0ec6c2b484b393e3
