This fixes a bug where the forgot pattern button wasn't working because
the logic for face unlock was interfering with determining the proper
backup to use.
The fix:
- adds a new state to SecurityMode so we have an initial condition
we can check for.
- passes the current mode to SecurityModel.getBackupSecurityMode() so
it relies on the current state.
- prevents face unlock from invoking callbacks that change state
once we're no longer showing face unlock.
Fixes bug 7346989
Change-Id: I4e64515efbbad712f11c820e690b458f352bf46c
Add Keyguard to list of windows that can't be hidden by keyguard.
Don't assign Configuration to window until layout has had a chance
to compare it to window's existing Configuration.
Bug: 7094175
Change-Id: I99a9fd4af9a31871fe130db7b6bdf49bd51a6092
-> Recovery button should only appear if account present
-> Recovery button should appear at bottom
-> Account view should have emergency call button
-> Account view should not show the clock / status area
Change-Id: Id12e8219f3fc6ecb14e82c5ec6ea4b3e28ed772d
-> Dealt with this NPE, and guarded against all related NPEs (which probably
can't happen, but given the stakes of a system crash, this is safer).
Change-Id: I3c207839ae0279033b6f3dad791d710b19415439
Now that we have a single stage unlock, there's no need for the transition. This
was causing unnecessary flickering to happen in views where we add the security view
just after inflation, which triggers the animation.
Fixes bug 7343632
Change-Id: I5bb8e37df66e4d96f00719e318424d46bf0e2e5a
-> When an unimportant message is set, we need to clear the security string
so that battery / owner info takes precedence at that point.
Change-Id: I3f86b0c2cc8fb2fb0023fce77a7725d8ada96d9e
Fix a bug where ordering during inflation caused us not to set a
keyguard callback early enough to properly modify window flags. Add a
gross hack to work around this for now.
Fix status layouts to scale a bit more gracefully in the presence of
an IME.
Fix password layouts to scale more gracefully in the presence of an
IME
Bug 7343312
Bug 7341795
Bug 7342963
Bug 7343089
Change-Id: Ifb2c06defef11e8f7f9d0e09855632ed491bb31c
Now that there isn't a swipe before launching face unlock, face unlock
needs to be suppressed during a phone call. If it isn't it will popup
on top of the phone call screen.
Change-Id: Id6c4165bf4df606ebf396c151f1c80603d5abca3
The code really shouldn't select the page until after the view has been
removed and had a chance to measure itself. The fix is to post a message
to select the correct widget page.
Bug 7334209
Change-Id: I5c2d59b00b3c502893da6000154ce6cdc79ecc1c
When we defer making the screen visible (waiting for the lock screen
to be ready) the screen may actually be on but covered by a black
surface. We need to make sure to ignore any touches on the screen
during this time until the black surface is about to be removed.
Bug: 7318962
Change-Id: I50eb7dcf05295cd276925625240996c4b80c5fe2
This change integrates the finalized tablet layouts for keyguard. It supports
both 7" and 10" tablets and makes some minor tweaks on phones.
Bug 7094419
Change-Id: I7b683382974de509e8045210544ea959db82e72d
1. If the global gesture to enable accessibility is enabled there should
be a haptic or auditory feedback after the global actions dialog pops up
as a result of a long press on power. On devices with no vibrator an
attempt to vibrate was performed evne if not hardware support exists
As a result no sound was played because the it was assumed a haptic
feedback was provided.
bug:7324903
Change-Id: Ic76db232d761a2899c1ca5f59ca55ff15ae575dd
The bug cropped up again. Need these statements to pin it down.
This reverts commit f1f3b49b949af72692f7f85a1c1ef220e8630e30
Change-Id: Ie0548232daff32ee2541249b0950e23bd98c08d2
Check the status of Settings.Secure.USER_SETUP_COMPLETE for the current
user when showing the keyguard, disabling the Camera + Search touchpoints
entirely until the user makes it through the setup wizard.
Bug:7308791
Change-Id: Ic8e3596582c2aefc7fe15af1824ed6bfd541dffa
If the user was in the middle of a phone call and went to the lock screen
it would show a black box with an X, but Face Unlock wouldn't pop up and
the X was unresponsive.
There were a few issues causing this. The X on the default view wasn't a
button, so it has been changed to a button which will go to the backup
lock. The concept of show() and hide() in FaceUnlock.java are obsolete
because Face Unlock is no longer being overlayed on top of the backup so
there's isn't a black box to show or hide. In addition, since it's not being
overlayed, Face Unlock doesn't cover the backup lock so fading to the backup
looks janky. The flip animation is more appropriate.
Change-Id: I730aa4bbce42b4656ee1bce61352b8aefbd6892d
When switching users, Face Unlock starts in onResume(). However,
there is no signal to indicate when the user actually sees their
unlock screen. This means Face Unlock could be running unseen, timing
out soon after it becomes visible, or letting the user in before they
see the preview.
This fix simply suppresses Face Unlock immediately after switching
users. This is not the ideal behavior, but there is no easy way to
make Face Unlock start only after the unlock screen becomes visible.
When the user changes screens it becomes unsuppressed, so if they go
back to the multi-select widget screen or login, Face Unlock works as
expected and is only suppressed again when the user is switched.
Change-Id: I80a302b0aefc1dee3c2dc77557978cbe062de435
This fixes an issue where the music transport hangs around indefinitely.
It used to get dismissed when music stopped playing and a notification came in.
This was due to a bug in JB.
Now that the bug is fixed, the music control hangs around indefinitely until
the application actually releases it.
Since we have widget support, we can now leave the transport control in place
for as long as it's possible to resume music (state = playing | paused).
If music is playing, we start with the trasport showing
If not, and multi-user is enabled for more than one user, we show the user switcher.
Otherwise, we show the clock.
Bug 7290707
Change-Id: I6f0553a64b7b66bac7b35eca6d8a8793c15b918c
When Face Unlock failed the maximum number of times (3), it was asking
for account login when it should have been asking for the backup lock
that the user chose when setting up Face Unlock.
This change splits the isBiometricUnlockEnabled() function into two.
One of them strictly checks whether it exists and is selected. The
other one checks whether too many attempts have occurred. When
deciding which backup to choose, the decision is now based only on
whether Face Unlock is enabled. Checking whether too many attempts
had occurred caused the bug because the check indicated it had already
'fallen back' to pattern, and the backup for pattern was being
selected instead of the backup for biometric unlock.
Change-Id: I6b9cf2c5155e8c14933cbfc8f5d58ebc007e53cb
The final iteration of that change was a little too aggresive in
deciding when it turns off the dream's enter animation, so it was
doing this always instead of just when it needed to (when it is
being displayed to hide the lock screen).
This change fixes a dumb typo that was causing the dream to always
turn off its own animation (duh!) and tweaks the logic for deciding
when the dream should be able to cause the lock screen to hide to
better ensure that it is shown before the lock screen gets hidden.
Change-Id: Ie73a5be9ee597713644fb2a0202f36c32b4f1fca
