Rotation lock does not override NOSENSOR mode anymore.
Centralize the rotation policy settings into a new class shared by
the System UI and Settings applications.
Add a new setting to specify whether rotation-lock is being hidden
because the "auto-rotate screen" option has been toggled in the
Accessibility settings panel.
Bug: 6523269
Change-Id: I15173280d25bc5d101e89a9c65913aefc53fc33a
Define two integers in the platform configuration to
define the sound level for lock/unlock sounds, and
UI sound effects.
Use the corresponding value in KeyguardViewMediator for the lock sounds.
Use the corresponding value in AudioService when playing sound effects.
Bug 6448481
Change-Id: Ie238f5eb1645e395412864d93447ac4049f7e54b
This provides the means to replace the assist icon shown in keyguard and the
navigation gesture for assist. It's done by adding metadata called
"com.android.systemui.action_assist_icon" to the activity that handles
android.intent.action.ASSIST. It should point to a StateListDrawable
in that package with the required states. For example:
<meta-data android:name="com.android.systemui.action_assist_icon"
android:resource="@drawable/ic_android_systemui_action_assist" />
And then something like this in drawable/ic_android_systemui_action_assist.xml :
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:state_enabled="true"
android:state_active="false"
android:state_focused="false"
android:drawable="@drawable/ic_action_assist_normal" />
<item android:state_enabled="true"
android:state_active="true"
android:state_focused="false"
android:drawable="@drawable/ic_action_assist_activated" />
<item android:state_enabled="true"
android:state_active="false"
android:state_focused="true"
android:drawable="@drawable/ic_action_assist_focused" />
</selector>
Change-Id: Ibc29360e179fed68253ff06a07b1bb2b982d0dab
The computation moving the navbar up is too drastic when a device locked
in a portrait dock is connected to a landscape external display (e.g. a TV).
Instead, only do this if the aspect ratios of the device and external display
are the same.
Bug: 6513219
Change-Id: I7cfb1096b7d1a774032d22c4b0d7eb3177766c58
Squashed commit of the following:
commit c0969669a6bd55df805665c17e088456c1672da3
Author: Danielle Millett <dmillett@google.com>
Date: Wed May 30 15:41:22 2012 -0400
Turning liveliness back on
As part of the change of putting in the new head turn option, it's
now passing in the correct value to Face Unlock instead of forcing it
to always be false.
Change-Id: I745da5431cbc2d447f3d07ec7215c5b1850f6d57
Change-Id: I36a819b43e89a463bb3bb3ede0db36477fd45066
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
