When multi-user is disabled and user button is tapped
on the keyguard, the contact app is displayed behind the keyguard.
The keyguard should be dismissed when the contact app is launched.
Change-Id: I7daa0bec84b5172e78668cc71e51955f166ede0a
The text "customize" is not updated in onConfigurationChanged()
after changing language, so the "customize" text is displayed
incorrectly.
Change-Id: Id6ecdff1f22724955fb1080609da15ccd38d2209
The alarm icon is not shown in the status bar
when switching to a secondary user and setting an alarm.
Bug: 27688859
Change-Id: I9731e6772560853282b6c0348d647024d3424190
StringBuilder doesn't have a char constructor and so passing a char calls the
int constructor that presizes the StringBuilder rather than creating it
containing a single character.
This bug was caught by error prone.
Change-Id: I809ce0fcf930688db925ac7a8e23ee85086d479e
When multi-user is disabled and user button on the notification panel
is tapped, the contact app is displayed behind the notification panel.
The notification panel should be closed
when the contact app is launched.
Change-Id: I66ebcb66c898dfebe1d09b798f750f696c360da8
If NotificationListenerService is not bound the
getActiveNotifications function will return null.
This will result in a Nullpointer exception in BaseStatusbar
onListenerConnected if it is called. A Nullpointer check was
added in onListenerConnected to avoid this Nullpointer exception.
Change-Id: I0aec040f11101e8f7b5863879b3774dc2bb6ce2b
If a Notification changes groups (either from one group to
another, or gets a group key for the first time, which takes
it out of its implicit singleton group) it should be removed
from the old group in NotificationGroupManager's mGroupMap
and re-inserted under the new one.
Unfortunately we were passing the *new* notification in the
oldNotification argument, so we would always attempt (and
fail) to remove it from the *new* group, leaving a strong
reference to the Notification inside mGroupMap under an
obsolete group key.
Bug: 26561365
Change-Id: Ie5cdceb4f843dbd363652e00fbc0f3ac6f6ef247
Never attribute to malice that which is adequately explained
by a bug, particularly one involving date math.
Bug: 26326394
Change-Id: I3483ac102c678a8852565c8ea94c06e19b3f26d8
Never attribute to malice that which is adequately explained
by a bug, particularly one involving date math.
Bug: 26326394
Change-Id: I3483ac102c678a8852565c8ea94c06e19b3f26d8
PowerManager can log into BatteryStats the reason for the device being
woken up. This change has the Fingerprint controller report the reason
instead of a default non-descriptive 'wakeUp' reason.
Bug:26209577
Change-Id: I12d80682dad888add139cca586d4b948e9d546e5
(cherry picked from commit 5bcb8bb31a)
Sometimes, the volume control expand arrow would be displayed
incorrectly. When different apps use different volume controls and
force different orientations, the position of the arrow (expand button)
will not be updated correctly. When this happens the arrow cannot be
pressed and the volume settings cannot be expanded.
The underlying reason is that onLayoutChange only compares the old
dimensions of a view with the new dimensions, which doesn't take into
account that the last time onLayoutChange was run it may have been run
for a different view (a different volume control), in which case the
dimensions of the new view may not have changed, but the arrow needs to
be repositioned anyway as it needs to be positioned in relation to
another view.
Fix this problem by storing the last stream (volume control) that the
arrow was positioned in relation to, and checking if we're positioning
in relation to the same stream the next time the position of the arrow
is updated.
Change-Id: Id23e7605d50857292e09c1909b3e27f01bdf5e22
Also takes into account the voltage
at which we charge to make speeds
at different voltages comparable.
Bug: 25229483
Change-Id: I62a192932a013036585cd9fc870808debceac0d3
