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
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
Be more explicit about initialization -- power manager never sends
screen update when first initializing, phone window manager retreives
current screen state and applies that itself when initializing.
Change-Id: I8294ed36d700e186c1637754df8c8183721c15dd
1. Make Pin and Puk focusable EditText.
2. Add hint text for pin and puk.
3. Update focusEntry logic.
bug:5243771
Change-Id: I65bd52510bbbf0ebd7830ecac7e31159ae750c6c
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
