| 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/KeyguardUpdateMonitor.java
|
| aa24906de299b392a3aa8576d3f0df77089f53c2 |
|
13-Jun-2012 |
Uriel Rodriguez <urodriguez@google.com> |
BUG 5457035: lowering max FUL failed attempts to 3
After an unrecognized face occurs 3 times in a row, we disable FUL until the user unlocks via the
backup lock. Lowering this values makes spoofing with liveliness enabled more difficult. Since
we currently don't differentiate between the max number attempts with and without liveliness
enabled, we had to lower it for all uses of FUL.
Change-Id: I7a429f64cde2767ddd2ceb0885343acd0b802aac
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java
|
| ffefd0fdd1baa66665ed6195b2adeb0e1e3bb7e4 |
|
14-May-2012 |
Brian Colonna <bcolonna@google.com> |
Fix 6283709: set max FUL failed attempts to 5
After an unrecognized face occurs 5 times in a row, we disable FUL
until the user unlocks via the backup lock. This prevents attacks
where someone tries a bunch of different photos, hoping for a good
enough match to the device's owner.
This value was previously set to 15, which is much higher than
necessary. This change sets it to 5. We've been holding off on
this change because it makes our testing more difficult, but we
want this in there for factory ROM this week.
Change-Id: I4e1acc5b1dcc2c0629e0c0fe97a837d6edc44d5d
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java
|
| c458ce98ce42c00b98afe00670f822814f3da572 |
|
30-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Add support for using the lid switch to turn off the screen.
Added a config option to allow the lid switch to turn off the
screen. This is a closer match to what a lid switch should be
doing.
Removed an old feature to bypass keyguard when keyboard is visible
because the way it was plumbed in made bad assumptions about
the meaning of the lid switch. Also, the last product we shipped
that had a physical keyboard turned this config option off.
So away it goes. We can bring it back someday if we really want it.
It's questionable how useful the feature is anyhow, since it only
works when the keyguard is unsecure and when the lid switch is
unlikely to be jostled in the user's pocket.
Fixed a bug where we would tell the power manager that the keyboard
was visible even if the lid switch did not control the keyboard.
This used to cause the power manager to try to set the keyboard
brightness, which doesn't work.
Bug: 6377115
Bug: 6406726
Change-Id: Ic84b71d09563d51c92cd1cf132fa8bdee6509103
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.java
|
| 0b92eb4b8c2cfd1230245e387424df19ae0535d9 |
|
12-Jan-2012 |
Jim Miller <jaggies@google.com> |
am 1aff11be: am 7a286d83: Merge "Fix 5620754: don\'t show pattern screen after SIM PUK unlock" into ics-mr1
* commit '1aff11be4585d6ddff784d7e74188963050805fa':
Fix 5620754: don't show pattern screen after SIM PUK unlock
|
| 28a0767751268601c4b8c208e4f8708ee2e88533 |
|
11-Jan-2012 |
Jim Miller <jaggies@google.com> |
Fix 5620754: don't show pattern screen after SIM PUK unlock
This fixes a bug introduced in testing 34a62348. The code now
properly invokes the callbacks before returning.
Change-Id: I637a8a792838379f0c8b42ef634da82787fcd961
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.java
|
| 90d5d46b9e1bfc2df1a4a16b411eafb43c80eba5 |
|
18-Nov-2011 |
Jim Miller <jaggies@google.com> |
Fix 5620754: don't show pattern screen after SIM PUK unlock
This fixes a bug where we would inadvertently show the pattern
screen after PUK-unlocking the device. Could potentially happen
after SIM unlock as well, but that path appears to be fast enough that
it's rarely seen.
The cause was not getting the SIM state change before deciding to show
the Unlock screen.
We now immediately invoke the callback if SIM/PUK unlock succeeds without
waiting for the round-trip from the radio layer.
Change-Id: I02dcb456da415b82f30f8e3abc43f788f3931b33
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java
|
| 16464b8e55020a4d77a8e5e4673db974e749dc82 |
|
21-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5369428: Use full battery state information when determining charge status
This is a fix for a bug where we'd show "connect charger" when the device was
connected but not charging due to the battery being in an unchargeable state
(too hot, cold, etc).
It now maintains a full copy of the battery state and uses the plugged status
to determine if the device is plugged in.
Change-Id: I60fa4e4566a45663b130f0ff4863bcc595ae3c4a
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.java
|
| 19fa262c52ddaf0e5ec200f4f7f21bda0d4b617b |
|
14-Oct-2011 |
Martijn Coenen <maco@google.com> |
Merge "Send ACTION_USER_PRESENT when provisioning is completed." into ics-mr0
|
| 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/KeyguardUpdateMonitor.java
|
| baa2812b377ec412f1b764463f20b8baad91b207 |
|
11-Oct-2011 |
Jim Miller <jaggies@google.com> |
Fix 5386408: Fix battery state information propagation in Lock Screen
This fixes a bug where Lock Screen would sometimes inappropriately show
"charged" if it took a while for Lock Screen to get an update on the
battery state. It now starts with the state set to BATTERY_STATUS_UNKNOWN
so we properly update listeners when we finally get battery information
in handleBatteryUpdate().
Change-Id: I71018a233f38b2f897ff2e6592d7e310550fa016
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.java
|
| 3f5f83b54fad4c797f5dbd75f050e4980e839122 |
|
27-Sep-2011 |
Jim Miller <jaggies@google.com> |
Fix 5326463: rework sim state handling in lockscreen
Previously it was possible to get an inconsistent state because there
were two paths that updated the lock screen sim state. This reworks
the data flow to ensure the same path is always used to update the state.
KeyguardUpdateMonitor now correctly updates the entire state of the callee
whenever a new callback is registered.
In addition, KeyguardUpdateMonitor now caches the phone state in order
to avoid a round-trip binder call in updateEmergencyCallButtonState().
This avoids a condition that could make lockscreen unresponsive while
updating the emergency call button state.
KeyguardStatusViewManager also ensures the TransportControlView is
hidden when created to ensure we don't inappropriately update the carrier
line while waiting for the first callbacks to update the status lines.
Change-Id: I6b3975b703a7d90bac8d0fe29fbc0f1d9c5e0e7d
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java
|
| 61e159504a49cd283fea1658beaa758a3d3e0a99 |
|
21-Sep-2011 |
John Wang <johnwang@google.com> |
Notify the sim state after callback registration.
Notify the register the current sim state right away in
registerSimStateCallback.Otherwise the register won't
receive any state until sim state gets changed again.
That will introduce a racing condition. If the sim state
changes to PUK_LOCKED after registering the callback, the
PUK unlock screen shows up. If the sim state changes to
PUK_LOCKED before registering, the PUK unlock screen won't
show.
bug:5243771
Change-Id: I27de1329a30adba68952cf086d2130c4cef54270
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.java
|
| f3447351f7571b5ab3c2a59832d9497bde4f6776 |
|
07-Aug-2011 |
Jim Miller <jaggies@google.com> |
Fix 5125978: remove lockscreen logspew
Change-Id: Iefa103e867e870dfe587271e0555404589d9e5b3
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java
|
| 6b05d58018c2806459c121e507c005639b74aee9 |
|
18-Jul-2011 |
Jim Miller <jaggies@google.com> |
Fix 5044158: Initial pass: add music transport controls to LockScreen
Refactored all lockscreen notifications to go through new KeyguardStatusViewManager.
This is required to intercept messages originally intended for separate TextViews that
are now shown in a single view when showing the transport control view.
Refactor EmergencyCallButton to be handled by common code in KeyguardStatusViewManager.
First pass at LockScreenWidgetCallback for LockScreen "widgets" to send events back to LockScreen.
First pass at LockScreenWidgetInterface, which will be required of Views that want to be rendered on
LockScreen.
Added place-holder TransportControlView until the real one is ready and integrated it into GridLayouts.
Ensured emergencyCallButton is in all views, even if not shown since some devices may lock the user
out if certain criteria isn't met (missing SIM, etc).
Refactored layouts and removed keyguard_screen_status*.xml since layouts are all over the map and
no longer make good use of a shared layout for this.
Minor tweak to MultiWaveView to fix layout issues when placed in GridLayout where the measurement
was being calculated improperly.
Moved EmergencyCallButton to bottom of view where we can.
Removed unused Alpha keyboards from tablet password unlock layouts.
Removed unused views (status2, emergencyCallText screenLocked) from layouts and made common views have common names.
Fixed bug with MultiWave layout in landscape where array was shown in wrong orientation.
Separated clock colors for phones/tablets since they're now different.
Converted remaining phone layouts to use GridLayout.
Start routing audiomanager events to lockscreen views.
Move emergency call button handling to KeyguardStatusViewManager.
Change-Id: I480b0346cfe19aad316fea0c0aaabf8862693636
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.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/KeyguardUpdateMonitor.java
|
| 79a444a0cd78bc6528e19336a0d49ef4a17b263c |
|
16-Feb-2011 |
Jim Miller <jaggies@google.com> |
Fix 3391330: Use BATTERY_STATUS_FULL as "Charged" state
Some devices that use LiPo batteries do not charge them to 100%
as a safety margin and to preserve battery longevity. This change
allows KeyguardUpdateMonitor to determine when the battery state should be
reported as "Charged", provided the device sets BATTERY_STATUS_FULL in
that case.
Manual merge of Change-Id: Iac6cb78e24f9a696017459cc773c38ef7fe7779f
Change-Id: I15c316a17108c064bf2c7e657ca908f8767be936
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java
|
| b92e18e2dfa4f5b791a53b9c963cf2b9e1f1f25c |
|
27-Jan-2011 |
Jim Miller <jaggies@google.com> |
Fix 3388705: Explicitly check for low battery level
This fixes a bug in StatusView believed to be caused by
seeing "invalid charger" update from BatteryService.
The code normally relies on "interesting events", as determined
by KeyguardUpdateMonitor. I believe something else is
triggering an update (perhaps a SimStateChanged event) that updates
the status without also updating StatusView.mShowingBatteryInfo
and mPluggedIn.
The safer way to do this is to explicitly check the battery
level before telling the user the device needs to be charged.
Change-Id: Ic39ed86c78a157dc9fbdef4d76a9c3db39ccafca
/frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardUpdateMonitor.java
|
| 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/KeyguardUpdateMonitor.java
|