Bug: 6524432
Show power menu on all devices by default. Specific devices will be disabled in overlays.
Handle airplane mode changes differently when the telephony states are not reliable.
Use simple toggle for silent mode when there's no vibrator.
Change-Id: Ic5ef521eee19cd300d909250203ff204f3a1ae1e
Send a message to all windows to redraw before notifying
PhoneWindowManager of screen on. This minimizes the delay in
screen update that causes the keyguard clock to display the old time
before displaying the current time.
Fixes bug 6381021.
Change-Id: Ida7071e7dac2284540f101c5d004511b52133b91
Do not create a StartingWindow for apps that show wallpaper.
Fix handling of obscure case where found wallpaper is hidden.
Fixes bug 6484034.
Change-Id: I07181c4aea56fa9e530df0c95d886fe8ad61ec9d
This change add a feature to reveal the swipe to search interface
when the home key is pressed for longer than 50ms. It progressively
reveals the interface. It still requires a bit of tuning, but all
the basic parameters are in this CL.
Change-Id: I1d3a5bb7b912265eb41da68bc9313eee1af2e415
Moved the check to suppress face unlock if a call is in progress from
onScreenTurnedOff() to initializeBiometricUnlockView(). onScreenTurnedOff()
is only called if the screen was turned off while on lockscreen and we
actually want to be doing this every time the screen is turned off. Put a
check around it to only do it when the screen is off, so that for orientation
changes, or on first boot it doesn't override the current flag value.
This fixes the following 2 bugs:
Bug 6460309: When making a phone call, after the user hangs up and it goes
to lockscreen we don't want face unlock to show. In the case where a
user makes an outgoing call and the phone goes to sleep by itself during
the phone call, when the call is ended face unlock was popping up because
it never went through onScreenTurnedOff().
There is a flag to make sure face unlock doesn't come up
immediately after booting the phone, which is done by not showing
face unlock the first time lockscreen is constructed. But there are
a few cases where lockscreen doesn't come up immediately after boot: 1. When
the device is factory reset, it goes through the wizard instead of
lockscreen. 2. In userdebug if the lock type is set to none.
In both of these cases, if face unlock is set up, it doesn't show up on
the first time. Setting the phone flag in initializeBiometricUnlockView
overrides the initial setting, which is what we want because if the screen
has turned off, it isn't the initial lockscreen after boot.
Change-Id: Iacafc515f2b594e12c853308c40cd48f3fb83e63
Also show a notification when an external keyboard is connected
and does not have a keyboard layout selected yet.
Bug: 6405203
Change-Id: Id0ac6d83b3b381f8a236b2244a04c9acb203db3c
Some apps can get into a case where the saved view hierarchy states
for action bar views are missing. Log a warning instead of crashing.
Bug 6510800
Change-Id: I95ede64ec584892e6e76ca9ab9d53e9d3689984f
Removing the code that delays a surface destruction when
WindowManager.FLAG_KEEP_SURFACE_WHILE_ANIMATING is set. The lock
screen that continued to animate after destroySurfaceLocked is no
longer used and this code was causing problems.
Also mDrawState was being set to NO_SURFACE in destroySurfaceLocked
even if the surface ended up not being destroyed. Later when it was
reused the false value of mDrawState was messing things up.
The screen lock bug referenced below no longer levaes the user stuck
with a black lockscreen. However it occasionally powers back up in the
launcher screen rather than the lock screen.
Fixes bug 6485955.
Change-Id: I684104c7e7c39c161a5118aa890889fbae92e635
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
