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
Fix for bug 6446715
Fix a deserialization bug which was causing an assertion failure in
stagefright and bringing down the entire media server. Basically, you
will hit this any time you play a track longer than ~2147 seconds.
(Technically, the crash will happen any time the play pointer at a
position which is ~2147 * (1 * 2N) where N >= 0)
Change-Id: Ic0d371b0f6c29fddf0a033f5de08a70b3e63c854
Add the dialog behavior for MediaRouteActionProvider/MediaRouteButton.
Still TODO:
* Switch audio icon based on source; speaker/bt/user
* Rig up volume slider
* Rig up item icons
* Rig up group button for groupable categories
* Make grouping work
Change-Id: I3f992516b184d5ae940ddb7bbb7f94ff58914589
Bug: 6656538
Due to the WebView/WebViewClassic refactor we need to call
WebView.performLongClick instead of performLongClick directly
to allow subclasses to override performLongClick
Change-Id: I9b580217fbafc82d03e63eabfdda9f5bad98db0f
