| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Bug: 15286335
Change-Id: I3114d7bcd8f05ca3a58f3598b95fdb507f6c646c
|
|
|
|
|
|
| |
Bug: 15324972
Bug: 15436573
Change-Id: I838370a23fb07cb876e08c41ef11653f2658719e
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce RankingMap holding single notification Rankings
indexed by SBN keys.
Also, pass RankingMap with notification event callbacks so
subclasses don't have to call getCurrentRanking() unnecessarily.
Bug: 15415840
Change-Id: Id41e174f00c06c86359c03646abc3db78028b324
|
|/
|
|
|
|
|
|
|
| |
- Updated location icons.
- Updated no-sim, plumb up to QS.
- Updated zen mode synthetic notification icon.
- Updated color inversion icons.
Change-Id: I4849fbe11683feab37160c3d23502b01035de66a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updates to intercepted notifications come in through addNotificatiom
instead of updateNotification, because the intercepted notifications
are not in mNotificationData.
If an update causes a notification to surface, we need to notice and
remove it from the synthetic notification. However, addNotification
is called from within InterceptedNotifications inside loops over
mIntercepted, and we cannot remove items from mIntercepted while
looping, so we split addNotification into two parts, one part is only
used by InterceptedNotifications to unconditionally surface previously
intercepted notifications.
Bug: 15389069
Change-Id: I7b0952a337f15d4009e3e61360344012345eac95
|
|
|
|
|
|
|
|
|
| |
This requires the record to be present in makeRankingUpdateForListener,
however, if the ranking object is created before the post to the handler,
then no cloning is necessary.
Depends-On: I907a1ff28123219db1c08889d723ad1b70b191ab
Change-Id: I51fcf689ddbee7715e3387b865f18a715887c943
|
|\
| |
| |
| | |
lmp-preview-dev
|
| |
| |
| |
| |
| | |
Bug: 15303664
Change-Id: I295293e62ee878be9b4aa7b13e0c014f935072ca
|
|/
|
|
|
|
|
| |
Respect the ranking received via NotificationListenerService.
Bug: 15131411
Change-Id: I9e3a1530ffb5f4c29eeeccdbc910261d2eb72216
|
|
|
|
|
|
| |
This is currently disabled by constant that is off.
Bug: 15131411
Change-Id: I0da6e5b3b81c87004f0794d3056c4cf0ecbb1d61
|
|
|
|
|
|
|
|
|
|
| |
In preparation of migrating to NotificationListenerService,
remove dependence on IBinder keys for notifications and switch
to SBN.getKey() instead.
Bug: 15131411
Change-Id: Ic272e4a05fde6481c734144c5b34c49b2f021649
(cherry picked from commit 7c96ae873d9a54ebaeb5b7ef21b48224dc42d094)
|
|
|
|
|
|
|
| |
Don't suppress notifications if the user has configured them
to display, even in zen mode.
Change-Id: Ief549164cafd0922726feaeaf2029b8840dcf735
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove temporary harness responsible for creating enabled/disabled
versions of vectors at runtime. Instead, pre-compute the necessary
states as separate files.
Normalize all qs icon names, cleanup obsolete pngs, and replace
the DND hangtag.
Bug:14133785
Change-Id: Ifb58635b832d25ca1de7e9f79cf8ec3503ea8cec
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the padding and the glow was inside the individual
notification. This no longer works if we want to adjust the
padding dynamically whether we are on Keyguard or not. This change
moves the padding outside of the individual notifications, and as
a side effect, removes the glow. The glow wasn't really visible with
the new layout, so it's not a breaking change. We have to discuss
with UX first what the new "glow" solution is going to be.
Change-Id: Iac16892cb3b7bb1de3001954b1428796b07950c1
|
|
Bug:13726563
Change-Id: Ib1c3fba3a328792dc674c8403735f75d4db41973
|