This reflects the changes in da89dde9787dfbd8c053119ab52d9e671106b18e
in system/keymaster.
Bug: 19919114
Change-Id: I9cdfc7ce63099c4de29029b1fc112369c4a68eba
When wifi traffic causes a stats collection, we shouldn't care about
cpu or bluetooth updates.
Bug:21478443
Change-Id: I177dc0fc09951813cb4a702ad0e5d951d69f8c22
Rework how we record active transitions in battery stats to be
more general, and add an API that others can call in to
DeviceIdleController to request that we go out of idle mode.
use this for VOICE_SEARCH_HANDS_FREE.
Change-Id: Ie58de60e63036a4142881283835961fbcceec892
Also removes the class name since it's not helpful to expose framework
internal class names to accessibility services that can't access them.
Bug: 18864087
Change-Id: If9b29d3929970bd893168444584a5dd1ba593c5b
Notifications in which the icon resource ID is changed after
Builder.build() is called (even, and particularly, as the
last step in the current implementation of
setLatestEventInfo()) were not having their icons properly
parceled. In these cases we now attempt to catch this at
parcel time and construct the necessary Icon object.
But wait! Parceling does not require a Context. So we don't
actually know which package to load the resource from.
Therefore we now allow an Icon to be constructed with an
empty ("") package name, which allows us to complete this
parceling task despite the fact that a Notification does not
know its own package name. (In case you attempt to load a
drawable for such an Icon, loadDrawable will spot the ""
package and instead substitute the Context from its
parameters to try to load the resource.)
As it happens, even though the Notification does not know
its own package name, BaseStatusBar does, because it was
provided at NM.notify() time and is therefore included in
the StatusBarNotification structure. So we can actually
patch up the Icon (if it is TYPE_RESOURCE) and be sure to
get the icon loaded out of the correct package.
While we've got the hood open, this change fixes a couple of
related problems:
• Foreground service notifications synthetically
constructed for naughty icon==0 notifications (which we
are still allowing...FOR NOW) were losing the
FLAG_FOREGROUND_SERVICE flag (because we're
re-build()-ing them from scratch rather than rewriting
the provided Notification object). Now we set the flag
and hang onto the new notification for next time
setForeground() is called.
• We now allow media notifications to avoid getting bumped
to the top of the notification list if they're
PRIORITY_MIN. You might want to do that, I guess?
Bug: 21333763
Change-Id: Ia5d1f1acb594c7677bcc75ee3d624da4ffca671f
We used to give 50% of the cpu time of each app to any app holding a wakelock
while the screen is off.
Since we switched to the new kernel module for measuring app's cpu time, this distribution
was lost.
Bug:21876567
Change-Id: I42c294547f63d150d9929271ca0e27fedaaa9d77
The new assist panel (long press on home) was not centered in landscape
mode on phones. This was caused by ignoring the stable insets in the
PhoneWindowManager.
bug: 21708971
Change-Id: I97a968a41c2966b09eba496fbe57c840affdf9ec
These methods are generally useful for writing custom views, and by
exposing them we make it easier for custom view authors to still allow
app developers to use an OnHierarchyChangedListener since it will not
be occupied by a custom view's implementation.
Also move the actual dispatch to package-scoped dispatch methods so
that a developer forgetting to call super won't stop a listener from
functioning.
Bug 21866523
Change-Id: Ie2bb5e241d7c5a02a5033f33ecdaeb40aceb20b5
We were not taking into account configuration changes to update the
available space for the toolbar.
Bug: 21816857
Change-Id: I0f346e8eecb66ab788d1500239d5c1e020b87f97
