...into account when calculating the position information
Actually what we need here is the full transformation matrix, if it
is available. And that means actually computing the location of
views on the screen requires doing this all through transformations,
so the AssistVisualizer has been changed to do this (while still
also keeping the old mechanism for comparison to verify that things
are working correctly).
Also added new properties for elevation and alpha.
And optimized the parcelling of AssistStructure to not write things
that aren't needed; this reduces the parcelled size by about half.
Change-Id: I50b0dd2e6599c74701a5d188617a3eff64b07d03
The new option "--track-allocation" is to work with the new
allocation tracker in ART.
Bug:20037135
Change-Id: Ic5f8945ab4c1f167c27b05ad0d11d04bac680c1f
Otherwise after the Device Owner is gone, runtime
permissions might still be auto granted/denied.
I understand that there are many other policies that
we don't reset after the device/profile owner goes
away (e.g. keyguard enabled/disabled). At least now
we have a single method when we could clear the
ones that we care about.
Bug: 21889278
Change-Id: I6997655e6ef6d474bd25ae1c323eca5b17944b16
Avoids many copies during IPC and duplicate Java heap consumption in
system_server, SystemUI, etc.
Bug: 18386420
Change-Id: Id5ac9406062d472f7848009d65f12131f5f4dac9
Clarify docs that runtime permissions can be granted or revoked by
a profile owner/device owner only for MNC apps and not legacy apps.
Check the targetSdkVersion and return false if legacy app.
Remove all policy flags from permissions when cleaning up
a device or profile owner.
Bug: 21835304
Bug: 21889278
Change-Id: I4271394737990983449048d112a1830f9d0f2d78
Currently when app idle parole state changes, all idle apps' states
are updated one by one including firewall modifications which are
very expensive. This optimization gets rid of individual firewall
rule changes and makes sure we only modify the firewall once at child
chain level.
BUG: 21446713
Change-Id: Iafc415fe0bc127826fe17894d4fedcf1755cb17d
Caused when there are multiple calls to
setActionBar(). getMenuInflater() will
instantiate and keep an instance to the first
Toolbar (and it's container, etc).
BUG: 21638877
Change-Id: Ic9e45bf8f810a033c31b7484244f14e08a72b9f4
Set sync adapters to active if the associated content providers are used
at foreground process state.
Minimize how frequently published content providers are reported by
keeping track of last reported time.
Also cache sync adapters associated with an authority in SyncManager.
Bug: 21785111
Change-Id: Ic2c8cb6a27f005d1a1d0aad21d36b1510160753a
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
