Bug 18399514
Adjust the contentUri to contain the caller's userId so that when
the phone process tries to open the Uri, it will open the provider
on the correct user.
Also make sure the Uri grants are properly qualified. We only need to grant
permission for sending. Receiving an MMS is always done by the primary
user and doesn't need special permissions. Move various permission grants
from the SmsManager to here.
Change-Id: Ib192f651ab05db9f07e9e6245bb343ed7a55b18e
Handles backup/restore of recent tasks for the system. Currently the
thumbnails are not saved.
At restore time the historical task records are placed in a designated
separate location rather than directly in the live bookkeeping; this
avoids ID duplication issues and makes it easier to deal with lazy
adoption of the historical task state as apps are installed on the
device post-restore.
Bug 17303286
Bug 15986349
Change-Id: Ie156c1e2ab9c9a7e7ac0447b27016fdcef55dded
A previous fix for IndexOutOfBoundsException (ag/584621) left a
situation where the index would not decrement if the arraylist
size didn't change. The size doesn't change if the window being
removed is animating away. That caused window manager to remain
in an infinite loop within removeAllWindows.
This change ensures that the index diminishes each pass through
the loop and doesn't exceed the bounds of the arraylist.
Fixes bug 18362246.
Change-Id: Ibca70d95622f3b152ede14857f0e913099dc7b88
ProxyInfo.getPacFileUrl() can not be null. It will be equal to
Uri.EMPTY. Checking for null was causing global proxies to never be
disabled. Or more accurately, global proxies would be disabled, but
would reappear after a reboot.
ProxyInfo.getExclusionListByString() can be null. If no
exclusion list was specified, the proxy settings would not be
successfully saved, they would disappear after reboot.
Bug: 18453223
Change-Id: I1c27e5dca5b9664bb7468ea909bff489fa110a07
Once an activity is no longer visible behind and has released
its background resources, it is added to the list of activities
that can be stopped, but not actually stopped until the next
major event (like another activity starting). We now schedule
the idle processing once the background resources have been
released so the activity can be stopped as soon as possible.
Bug: 18191707
Change-Id: I472eee949c1a78b4d944454463f03c90e7d2618b
All but a few lines of this is for issue #16013164, which allowed
apps to do some operations as the media uid by having it call
back to them to open a file. The problem here is with the tempory
identity stuff in the activity manager, allowing us to make the open
call as the original caller... ideally we should figure out a way
to just get rid of all of that, but the solution here is actually
easier (even though it doesn't look it) -- we now hand a token over
to the openFile() call that it can use when doing permission checks
to say "yes I would like the check to be against whoever is responsible
for the open". This allows us to do the uid remapping for only this
one specific set of permission checks, and nothing else.
Also fix issue #17487348: Isolated services can access system services
they shouldn't be able to. Don't send any system service IBinder objects
down for the first initialization of an isolated process.
Change-Id: I3c70e16e0899d7eef0bae458e83958b41ed2b75e
This could happen when another Network changes its capabilities and
updateCapabilities() calls rematchAllNetworksAndRequests() which
calls rematchNetworkAndRequests() on all Networks, even those that
are uncreated.
Allowing uncreated Networks to satisfy requests can lead to bugs
where ConnectivityService instructs netd to perform actions
(e.g. set default Network) on uncreated Networks which netd doesn't
know about yet.
bug:18446301
Change-Id: I857262ac66d1d3af4c264ce128f0a4bee95655de
getSystemAudioMode() should have used the thread-safe method
to get the information of the connected AVR.
Bug: 18426137
Change-Id: Ib3edff97337b5960160dd39d551fbfbbfdfce93b
It will be hard to mandate the contents
of the FRP partition out of factory. Further, for upgrading
units, it would require that OEMs format the partition and then store
a bit saying that they've done so. This adds another attack vector.
Now defeating FRP means either compromising the FRP partition
OR wherever the OEMs decide to store that bit.
This patch adds a checksum to the FRP partition. If the checksum
is not valid, the partition is wiped - disabling OEM unlock.
This ensures that no matter what data comes on the partition, we will
always disable OEM unlock by default. It also allows OEMs to not have to
worry about initializing the partition, as it happens automatically.
Bug: 18322021
Change-Id: Ib30782baa771591c30ea95054d3b83f36fc08cc2
* Sanity-check the recurrence interval. Some buggy apps pass seconds
where the API expects milliseconds, with the result that the device
pins the CPU at 100% trying to deliver alarm broadcasts every 60 ms
or what have you. The minimum recurrence is now 1 minute.
* Sanity-check alarms being scheduled for the immediate future. As
with the above this will catch people trying to schedule alarms
in a spammy way that keeps the device from entering low-power state.
The minimum futurity of a new alarm is now 5 seconds.
Bug 17495168
Change-Id: If8ff7d88da48960532ac21a0ba20094af9912603
We weren't passing volume events to the master volume correctly on
devices that only use a master volume. This fix checks if the device
only has a master volume and adjusts the master volume instead of the
stream's volume if that's the case.
bug:18305790
Change-Id: Iec35e0a7dc59e6d73c9dfc88da324660bb15b1f3
Just don't use then to compute unaccounted space. This is a partial
revert of commit 9538eea5ff6f8e2183ced81b5b8eac60b0e774ea.
Change-Id: Ie2e29c8934da8ef707d20db1333abd4e240cd213
This is NOT designed to be called normally. Most apps (even
system-privileged ones) should request user consent before launching a
VPN. However, it is needed to support flows where consent can be
obtained through other means external to the VPN flow itself.
The API requires a system-privileged permission, CONTROL_VPN.
Bug: 18327583
Change-Id: I1bcdcf0fb5707faeb861ec4535e7ccffea369ae7
