Now runtime permissions are granted only to components that are
part of the system or perform special system operations. For
exmple, the shell UID gets its runtime permissions granted by
default and the default phone app gets the phone permissions
granted by default.
bug:21764803
Change-Id: If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9
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
Add an animation that discloses delivery
of contextual data to the assist component.
Also fixes a bug where contextual data was
delivered to legacy assist activities even
though the user explicitly disabled context.
Bug: 21568059
Change-Id: I27dfaa36e2f677b0d73acfa4730f0f4ea3486919
When flags NEW_TASK and CLEAR_TASK are set, the task gets reused
which causes the lock task to be ignored. Add a special check
for this to be a lock task violation.
Bug: 20893212
Change-Id: Ibf3c71f40e197f0830410eb4e20429e901998378
While in computing surface crop region, magnification specs are
not applied to surface insets from LayoutParams.
So, in case magnification specs are set,
surface crop region should be calculated considering scale factor.
(For instance, using TouchZoom in Accessibility
at AppsPermissionActivity in market app)
Bug: 20863078
Change-Id: I9e7e21e502b29208f2856918d6fcda050f515595
Signed-off-by: Seunghyun Lee <seunghyun85.lee@lge.com>
This was not a clean revert!
This reverts commit 2ed6fee15c85ff991f64ecfa8c1c4738e0fdf9b6.
We essentially only revert the functionality for going through a list of
WebView package names and picking the first compatible one.
Except for that functionality we also fetched the name of the shared
library from a flag in WebView and made some minor refactoring in the
initial commit, these changes have been left alone in this revert.
Bug: 21893371
Change-Id: Idb2539dc33cc5f9e2894ecd665c23573c6cba9f3
This follows a change in dex2oat.
(cherry picked from commit f39477b592e6e17fe41ace2e18602a69b2dd1619)
Bug: 21924613
Change-Id: I46b61298ca00bee2e83080456b180d63efd95b8f
When wifi traffic causes a stats collection, we shouldn't care about
cpu or bluetooth updates.
Bug:21478443
Change-Id: I177dc0fc09951813cb4a702ad0e5d951d69f8c22
We have issues with bad data coming from the WiFi system, so
log when we have unreasonably large WiFi idle time.
Bug:21929173
Change-Id: I54b34c5efad14264306155c588f4c3b71cae35df
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
Some permissions have the side effect of adding GIDs right now,
so we need to flush out packages.list.
Bug: 21874693
Change-Id: Ia4398c9f84cf7f151248f821b3fa2c12bdf91b80
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
Select only DNS servers that:
- are reachable, according to routes in the LinkProperties, AND
- have a "suitable" source address in the LinkProperites, meaning:
- IPv4 DNS server:
- only if LinkProperties has any IPv4 address
- IPv6 link-local DNS server:
- only if the server has a scopeId set
- assume for now that LinkProperties has a suitable
link-local address
- IPv6 non-link-local DNS server:
- only if LinkProperties has a global, preferred IPv6 address
Bug: 19470192
Bug: 20733156
Change-Id: Ibd95f3f7b33a4fb6c36d1cea4adb63c99068f657
This was introduced by Ifd15736b163ab,
performLayoutAndPlaceSurfacesLocked is called even if
computeNewConfigurationLocked() returns non-null object.
This is simply by mistake and now computeNewConfigurationLocked
never returns null. The only case we need to care is that
mDisplayReady is false, but there is nothing to do with that state.
Thus simply removes if segments from computeNewConfiguration.
Bug: 20823978
Change-Id: I527dfeddffb8d928d578f8d60d64f98557aa3dcb
It looks like the synchronization of the Bluetooth name and address
from the Bluetooth Adapter has been removed by the following commit
without an explanation:
Bluetooth LE background operation mode (2/2)
As a result, the BluetoothManagerService.mAddress was always null.
Bug: 20545952
Change-Id: I595f370e06e17b2c67ce511f793efdee7674598c
