Fix 5783857: Device Policy Manager doesn't allow Face Unlock
This makes it so that if face unlock is enabled and then a device policy
manager that requires something more secure than face unlock is installed,
the user will be forced to choose a new acceptable lock type.
This was previously fixed for the case where the device had been reset, or
the shell was restarted after setting face unlock, but not for the case where the
device remained on between setting face unlock and setting up a device policy
manager.
Also changed the function ordering of saveLockPattern() so that the overloaded
wrapper function is next to the main function.
Change-Id: Ibed8c4ab137ebbc07fb143faef6f047bc6dc4474
This adds a feature to delay locking the device when the power button
is pressed. This fixes a use case where the user wants to turn off
the display (e.g. to save power) but doesn't want to lock the device.
For the case of a secure device (user has a pin/password/pattern),
this will lock the device immediately or not based on the setting.
For the non-secure case, this always "locks" the device to provide easy
access to the camera while preventing unwanted input.
Change-Id: Ie328485c3f7559e26896d761cbf0e69d3f4df4e2
This issue was found while investigating b/5328288.
After navigating to a page that specifies target-densitydpi in the
viewport meta tag, this density value wasn't reset to the default value
for a page that didn't.
Change-Id: I1a66dab769026367224ecf4cc28bc033ee97e475
The audio gap when looping audio is mostly due to
a delay requested by the audio player when executing
the end of stream message. This is to allow the audio
to be drained out of the pipe before actually stopping the
AudioTrack.
This delay is not needed when looping as the AudioTrack
is not stopped.
The fix consists in ignoring the requested delay when the
looping flag is set in awesome player.
Issue 5800981.
Change-Id: Ib32d2930c53ecebc21ca8440e6e054c7e20db4a5
For non-localized strings like the keywords in SQL statements, we shouldn't use
locale-specific case transformations.
(Cherry pick of 03f8f84c345e7c861a6de889d434b9d82cf04c8d.)
Bug: 4284951
Change-Id: If5b7154f70a7db22837d071d1c57e929729b7d35
- cherry-picking framework CLs from master into ics-mr1 that are
needed for FU to work on tablets
- needed for OEM partners even FU isn't going on xoom
Squashed commit of the following:
commit 3258f2528f558efdaf34ae15c5425f2d879848fe
Author: Brian Colonna <bcolonna@google.com>
Date: Tue Dec 13 15:49:48 2011 -0500
Added Face Unlock to tablet lockscreen layouts
The Face Unlock Area was not part of the tablet layouts, so prior to
this change, Face Unlock would not show up on tablets when selected as
the unlock method. The backup unlock method would show up instead.
The goal here is for the pattern and PIN unlock layouts (in both
portrait and landscape mode) to look the same as before this change.
This was a little harder than it was with the phone layouts for two
reasons:
1) For the phones it was ok for Face Unlock to be sized such that it
just covers the backup method. For the tablets we want Face Unlock
to cover far more real estate.
2) The phones were based on a grid layout, whereas the tablet is a
linear layout.
Note that the diff makes the modifications look way more extensive
than they actually are. Basically, in most cases I am putting a
relative layout around some existing portion of the layout and
putting the Face Unlock Area area inside of the new relative layout.
Change-Id: I478becddf2a9ee9fe7b6d653e604fa3ad89b822f
commit 821cfe85cf2b3daf074d9749dbf6e0a5663af0de
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 19 15:51:10 2011 -0500
Unbinding from FU when going to backup
Lockscreen was stopping Face Unlock when going to the backup lock, but
not unbinding from the Face Unlock service until the device was
unlocked.
This caused a bug on the tablets where Face Unlock would reappear when
switching between portait and landscape orientations, even after the
backup lock was exposed. On an orientation change, Face Unlock is
restarted if the service is bound to during the orientation change.
Since it was bound to when it should not have been, Face Unlock was
restarting when it should not have been.
The wakelock is also now being poked on an orientation change because
on the tablet you can keep Face Unlock alive by switching the
orientation back and forth, but eventually the screen would go dark
with Face Unlock running.
Also, a conditional was moved in activateFaceLockIfAble() so the whole
section isn't executed if Face Unlock is not in use. Part of it was
being executed with only the inner-most part having the check. This
did not cause any issues that I am aware of.
Change-Id: Ib452b8ced28a507bf9272dbf5d3477a8abd1ba90
commit fa90bb76ac6b311d12b55d23df4ac44cec62c7b3
Author: Brian Colonna <bcolonna@google.com>
Date: Mon Dec 12 18:02:23 2011 -0500
Changed how Face Unlock coordinates are specified
Was using View.getLeft() and View.getTop() to specify the upper-left
corner of the Face Unlock area. That gives coordinates relative the
view, which was fine for the phones. For the tablet it needs
coordinates relative to the window (which still works for the phones).
Also fixed a 'bug' where h and w were swapped. However, it wasn't
causing a problem because it was swapped in two places.
Change-Id: I86c1f68439f1dcef826cfe6b8fb56c9a4a6b8dc3
Change-Id: I962c0486be85949e002b0a2701286a6a39251f36
This adds Resources.getDrawableForDensity() and
Resources.getValueForDensity(). These are needed for applications
to correctly retrieve larger icons such as in launcher when
running on a tablet. We had already exposed the APIs to tell the
application which density to use for app icons on the current
device, but didn't unhide these APIs that allowed you to
actually retrieve them.
This is safe to do without introducing a new API level (as long
as we do it soon) because we know these APIs already exist in
Android 4.0, and there is no reason for anyone to be removing
them when building a device.
Change-Id: I5138e5dc908197b66a98d20af73c5374cb5d41d3
Bug 5806859
Bug 5795341
Add a custom InputConnection to capture the deleteSurroundingText
command and use it to send delete key codes to the WebView for
single deletes or calling into WebViewCore to delete contents for
more complex changes.
Also makes the IME options "normal text" for webkit-based text
entry.
Webkit change: Ic938d6fa
Change-Id: I18606014a034194928a61981dc3e2400a7db5fac
Run a background "watchdog" thread that will check for
the WebCore thread stopping processing messages (this
can happen if a piece of JavaScript goes into an infinite
loop, for example) and offer to close the WebView app when
it detects such a case, much like the normal system ANR.
Bug: 2563868
Change-Id: Ic74813b1e630d657c340a7017a4b0814071eb041
To make it easier to test tethering, have fetchDunApn
return null when the system property
net.tethering.noprovisioning is true.
Change-Id: Id6162967c6b8b25f04380fe009961c150fa714ef
