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
Leaky singleton bug! GlobalActions, recents, and the
keyguard are all in the same process and therefore receive
the same StatusBarManager instance. Therefore, their calls
to enable() and disable() clobber one another.
Bug: 5423182
Change-Id: I724d17dfc5289141690560cc8ff83cc8543b25b1
The PhoneWindowManager is now responsible for hiding and showing
the nav bar.
For hiding, it just moves it off the screen (easy way to get a
nice slide animation on and off). At the same time, we use a
new WM facility to put up a fake input window to capture all
touch events.
When a touch event is received, we force the system UI to clear
the navigation hiding bit so it will be shown again.
This removes a bunch of code from the system UI for hiding and
showing the nav bar. Also removes the code calling from userActivity()
to the system UI, which was bad. (Also no longer using userActivity()
fixes bugs around re-showing the nav bar due to key presses and
other wrong things.)
Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
This fixes a bug where the state wasn't being updated because it wasn't
registered for KeyguardUpdateMonitor state changes when the view first created, like on first boot.
Change-Id: Ic6838afffd0de51decdc43a8e8a796696aed49df
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
This cleans up how ui flags are managed between the client and window manager.
It still reports the global UI mode state to the callback, but we now only clear
certain flags when the system goes out of a state (currently this just means the
hide nav bar mode), and don't corrupt other flags in the application when the
global state changes.
Also introduces a sequence number between the app and window manager, to avoid
using bad old data coming from the app during these transitions.
Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
This needs to actively listen for phonecall callbacks,
or calls that come in while Facelock is active will drop.
Change-Id: I818433e5de9085f0357f61d6a04b395e58871396
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
Multiple focusable windows cause undesired behavior around selection
modes. TextView isn't sure how to behave when it loses window focus
with regard to selection handles and action modes need to be focusable
for WebView find on page since it uses an EditText as a custom view.
For now:
* Use a layered window decor for overlay action mode when there is no
action bar requested. This eliminates an extra window and avoids the
issue described for full-screen UIs.
* Disable WebView's find-on-page mode when the action mode's UI will
not be focusable. This only affects WebViews in floating windows.
Also remove the "Text Selection" title for WebView's selection mode at
UX's request, as it is inconsistent with TextView's selection mode and
the string does not fit on phones in portrait even on wide
devices. This now uses the same mechanism used in TextView to decide
whether to use title text.
Change-Id: I80caeecea9b47728cf26bb0a388153ca0bdeafe1
Actual volume is a ratio of the ringer volume and drops along with
but slower than the ringer volume, so that at lowest ringer volume,
the lockscreen sounds are still somewhat audible.
Don't start the sounds if the ringer is muted.
Bug: 5394473
Change-Id: Ifcf242b3198b4ec8f12334e26ec23ebf05a96b83
The lock screen was using Ringtone for the lock/unlock sounds, which
meant two new MediaPlayers were created every time a sound needed to
be played. In addition, the Ringtone was assigned to a local variable,
which means it could go be garbage collected and finalized while it
was still playing.
For short sounds that need to be played repeatedly, SoundPool is a
better option anyway, so use that instead.
b/5382634
Change-Id: I8794cbb24604fa7c03032bd5e32ceab37a858054
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
Action bars in dialogs are largely an undocumented "feature" but they
do work - with the exception of this since it previously relied on the
host being an Activity. Make it work.
Change-Id: I52ae24c3bfdd9766e4c0f035183e7f148a4e0162
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
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
This allows kiosk/demos to be given in portrait mode. Set with:
adb shell setprop persist.demo.hdmirotation portrait
Change-Id: Ic0c858dcf6329ca34180f582d4869539dde8f69b
Signed-off-by: Erik Gilling <konkers@android.com>
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
Bug: 4981385
Changed the orientation listener to notify the policy whenever
its proposed orientation changes, and changes the window manager
to notify the orientation listener when the actual orientation
changes. This allows us to better handle the case where the
policy has rejected a given proposal at one time (because the
current application forced orientation) but might choose
to accept the same proposal at another time.
It's important that the proposal always be up to date. A proposal
becomes irrelevant as soon as the phone posture changes such
that we can no longer determine the orientation with confidence
(such as when a device is placed flat on a table).
Simplified the orientation filtering. Now we just wait 200ms
for the device to be still before issuing a proposal. The idea
is that if the device is moving around a lot, we assume that
the device is being picked up or put down or otherwise in
the process of being moved. We don't want to change the rotation
until that's all settled down. However, we do want to tolerate
a certain amount of environmental noise.
(The previous confidence algorithm was also designed along
these lines but it was less direct about waiting for things
to settle. Instead it simply made orientation changes take
longer than usual while unsettled, but the extra delay was often
too much or too little. This one should be easier to tune.)
Change-Id: I09e6befea1f0994b6b15d424f3182859c0d9a530
change
Let action bars move between split/unsplit mode on configuration
changes if set to split when narrow.
Change-Id: I13f5115a65247cb1878ee823493ca8e2b6ba4cf6
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
After pressing forgot pattern and entering credentials, it used to
bring you to the screen to choose a new pattern. Now you are brought
to the screen to choose any unlock method. The reason for this change
is that both Pattern and FaceLock are valid possibilities when a
pattern is forgotten since FaceLock can use a pattern as a backup
method.
Change-Id: Ide28a780771a50952e72c3c06e1f71cbcb48f834
Theme.Holo.Light.DarkActionBar gets black text
Make sure that menus generated for use in action bars get themed correctly.
Change-Id: I14ba676d296c785514425d40d89e62dc4ff1da1a
