- Linking the conversation notification to the newly created
channel and triggering a ranking update
- Incorporating the flag for whether notifications/channels with
invalid shortcut ids should be allowed
Test: atest
Bug: 137397357
Change-Id: Ice1d545f2405a6c9b9eefaf1fd5481622ad72d7b
- Remove them from the non-conversation controls
- Make sure to turn on bubbles globally if a person
is bubbled
Test: atest
Bug: 137397357
Change-Id: I5ae102d739acf4d821af8380287cdf21bca7abd9
The new config resource allows for an overlay to specify additional QS
Tiles. These tiles will be available on a fresh flash of the device, as
well as when the user resets the tiles in QSCustomizer.
If the tiles are custom tiles and the apk is not installedi or the
TileService is disabled, the tile will just be discarded.
Test: atest QSTileHostTest
Test: add the grayscale custom spec to the config value and check that
the tile appears on reset.
Bug: 147493661
Change-Id: Ifbb8cc8ac7ef16c4b67ebbc776703e9ac8208c43
Also default the flag to allow more notifications into that
space to on.
Test: atest
Bug: 137397357
Change-Id: I225f462879bdb28411cc631a3e259b4c71ba7394
Previously GroupCoalescer would delay all notifs in a group until some
max time limit had been reached. However, it can take a full group
upwards of 400ms to be delivered, but we don't want to delay ALL group
notifications by 400ms, because updates to individual children would
also have to wait that long.
Instead, switch to a debounce system where each time a grouped
notification is posted, it sets a timer for a relatively short amount of
time (~50ms). If another notification from the same group comes in, the
timer is reset. And there's still a max of 500ms for safety purposes.
This way, something that is truly a large group post can take up to
500ms by constantly resetting its timer, but a one-off group update can
take place almost immediately.
Test: atest SystemUITests:GroupCoalescerTest
Change-Id: I9808258069c00e7d994035edcfb154b93f75d15a
This CL adds the following controllers for dealing with Controls in
SystemUI:
* ControlsController - Handles favorites and communication with other
controllers
* ControlsBindingController - Handles binding to the different services
and comunication with them.
* ControlsProviderLifecycleManager - Handles binding with one service
and forwards API calls to it.
* ControlsListingController - Handles finding and listing apps that
satisfy the service requirement
Additionally, this CL adds first versions of the management screen to
add or remove favorites. These are persisted.
To enable:
* adb shell settings put secure systemui.controls_available 1
* restart
To launch management activity:
* Enable controls
* adb shell am start
com.android.systemui/.controls.management.ControlsProviderSelectorActivity
Missing from this CL:
* Multi user support
* Documentation in the controller classes
* Graceful rebinding
* Throttling of Binder calls
* Better dumps
Test: atest com.android.systemui.controls
Test: manual testing of favorite management activities
Bug: 147732882
Change-Id: Ib4932b7f8fd3f2e3ee0ef1c28ddda1bec66c41e4
Round one - needs polish, and actions may be added or removed
in the future, and demote isn't working yet.
Bug: 137397357
Test: atest
Change-Id: Ia52598bec58fc54b8bde29168cd419a24d1e4dab
To create a notification section:
- Override Coordinator#getSection to return your desired NotifSection
- Ensure your new section is added in the correct order to
NotifCoordinators.mOrderedSections
Test: atest SystemUiTests
Change-Id: Ia3f83f4b662cdfb198981e94fba67f97eab767b8
Keep the base statusbar.notification.collection package *only* for
classes that need to access package-private members of
NotificationEntry/GroupEntry/etc.
At some point, we should move NotifEntry et al into their own package
like "core" but that will involve a massive scary CL.
Test: atest
Change-Id: I10808f8ce6bd4ae4ce8c1ac194bde6b8a6fea758
We have a bunch of setters for stuff that is only initialized once on a
row. So let's just go ahead and move these into an initialize method so
it's more readable and harder to mis-use.
There are a few others that are used in tests that should probably be
moved into this method or just moved out of ExpandableNotificationRow
entirely.
Test: builds
Test: atest SystemUITests
Change-Id: Ifa55ca19fa2fd1f2030caa0676e6aa3e1713f134
Convert NotificationContentInflater into a singleton since it has
almost no state, making it easier to inject and re-use.
Move the only per-row state it has, cached remote views, to a separate
class NotifRemoteViewCacheImpl that manages the lifetime of the cached
remote views based off the notification's lifecycle. This has the added
benefit of being re-usable for content recycling later on.
Bug: 145749521
Test: atest SystemUITests
Test: atest NotificationContentInflaterTest w/o @Suppress locally
Test: smoke test (add, remove, cancel, expand, groups, HUN)
Change-Id: I7c05b19a0e12bced02bfdaa21e0243f35d64029f
Part of prepatory work for changes coming to
ActivatableNotificationView.
Bug: 147245740
Test: atest SystemUITests
Change-Id: Id85767ab3365e0da659941f267b5d925d6da9dd9
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.
Also removed user sensitive checks.
Test: atest AppOpsControllerTest
Test: use app from bug report. Observe that notification does not lose
the microphone indicator
Bug: 144092031
Change-Id: I180e7c257e6171e7686ba7eda9bf02249358ed00
registerReceiver takes an optional Executor parameter. The old
registerReceiver that takes a Handler has been renamed and @Deprecated
Test: SystemUITests
Change-Id: I43b97f720b2b153d1019ed3cf19e1533558e380f
