The PacManager would clear the pac url by setting it to null, however
everywhere else, pac url is cleared to Uri.EMPTY. This sometimes leads
to an NPE when PAC is set and cleared rapidly and take down the whole
framework.
Bug: 17581527
Change-Id: I84ce215f4f6a8a7e804372fc0a1e20ac609a21f1
Instead of clearing the Statusbarwindow buffer in the beginning
we now draw the scrim with mode SRC and therefore a whole screen
of overdraw is saved!
Bug: 17287256
Change-Id: I29f14a2c3d4cb087c422ae6f486d23d7f8ec173b
Recently we started letting system apps always take precedence over
third-party apps when defining permissions. This change fixes that
logic to claim the permission immediately, instead of delaying until
after the next reboot. (Permissions are always reevaluated after
each install.)
We also tighten the constraints slightly to prevent two system
apps from fighting over a permission definition; the first system
app to claim the permission wins.
Bug: 17526617
Change-Id: I49686407f5e99322bc511795c653c5d702becd9d
In order to create a DisconnectCause with a label/description that does
not require specifying a tone.
Bug: 17486242
Change-Id: If82605ff20fc9f53ed41b49e12575424c6efc2b6
Recently we relaxed revokeUriPermission() to allow apps to revoke
Uri permissions that had been granted to them, but this uncovered
bugs in apps that had been relying on the previous no-op behavior.
To mitigate this, only revoke ownerless Uri permissions when in the
unprivileged state; an active owner indicates that another component
of the calling app still needs the permission.
Bug: 17554268
Change-Id: Icc412933b29041ffb699d20136a623440ecc71ec
- Reactivate our configured keyguard falsing swipe threshold
for secure keyguards, but only when dozing.
- Add DozeLog helper to capture/maintain interesting events
about the doze + unlock process, enabled by default, but
only on devices that start dozing at least once.
- Dump summary counts + logged events to dumpsys output.
- Pass notification pulse "instance" as an extra to the scheduled
intent, so we can log accordingly.
Bug:17496795
Change-Id: I7e88f93bfc967bdc06550cf1fe5e74d535edd774
These were already removed from public.xml, so this change does
not affect current.txt or public resource IDs.
BUG: 17577849
Change-Id: I3a754e968732705e5facfbc96e6e14c901d08596
The locks were added in c006f1 when underlying functions weren't performing
locking. In d2a4587 the underlying functions were changed to perform locking
but the higher level locking wasn't removed. The higher level locking can
now cause deadlocks with the new NetworkAgentInfo locking. This change
removes the needless higher level locking. Now all mRulesLock locking
only guards simple accesses to the appropriate two data strucures so there is
no chance of a deadlock. I verified that all accesses to the appropriate
two data structures are guarded by mRulesLock locking.
bug:17569997
Change-Id: Id9f4e3d19d6895876925ae32f12460db30359368
Instead of comparing MediaControllers via reference equality
(which is never true), go deeper and check whether the two
controllers are connected to the same IBinder.
Bug: 17571414
Change-Id: Id25d70be0a60d1900e977310dedcc7063552e018
We had an additional check for managed profile in there, so it wasn't working for device owners. Also needed to look at uninstalled packages.
Change-Id: I4813f23b00d7905e92ade582ce082a6f295a322d
Bug: 17384318
When services call Service.stopForeground(), remove
FLAG_FOREGROUND_SERVICE from the notification that was supplied
to Service.startForeground().
This enables services to post notifications that become user
dismissable when they switch to being a background service.
Restrict this to targetSdk=L apps to reduce the risk of breaking
existing apps.
Bug: 17551106
Change-Id: Iff8541e5bb2a23ad1fbc9ad80df5fd6eb683148b
This CL is a follow up CL for I6571d464a46453934f0a8f5e790.
Do not propagate Resources.NotFoundException to the caller
of InputMethodInfo.isDefault().
BUG: 17553712
BUG: 17549437
BUG: 17517332
Change-Id: Ie95880c1f68f49eb63518e69b7dfa20af3ce8737
...to the primary user, even if it was not whitelisted to be forwarded.
The path where getActivityInfo is called for the ResolverActivity
would not correctly apply the requested user ID to the result, so
it wouldn't run under the correct user.
Change-Id: I1da47c54bbed26091832a28236d0b06762c92437
