After the bind to the FUL service is complete, an
onServiceConnected() callback is received. This callback is
asynchronous - bindService() does not block while we are waiting for
the service to finish binding. Therefore, when rapidly turning the
screen on and off, it is possible to call bindService() and then call
unbindService() before the onServiceConnected() callback is received.
When onServiceConnected() is received, startUi() is called. If the
service is no longer bound, a runtime restart occurs when calling
startUi().
Note that onServiceConnected() actually has its work done via a
handler. The delay of calling the handler increases the possibility
of unbindService() being called before trying to call startUi(). But
since this problem still happens without using the handler,
eliminating using the handler would not solve the problem and would
just create the problems that come with performing operations on
different threads since onServiceConnected() is not called on the main
thread.
Also note that a new instance of FaceUnlock is created in
LockPatternKeyguardView with each iteration. So, if we bind/stop/bind
before getting onServiceConnected(), the second bind happens in a new
instance of FaceUnlock and therefore does not lead to a problem when
onServiceConnected() returns as a result of the first bind.
This fixes some occurrences of bug 6409767. However, this fixes the
problem when turned the device on and off rapidly. It seems there
are some reports of bug 6409767 where this is not the case, so I
can't be sure this has any affect on those cases.
This change also cleans up some debugging and modifies other
debugging to try to get just the information that is useful for
tracking down the bug.
Change-Id: Ifa59107b9974acaa8a18b74b5d47e4cf3a794b8e
When using stable layouts, you are typically expected to hide and
show the status bar through the system UI fullscreen flag. This hides
both the status bar and the action bar. The stable layout assumed
that when not hiding the status bar through the system UI flags, that
the status bar would be visible.
This change makes things a little smarter, also looking at the
window's fullscreen flag (which only hides the status bar). If this
flag is set on the window, then the stable layout now assumes that
the status bar will never be shown. This allows us to position the
action bar correctly in the situation where the application has set
the window to fullscreen and requested a stable layout, instead of
always leaving room for the status bar above it.
Change-Id: I757072ae99cd3741753af7210dbf51afe94d3db5
Ensure that the shown panel view is not currently attached to a parent
before adding it to the panel decor view.
Bug 6430928
Change-Id: Ic64ec4222db4754e64afdf06d7d2b77fb5ef825a
This is part of the change to remove the blink checkbox. Since the
blink checkbox won't be visible anymore, we want to set liveliness to
off instead of checking the current value.
Change-Id: Iaa68cea8ec0a6012eaaaac77cea0f50575b7e660
After an unrecognized face occurs 5 times in a row, we disable FUL
until the user unlocks via the backup lock. This prevents attacks
where someone tries a bunch of different photos, hoping for a good
enough match to the device's owner.
This value was previously set to 15, which is much higher than
necessary. This change sets it to 5. We've been holding off on
this change because it makes our testing more difficult, but we
want this in there for factory ROM this week.
Change-Id: I4e1acc5b1dcc2c0629e0c0fe97a837d6edc44d5d
The biometric unlock initializeView() function is called every time
the lockscreen is recreated. Since this normally happens when the
device turns off, initializeView() was covering the backup lock so the
backup lock is not exposed when the device turns back on. However,
initializeView() is also called when lockscreen is recreated due to an
orientation change.
With this change, the show() call to cover the backup lock has been
moved out of initializeView(), and the backup lock is now only covered
when the screen is turning off, preventing the backup lock from being
covered on an orientation change.
This also includes changes to prevent biometric unlock function calls
from occurring when SIM or Account unlock is in use. In fact, in any
situation where we know FUL won't be used, we don't even construct it.
This is not only more efficient, but it also cuts down on the
possibility of errors where FUL is being used when it shouldn't be.
Change-Id: Ie97761840df8de5701703d9b9b991726fb601064
The window manager now performs the crop internally, evaluating
it every animation from, to be able to update it along with
the surface position.
Change-Id: I960a2161b9defb6fba4840fa35aee4e411c39b32
This refactoring sets the stage for a follow-on change that
will make use additional functions of the power HAL.
Moved functionality from android.os.Power into PowerManagerService.
None of these functions make sense being called outside of the
system server. Moving them to the PowerManagerService makes it
easier to ensure that the power HAL is initialized exactly once.
Similarly, moved ShutdownThread out of the policy package and into
the services package where it can tie into the PowerManagerService
as needed.
Bug: 6435382
Change-Id: I958241bb124fb4410d96f5d5eb00ed68d60b29e5
This fixes a rare crash that could happen when the device orientation
changes while the handle is held over a target. LockScreen.cleanUp()
was being called which set mCallback to null which then causes it
to crash in MultiWaveViewMethods.onTrigger().
The solution is to also remove OnTriggerListeners in LockScreen.cleanup().
Change-Id: I487c7c9dbbe40417e685b39f2e79b1c43b30fa00
This change allows more flexibility in target placement in MultiWaveView.
It now supports a new way of specifying chevron drawables that allows
them to be moved in directions corresponding to more than the four basic
directions (right, up, left, down).
Chevron drawables can now be updated in an overlay.
This change also adds a place holder and makes a minor tweak to the layout
on 720dp devices where the navbar buttons weren't centered.
Change-Id: Icd319ec5f276870380e27737c873e78f599ff751
Changed the pokeWakelock() call back to take one argument - the duration to stay awake in ms. This
change was needed in order to poke the wakelock for the duration of the watchdog timeout. This
must be done in the service because the duration of the watchdog timeout is unknown at this point.
Moved pokeWakelock() from start() to handleServiceConnected() to make sure that this poke happens
before the poke in the service. This poke is still needed to account for when devices are rotated.
Change-Id: I19d62df1489514de0588ebb937678358e70ffc95
If a fallback key is generated using a key plus a modifier,
then it's possible we might get a different fallback key
generated if the modifier has changed. PhoneWindowManager
needs to remember which fallback is last generated for a
given key code so that it can apply the same fallback action.
When generating cancellation events, it's important to have
preserved the policyFlags of the original event. Otherwise
we may not dispatch the cancellation properly. For example,
some actions are not performed if the POLICY_FLAG_TRUSTED
is not specified.
Remember the metaState associated with a key event so we can
include it when canceled.
Tell the policy when a fallback is being cancelled so that it
can clean up its state.
After a SEARCH shortcut is invoked, clear the flag indicating
that a shortcut is pending. This is to prevent SEARCH from
getting stuck down in the case where we might forget to send
the up. (Shouldn't happen anymore after the prior fixes.)
Bug: 5616255
Change-Id: I68f0a9679c7af464eaf31c099f2aa50b53fecf1f
There are three functions in FaceUnlock.java that have the requirement
that they are to be called on the UI thread. I added checks to log
an error if they are ever called off of the UI thread.
Change-Id: I581968e8138b7561b7ad75a1ac6945bf218e2bcf
Clean up related to new Vibration policy.
The vibrate behavior is now only derived from:
- presence of a vibrator on the device
- current ringer mode selected: NORMAL, VIBRATE or SILENT
If no vibrator is present the ringer mode can only be NORMAL or SILENT.
The control of ringer mode via volume keys when volume keys control the "master"
stream type (RING on phones, MUSIC on tablets) is as follows:
If a vibrator is present:
VOL- and volume equals 1: NORMAL => VIBRATE
VOL- and volume equals 0 and not continuous press: VIBRATE => SILENT
VOL+ and in SILENT mode: SILENT => VIBRATE
VOL+ and in VIBRATE mode: VIBRATE => NORMAL, volume = 1
If no vibrator is present:
VOL- and volume equals 0 and not continuous press: NORMAL => SILENT
VOL+ and in SILENT mode: SILENT => NORMAL, volume = 0
VIBRATE_ON and VIBRATE_IN_SILENT settings are not stored/retreived any more.
AudioService checks and corrects ringer mode and stream volumes if necessary when reading from
DB at boot time.
Also:
Added dump for stream volumes in AudioService.
Added device names missing in AudioSystem for USB accessory and USB device.
Issue: 6036529
Issue: 6414950
Issue: 6448163
Change-Id: I77fb821ec63e4e566320cac2701b4ac466e86aef
This fixes several layout issues on phones and tablets with MultiWaveView.
It adds a new background scrim to be shown behind the MultiWaveView
on the navigation bar.
MultiWaveView is updated to handle gravity constraints which makes layouts
much more flexible across devices.
Change-Id: I64068f4eaa81ef6c464247049117d53432fcacbd
activities
Bug 6413342
Clear extra attributes in the base theme so that they properly overlay
a ContextThemeWrapper over a fixed-size dialog theme.
Change-Id: Ia0d49f0746ca01516afa1eaea7091e5da60d14ae
Inform user "Unusable SIM card." when SIM is permanently disabled
due to too many wrong PUK inputs.
bug:5548405
Change-Id: Id82c7681f58f09709c630b4bc455facb549938ed
The window manager policy made some incorrect assumptions about the
meaning of the Configuration.keyboard field. We need to be more
careful about distinguishing between built-in and external keyboards.
Most of this change is to move the determination of the parts of
the Configuration related to input devices into the WindowManagerService
leveraging new features of the InputManagerService to good effect.
Then we plumb through the flag that indicates whether a device
is internal or external so that we can be more particular about
how the lid switch effects changes to the Configuration.
Bug: 6424373
Change-Id: I36a1c22ade35e578955465a25940a33f227b9763
