| 7019325e183ba1abf1869ccffc4b1ecd8c771a44 |
|
04-Jun-2012 |
Brian Colonna <bcolonna@google.com> |
Bug 6605167: Turning off FUL during error counts as attempt
If FUL was turned off while the error message was displayed it would
not count as a failed attempt. This commit changes the
reportFailedAttempt callback to just report the failure rather than
report the failure and close. This allows the FUL service to send the
reportFailedAttempt message earlier and then later close using the
existing cancel function, which closes without reporting a failed
attempt.
Change-Id: Ib3b76f477a98b149fcccc32ac39ecaeccd88a7e2
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| 4fa995a932d876b98c393c909c4eb2e303783e59 |
|
31-May-2012 |
Uriel Rodriguez <urodriguez@google.com> |
BUG 5457035 : Anti-spoofing : DO NOT MERGE
Squashed commit of the following:
commit c0969669a6bd55df805665c17e088456c1672da3
Author: Danielle Millett <dmillett@google.com>
Date: Wed May 30 15:41:22 2012 -0400
Turning liveliness back on
As part of the change of putting in the new head turn option, it's
now passing in the correct value to Face Unlock instead of forcing it
to always be false.
Change-Id: I745da5431cbc2d447f3d07ec7215c5b1850f6d57
Change-Id: I36a819b43e89a463bb3bb3ede0db36477fd45066
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| c266070aec3d99c9a4d422325fbceae44c37a4d3 |
|
17-May-2012 |
Brian Colonna <bcolonna@google.com> |
Not calling startUi() if no longer bound
After the bind to the FUL service is complete, an
onServiceConnected() callback is received. This callback is
asynchronous - bindService() does not block while we are waiting for
the service to finish binding. Therefore, when rapidly turning the
screen on and off, it is possible to call bindService() and then call
unbindService() before the onServiceConnected() callback is received.
When onServiceConnected() is received, startUi() is called. If the
service is no longer bound, a runtime restart occurs when calling
startUi().
Note that onServiceConnected() actually has its work done via a
handler. The delay of calling the handler increases the possibility
of unbindService() being called before trying to call startUi(). But
since this problem still happens without using the handler,
eliminating using the handler would not solve the problem and would
just create the problems that come with performing operations on
different threads since onServiceConnected() is not called on the main
thread.
Also note that a new instance of FaceUnlock is created in
LockPatternKeyguardView with each iteration. So, if we bind/stop/bind
before getting onServiceConnected(), the second bind happens in a new
instance of FaceUnlock and therefore does not lead to a problem when
onServiceConnected() returns as a result of the first bind.
This fixes some occurrences of bug 6409767. However, this fixes the
problem when turned the device on and off rapidly. It seems there
are some reports of bug 6409767 where this is not the case, so I
can't be sure this has any affect on those cases.
This change also cleans up some debugging and modifies other
debugging to try to get just the information that is useful for
tracking down the bug.
Change-Id: Ifa59107b9974acaa8a18b74b5d47e4cf3a794b8e
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| 05dde913f97b29751572ed8169f6ba20374c7036 |
|
15-May-2012 |
Danielle Millett <dmillett@google.com> |
Merge "Setting liveliness to off" into jb-dev
|
| 46bbdec799002a33c5890f70225bef9f23fdef93 |
|
14-May-2012 |
Danielle Millett <dmillett@google.com> |
Setting liveliness to off
This is part of the change to remove the blink checkbox. Since the
blink checkbox won't be visible anymore, we want to set liveliness to
off instead of checking the current value.
Change-Id: Iaa68cea8ec0a6012eaaaac77cea0f50575b7e660
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| 88240596fce58afe79a4d06752cd8f6c086e2600 |
|
04-May-2012 |
Brian Colonna <bcolonna@google.com> |
Fix 6437474: Fixed black box appearing on rotation
The biometric unlock initializeView() function is called every time
the lockscreen is recreated. Since this normally happens when the
device turns off, initializeView() was covering the backup lock so the
backup lock is not exposed when the device turns back on. However,
initializeView() is also called when lockscreen is recreated due to an
orientation change.
With this change, the show() call to cover the backup lock has been
moved out of initializeView(), and the backup lock is now only covered
when the screen is turning off, preventing the backup lock from being
covered on an orientation change.
This also includes changes to prevent biometric unlock function calls
from occurring when SIM or Account unlock is in use. In fact, in any
situation where we know FUL won't be used, we don't even construct it.
This is not only more efficient, but it also cuts down on the
possibility of errors where FUL is being used when it shouldn't be.
Change-Id: Ie97761840df8de5701703d9b9b991726fb601064
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| e2d47e63cf1c5c095eb54f7af2a4a02b46862ddd |
|
10-May-2012 |
Brian Colonna <bcolonna@google.com> |
Merge "Added FUL client-side debug" into jb-dev
|
| dff307697d7a7482efe4c10cb3b07b9249524a42 |
|
09-May-2012 |
Uriel Rodriguez <urodriguez@google.com> |
changed pokeWakelock() callback to take time in milliseconds
Changed the pokeWakelock() call back to take one argument - the duration to stay awake in ms. This
change was needed in order to poke the wakelock for the duration of the watchdog timeout. This
must be done in the service because the duration of the watchdog timeout is unknown at this point.
Moved pokeWakelock() from start() to handleServiceConnected() to make sure that this poke happens
before the poke in the service. This poke is still needed to account for when devices are rotated.
Change-Id: I19d62df1489514de0588ebb937678358e70ffc95
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| cfeda767c87c2d9dd1966c7fbc1f77fa14f80920 |
|
09-May-2012 |
Brian Colonna <bcolonna@google.com> |
Added FUL client-side debug
This is to help track down bug 6409767 and will be removed when that
bug is fixed.
Change-Id: I51df2fd7d14ecd8f311fdf2ae993ba4943764011
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| 22001c1f96984655f7205ecbc93dd982c47b4e97 |
|
09-May-2012 |
Brian Colonna <bcolonna@google.com> |
Added checks to make sure FUL functions are on UI thread
There are three functions in FaceUnlock.java that have the requirement
that they are to be called on the UI thread. I added checks to log
an error if they are ever called off of the UI thread.
Change-Id: I581968e8138b7561b7ad75a1ac6945bf218e2bcf
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| 257f2ecc97d294e95b069547466d2054926d960f |
|
27-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Fix 6395288: Added lock to avoid unbind race condition
If turning the power off while FUL was closing (due to a timeout or a
cancel for example), it would be possible for unbind() to get called
twice due to a race condition. Turning the phone off calls unbind()
from the UI thread, while the other close comes from a binder thread
since it is coming from the service.
PATCH SET 1 attempted to solve the problem by adding a lock, but
having a lock around the bind is a bit scary.
PATCH SET 2 takes a new approach by having all calls coming from a
binder thread to be sent as messages to be handled on the UI thread.
Having all events occur on the UI thread removes the possibility of
race conditions and makes the code stronger by making everything
happen in a deterministic order.
This commit also cleans up the logcat logging a bit. A couple of the
log messages are now printing without DEBUG being set to true. This
is by no means spamming the log and they of course are only logged
when FUL is being used. But it serves to give us some meaningful
information from bug reports that are currently showing nothing. The
statements that are now logged would have made this particular bug
easy to track down.
Change-Id: I25a65c0808d88cb941439e5bf1f989dba8608be4
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| ea8441e22a4316cb6e78dd8bf461d3e658545b64 |
|
25-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Changes to biometric sensor interface in lockscreen
This cleans up the biometric sensor interface - the interface between
lockscreen and Face Unlock. Not only does it document the interface,
but it also makes two noteworthy changes to the interface:
1) Instead of calling mBiometricUnlock.start() with a parameter to
tell it whether to suppress itself, lockscreen makes all of the
decisions about whether the biometric unlock should be started or not
and only calls start() if it should be started. Passing a parmeter to
tell a function to not start itself was strange, but it was a
necessary intermediate step in the process of fixing this interface.
2) Instead of calling mBiometricUnlock.initializeView() with a top
view that the biometric unlock should attach to, lockscreen now
provides the biometric unlock with the actual view it is allowed to
work in. This keeps lockscreen in control of where the biometric
sensor is allowed to display.
A few things were also cleaned up within the Face Unlock
implementation of the biometric interface:
1) Changes needed to match the requirements of the improved biometric
sensor interface, including moving the functions into an order that
makes more sense.
2) The bind() function was only being called from start(), which has
turned into only a couple of lines of code, so the bind() code has
been just put inline into the start() function, which mirrors the
stop() function which has the unbind() code in it.
3) The showArea() function was really just one line of code with a
check. It was being called from two places. The showArea() code is
now just written inline in those two places, which makes the code
much easier to follow.
4) Renamed occurrences of FaceLock to Face Unlock.
Change-Id: Ie95ce21dcc77170381af9ce320f2675dfe249741
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| c169366f2cc44fc395dba76c763505ac2bd61640 |
|
19-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Moved biometric sensor selected check into LPKV
This change moves all of the mBiometricUnlock.installedAndSelected()
checks from inside the biometric sensor implementation to
LockPatternKeyguardView. There are several reasons for this change:
1) Instead of constructing a BiometricUnlock object and asking it if
it's enabled, LPKV can check this for itself and not even bother
constructing it if it's not enabled.
2) Since mBiometricUnlock will not be constructed if biometric unlock
isn't enabled, LPKV can simply do null checks to see if it should call
biometric unlock functions. So it serves the dual-purpose of ensuring
there will be no null-pointer exceptions with regards to using the
biometric unlock.
3) This greatly reduces the chance of bugs being introduced into
non-biometric unlock methods because no biometric unlock calls will be
attempted if biometric unlock is not enabled. Previously, the calls
would be made and then the biometric unlock would check if it was
enabled and return, which was not only bug-prone, but also
inefficient.
4) This simplifies the biometric unlock interface by removing an
unnecessary function call.
5) The biometric unlock implementations do not have to check if they
are installed every time they do something, which greatly cleans up
biometric unlock implementations. It makes much more sense for the
biometric unlock functions to be able to assume that they aren't
being called unless they should be.
6) Eventually when there is more than one possible biometric unlock
method, it will make much more sense for LPKV to be in charge of
what is constructed and what isn't.
Change-Id: I5437ac05d8ceb2b182fe372cd6c75ad944ade28f
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| fe444b48bac83bd5472b1102dae87661bafcfccb |
|
13-Apr-2012 |
Steven Ross <stross@google.com> |
Always showing FaceUnlock view before bind fixes 6330358
Sets the view to visible directly on the UI thread when feasible
this includes all cases where FaceUnlock is bound.
The delay in processing a message was causing the bug.
This additionally replaces the call in the keyguardview show
with one when the facelockareaview is initialized.
Change-Id: I8511f175d68023372e11d6e76fa1c44df6ac8a3d
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| 3223e2537d5f4e2eceeb321405dbd6da50df66b6 |
|
11-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Changed FUL calls to more general biometric sensor calls
This is another step toward fix 5460649 - cleanup
LockPatternKeyguardView (LPKV).
After this change, LPKV has minimal knowledge of FUL. FUL now
implements a new BiometricSensorUnlock interface and LPKV talks to
that interface. Other biometric sensors can implement the same
interface such that LPKV doesn't need to know much about what type
of biometric sensor is being used or its implementation.
The new interface has better, more general function names, so some
function names in FaceUnlock.java were changed. Some of the functions
in FaceUnlock.java were also reordered to match the interface.
This change should not change the behavior of FUL. There are two
places where code functionality was changed:
1) There was a showArea() function and a showAreaWithTimeout()
function that were both called from LPKV. To simplify the interface,
only a show() function is provided - it takes a timeout and if the
timeout is 0 it doesn't do the timeout.
2) There was a stopIfRunning() function that did a check to make sure
FUL was running. If FUL was running, it stopped FUL. Then it
returned a boolean indicating if it had been running. LPKV sometimes
needs to know if FUL was running so it knows if it should restart FUL.
To simplify the interface, a single stop() function is provided which
returns whether or not it was running. I believe the 'if running'
check was redundant and that there was no case where calling stop()
when it wasn't running would cause any badness.
Change-Id: I717268f360aed823e603df8e687cd107aa69ae11
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| f882f1ad4edd790483924e7bf485fd7c7240d110 |
|
11-Apr-2012 |
Amith Yamasani <yamasani@google.com> |
Bind to the correct face lock service.
When switching users, bind to the correct instance of FaceLock.
Tried to get the facelock screen to show up when switching users, but it
doesn't. Power off/on works, but not switching between users on the
lockscreen. Maybe a timing issue? Or not calling some function to make
the overlay visible?
Change-Id: I9300971331c7f0ed93ae7da28170342629426b20
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| f66e930e726f4caf49b7d47c08d160b14628c99f |
|
09-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Passing useLiveliness flag to FUL in startUi call
Because of changes in support of multi-user functionaity, the FUL
'eye blink' checkbox was no longer enabling liveliness detection.
It no longer makes sense to check the biometric flags (such as the
liveliness flag) inside of the Face Unlock service. Instead, that
flag is now passed in from lockscreen via the aidl interface when
startUi is called.
Change-Id: I591cf1924fbb24da7d54b94ef29824e5197d3b20
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|
| 9431366ecb4b6e4a87c0047c36548aa0bc23f2b1 |
|
06-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Separated FUL functionality from LockPatternKeyguardView
This is the first step toward fix 5460649. All of the FUL functions
were pulled out of LockPatternKeyguardView into their own FaceUnlock
class. LockPatternKeyguardView now has an mFaceUnlock member, which
is new'd inside of the LockPatternKeyguardView constructor, passing
it some objects it needs to do FUL. FUL calls are now made from
LockPatternKeyguardView by doing mFaceUnlock.foo(). Some of the
function names were reduced to avoid redundancy (e.g.
mFaceUnlock.start() instead of mFaceUnlock.startFaceLock()).
This change is just a refactoring and is not intended to change
any functionality. There will be other cleanups in the near
future...this is basically just the minimum changes needed to get
the FUL functionality into its own class.
Change-Id: I7dc5b22857bbf1659238b0e2d113069f7bf9ffe7
/frameworks/base/policy/src/com/android/internal/policy/impl/FaceUnlock.java
|