Moved some duplicate code from SearchPanelView and LockScreen
over to SearchManager to avoid creating yet another copy of it
in PhoneWindowManager.
Bug: 6594275
Change-Id: Ib4ebcd6817639d17548952ab2ce7cb876c05777c
Previously, it was observed that while a SIM is being initialized
by the hardware the SIM may briefly be reported as being in an
ABSENT state before eventually transitioning into a READY,
PIN_REQUIRED, PUK_REQUIRED, PERM_DISABLE state.
While booting up, the phone might observe that the SIM is ABSENT and
therefore bypass the keyguard going straight to the home screen.
Later when the SIM was fully initialized, the phone would revert back
to the lock screen in order to ask for the PIN. The user might
turn on the phone, slide out the keyboard (bypassing the keyguard),
then a few moments later the keyguard would pop up prompting for a PIN.
The user experience could be somewhat jarring, so the keyguard was
changed to handle the transient case differently. While the SIM
was ABSENT, the keyguard would not be automatically bypassed
by opening the keyboard slider. Thus the user would be forced to
manually swipe away the keyguard before interacting with the
device. This would help to cover the time it would take before
the SIM was fully initialized and the keyguard could determine
whether the user would need to be prompted for a SIM PIN or PUK.
To prevent the keyguard from being bypassed automatically, we
hacked up the keyguard so that it would be considered to be in a
secure state while the SIM was ABSENT. It's worth noting that
considering the keyguard to be secure did not confer any
additional security properties to the system whatsoever.
If the user did not have a pattern lock, PIN or password set then
all it would take to access the phone is to swipe away the keyguard.
This old hack was all about devices with slide-out keyboards,
but it had some side-effects. Namely, it assumed that the SIM
ABSENT state was transient. But what about phones that are
being used without a SIM at all?
Considering the keyguard to be secure when the SIM is ABSENT
breaks stuff. In fact, it turns out that making the keyguard
secure isn't really what we want at all. What we want is a way
to prevent the keyguard from being automatically bypassed on
boot when the user opens up a sliding keyboard. But we don't
have those anymore... and in the worst case it was just a little
janky... and what's more, nowadays the keyguard provides useful
features so maybe we shouldn't bypass it anyhow... oh and actually,
I deleted the code that used to bypass the keyguard when the
keyboard slider was opened... so this does nothing useful at all.
Right...
This change removes the old hack thereby ensuring that non-secure
keyguard features like launching the Camera or Assistant or
application features like hands-free voice search will work
correctly on phones without a SIM.
Bug: 6022658
Change-Id: I019d1d8c65c55cbf4d10d4928e1d2b2b242162a6
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
If FUL was turned off while the error message was displayed it would
not count as a failed attempt. This commit changes the
reportFailedAttempt callback to just report the failure rather than
report the failure and close. This allows the FUL service to send the
reportFailedAttempt message earlier and then later close using the
existing cancel function, which closes without reporting a failed
attempt.
Change-Id: Ib3b76f477a98b149fcccc32ac39ecaeccd88a7e2
Rotation lock does not override NOSENSOR mode anymore.
Centralize the rotation policy settings into a new class shared by
the System UI and Settings applications.
Add a new setting to specify whether rotation-lock is being hidden
because the "auto-rotate screen" option has been toggled in the
Accessibility settings panel.
Bug: 6523269
Change-Id: I15173280d25bc5d101e89a9c65913aefc53fc33a
Define two integers in the platform configuration to
define the sound level for lock/unlock sounds, and
UI sound effects.
Use the corresponding value in KeyguardViewMediator for the lock sounds.
Use the corresponding value in AudioService when playing sound effects.
Bug 6448481
Change-Id: Ie238f5eb1645e395412864d93447ac4049f7e54b
This provides the means to replace the assist icon shown in keyguard and the
navigation gesture for assist. It's done by adding metadata called
"com.android.systemui.action_assist_icon" to the activity that handles
android.intent.action.ASSIST. It should point to a StateListDrawable
in that package with the required states. For example:
<meta-data android:name="com.android.systemui.action_assist_icon"
android:resource="@drawable/ic_android_systemui_action_assist" />
And then something like this in drawable/ic_android_systemui_action_assist.xml :
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:state_enabled="true"
android:state_active="false"
android:state_focused="false"
android:drawable="@drawable/ic_action_assist_normal" />
<item android:state_enabled="true"
android:state_active="true"
android:state_focused="false"
android:drawable="@drawable/ic_action_assist_activated" />
<item android:state_enabled="true"
android:state_active="false"
android:state_focused="true"
android:drawable="@drawable/ic_action_assist_focused" />
</selector>
Change-Id: Ibc29360e179fed68253ff06a07b1bb2b982d0dab
The computation moving the navbar up is too drastic when a device locked
in a portrait dock is connected to a landscape external display (e.g. a TV).
Instead, only do this if the aspect ratios of the device and external display
are the same.
Bug: 6513219
Change-Id: I7cfb1096b7d1a774032d22c4b0d7eb3177766c58
Squashed commit of the following:
commit c0969669a6bd55df805665c17e088456c1672da3
Author: Danielle Millett <dmillett@google.com>
Date: Wed May 30 15:41:22 2012 -0400
Turning liveliness back on
As part of the change of putting in the new head turn option, it's
now passing in the correct value to Face Unlock instead of forcing it
to always be false.
Change-Id: I745da5431cbc2d447f3d07ec7215c5b1850f6d57
Change-Id: I36a819b43e89a463bb3bb3ede0db36477fd45066
Bug: 6524432
Show power menu on all devices by default. Specific devices will be disabled in overlays.
Handle airplane mode changes differently when the telephony states are not reliable.
Use simple toggle for silent mode when there's no vibrator.
Change-Id: Ic5ef521eee19cd300d909250203ff204f3a1ae1e
Send a message to all windows to redraw before notifying
PhoneWindowManager of screen on. This minimizes the delay in
screen update that causes the keyguard clock to display the old time
before displaying the current time.
Fixes bug 6381021.
Change-Id: Ida7071e7dac2284540f101c5d004511b52133b91
Do not create a StartingWindow for apps that show wallpaper.
Fix handling of obscure case where found wallpaper is hidden.
Fixes bug 6484034.
Change-Id: I07181c4aea56fa9e530df0c95d886fe8ad61ec9d
This change add a feature to reveal the swipe to search interface
when the home key is pressed for longer than 50ms. It progressively
reveals the interface. It still requires a bit of tuning, but all
the basic parameters are in this CL.
Change-Id: I1d3a5bb7b912265eb41da68bc9313eee1af2e415
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
Also show a notification when an external keyboard is connected
and does not have a keyboard layout selected yet.
Bug: 6405203
Change-Id: Id0ac6d83b3b381f8a236b2244a04c9acb203db3c
Some apps can get into a case where the saved view hierarchy states
for action bar views are missing. Log a warning instead of crashing.
Bug 6510800
Change-Id: I95ede64ec584892e6e76ca9ab9d53e9d3689984f
