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
Adding the copyAccountToUser method which copies an account
along with its credentials to a different user.
Also an extra in the public api to identify the account to migrate
during provisioning.
Bug: 17716971
Change-Id: I2f29f1765ba0d360a3894b13ef86253b7c7d3284
When the DisplayPowerRequest policy is POLICY_OFF, a screen state
transition animation to DISPLAY_OFF is intiated. However, in
updatePowerState() the screen brightness setting, based on the current
display state, is set to normal brightness and an animation is
triggered. This causes a transient flash on some devices, which are
transitioning from a dimmed screen to screen off.
This change checks for a pending screen off transition before
triggering a screen brightness animation, to prevent the flashes.
Bug: 18136235
Change-Id: I37f9fb28b3ec8a4fdbb45920c40d25ebd50c220b
Previously, the conditional for checking the layer type before
accounting for the window bounds was incorrectly inverted, but
we can simplify by just skipping accessibility overlay windows
completely.
BUG: 18358878
BUG: 18359820
BUG: 18359788
Change-Id: I9ba1e43a0fef4fa40693bd8c7e883c2ef45b4c4d
We're using ordered broadcasts (sigh!) for package verification, and
we could be stuck behind dozens of other background broadcasts, so
hoist into foreground queue.
Bug: 18356768
Change-Id: Ib4abf771db0147f8fbd7227f32297602816c84ae
The bug has been fixed. No longer needed.
This reverts commit 5a3c231dc832c205d2bb2f7f0881925b92c9e5e2.
Change-Id: I4a0dda5321f4eeb989c4c58951c43c8d62fd3664
If the provider sends us an updated summary (or other text)
for the currently selected exit condition, update the UI and
persisted condition.
Update the downtime condition text (end time/line2 + summary)
when the next alarm changes (if downtime = none).
Also, clear the fired-alarm cache on time or time-zone resets.
Bug: 16373455
Change-Id: Ib38c52104a281fcc04a89612b643a219fd82b40b
Wake-up when entering brightness boost mode, don't boost in ambient
mode since some display device drivers do strange things in that mode and
boost doesn't work. Waking up feels more natural as well.
Don't flutter the power HAL's interactive mode bit simply due to changes
in display ready state since that may result in visible artifacts
such as display flashes.
Don't stop the auto-brightness sensor while temporarily boosted.
Don't prevent the display from entering the ready state while in brightness
boost since that would unnecessarily delay the transition from DOZING to AWAKE
until boost is finished.
Restart the user activity timeout when brightness boost ends and prevent
the display from dimming while boosted.
The pixel fairies basked in the sunlight.
Bug: 18262044
Bug: 18261782
Change-Id: I8c42a1e6091b0fe1253e90265ac248087ebc24e1
Eagerly connecting to MmsService in MmsServiceBroker during system
bootup caused a 2-second delay. Removing the connection in this CL. The
connection will be made when any of the API is called.
b/18085396
Change-Id: I201abcb5f8c5ac69e347e2c69fd20b8215bb0654
There was a window of time in Lollipop where we persisted certificates
after they had passed through a decode/encode cycle. The well-written
OpenSSL library was liberal when decoding (allowing slightly malformed
certs to be parsed), but then strict when encoding, giving us
different bytes for effectively the same certificate.
A related libcore change (0c990ab4a90b8a5492a67b2b728ac9a4a1ccfa1b)
now returns the original bytes verbatim, fixing both pre-Lollipop
installs and installs after that change.
This change recovers any apps that had been installed during the
window of time described above by doing a one-time check to see if
the certs are effectively equal.
Bug: 18228011
Change-Id: Ib82bd6db718d0490d7a26c9c1014b7c8457a7f2d
The current implementation uses a whitelist of package names. Use a
system|signature permission instead of rolling our own security and
add that permission to the existing set of whitelisted packages
(SystemUI and VpnDialogs).
In addition to being less of a security risk (using well-known methods
like Context.enforceCallingPermission rather than manually querying
PackageManager and checking UIDs for package names), this enables
other system-privileged apps to control VPN as needed per the below
bug.
Bug: 18327583
Change-Id: I38617965c40d62cf1ac28e3cb382c0877fb1275d
