If a VPN app requests to be prepared and has already obtained user
consent, there is no need to additionally enforce the control
permission. We only need to enforce the control permission when a VPN
is first being prepared, where such a preparation would bypass user
consent.
Also ensure that in this case, the VPN being prepared matches the
calling app. Otherwise an app could prepare another pre-consented VPN,
which is not particularly dangerous but is likely unexpected.
Finally, remove misleading comment in ConnectivityService#prepareVpn.
This method IS called from VpnService.prepare(), not only from
system-privileged apps.
Bug: 18442887
Change-Id: Ic3227c6c1c74312697f0576d3811b06692a4edff
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
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
Windows without a surface didn't get the correct policy visibility
applied after dismissing lockscreen. Thus, when launching something
from lockscreen, home activity was hidden but never set to visible
again. Before executing the transition to home, we didn't consider
home as a wallpaper target because it was still invisible, and thus
we picked the wrong transition.
Always applying policy visibility when lockscreen changes fixes this
outdated state.
Bug: 18369599
Change-Id: I2933eaf0ab55fe31cb382c46c411033e33a756e0
adding the following two system properties to control remote
display rotation and device orientation lock:
"persist.demo.rotationlock"=true|false
"persist.demo.remoterotation"=landscape|portrait
Bug: 18317603
Change-Id: Id5fe115f895c6a0e72563036b9a98ff3b5037763
We're still seeing rare cases where a device struggles to create a
new user, probably because of a subtle bug in the FUSE daemon. To
work around this, only allow user IDs reuse after reboot.
Bug: 8302014
Change-Id: Id7f9fb539c6d6d1ff3d47d941af1d9e6b93eca03
We're now shipping devices with several partitions which may end up
mismatched, causing subtle runtime issues. To help manufacturers and
users catch this case, show wanring when we detected mismatched
fingerprints.
Bug: 18357469
Change-Id: I897d7ee8cbf3b8042d3d7d282afab277d242ed3f
...by default on Svelte devices
Also make sure the voice_recognizers feature is not enabled on
low-ram devices, with a new facility for platform feature
declarations to say they should be ignored on low ram devices.
Change-Id: I833c04b12e0e566dd682ed20adb0985c677a696f
The process name was being assigned null. This meant that after the
process attached we weren't matching the name in
ActivityStackSupervisor.attachApplicationLocked(). That meant missing
the call to realStartActivityLocked() and then the resolver didn't
start until window manager timed out and resumeTopActivity was
called five seconds later.
Fixes bug 18301267.
Change-Id: If3721caeebb309c6054150b2f707e3d6e38a74d2
