This turns out to happen a lot in normal usage, but we're logging
copiously about it each time. It's reporting "oh hey we're already
in this state" -- and so the log is not useful anyway.
Logspam is spam.
Bug 15169507
Change-Id: Ie2d01ff1b0b3600dd9c15ccf83d60875558f1dc2
...due to dying renderer process
Don't kill processes if they are bound to a service but not impacting
oom adjustment.
Change-Id: I1cc44e633feaeaad6e996b79a6cfd7b386c04095
Very useful for testing persisting/restoring, to make sure
that all pending changes have been written.
Change-Id: I0e3b7cd3af8afb0b6e751e086081566ab00b76c9
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
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
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
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
...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
In addition to device owners, profile owners on the primary user
can also set user restrictions that are necessary to lock down the
user.
This is to enable the case of a profile owner registered after setup
wizard is completed, on the primary user.
Also make managed profile vs. profile wording consistent in the
DevicePolicyManager docs.
Bug: 17555025
Change-Id: Ib9d08b8af34a99b25e11757fa7dc83673a7deb32
When a TaskDescription is sent up to the system process, the Bitmap
contained in the mIcon member is immediately flushed to disk and the
name of the file replaces it in the TaskDescription. Thereby saving
mucho RAM for better uses.
Fixes bug 17527308.
Change-Id: Ifac63ea5d12ed091d1eb03e178b8b847a827f940
