| 7664c0e99d2ee70ad714b904a166b17ac7efdf9f |
|
09-Jan-2012 |
Brian Colonna <bcolonna@google.com> |
DO NOT MERGE cherry-picked FU framework tablet commits
- 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
/frameworks/base/policy/src/com/android/internal/policy/impl/LockPatternKeyguardView.java
|
| 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
|
| 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
|
| 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
|