MediaController requires a non-null token as input, which updateState
did not check before calling. The token is required to be non-null
already for active media, but it can be null for resume players, so it's
possible for users to hit a race condition between the notification
removal (token set to null) and a final PlaybackState update (attempting
to use the token).
Also added an annotation to the MediaControllerFactory method so that Kotlin
code is aware of this requirement.
Fixes: 231733532
Test: atest MediaDataManagerTest
Change-Id: Id5e4a52cba74fafa04331a663cd4ce870fe920a2
When notifications are shown in a group, group alert setting can be set
to GROUP_ALERT_SUMMARY to notify the user only once per group.
Regardless of this alert setting, user is still allowed to bubble
individiual notifications in a group (button is shown).
Issue was that our check if a notification can be bubbled was applying
the check for alerting on a child notification in a group. Which is not
needed as bubbling should be allowed regardless.
Removing the check for bubbles.
Bug: 214130620
Test: atest NotificationInterruptStateProviderImplTest
Test: manually verified that when there are multiple notifications from
Telegram, they can be opened as bubbles
Test: manually verified with Messages that notifications in a group can
be opened as bubbles
Change-Id: I01258e0db041b8eb04160242f4fd9a875315ad3d
- Update a couple rotations to match spec (ex. rotation occurs at 151
degrees instead of 141)
- If hue rotation specs have an entry at 0 degrees, they also need an
entry at 360 degrees. There's no way to determine that, for example,
321 is between 315 and 0, 360 must be listed.
- Find hue rotation in a way that ensures ex. an angle isn't tested for
being between 0 and 360 degrees, as that will always return true.
Instead, use first element, (always 0 degrees), check if angle is
between and the next element, and stop once the next element is 360
degrees (always the last element in the array)
- Remove code that became unused after the above change.
Test: atest ColorSchemeTest (unit test); atest SystemPaletteTest (CTS).
Spent ~4 hours trying a variety of wallpapers, and seed colors, and
used dumpsys to verify results match UX spec. Create spreadsheet for UX
to fill out their spec, then another spreadsheet that contains the
dumpsys results for blue/red/yellow/green seed colors across all theme
variants, and the preset colors for Ice Cream and Fruit Salad variants.
Confirmed the runtime results, as reported by dumpsys, match the spec
in all cases.
Bug: 213314628
Change-Id: Id35faa294bf82c0e81c2690c65c42218a87c236a
This reverts commit 5481291dca.
Reason for revert: DroidMonitor: Potential culprit for Bug 233958841 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I4f28fac9784da045866bb592c163f834c0dc856b
When the screen times out, the device may not immediately lock based
upon a user setting. In this case, keyguard is visible but not fully
locked. If the user uses bio auth, MODE_ONLY_WAKE is used but the
keyguard is not properly dismissed. Issue a call to keyguardDone so
that the correct animation is shown.
Fixes: 231553219
Test: atest BiometricsUnlockControllerTest
Change-Id: Ib3fa05f2a1054b122a80ca5d27b0a99d12dd27f2
The change I6575f733b17d6c8905150c0a7854d752dd0a5cfe suppressed recalculation of the number of notifications whenever dozeAmount != 0. However, this meant that from the time the device was locked to the time it finished the screen on animation, the number of notifications that fit on the device was never updated. In cases where notifications changed while on aod, this meant the number could be completely wrong. But even without that, this meant that when locking the device and then unlocking, the count would be based on the height of the notifications given their non-keyguard expansion state (i.e. first notification expanded) which meant that we almost always showed too few notifications during the aod->ls transition.
I am unable to reproduce b/229882633 (which that CL was fixing) until I also revert I139d25e2bb57257a18f18f6288f3e18b7a1b72d1 which landed a week later.
Bug: 229882633
Fixes: 232079794
Test: atest NotificationPanelViewControllerTest
Test: numerous failed attempts to reproduce b/229882633#comment2
Test: unlock; screen off (to aod); screen on (to ls); observe no jumps
Test: post notify notifications with "no text" ; slow animations; lock; aod -> ls; post notifications via shell during animation; observe no jumps during or at end of animation
Change-Id: Ib3a3c6377a71cc4c1a1b06eb652237a5493a56d0
This reverts commit 3f2eea4703.
Reason for revert: http://b/229046375 - slower shade open when shade is full
Change-Id: I65d627310986cafd01e32ccaba4050c62b4c1253
The cancelAction was never run on non-UDFPS devices when the bouncer
was canceled. The check for bouncerIsOrWillBeShowing() will always be
true, so move the call to cancel AFTER the bouncer hide() invocation.
Fixes: 233741191
Test: atest StatusBarKeyguardViewManagerTest
Change-Id: I0ababa6b69cdc3fea558c063a8d3839172470ee1
When view is attached to window in NPVC, we add a listener to the bar
state controller; however we do not update to the existing bar state if
any. This means that if the listener is added before the bar state
change is made, then we will default to 0 (SHADE) for NVPC. We have
experienced strange LS states because of this.
Bug: 230911766
Test: Added a 5s delay to adding the callback to experience the weird
state. Added a unit test.
Change-Id: Ieb6d6537eb002b03beceef6f701b826df48feeeb
In the old pipeline, notifications were inflated before the media
notification(s) were filtered out and used to populate the quick
settings, lockscreen, or AOD media views.
In the new pipeline, MediaCoordinator filters out media notifications
before PreparationCoordinator inflates them, so they're never inflated.
This is mostly okay, except that the AOD (and maybe lockscreen?) media
views use one of the media notification's icons to label the media
metadata, and that icon was no longer getting inflated.
Therefore, have MediaCoordinator do the necessary subset of the work of
PreparationCoordinator for the media notifications it filters out:
create and update icons for notifications it filters out, report
inflation errors back to StatusBarService, and do the bookkeeping
necessary to do the right thing (create, update, or nothing) each time
we see a notification.
Bug: 228397680
Test: atest MediaCoordinatorTest (added some test cases)
Change-Id: Ic42c276e5a973cdd260a8c4729a5abdf53987199
