Adds the NotifListBuilder, the second half of the new notification
pipeline. The NLB is responsible for building the "notif list", the list
of notifications that are currently visible to the user. This differs
from the current list that is generated by the NEM/NotificationData in a
couple ways:
- It's grouped. Children have already been collected into their parent
groups. This means that the notif list now contains only "top-level
entries" -- i.e. either notification groups or notifications that aren't
part of a group.
- It's completely filtered. Previously, we did some filtering in
NEM/NotificationData and some filtering in ViewHierarchyManager. Now,
all filtering should take place in NotifListBuilder.
In order to build the final list, the NLB executes four distinct stages
of its pipeline:
1. Filtering: Notifications that shouldn't be shown right now are
excluded.
2. Grouping: Notifications that are part of a group are clumped
together into a single object (GroupEntry).
3. Group transform: Groups are optionally transformed by splitting
them apart or promoting single entries to top-level.
4. Section assignment & sorting: top-level entries are divided into
major "sections" (e.g. silent notifications vs. people
notifications vs. ...) and then the contents of each section are
sorted (as well as the contents of each group).
The NLB tries to avoid having any "business" logic in its own
implementation of the pipeline. Instead, parties that want to
participate in building the notif list can register "pluggables" that
can take part in stages 1, 2, and 4. These are:
* NotifFilter (stage 1): A pluggable for filtering out notifs from
the final notif list.
* NotifPromoter (stage 3): A pluggable for "promoting" a child
notification out of its enclosing group and up to top-level.
* SectionsProvider (stage 4): A pluggable for determining the
overall section that an entry belongs to.
* NotifComparator (stage 4): A pluggable for sorting notifications
within sections.
Whenever something about a pluggable changes so that it would like to
give a different answer than the one it gave previously, it should call
invalidate() on itself. This will trigger a new run of the pipeline.
In order to represent a list of top-level entries that might be either
single notifications or groups, this CL introduces a new object
hierarchy:
- ListEntry (superclass)
- NotificationEntry (subclass, pre-existing)
- GroupEntry (subclass, new)
Thus, the output of the NLB is a List<ListEntry>. Consumers will need to
do instanceof checks on each entry to discover if it is a
NotificationEntry or a GroupEntry. We could have just allowed
NotificationEntry to have children and skipped the need for GroupEntry,
but it's usually important to force code to think about whether it needs
to examine just the summary or also the children. Some code just cares
about the summary but some really should look at the children as well,
and it's too easy to forget to think about groups if everything is a
NotificationEntry.
Test: atest
Change-Id: I86ffe97611b0cc9792b6c96f3196061b170f56b7
Ye olde NotificationData class was responsible for a few general things:
- Keep a list of visible `NotificationEntry`s
- Filter / sort the visible entries
- Keep a sorted / filtered list of those entries
- Answer lots of questions about the entries themselves (rank,
isAmbient, list of entries for current user, etc.)
- Keep track of the current RankingMap
- Set priority buckets on entries
- Tell the group manager when things changed
The basic idea here is to remove NotificationData in favor of 3 other
changes:
1. Any place which needed to query NotificationData for info about the
entry (in particular its ranking) can just ask the entry for it now.
Entries all keep a reference to their rank
2. NotificationEntryManager now just maintains its own list of visible
notifications. It was already the point of contact to get a handle to
NotificationData so this makes call sites simpler.
3. Create a simpler NotificationRankingManager (maybe delete this
eventually) to encapsulate the sorting logic and hang on to the latest
RankingMap
Test: atest SystemUITests
Change-Id: I14073e103c6d50da37207ca8fd86828da0aaaff9
Test: cd to Master directory, lunch target <hawk-userdebug>
cd frameworks/base/packages/CarSystemUI/src/com/android/systemui
run `atest :auto-end-to-end-postsubmit`
test would fail if SystemUI is broken or any element is missing on
homepage
bug:144112416
Change-Id: I71c61a5361f69a87d91684bf1905b6dc5866e446
Also clean up some things w.r.t. CarFacetButtonController
Bug: 143610340
Test: manual, atest HvacControllerTest
Change-Id: Idca6f5731704da893fb530deefe2e695281c6f60
Using this as an opportunity to daggerize related classes.
Bug: 144189328
Test: manual, atest CarNavigationBarControllerTest
Change-Id: I58d142bf20b50dca509d84fce6b6258e7d47e98e
Had to reformat a block of code because linter was complaining.
Bug: 143972303
Test: atest SystemUITests
Change-Id: I96c163b09217671fcbd3f20133c3a13b696afc75
There is a circular dependency between KeyguardViewMediator and
StatusBarKeyguardViewManager which is addressed via Lazy<> for the
ViewMediatorCallback.
Test: manual (sdk_gphone_x86 and hawk), atest SystemUITests
Change-Id: I10e37a40ba966a9f458155fff2957f5534cb9f91
- Remove AppOpsManager + ForegroundServiceController from status bar, instead
register for appOps directly in the ForegroundServiceController
- Remove DozeLog from status bar - it's dumped via DumpController
- Remove ZenController from status bar - only NSSL used it and NSSL can
get it via injection
- Remove NotifLog from StatusBar - move the notifLog for inflation from
NotificationRowBinderImpl to NEM's onAsyncInflationFinished method
Test: atest SystemUiTests
Change-Id: I9fba540c0d8af40b1d1939ff8cb06ee1f5dcc534
Apps can request a low profile mode where status bar and
navigation icons dim. In this mode, a notification dot appears
where the notification icons would appear if they would be there
outside of this mode.
This CL moves the logic for this dot to its own controller
Test: manual (ie: NY times app)
Test: atest LightsOutNotifControllerTest
Change-Id: I46dfab2c7f83cc26c25c257ee02d84058b127036
This removes all calls to getComponent(Divider.class) and
replaced them with dependency injection.
Bug: 143777499
Test: atest SystemUITests
Change-Id: Ib3704a282593b694fe08bd7228e87f75d18920ed
Next step would be move ShadeController into a separate injectable
object outside of StatusBar to remove circular dependency in
StatusBarWindowViewController.
Bug: 138786270
Test: manual on sdk_gphone_x86-userdebug, atest SystemUITests
Change-Id: I4064278d33d3ae5652e70e109deaa20db86512b3
This CL reorgnized providers of StatusBar related classes into
StatusBarModule and StatusBarDependenciesModule. The latter only
contains a provider for CommandQueue, but other common StatusBar
related classes can be added to it in the future. In this way,
changes to CommandQueue construction (or related classes) do
not need to be repeated across multiple projects.
Bug: 143844964
Test: atest SystemUITests
Change-Id: If7e5fcf17eb4c3fee35ac48cc3565d650a916d6b
A recent change was made to inject CommandQueue rather than using
Dependency.get. This change missed one of our usages of Dependency.get.
Bug: 143883030
Test: manual, atest CarNavigationBarControllerTest
Change-Id: I6ad888b178071121ac6000f0f622add58db0ca59
Bug: 142492493
Bug: 137398133
Test: Unit tests pass. Manual testing with an app configured to receive images via RemoteInput can access and display image URIs after the notification has been canceled, but before the notification entry has been removed from the shade.
Change-Id: If64ae7eff7293df3317a1f629977aaaccd866b32
This CL migrates most of the remaining classes to use
BroadcastDispatcher. Some classes left are Views or created before the
BroadcastDispatcher can be injected.
Adds docs for instructions on using the BroadcastDispatcher.
Using the broadcast dispatcher, the time system_server spends
dispatching common intents to SystemUI like SCREEN_OFF and SCREEN_ON can
be seen to decrease from ~70-150ms (in a Q build) to ~2-4ms.
Additionally, once a broadcast is received by the dispatcher, time
until it is fully dispatched inside SystemUI is not impacted greatly.
Most broadcasts are fully dispatched after ~20ms with a few of them
taking ~100ms.
Test: atest SystemUITests no regressions
Test: build and boot
Test: tried some random broadcasts and they are properly dispatched
Test: BroadcastDispatch dump
Test: adb shell dumpsys activity broadcasts
Bug: 134566046
Change-Id: I26a592be66b053f25669b5481b58bf7f07bfd0da
GlobalScreenshot.ActionProxyReceiver was calling
getComponent(context, StatusBar.class). With this change, StatusBar is now
injected into the constructor of that class.
Bug: 143224715
Test: atest SystemUITests
Change-Id: I2f635ce98c1c0e2326784c4558b28ce51f347fa9
This removes the last call to getComponent(StatusBar.class).
Prior to this change, we would register a listener for OverlayPlugins
inside the SystemUIApp. Because they are directly related to the
StatusBar, it is safe and appropriate to have the StatusBar register
with the PluginManager itself.
Bug: 143224715
Test: atest SystemUITests
Change-Id: I5ecdf6a4dae05ba674bcbcd940b9f2655d2b1cbb
Makes AuthController, GlobalActionsComponent, InstantAppNotifier,
SizeCompatModeActivityController, and TvStatusBar all injectable.
Prior to this CL, CommandQueue contained within it a SystemUI object
that it used to start itself up and add itself to components. With
this change, the SystemUI object is no longer necessary, as Dagger
will ensure that a CommandQueue is available to those who need it.
Bug: 143702229
Test: atest SystemUITests
Change-Id: I2763a6d918b41fe27a2370fdd820da476654e14f
If volume dialog is not expanded, then we just replace the old default
CarVolumeItem with the new group.
Bug: 141752233
Fixes: 141752233
Test: Manual
Change-Id: Idfa6ad3a1129e069a297f1c1cfd47b40a61773cc
StatusBar is now marked as an Optional component.
This also makes implementations of RecentsImplementation injectable.
Bug: 143224715
Test: atest SystemUITests && manual
Change-Id: I9a8c4af477693d133f06b8dbda2f08d904cfdb57
Updated framework to handle user switchability cases, so use that
instead of CarUserManagerHelper.
Bug: 131776619
Test: Manually play with user picker.
Test: [1] Open User Picker
[2] Verify can switch to a different user user
[3] adb root && adb shell pm set-user-restriction --user 10 no_user_switch 1
[4] Verify can't switch to a different user
[5] adb root && adb shell pm set-user-restriction --user 10 no_user_switch 0
[6] adb root && adb shell pm set-user-restriction --user 0 no_user_switch 1
[7] Verify can user switch
Change-Id: Ie898723bd93a85d0ea01a9d0879af0c84e904c98
