Fixes a bug that the panel height was wrongly calculated and lagging
one frame behind. Also fixes the animation when overscrolling and
then flinging the panel to collapse. In addition, the logic to handle
the over expanding is much cleaner and calculated in an absolut
manner (before, it was relative an really complicated to understand).
Bug: 14487435
Change-Id: If8dbb3e063ef63f51f6dac0ae5bf276480514103
Reposition animations were generated even if the shade is closed
or animations are disabled.
Bug: 15181880
Change-Id: I278278862f4b4837fe164ce2b769d9d50fa50ced
Also fixes that the go-to-shade gesture sometimes triggers the unlock
hint animation.
Bug: 14487435
Bug: 15421928
Change-Id: Ie7e01c81a397b9b1a03baed82c1270ba4e7eb799
Only the first selected element will be expanded, no subsequent children.
Afterwards, overscrolling is performed.
This improves overscroll consistency a lot and people don't accidentally
expand unwanted notifications, just the one they wanted to.
If the users primary intent is overscrolling (i.e if he drags on a card
which is already expanded), then we allow him to go to the quick settings.
Bug: 14487435
Bug: 15181651
Change-Id: I978cc4e06ae85c2ca69e15a149cb85ac54b2ef35
When DND is on, expanded panel shows the current time
condition, or time remaining. The last time bucket
selected is remembered as the default option for the
next time.
Move the server-side countdown helper into a proper
condition provider, but register it in-process as a
system provider.
Move common countdown condition parsing into ZenModeConfig
to reuse from system components.
Keep the manual exit condition around in zen mode config
and add plumbing for getting / listening to the
controller.
Keep the last QS detail panel around instead of
recreating it every time.
Fix the time condition's plus and minus button
enabling logic, and enhance the click handler to
deal properly with the next or previous bucket.
Bug:15344758
Change-Id: Ie7018a1c20e20f6d7e5f9e7874188374e6f8e2ab
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
