| 2de5ee84636739dc82a4c4dda76666bf38cf281c |
|
15-Jun-2012 |
Jim Miller <jaggies@google.com> |
Fix 6507787: fix MMI PUK unlock procedure
This fixes a bug where the user uses the MMI sequence (**05*PUK*PIN1*PIN1#)
from the EmergencyDialer to unlock their phone instead of the provided interface.
The code now recognizes when UnlockMode becomes invalid because it was previously
locked because of SIM state. It then dismisses the PUK unlock screen and advances
to the home screen.
Change-Id: I8902350e6f640cd2fa0af3460c3ea1a39d926c8a
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| cafd387d7a2d91a2c900b7744b0486818cd1aac2 |
|
17-May-2012 |
Danielle Millett <dmillett@google.com> |
Moved setting the flag to suppress face unlock during a phone call
Moved the check to suppress face unlock if a call is in progress from
onScreenTurnedOff() to initializeBiometricUnlockView(). onScreenTurnedOff()
is only called if the screen was turned off while on lockscreen and we
actually want to be doing this every time the screen is turned off. Put a
check around it to only do it when the screen is off, so that for orientation
changes, or on first boot it doesn't override the current flag value.
This fixes the following 2 bugs:
Bug 6460309: When making a phone call, after the user hangs up and it goes
to lockscreen we don't want face unlock to show. In the case where a
user makes an outgoing call and the phone goes to sleep by itself during
the phone call, when the call is ended face unlock was popping up because
it never went through onScreenTurnedOff().
There is a flag to make sure face unlock doesn't come up
immediately after booting the phone, which is done by not showing
face unlock the first time lockscreen is constructed. But there are
a few cases where lockscreen doesn't come up immediately after boot: 1. When
the device is factory reset, it goes through the wizard instead of
lockscreen. 2. In userdebug if the lock type is set to none.
In both of these cases, if face unlock is set up, it doesn't show up on
the first time. Setting the phone flag in initializeBiometricUnlockView
overrides the initial setting, which is what we want because if the screen
has turned off, it isn't the initial lockscreen after boot.
Change-Id: Iacafc515f2b594e12c853308c40cd48f3fb83e63
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.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/LockPatternKeyguardView.java
|
| 354619c1cc1b4668c81c5368b2256335cc9e8538 |
|
28-Apr-2012 |
Jim Miller <jaggies@google.com> |
Fix 6397736: Swipe up to search layout fixes
This fixes several layout issues on phones and tablets with MultiWaveView.
It adds a new background scrim to be shown behind the MultiWaveView
on the navigation bar.
MultiWaveView is updated to handle gravity constraints which makes layouts
much more flexible across devices.
Change-Id: I64068f4eaa81ef6c464247049117d53432fcacbd
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 78c629807c8fe914801ed17f7e16dc1f820e67cd |
|
27-Apr-2012 |
Steven Ross <stross@google.com> |
Don't show Face Unlock on initial boot fixes 6396685
Uses a static to keep track whether this is the first pass through the lockscreen
This will be true from when the process is instantiated until the lockscreen
is constructed for the first time, and then false afterwards.
When it is true, we suppress the biometric unlock (Face Unlock).
This avoids the problem of unpredictable and slow startup behavior for Face Unlock
on the first unlock after boot.
Change-Id: I70033af17ba3163d5fe07fc58096f01afaaaafd0
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.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/LockPatternKeyguardView.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/LockPatternKeyguardView.java
|
| f6d61c64fb173aa7a1415870d5fdfe730eaa4160 |
|
19-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Fix: refreshBatteryInfo was uncovering backup
The onRefreshBatteryInfo() function hides the biometric sensor area so
the biometric sensor isn't shown when the screen turns on during a
plug/unplug. However, sometimes the function is called when there
is no plug/unplug. This fix makes it only hide the biometric sensor
area (thus exposing the backup lock) on plug/unplug.
Note that this does not fix b/5465535 although it may help reduce its
frequency.
Change-Id: Iccff382c23d71257593dc1595ed8fec57adaf5bd
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.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/LockPatternKeyguardView.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/LockPatternKeyguardView.java
|
| c3cd2500a535aeba8e8ce2876844542829dd8e68 |
|
12-Apr-2012 |
Brian Colonna <bcolonna@google.com> |
Fix: FUL coming up when phone is powered off from lockscreen
When FUL was enabled and the power was turned off from the lockscreen,
either manually or by timing out, the lockscreen would turn back on
and FUL would start.
I believe this is due to a recently-added 'force' flag, which this
commit removes.
Change-Id: I314125fe52afe1536ab5a4600f39f563e1d58991
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.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/LockPatternKeyguardView.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/LockPatternKeyguardView.java
|
| 52c489cd63cca0361f374f7cb392018fabfa8bcc |
|
28-Mar-2012 |
Amith Yamasani <yamasani@google.com> |
Lockscreen settings per user
Move all lockscreen related settings to LockSettingsService.
LockPatternUtils uses this through IPC instead of Secure settings.
Migrate old settings to new database managed by LockSettingsService.
Passwords and patterns are stored in a new per-user location, except
for the primary user, for backward compatibility.
KeyguardViewMediator and LockPatternKeyguardView listen for changes
to user and updates the lockscreen.
Settings provider will look for Lock settings in the LockSettings
service now for the entries that used to be stored in Settings.
Change-Id: I956cd5b95e2d9d45a6401af7e270e6a5aa2dcc98
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| b030476d193a423f6c1baf3053f66fc768c925e0 |
|
14-Mar-2012 |
Jim Miller <jaggies@google.com> |
Fix 6021938: Improved target support in lock screen
This adds the ability to enable or disable target icons based on the drawable
resource of the target.
It also fixes a bug where we'd show the camera while displaying
the PIN/PUK unlock screen or when it's disabled by DevicePolicyAdmin.
Minor simplification and cleanup KeyguardUpdateMonitor callbacks.
Change-Id: I33fad56a2203bc8b7bcd0300c20478711a56713a
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| fbc46dc3c2be5f89041d9e4d3447bc65d303d43a |
|
02-Mar-2012 |
Jim Miller <jaggies@google.com> |
Fix 6028595: Fix reboot loop in AccountUnlock due to null callback
This fixes a bug where the device would get into a reboot loop due to having
a null callback. The problem was that a recent change caused the callback
to be used indirectly by the constructor before being set.
The solution is to pass the callback to the KeyguardViewBase constructor
which ensures it's ready by the time we call getCallback().
Change-Id: I2598fc5338be99977980e4dea41a096fb2a7ef7e
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 93708af1329bb278d83c1fac6a623629cb42a3d4 |
|
26-Jan-2012 |
Jim Miller <jaggies@google.com> |
Fix 5620754: don't show pattern unlock after SIM unlock if not enabled.
This fixes a bug where the device would show pattern unlock after the user
entered the SIM PUK unlock code. The code now correctly determines that
the device isn't secure and thus shouldn't show the unlock screen.
Change-Id: I49fd749592154a4c5840038b92d54ca7ca086074
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| fb45f7b08b0218b59b5b3a9631f9b37fc8fb3dfd |
|
19-Dec-2011 |
Brian Colonna <bcolonna@google.com> |
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
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| a44f2a59a2408ff367bd2efc7f74ec56f92565dc |
|
13-Dec-2011 |
Brian Colonna <bcolonna@google.com> |
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
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| ebc6fb46c28c972d745c3d34b9fdfaf46fb20c1d |
|
09-Dec-2011 |
Steven Ross <stross@google.com> |
Checking whether screen is on in constructor fixes 5658742
Change-Id: Ic96c8dd9ee9e86000b0cbe22a7d068a8ee424448
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 6e6e5df754bb6f41a37500d5b1c45329a37ca326 |
|
06-Dec-2011 |
Brian Colonna <bcolonna@google.com> |
Making Face Unlock fix that wasn't proerly merged in master
It appears that https://android-git.corp.google.com/g/#/c/144795/1
was incorrectly merged down into master. This commit is to correctly
add the change from that cl into the master branch.
Without this change, if you bring up the emergency dialer while Face
Unlock is running, you momentarily see the backup lock.
Change-Id: I6350150bf46ac52d5c50c9e88119f09397d22902
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| b9430d2a1c8dbf7b9998d349544c9ae133dab18f |
|
23-Nov-2011 |
Steven Ross <stross@google.com> |
Display max retry lockout message on backup lock fixes 5462647
Change-Id: I75e51f45f821542ae380e4ec4e3232b3fbe660f4
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 76b2337cfaeaf066f907b611d5e2ba380a619ab7 |
|
18-Nov-2011 |
Jim Miller <jaggies@google.com> |
resolved conflicts for merge of 1a783be3 to master
Change-Id: Ibaff3547ac51250fe40adf3aa06d6a30ecfcef54
|
| 9a3caf39e4c628c6dfcac92f7e2b7e4538a73009 |
|
18-Nov-2011 |
Jim Miller <jaggies@google.com> |
Fix 5636798: clear PIN/PUK fields when device sleeps or user cancels
This bug is the result of onPause()/onResume() not being called properly
when we have both lock and unlock screens present, which is true for the SIM
and PUK unlock cases.
The fix is to invoke onPause() and onResume() on both of them if they exist.
Verified the rest of the code correctly handles having both.
Also, when the user cancels, we now clear the fields.
Change-Id: If7fbd31df7eab9e3d60656d50d2392607a4bf471
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| c753a1865ca049fb20fc5cea036c06ea77647ff1 |
|
15-Nov-2011 |
Steven Ross <stross@google.com> |
Not showing facelock when plugging/unplugging fixes 5438524
This will close down or prevent the start of FaceUnlock if
the device is plugged in or unplugged,
unless FaceUnlock is currently active.
Change-Id: I216831964472da47fb24644070d1717dffe1b7f7
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 0a981cf522ba816065494473651105f4aa981654 |
|
15-Nov-2011 |
Steven Ross <stross@google.com> |
No blackscreen when dialog is showing fixes 5511992
When a dialog is activated, we won't show the blackscreen
until after the lockscreen comes back in focus, which occurs
when the dialog closes.
The user may toggle the power button, causing onScreenTurnedOff to
reset mHasOverlay, even though the dialog is still on top of the window.
Thus, the dialog will have a black box behind it without this change.
Change-Id: I6bec7984b88454e9fff22147cbbfc27b9c0a74f2
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 6162960c1eda8cce32a236e7f805cc4fdf9cf656 |
|
15-Nov-2011 |
Jim Miller <jaggies@google.com> |
am 3dd55677: am ff95f657: Merge "Fix 5579440: Add transport control view to tablet unlock screens" into ics-mr1
* commit '3dd5567710168da330741cb4c4263cc03dd942f1':
Fix 5579440: Add transport control view to tablet unlock screens
|
| faed16030df5221f790a4d6fd5bdfb592db977fa |
|
09-Nov-2011 |
Jim Miller <jaggies@google.com> |
Fix 5579440: Add transport control view to tablet unlock screens
This updated tablet layouts to support showing album art and transport
control views in PIN, pattern and password screens of lock screen.
It also allows the addition of a background protect asset and
the ability to show the system wallpaper on layouts that define a
transport_bg_protect view.
Also updated layout to use new ICS-style buttons on lock screen and
fixed bug with "forgot pattern" button where we were showing the
emergency call icon.
To avoid problems with leading ones in the mono-space clock font,
we now right-justify status text on tablet and remove the AM/PM
indicator.
Status font size adjusted by UX.
Added background protection drop shadow to transport control.
Fixed portrait mode to be right-justified when transport is showing.
Change-Id: I790292fc39f4588f87adc9d9241706817ae6baab
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 1ae5b71a95c0472fd07d9928ff34ee1870081e66 |
|
09-Nov-2011 |
Brian Colonna <bcolonna@google.com> |
resolved conflicts for merge of 7cf1eeb9 to master
Change-Id: Id125e315e24ced927f3a500135af7e5aff50cfa2
|
| 6233fbe5da2466da26245a35acc5129974dd5440 |
|
04-Nov-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5514230: preventing null window token from occurring
Sometimes the lockscreen view is recreated even though it has already
been created (and therefore Face Unlock is already running). One
example of this is when the lockscreen momentarily displays in
landscape mode and then corrects itself into portrait mode.
When lockscreen recreates itself, it removes the view and then later
re-adds the view. During that time the window token is null and may
be passed to Face Unlock when it tries to restart. The reason this
doesn't happen *every* time the view is recreated is because the
onServiceConnected() callback starts Face Unlock, and usually it
runs after the view is re-added, but sometimes it runs before the view
is re-added, resulting in this bug.
An earlier fix put null-token checking inside of the Face Unlock
service, which prevented crashing but Face Unlock was still unable
to run. This fix makes the null token case not happen so Face Unlock
can run every time. It accomplishes this by simply not restarting
Face Unlock until the view has been re-added.
This fix also replaces checking two flags everywhere to see if
Face Unlock is being used and instead uses a single function call.
Change-Id: Ib46f25f2a58ab2e70470337861c25ee81a858873
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 1a088aa1b9350681edcf1a94f54e45debd7eca15 |
|
24-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5479823: black patch was showing before resuming call
- This issue was marked as RelTeamHotIssue
- When Face Unlock is enabled, the black area is shown when going into
the emergency dialer to prevent the backup lock from showing.
However, it was doing this even if Face Unlock has already gone to
the backup method.
- Since the same code is used for returning to a call as is used for
starting the emergency dialer, it was doing the same thing when
resuming a call.
- Just had to add a simple check to only display the black area if
Face Unlock is still running.
- Note that this did *not* cause a problem when Face Unlock was not
the unlock method.
Change-Id: Icc4deebcb47ceda035ea29c7d976342d3a8a60a7
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| f8b9a4751e6d0721804931aa39545e3741ff5013 |
|
24-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Added callback to allow Face Unlock to hide black area
- Part of fix 5491362 (RelTeamHotIssue)
- Because the fix closes the camera early, this change is needed so
the black area isn't still hanging around while the camera fades
to the backup lock.
Change-Id: Iab7c264adab0fb05979fe2732048ccf2237e64c5
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 2928c9d82b4fcca67472cf77e3c508e64baff1fc |
|
21-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5493266: Properly restore background after playing music
KeyguardViewBase maintains the transparent background for all lock screen
views. The background was being overwritten by the change to make lock
screen opaque when music was being shown.
Change-Id: Id1ab415f68746b20c9229fa58fef9ec8be354f01
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 06398768ec048cf05717ee44b81cb357fdc896dd |
|
19-Oct-2011 |
Jim Miller <jaggies@google.com> |
Merge "Fix 5288804: Make music trasports in lockscreen more closely match design" into ics-mr0
|
| 2720cfae624770674122640f2d4a3f55702d80ff |
|
19-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Merge "Fix 5433466 - FU out of position during orientation change" into ics-mr0
|
| 02c4c8a700ab2c5dc10566550ba0cab121eff0ce |
|
18-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5288804: Make music trasports in lockscreen more closely match design
This fixes three issues;
- Make the background black while the transport is showing.
- Show scrim sandwiched between artwork and overlapping UI.
- Remove gaps in sides of background assets.
Change-Id: I563fc680c4c042d8b25ec37332aeab528cf838ca
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| f13313a073ad3f3c4e91baa4adbfdec66395065e |
|
19-Oct-2011 |
Jim Miller <jaggies@google.com> |
Merge "Fix 5452698: fix broken logic in reportFailedAttempt() in lockscreen" into ics-mr0
|
| 9d20405e5117f05dfd3049798cd36a74142a6822 |
|
18-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5433466 - FU out of position during orientation change
If you turn the device from portrait to landscape mode and immediately
invoke the lockscreen, it will come up in landscape mode and switch to
the desired portrait mode within a couple of seconds. Previously,
Face Unlock would come up in landscape mode, but its position would
not change once lockscreen corrected itself, causing Face Unlock to be
partly off the screen.
This has been fixed by checking if we are already bound to Face Unlock
when the layout is created. If this is true, then the layout is being
created due to a change in orientation, and we stop Face Unlock, and
restart it at the new position.
This commit also adds a fix where we now use INVISIBLE for the Face
Unlock area when it is not showing instead of using GONE. The
dimensions of the Face Unlock area is 0-by-0 when set to GONE, and we
want to avoid the possibility for the Face Unlock service being
assigned a zero area. I'm not sure if this was ever causing problems,
but it certainly is not the intended behavior.
Also cleaned up some comments and logging.
Change-Id: I68deb49cb26dafb5c238167d0c23f0eed2cfb75a
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 29aa5dc7de41cc41428dfa958a0cbeac38b29e26 |
|
18-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5452698: fix broken logic in reportFailedAttempt() in lockscreen
This fixes a bug where we were no longer showing the countdown dialog
every 5 attempts or "forgot pattern" button when the user has a fallback
password enabled on the pattern unlock screen.
It now correctly shows the dialog whenever the user hits a multiple of
5 bad attempts on any of the pin/pattern/password screens.
Change-Id: I4eb47b4149958a93572d256a4a70f9d67bc1eb38
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 305c78cce649056643641c51f12f2b6d2eb839f3 |
|
16-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5466678: use new setSystemUiVisibility() API to enable clock in statusbar
This fixes a bug where the clock wasn't being shown in the statusbar while
the music widget is showing.
Change-Id: Ic1c52c4ab7fa1490fe14ddafaf2c494bcf51866d
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 7b5dd87351ac476dd872c51f9b819d2a3e572382 |
|
16-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5466793: Fix memory leak in system process when face lock is enabled.
Previously, the code was not unregistering the callback when we unlocked
the device, which kept a reference to LockPatternKeyguardView indirectly
by a reference to mFaceLockCallback.
It now correcly removes the callback when we unlock the device.
Change-Id: Ie592d007a1dfc2416b9e8956aba2c34e3d0120ee
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| d814d4fa0c76a0384f7e32816e1ca36f237911c6 |
|
15-Oct-2011 |
Uriel Rodriguez <urodriguez@google.com> |
Merge "going directly to backup after face unlock fails 15 times" into ics-mr0
|
| ef0e259d59a20e6ed2334f37b2fb8067ff9cbf99 |
|
14-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5458658: Fix memory leak in lock screen
This fixes a memory leak caused by not unregistering the info callback
held when LockPatternKeyguardView gets destroyed.
Change-Id: I8c008b6f8a5e8471bd0e1fd3939aa75175923ce5
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| fd2ed6910f932ce43b621d6296eff112e137fbf9 |
|
14-Oct-2011 |
Uriel Rodriguez <urodriguez@google.com> |
going directly to backup after face unlock fails 15 times
- after 15 failed face unlock attempts, go to backup until the backup method is successful
- if the backup method times out (because too many unsuccessful unlocking attempts),
face unlock will not be launched until the backup method is used sucessfully
- fixes 5365919
Change-Id: I9aef7a4f1abcceefc5d6f1c0458ae5cbe8a902df
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 4e6d35829ebf98ea37f77ea434550d51950c1119 |
|
14-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5358124: Better transport control visibility management in lock screen
This changes TransportControlView to be "sticky" on lockscreen. Basically, once it
appears on lockscreen, it stays there until unlocked and then locked again in paused state.
Tested basic design goals (using Music2):
- play then lock -> shows
- pause then lock -> not shown
- toggle pause to play while locked and not shown -> shows
- pause after played once while locked -> stays until we unlock and lock again while paused
- remote control play while paused & sleeping -> resume lockscreen -> shows
Also tested:
- configuration changes (orientation) to ensure widget continues to show after it once appears
- remote events while lock screen on -> keeps lockscreen on.
- remote events while sleeping -> doesn't wake.
Change-Id: I23418c5f7dfd1457c0844d2683772e8a3ed0abd1
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 3406886939b0f28c426acefbe9dc77292210d8b4 |
|
14-Oct-2011 |
Steven Ross <stross@google.com> |
Merge "Making FaceUnlock not pop up for overlays Fixes 5451837 Fixes 5446341" into ics-mr0
|
| 2ce6882bb498c93af114626daa79cfa4f3f4e366 |
|
14-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Fixed problem where Face Unlock area was showing
I introduced a bug cl https://android-git.corp.google.com/g/#/c/141926
that caused black box to hide lock pattern even when not using Face
Unlock.
Fixed by adding the corresponding check to make sure Face Unlock is
being used.
Change-Id: I9c429c99d7db4d1ab831080f23a1e10123dbfe3e
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 7726289c2890d13baa3d10dc504b43e2128b4918 |
|
13-Oct-2011 |
Steven Ross <stross@google.com> |
Making FaceUnlock not pop up for overlays Fixes 5451837 Fixes 5446341
When the screen turns on because of an incoming phone call or
when the emergency dialer is selected, FaceUnlock is deactivated
until the phone call is completed and the screen is turned off.
This also checks for non-phone overlays.
If the lockscreen becomes unfocused while the screen is on,
we assume that the reason is an overlay and prevent FaceUnlock
from starting. The normal clock app is not considered an overlay by
this approach, and thus it works as intended (back button
brings up FaceUnlock).
Also reverts: https://android-git.corp.google.com/g/#/c/139885/2
to make FaceUnlock appear when music is playing again
Change-Id: Id715878556667d2b7e35c30a28d91be6a4eee575
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 3505abf31df8dafab2c83ceb8f85b5694cac3b78 |
|
14-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Merge "Fix 5451144: Poking wakelock upon fallback" into ics-mr0
|
| 9eeaaa39c3bad72a369aeff11f95ffea13a5e214 |
|
14-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5451144: Poking wakelock upon fallback
Now poking the wakelock when Face Unlock goes to the fallback method.
Previously, the backup lock would stay up for a varying amount of
time depending on how long Face Unlock took before fallback. The
backup is now consistently displayed for 5 seconds.
Also added comments to some older code.
Change-Id: I9f6bdd2d3015e7eb9cb90143737a3cdc87189993
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 19fa262c52ddaf0e5ec200f4f7f21bda0d4b617b |
|
14-Oct-2011 |
Martijn Coenen <maco@google.com> |
Merge "Send ACTION_USER_PRESENT when provisioning is completed." into ics-mr0
|
| 81cdada882f15acd69deca0803ea66dd5d0f6f32 |
|
13-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5437700: Underlying backup method was exposed
At one point we added a timeout to the black box that covers the
underlying backup unlock method so if Face Unlock doesn't start or
crashes, the user will see the backup method rather than being stuck
looking at a black box. However, when powering the phone on and off
quickly, the message to time out the black box could be received at
the wrong time, causing it to expose the underlying backup method
when it shouldn't.
This solution clears the existing SHOW/HIDE messages from the
handler's message queue before sending a new SHOW/HIDE message. In
particular, it clears out a delayed HIDE message when a SHOW is sent
so the SHOW can't be undone by a pending delayed HIDE message.
Also, logging errors for a couple of exceptions instead of rethrowing
so we can gracefully go to the backup in these cases.
Patch set 2 fixes problem where rare exceptions could prevent ever
binding to the service again because mBoundToFaceLockService was still
true.
Change-Id: Ieb7b6723161070f509277f67dc9ef100cf7c1aa6
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 4841e29d0fd3fbe0594f283e4897869331a20fbf |
|
12-Oct-2011 |
Steven Ross <stross@google.com> |
Fixes 5446301
If the user is making an emergency call, don't bring up Facelock
Has the side effect of not bringing up Facelock if they cancel dialing
Change-Id: I5d23e89b7f687f260670d41f1cc55ebf2a135181
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 24d7b5f22ac98392f8b2d2c94560173e44d1ca6c |
|
11-Oct-2011 |
Nick Pelly <npelly@google.com> |
Send ACTION_USER_PRESENT when provisioning is completed.
This is needed for application to know when the keyguard becomes
unlocked, because isKeyguardLocked() is typically true while
provisioning (setup wizard), but ACTION_USER_PRSENT was
not sent when it transitions to false after provisioning.
Bug: 5436867
Bug: 5430833
Change-Id: Icae13ff9cab84774a002a426eb9cb353fa1dc530
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| c3892c525d5fffc40f068e7fdc975807e987c9d4 |
|
08-Oct-2011 |
Steven Ross <stross@google.com> |
Fixes 5429869 Only displaying FaceUnlock when window is focused
Makes sure that the screen is on and the window is focused before bringing up FaceUnlock
Change-Id: I4c138c5c60fde217b6243627bd043194278835c2
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 9c2df261797259728845a04d5e47ddf36251f93d |
|
07-Oct-2011 |
Steven Ross <stross@google.com> |
Fixing alarm clock bug
The alarm clock doesn't actually hide the view until AFTER Facelock starts
hence the need to kill Facelock after it has started when the even is caught
Also fixing phone black box background in case the user cancels the call quickly
Also eliminating blackscreen after 4s for multiple reasons
so people can login if lockscreen locks up
also so cancel fade is to the backup lock
Change-Id: I8162ff67453038559f289408f4f0d452d4f79ab3
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 0c422a72edbbb0e259a123bd028eb264f5e3cd2c |
|
05-Oct-2011 |
Brian Colonna <bcolonna@google.com> |
Added callback for Face Unlock service to poke the wakelock
Change-Id: I76a4e0f8ac0fe17e39195f4593fac7e36d7281f0
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| dce0bb62ce4e1afbdacd2b4a8ee2e02a1563e852 |
|
05-Oct-2011 |
Steven Ross <stross@google.com> |
Killing Facelock when a phonecall comes in
This needs to actively listen for phonecall callbacks,
or calls that come in while Facelock is active will drop.
Change-Id: I818433e5de9085f0357f61d6a04b395e58871396
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 85b10b0dd0e568699f349ba500ddc8d3e6c1c12d |
|
05-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5317948: Don't display facelock when transport controls are showing.
Change-Id: I0061fa9ec184846b0ed82c977a2e48b36cb079af
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 58396984ef49080d5550919130fc0d869ccf840b |
|
30-Sep-2011 |
Danielle Millett <dmillett@google.com> |
Reworked biometric weak check functions
Renamed isBiometricEnabled to isBiometricWeakInstalled. This function
now checks if the system property is set, the facelock package is
installed, and if the phone has a front facing camera. It no longer
checks if facelock is currently set as the unlock method.
Added isBiometricWeakInstalled checks to all cases where facelock is used
in LockPatternKeyguardView
Change-Id: Ia86a7ad6118101c6aab90ffb2ee9c42bf2548149
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| b9a4b3c18aa0094bbbbc2858c765fb4aeafdee67 |
|
29-Sep-2011 |
Justin Ho <justinho@google.com> |
Fix lockscreen
Bug: 5391404
Change-Id: I021a37705b72ab1990f7651fecbe743a8af4e372
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| cfdd6242eb0c26373b9c57d2ad1ddc126708189e |
|
29-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5385186 - Face Unlock no longer shown when first booted
Face Unlock used to show on first boot via an onScreenTurnedOn()
callback. At some point something changed and this no longer gets
called at boot time. This left us in the state where the black box
was covering the backup method, but Face Unlock was not starting.
Instead of finding a new way to make Face Unlock start at boot, it
was decided that it is probably best for it not to start at boot
anyway. So much is happening at boot time, including camera
initialization, that trying to make this work right might cause more
problems than it solves.
This fix moves the code that makes the black box cover the backup
method. Instead of happening when the layout is originally created,
it now happens in the show() function, which gets called not only
when the screen is turned on, but also before the screen turns off,
such that it is ready to go when the screen turns back on. This not
only keeps the black box from displaying on boot (because show()
doesn't get called at boot time), but also makes sure the black box is
already there before the screen is turned on, preventing any glitches
that may briefly show the underlying backup method.
Change-Id: I99bdae561a70918b5f12ea5badff08b07d74403c
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 4284e9d19a3f917b85e5eac4d6e304fc9b866139 |
|
28-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Pulled out part of onScreenTurnedOn() into show() function
The onScreenTurnedOn() function in LockPatternKeyguardView was
actually being called in two cases - when the screen was turned on,
AND when the show() function was called in KeyguardViewManager, which
actually happens just before the screen is turned off. Face Unlock
functionality was added to the onScreenTurnedOn() function, not
expecting that the function was also being called just before the
screen turns off. This causes Face Unlock to run when the screen is
turned off, preventing it from running when the screen is turned on.
This was not obvious during testing because it's not a problem when
testing from the lock screen. To reproduce the problem you must log
in successfully, then turn the screen off, wait, and turn it back on.
The solution was to pull the non-face unlock functionality from
onScreenTurnedOn() into its own function called show(), which is
called from the KeyguardViewManager show() function and also called
from onScreenTurnedOn(). In this way, the onScreenTurnedOn()
functionality is not changed, but the show() function can be used
for the onScreenTurnedOn() functionality minus the Face Unlock stuff.
One exception to note - I left setting mScreenOn inside of
onScreenTurnedOn() and didn't pull it into show()...that seems like
the correct thing to do.
Change-Id: I9dcc144c7842112c4d35eb3f8b4ab1cd42c05675
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 267cb2b284626f910cf64352bfc494d0f8d3dc42 |
|
26-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Fix 5323545 - FaceLock no longer appears when taking a call
Prior to this fix if the screen was off and a call was received, the
onScreenTurnedOn() callback would bring up the FaceLock service,
which would cover the phone interface. It now requires the call state
to be CALL_STATE_IDLE to start FaceLock. When the phone interface
closes, the user is left at the backup lock screen. Bringing FaceLock
up after a call ends does not seem like the correct thing to do.
While working near the FaceLock callback code, the sleepDevice()
callback was removed because it is no longer used (Fix 5327896).
Some cleanup was also done with regards to KeyguardViewManager.
FaceLock calls were being made from the KeyguardViewManager in
onScreenTurnedOn() and onScreenTurnedOff() via an interface to
LockPatternKeyguardView. This level of indirection was removed
because it can just be handled inside of the corresponding calls
in LockPatternKeyguardView. Likewise the FaceLock functionality
inside of hide() in KeyguardViewManager is now in
onDetachedFromWindow() in LockPatternKeyguardView. Overall this
is much cleaner, especially considering interfacing through
KeyguardViewBase was a bit of a hack.
Patch Set 2:
- Now using KeyguardUpdateMonitor to get phone state
- Removed unnecessary wrapper functions for hiding / viewing
FaceLock area
- These were really only there because at one point I was calling
them from KeyguardViewManager and the naming was confusing
- Removed if(DEBUG) from a couple of log messages that are actually
warnings that shouldn't show up and I want to know if they happen
even if I don't have DEBUG set to true
Change-Id: Id7befc47dd421156ff6cdb3aaf62fc76fe9cfad2
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| eef1ae1d91d55341c25d01547ac9b952be5aa658 |
|
23-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
FaceLock is now closed if emergency dial button is pressed
Previously facelock would remain on top of the dial keypad until it
timed out.
Change-Id: Iaf1b3b0040fbfcb5c32e3db7b0466d2a6f89dc1d
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| cec857d85c838ed7253c64b84d5b1354be7595b1 |
|
21-Sep-2011 |
Adam Cohen <adamcohen@google.com> |
am 41298971: Merge "Fixing disappearing lock screen, issue 5319246" into ics-factoryrom
* commit '41298971c774a336257fff4a97ed5d5505bbfb60':
Fixing disappearing lock screen, issue 5319246
|
| 51e9d5c635b8882c1947122f1aa7e820d3a5f287 |
|
21-Sep-2011 |
Adam Cohen <adamcohen@google.com> |
Fixing disappearing lock screen, issue 5319246
Change-Id: Ia59ba6388775efc83aadf1e489b767be5624d385
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 68a8cf4a8e2829bc61c5f77cbb062a5ed143cd0a |
|
16-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Merge "Properly laying out FaceLock on lockscreen"
|
| 4d7cee1e4b9ed17da8fc041be80369eb525901f1 |
|
14-Sep-2011 |
Brian Colonna <bcolonna@google.com> |
Properly laying out FaceLock on lockscreen
- FaceLock area now specified in layout files instead of trying to
grab an existing view, which was only practical if pattern was
backup method
- Now fills area it is supposed to and works with pin as well as
pattern backup
- Backup method is no longer exposed behind FaceLock just before it
starts or just after it tells the lockscreen to unlock
- Added synchronized blocks so FaceLock cannot be told to stopUI by
two different threads at the same time
Change-Id: I3bfad6b44dbe0e3c2ea3c87d2978451c22a7484c
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 73da5fe0feda040b200aa60fff15024ec38d7edc |
|
13-Sep-2011 |
Danielle Millett <dmillett@google.com> |
isPasswordEnabled and isPatternEnabled return true if used as backup method
When facelock is enabled, isPasswordEnabled or isPatternEnabled will return true depending
on which one is set as the backup method. This is a cleaner way to handle things, rather than
specific cases for facelock in all the methods that call these functions.
Change-Id: Iacb802b89626dfc13f2306de1a2e622ca9b69427
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 6edf2637e96139735df83907c221cce16d4d7eaa |
|
06-Sep-2011 |
Jim Miller <jaggies@google.com> |
Fix 5185505: Add support for weak biometric sensors to lockscreen.
Added binder interfaces to the framework.
Change-Id: I7d55b45baa4d1600ebd2a3828e85c3357cfcfb58
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 62c3efd204acdf1f7bf3bde584e2a0dfd9ca046e |
|
03-Sep-2011 |
Jim Miller <jaggies@google.com> |
Fix 2679658: Be more aggressive about recreating lock screen.
In the past we were overly cautious about not recreating the lockscreen
under steady state conditions. However, that allowed lockscreen
to get into weird states where the screen orientation and the
loaded layout disagree. Once in this state, the user could not
recover because we would never reload the layout due to the fixed
orientation of lock screen.
This avoids the problem by being more aggressive about reloading
the layout. It now recreates the lockscreen (for reals) whenever
a view requests it via recreateMe().
In addition it serializes recreateMe() requests to ensure a pending
configuration change event has a chance to propagate and be handled
by the lockscreen looper.
Change-Id: I86a54abba899eb314f7cc8dbf6cbb98266bc548a
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 054340d0a3f242efeaf898cca38625bdcb3b4b5a |
|
02-Sep-2011 |
Jeff Sharkey <jsharkey@android.com> |
Show statusbar clock based on lockscreen status.
Keep track of lockscreen clock visibility, and only hide statusbar
clock when one is provided by lockscreen. This fixes bug where widget
would hide all clocks.
Bug: 5242065
Change-Id: I48de98ecb956c7f22bd40b54d771c78c1a80c14c
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 1c18828d20807342d37000746b18a3c1696f3b2e |
|
09-Aug-2011 |
Jim Miller <jaggies@google.com> |
Fix 5044158: Integrate music transport control into LockScreen
This integrates a new version of TransportControlView into LockScreen
and adds plumbing to handle new AudioService events to show/hide the view
and updates the required assets for all devices.
Updated to use new AudioManager API. Since the current API only supports
one RCD, the handler now lives in TransportControlView.
Change-Id: I220d4dd760bef35bd84209adc3c5829bf5bc9a2c
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 4ae8cb9e73b3b516434c9dc26fcc9697daff851d |
|
29-Aug-2011 |
Jim Miller <jaggies@google.com> |
Fix 5044158: Reduce overall memory footprint of lockscreen
On devices that do not require showing lock before unlock, we now only create
just the unlock screen. In addition to simplifying the code, this also
prevents keeping around a potentially unusued lock screen and saves ~1MB
in the system process on devices with only a secure lockscreen.
Change-Id: I533f2692b44a7991d4850cecc874c76166e7ce71
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 2e1db30d18a0ff6640bb0ad61f922ec1fdcf5a3c |
|
25-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Lock screen should be kept on while it is touch explored.
1. The lock screen goes off after a certain timeout but a blind
user performing touch exploration of that screen needs more
time to find controls and interact with them. Therfore, we
reset the lock timeout by poking the wake lock on the last
hover event so the lock timeout will start ticking after
the user has stopped interacting with the lock screen.
bug:5133879
Change-Id: I340d2a820e90f6fd63a45d65a5457ce6e570189c
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 67403e096e6f59b7cd18a90d0d3f5c3d17c31407 |
|
23-Aug-2011 |
Mathias Agopian <mathias@google.com> |
BLUR_BEHIND flag is not supported anymore
Bug: 5185650
Change-Id: I56541d4967b90b150a734be1bbeff696eb6a4fb3
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 4f36995777a4136e8e63ea51cef2ff61df48790d |
|
20-Aug-2011 |
Jim Miller <jaggies@google.com> |
Fix 5026428: Rework unlock attempt logic with active DPM to show better messages
Prior to this change, we didn't have a mechanism to warn the user when
they were approaching the wipe data threshold dictated by active DPMs.
Here's the new flow:
- If a device policy manager is installed and sets the max
password attempts, we start warning the user when they are within
a grace period of hitting the max (currently hard-wired to 5).
- We continue to show a dialog after each continued attempt
until the user reaches 0 remaining attempts.
- We now show a message when they hit 0 so they know why their device is
being reset. The device will reboot and wipe data shortly after this final
dialog is shown.
Also increased the criteria for a pattern attempt from 3 dots to 4 dots
since the user can never set a pattern less than 4 in length. This will
greatly reduce the likelihood of a false wipe on the pattern unlock screens
without compromising security.
Change-Id: I28825ef21dfa2e2b6540e743252c6d50c41e5ad7
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 2e4aa1888461426072f27217b8f9eb06f345bb9d |
|
28-Jun-2011 |
Jim Miller <jaggies@google.com> |
Fix 4691563: Don't show lock before unlock screen
- Rename config_enableSlidingTabFirst to config_enableLockBeforeUnlockScreen and
default to 'false' on all devices.
- Use new larger handle asset.
Change-Id: I2537158b67642eb3f4c4a22a0bc388bf3022d408
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| b0b24b3df50988d23f571b83d829fecc986ec497 |
|
11-Jun-2011 |
John Wang <johnwang@google.com> |
Support SIM permanently disabled state.
SIM card can get permanently disabled due to too many
PUK retries. The PERM_BLOCKED pin state of SIM application
represents this state.
This change decodes permanent disabled state and broadcasts it
via ICC_ABSENT intent with PERM_DISABLED reason. It also update
the lockscreen to show the prompt message.
bug:4392059
Change-Id: I5e60dd65f48f42aa2e54db4cdebf803d6e666b99
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 0f7b3f8ba5c2f0b8f96e072bd866c9fb374ebdeb |
|
31-May-2011 |
John Wang <johnwang@google.com> |
Add SIM PUK unlockscreen.
Puk unlockscreen is implemented as SimPukUnlockScreen.
Added config_enable_puk_unlock_screen to control the display of puk unlock screen.
Using config_voice_capable to control the display of emergency call button.
bug:4384956
Change-Id: I2b8256b4ecdf3d4f1e85c4e868fac1810cfd29be
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 4b8c9b740528301d3ca60fe3b4b861fcd85ceb0a |
|
01-Mar-2011 |
Dianne Hackborn <hackbod@android.com> |
am 7fff2d19: am 1de4a2ca: am 62619392: Merge "Fix leak when keylock is recreated."
* commit '7fff2d19a24f9f9b669676864dc5652ab179d2fc':
Fix leak when keylock is recreated.
|
| 1de4a2ca58df9bd21e054742f52e0af7a2ed5864 |
|
01-Mar-2011 |
Dianne Hackborn <hackbod@android.com> |
am 62619392: Merge "Fix leak when keylock is recreated."
* commit '626193926df0b3c7236e5c244f30d797d9192e0d':
Fix leak when keylock is recreated.
|
| 1e0c7ae184984051e8f42c71f89435fc1d40be35 |
|
10-Feb-2011 |
Kenneth Andersson <kenneth.andersson@sonyericsson.com> |
Fix leak when keylock is recreated.
DigitalClock could sometimes leak when the keylock was recreated.
This happened because onDetachedFromWindow() was called BEFORE
onAttachedFromWindow().
This is the flow that causes the memory leak:
1) The LockPatternKeyGuardView is created and added. This will start
a loop dispatching onAttachedToWindow() to all views involved.
2) PatternUnlockScreen.onAttachedToWindow() is called
3) If the configuration has changed since creation, recreateMe() in
LockPatternKeyguardView.java is called.
4) recreateScreens() is called
5) PatternUnlockScreen is removed (to be re-added later) in
LockPatternKeyguardView.recreateUnlockScreen()
6) Since DigitalClock is a part of PatternUnlockScreen, its
onDetachedFromWindow() will be called.
7) The loop started in 1) will continue to dispatch
onAttachedToWindow() - and will eventually call
DigitalClock.onAttachedToWindow()
8) DigitalClock.onAttachedToWindow() registers a receiver that is
normally unregistered in onDetachedFromWindow(). But since
onDetachedFromWindow was already called in 6), it will not be called
again.
9) The receiver has leaked, and it has a reference to DigitalClock,
so that will leak as well, together with its parents e.g.
PatternUnlockScreen and LockPatternKeyguardView
The fix is to wait with the recreation of the screens (in 4) until
the loop (in 1) is finished. This is done by posting this as an event
instead of calling recreateScreens() immediately.
It is possible that this a fix for the root cause mentioned in
"Fix 3106227: use WeakReferences for receivers in DigitalClock class"
8b886fab5496b0b1f5193f21855220176deddc37 by Jim Miller
<jaggies@google.com>.
Change-Id: I6a5f6f49a565d459bf4e285f34f053cc1022286f
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 3530ebe451fea39b159baa9b8c9f9cd851de42a3 |
|
17-Jan-2011 |
Jim Miller <jaggies@google.com> |
resolved conflicts for merge of 578e73da to honeycomb-plus-aosp
Change-Id: I334ae5382220a84881521885b6e3c3991fd8bbb0
|
| 8b886fab5496b0b1f5193f21855220176deddc37 |
|
14-Jan-2011 |
Jim Miller <jaggies@google.com> |
Fix 3106227: use WeakReferences for receivers in DigitalClock class
This works around a bug in the framework where LockScreen wouldn't
get GC'd under certain circumstances which would lead to an OOM
crash. It now uses WeakReferences for observers inside the
DigitalClock container class and unregisters them if the containing
DigitalClock goes away.
Also removed mLive variable which was unused and could potentially
leak the receivers.
Left mAttached for debugging so we can use it to determine if the
calls to onAttachToWindow() and onDetachFromWindow() are grossly
unbalanced which may be the root cause of the original problem.
Have cleanUp() explicitly clear unused references to make
tracing through hprof references easier.
Change-Id: I99a7e0c356001b05eab5aa729564553666febfea
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 8171b5182f5f07d33c9dfdf2dd8f0f6ae9588039 |
|
05-Aug-2010 |
Jae Yong Sung <jysung@google.com> |
lock screen for xlarge
Change-Id: Iab9f53609bf24be774752a9960aaaa654d7a614f
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 83ea9e395e86ca2d12d822609ca2a8b35b78cca9 |
|
16-Jun-2010 |
Brett Chabot <brettchabot@android.com> |
am 685fcf36: am c95812e6: Merge "Move out all framework-tests classes." into gingerbread
Merge commit '685fcf364b84d5ac911ae9cbbc4fec99f36cbd48'
* commit '685fcf364b84d5ac911ae9cbbc4fec99f36cbd48':
Move out all framework-tests classes.
|
| be81f4f15dad6d690efcab1973d1e174ce3b001b |
|
15-Jun-2010 |
Brett Chabot <brettchabot@android.com> |
Move out all framework-tests classes.
Previously tests/framework-tests contained a quarantined set of test classes
that needed access to package-private framework api. Running these tests
normally would cause the dalvik verifier to throw errors.
runtest now has support for turning off the dalvik verifier for frameworks
tests, so move this tests into their recommended location, close to the source
being tested.
Also move policy source into a 'src' folder to accommodate the tests move.
Change-Id: I62f839da185a55bc553b653bf583fd99da438512
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|