Being pulsing has nothing to do with having pulsing notifications.
A pulse might be triggered by a passive interrupt or by a broadcast
for example.
Test: double tap scrims when pulsing
Test: atest tests/src/com/android/systemui/statusbar/phone/StatusBarTest.java
Fixes: 119527622
Change-Id: Iadff7831392ed955f319f0e195fcdca18509553f
- Send the initial value of the focused field, so the service can decide whether
or not to display the autofill UI if it's not empty.
- Log how long it took for the service to handle the request and to hte system
to render the UI.
- Use CloseGuard to make sure the UI is properly destroyed.
Bug: 120303290
Bug: 119638877
Test: manual verification
Change-Id: I7abed10c0915ff9a2deddb488c70e1491cdbd480
A few additional changes (apart from style and usual dependencies) were needed:
- Dependency on KeyStore was removed (see b/75771701).
- References to internal names were removed or renamed.
- ByteStringUtils is used as a replacement for the Guava bytes-to-hex-string conversions.
- Uses java's Optional rather than Guava's Optional.
- Change to Slog for logging.
- TertiaryKeyRotationTracker.MAX_BACKUPS_UNTIL_TERTIARY_KEY_ROTATION is now a constant rather than a flag.
Bug: 111386661
Test: atest RunFrameworksServicesRoboTests
Change-Id: If9bcfb1f73ba78c278947b8499236bb536e625eb
This change modifies NotificationComparator such that when the new
interruption model is enabled, notifications are sorted with the
primary criterion being whether they are importance >= DEFAULT,
outweighing other criteria that are currently considered first
(colorization, ongoingness, messaging, people). This allows us
to ensure that high priority (>= DEFAULT) and low priority
(< DEFAULT) notifications are contiguous so that thedisplay of them
as two distinct groups makes sense.
Test: atest NotificationComparatorTest
Change-Id: Ifa1405546b75b9da4b8411f861675cd47793785c
It only guarded for null setting.
Blank sysui_qs_tiles should behave in the same way as null.
Test: atest
Bug: 118592837
Change-Id: Ie6e954a2f3bd6ff2b1a28f193d77549d9adfea81
- Surface Insets are set to offset the client content and draw a border around the client surface
(such as shadows in dialogs). Inputs sent to the client are offset such that 0,0 is the start
of the client content. When accounting for surface insets, check if the surface is already
cropped by a parent so that the input offset is not set twice.
- Restrict the touchable region to the input frame bounds.
Test: Open event in calendar. Try to close the event. The event is a dialog and draws shadows.
Test: Open app selector in secondary split screen. Ensure input does not go to primary split screen
window.
Bug: 120413463, 120460606
Change-Id: I518c52539cb72f3cf7207c47b9d25964c4737ec5
