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
IStatusBarService.collapseQuickSettings is gone;
collapseNotifications is now collapsePanels, which does what
collapse() used to do. Similarly,
IStatusBar.animateCollapseQuickSettings is now simply
IStatusBar.animateCollapse().
Bug: 7245229
Change-Id: Id157d2fdf34926d3c85ffa8b81c741a5359aede4
1. Added APIs for opening the quick settings to the StatusBarManagerService
and the local StatausBarManager. The new APIs are protected by the old
EXPAND_STATUS_BAR permission.
Renamed the expand* and collapse* non-public APIs that are expanding
the notifications to expandNotifications* collapseNotifications* to
better convey what they do given that this change adds
expandQuickSettings* and collapseQuickSettings*.
Added a global action to the accessibility layer to expand the quick
settings which is calling into the new status bar manager APIs.
bug:7030487
Change-Id: Ic7b46e1a132f1c0d71355f18e7c5a9a2424171c3
Additionally, start using setSystemUiVisibility() where
possible in the keyguard to allow activities and dialogs to
re-enable some of the navigation keys (notably: home but not
recents).
Finally, stop disabling MENU for activities atop the keyguard.
Bug: 5380495 // no home in driveabout, clock
Bug: 5396134 // able to show home/recent in keyguard
Change-Id: I04eb224554ee8cff79476b85148c4cda75bb0b62
Back is hidden by DISABLE_BACK; Home, Recents, and Menu are
hidden by DISABLE_NAVIGATION.
Bug: 5261576
Bug: 5284740 (confusion about visible inactive icons)
Change-Id: I410c133b737cc11d61bac0318dc24458353ee7b3
View.setSystemUiVisibility() now properly accepts a
bitfield, including:
* SYSTEM_UI_FLAG_LOW_PROFILE: "lights out mode"
(previously known, erroneously, as STATUS_BAR_HIDDEN)
* SYSTEM_UI_FLAG_HIDE_NAVIGATION: for when you need every
single pixel on a device that also has a navigation bar
These flags are painstakingly aggregated across the entire
view hierarchy and carefully delivered to the status bar
service, which in turn gently passes them along to the bar
implementation.
To really get access to the whole screen, you need to use
HIDE_NAVIGATION in conjunction with FLAG_FULLSCREEN and
FLAG_LAYOUT_IN_SCREEN. See development/samples/Overscan for
an example of how to do this.
Change-Id: I5fbfe009d9ceebbbf71db73f14a7008ea7c1d4da
1. Added content description to pretty much all animals
in the zoo including buttons in the navigation bar,
notifications and status icons for battery, signal,
data, etc.
2. Rectored to avoid ovelaying views since they block
touch exploratino. In general overlaying views
cause trouble for touch exploration and accessibility
in general.
3. Avoid sending accessibility events in case the user is
touching outside of the StatauBAr panels to avoid
confusion.
4. Added records to accessibility events in the places where
this would help the presentation. So the event comes from
a given "leaf" view and its predecessor is adding a record
to the event for itself to provide more cotext. It is up
to the accessiiblity service to choose how to present that.
bug:4686943
Change-Id: I1c1bd123d828fb10911bca92130e9a05c1f020b3
Views requesting lights out mode will cause the navbar to
disappear (this is useful for viewing videos/photos/etc
using every pixel of the screen).
But there's a catch: any user activity at all will cause the
lights to come back on and the navbar to return.
Change-Id: I535ed3ba9ae7fab3282c402be256add765395b6f
1. Views may setSystemUiVisibility() to recommend that
the system chrome (status bar or other UI) show or hide
itself. (This functionality was previously available only
via the FLAG_FULLSCREEN window flag for some SystemUI
implementations.)
2. Views may register a OnSystemUiVisibilityChangedListener
on a view, and find out when the system UI actually
appears or disappears, allowing apps to coordinate the
appearance of their own UI if desired.
Bug: 3241144
Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
(This introduces a StatusBarManager disable flag to ask the
status bar to hide just the clock, which might be useful in
other situations, such as clock/dock apps.)
Bug: 3130393
Change-Id: Ia08627508518e2ed3713ffbf856e4ec42952b3a8
When the user taps on an intruder alert (the priority
notification in immersive mode), the .contentIntent in the
Notification object will be sent, just as we handle tapping
on a normal Notification in the windowshade.
Change-Id: Ib6991837b0b2122fe138cddacf347fdbc426b99d
New actions:
- Toggle activity's immersive mode
- Post a priority notification with fullScreenIntent
that launches an alert-like activity
Change-Id: Ie38372209985577b6db856924c19914c000e1cec
The new flag, DISABLE_NOTIFICATION_TICKER, will be used by
the car dock app (in conjunction with DISABLE_EXPAND) to
minimize distractions to the driver.
It may also be used by the secure lockscreen to avoid
leaking personal information when the screen is on but the
device is locked (e.g. when the desk dock app is running).
Change-Id: Ibc8efde7da7501767163ae0a75f7c369b824e2a2
