If the user explicitly dismisses the warning notification,
don't update the notification until the next threshold value.
Bug: 17691122
Change-Id: I840f33f787f1dd6f217de543a291bc9f65b1b046
If the animation ends at the 'same' time as handleShowDetail is
running it is possible for the grid content to get cleared by the
animation callback just after it is shown in handleShowDetail.
This checks mDetailRecord to avoid that chance.
Bug: 18009138
Change-Id: Ia2951f44b5a1470321bf6580daf33917bbcb1ffd
This change animates the status bar and the bottom area when exiting
doze mode from touch. We also prevent all animations when exiting
from other means, i.e. usually when the power button is pressed, so
we don't have a distracting animation there. In addition, this also
optimizes the scrim animations a bit in terms of interpolation and
duration to make the experience smoother and cleans up some logic.
Bug: 18146441
Bug: 17717584
Change-Id: I495ce480c25de24b6433adebdfe923b637d98f66
Bluetooth has stayed pretty much the same, just came back.
Wi-Fi now shows the currently available networks like settings does.
Networks that require extra steps are taken to Settings to complete
the process.
Bug: 17722817
Change-Id: Idfcfd92f557b20168693ced26d4001f3708f08a4
Implement two-line exit conditions, display the duration + end
time on separate lines.
Bug: 16824863
Change-Id: I8dabc83042fce604ccb86b463b9bb547c7903c64
Also closes when tapping the current user.
Also fixes a bug, where the background alpha was
not properly initialized. And while we're at it,
fixes a bug where the user switcher was closable
in simple mode by extending quick settings.
Bug: 17691134
Change-Id: I5444fe42a8a2887ab012ef6cbdcc57ba81a8c1c2
Apparently, hideRecents blocks around 300ms so we avoid this as a
low-risk fix. In the longer term, we should investigate why it takes
so long.
Bug: 18133433
Change-Id: I3eae659d4720d3c95280e7f7a144e00f0c760388
When the max stream volume is configurable by
a system property, the default stream volume should
be set accordingly.
Bug: 17507571.
Change-Id: I9d9378292fc7b9c9e32acc55a275cc0ae5b203d4
When printing from two apps at the same time the second print UI is
getting stuck. There were a couple of issues here:
AdapterView was not notifying for item selection if the data changes
after scheduling a dalayed selection notification and the notification
execution. The code assumed that a layout pass will occur and posponed
the notification after the layout pass but it is not guaranteed that
such a layout pass will occur. Now we delay only if a layout pass is
being scheduled.
Also when binding to the PDF rendering service the print spooler was
using the same intent and as a result two print activites were getting
the same renderer instance while they should get separate ones. Now
we use different data in the intent to ensure we get separate renderer
instances.
Change-Id: I6aa7c7b041957804b4273549dd837a6d70064efc
Some mounted storage volumes may not have a user-defined label. In
those cases, use the default description for the volume.
Bug: 17781505
Change-Id: I8558ba2615c2ff2647a5d44afaec83249df466ab
If the printing app with the print UI on top is killed from recents we get
a crash because: 1) the remote print document was not transitioned to a
failed state if the printing app dies (this is an unrecoverable failure);
2) the print preview controller was destroyed asyncronosly during which it
also asynchronously disconnects from the rendering service which however
happens after the system has already cleaned up all connections of the print
UI activity as it is being destoryed.
bug:18109386
Change-Id: If6200b14a8aa90622228bbb659e9c4962226f561
