Added a config option to allow the lid switch to turn off the
screen. This is a closer match to what a lid switch should be
doing.
Removed an old feature to bypass keyguard when keyboard is visible
because the way it was plumbed in made bad assumptions about
the meaning of the lid switch. Also, the last product we shipped
that had a physical keyboard turned this config option off.
So away it goes. We can bring it back someday if we really want it.
It's questionable how useful the feature is anyhow, since it only
works when the keyguard is unsecure and when the lid switch is
unlikely to be jostled in the user's pocket.
Fixed a bug where we would tell the power manager that the keyboard
was visible even if the lid switch did not control the keyboard.
This used to cause the power manager to try to set the keyboard
brightness, which doesn't work.
Bug: 6377115
Bug: 6406726
Change-Id: Ic84b71d09563d51c92cd1cf132fa8bdee6509103
This will be used to determine which parts of a window a completely
hidden by system UI elements (status bar, nav bar, system bar) so
that they can be clipped out from rendering.
Change-Id: I2c6c6ac67dbdfeed82d2c089ef806fb483165bd9
If turning the power off while FUL was closing (due to a timeout or a
cancel for example), it would be possible for unbind() to get called
twice due to a race condition. Turning the phone off calls unbind()
from the UI thread, while the other close comes from a binder thread
since it is coming from the service.
PATCH SET 1 attempted to solve the problem by adding a lock, but
having a lock around the bind is a bit scary.
PATCH SET 2 takes a new approach by having all calls coming from a
binder thread to be sent as messages to be handled on the UI thread.
Having all events occur on the UI thread removes the possibility of
race conditions and makes the code stronger by making everything
happen in a deterministic order.
This commit also cleans up the logcat logging a bit. A couple of the
log messages are now printing without DEBUG being set to true. This
is by no means spamming the log and they of course are only logged
when FUL is being used. But it serves to give us some meaningful
information from bug reports that are currently showing nothing. The
statements that are now logged would have made this particular bug
easy to track down.
Change-Id: I25a65c0808d88cb941439e5bf1f989dba8608be4
Implement a more consistent policy for system and UI sounds (key clicks, lock/unlock,
camera shutter, DTMF, low battery...):
- All system sounds are played over STREAM_SYSTEM stream type.
- The STREAM_SYSTEM volume that was previously fixed now tracks the volume of a "master"
stream type. This "master" stream type is STREAM_RING for phones and STREAM_MUSIC for
tablets which corresponds to the stream whose volume is modified by default by the volume
keys.
- The STREAM_SYSTEM volume ranges from -24dB to -6dB (-24dB to -12dB over headphones) when the
"master" stream volume ranges from its min to its max.
- DTMF tones are played over STREAM_DTMF that tracks the "master" stream volume in the same
manner with the following exception: when in call, DTMF stream tracks STREAM_VOICE_CALL volume.
- Camera shutter sound is played over STREAM_SYSTEM_ENFORCED stream that tracks the "master"
stream volume except in countries where regulation enforces this sound. In this case
its volume is fixed and cannot be muted.
- Low battery sound is played over STREAM_SYSTEM and therefore has a tunable volume and is
heard while in call.
Issue 6344620.
Issue 6069229.
Issue 6213100.
Change-Id: I53a237878ead596e706c5dbbb1420e62cde32bd7
This cleans up the biometric sensor interface - the interface between
lockscreen and Face Unlock. Not only does it document the interface,
but it also makes two noteworthy changes to the interface:
1) Instead of calling mBiometricUnlock.start() with a parameter to
tell it whether to suppress itself, lockscreen makes all of the
decisions about whether the biometric unlock should be started or not
and only calls start() if it should be started. Passing a parmeter to
tell a function to not start itself was strange, but it was a
necessary intermediate step in the process of fixing this interface.
2) Instead of calling mBiometricUnlock.initializeView() with a top
view that the biometric unlock should attach to, lockscreen now
provides the biometric unlock with the actual view it is allowed to
work in. This keeps lockscreen in control of where the biometric
sensor is allowed to display.
A few things were also cleaned up within the Face Unlock
implementation of the biometric interface:
1) Changes needed to match the requirements of the improved biometric
sensor interface, including moving the functions into an order that
makes more sense.
2) The bind() function was only being called from start(), which has
turned into only a couple of lines of code, so the bind() code has
been just put inline into the start() function, which mirrors the
stop() function which has the unbind() code in it.
3) The showArea() function was really just one line of code with a
check. It was being called from two places. The showArea() code is
now just written inline in those two places, which makes the code
much easier to follow.
4) Renamed occurrences of FaceLock to Face Unlock.
Change-Id: Ie95ce21dcc77170381af9ce320f2675dfe249741
...has no cross-activity transition
We apparently no longer want to skip the activity transition when
it is starting from behind the status bar.
Change-Id: I1feb0cf0303f8b89d9089b38b217eac440382059
Devices between 600 and 719dp will now use the two-bar
(phone) SystemUI layout, or something like it, derived from
PhoneStatusBar. Devices above 720dp will use the system bar
from TabletStatusBar.
However, this distinction is not to be made based on dp, at
least, not by the SystemUI; the goal is to drive most of
this switch from the window manager. Therefore most of
SystemUI's sw600dp resources have been folded into the main
set of resources (renaming them to avoid collisions where
appropriate). This allows SystemUI to choose which set of
resources to use entirely by switching status bar
components, entirely independent of Configuration.
(For some resources, particularly around recents, it seemed
more expeditious to keep relying on the device
configuration, so those resources have been bumped up to
sw720dp.)
Bug: 6297838
Change-Id: I3f5414a6a718bdc83f51930d6878cdf97df48c9c
This change moves all of the mBiometricUnlock.installedAndSelected()
checks from inside the biometric sensor implementation to
LockPatternKeyguardView. There are several reasons for this change:
1) Instead of constructing a BiometricUnlock object and asking it if
it's enabled, LPKV can check this for itself and not even bother
constructing it if it's not enabled.
2) Since mBiometricUnlock will not be constructed if biometric unlock
isn't enabled, LPKV can simply do null checks to see if it should call
biometric unlock functions. So it serves the dual-purpose of ensuring
there will be no null-pointer exceptions with regards to using the
biometric unlock.
3) This greatly reduces the chance of bugs being introduced into
non-biometric unlock methods because no biometric unlock calls will be
attempted if biometric unlock is not enabled. Previously, the calls
would be made and then the biometric unlock would check if it was
enabled and return, which was not only bug-prone, but also
inefficient.
4) This simplifies the biometric unlock interface by removing an
unnecessary function call.
5) The biometric unlock implementations do not have to check if they
are installed every time they do something, which greatly cleans up
biometric unlock implementations. It makes much more sense for the
biometric unlock functions to be able to assume that they aren't
being called unless they should be.
6) Eventually when there is more than one possible biometric unlock
method, it will make much more sense for LPKV to be in charge of
what is constructed and what isn't.
Change-Id: I5437ac05d8ceb2b182fe372cd6c75ad944ade28f
The onRefreshBatteryInfo() function hides the biometric sensor area so
the biometric sensor isn't shown when the screen turns on during a
plug/unplug. However, sometimes the function is called when there
is no plug/unplug. This fix makes it only hide the biometric sensor
area (thus exposing the backup lock) on plug/unplug.
Note that this does not fix b/5465535 although it may help reduce its
frequency.
Change-Id: Iccff382c23d71257593dc1595ed8fec57adaf5bd
These now do something reasonable when performing transitions
across two activities that are both on top of the wallpaper.
Fixed computation of the pivot point of the animations.
Fixed issue where the recents panel was considered a status
bar element for purposes of deciding if the animating elements
are obscured by the status bar, which would result in us not
running the animation correctly.
Change-Id: I4b9b588b80243463e6f087a9703ee886ee281630
Sets the view to visible directly on the UI thread when feasible
this includes all cases where FaceUnlock is bound.
The delay in processing a message was causing the bug.
This additionally replaces the call in the keyguardview show
with one when the facelockareaview is initialized.
Change-Id: I8511f175d68023372e11d6e76fa1c44df6ac8a3d
Moved the core logic of Vibrator into SystemVibrator, potentially
allowing for the creation of other Vibrator subclasses.
Fixed several places where we were creating new Vibrator
instances unnecessarily instead of getting it from the Context.
It is safe to make Vibrator abstract because its constructor
was hidden from the SDK so it was not possible to subclass it.
Bug: 6334179
Change-Id: I18ece6544c26a7efb2d5099f8346a10aef8a5e18
Tell the activity manager when the lock screen is shown, so it
can keep itself (mostly) in sleep mode during this time, having
the foreground actvities remain in their stopped state.
Change-Id: I71c86d3298f23a98014d7ae36fd540c9df9a64e6
We now have an animation to apply to the thing behind the lock
screen animation when it isn't on the wallpaper, which looks
similar to the animation we use when both are on the wallpaper.
In implementing this, cleaned up the code to figure out up-front
which animation to run, getting rid of that kludgy thing that
cleared the window animation if the wallpaper was not being used
for the lower windows.
Change-Id: Ifc4c8a8894ad384124dcf4bbdaab134f1157b0f3
This is another step toward fix 5460649 - cleanup
LockPatternKeyguardView (LPKV).
After this change, LPKV has minimal knowledge of FUL. FUL now
implements a new BiometricSensorUnlock interface and LPKV talks to
that interface. Other biometric sensors can implement the same
interface such that LPKV doesn't need to know much about what type
of biometric sensor is being used or its implementation.
The new interface has better, more general function names, so some
function names in FaceUnlock.java were changed. Some of the functions
in FaceUnlock.java were also reordered to match the interface.
This change should not change the behavior of FUL. There are two
places where code functionality was changed:
1) There was a showArea() function and a showAreaWithTimeout()
function that were both called from LPKV. To simplify the interface,
only a show() function is provided - it takes a timeout and if the
timeout is 0 it doesn't do the timeout.
2) There was a stopIfRunning() function that did a check to make sure
FUL was running. If FUL was running, it stopped FUL. Then it
returned a boolean indicating if it had been running. LPKV sometimes
needs to know if FUL was running so it knows if it should restart FUL.
To simplify the interface, a single stop() function is provided which
returns whether or not it was running. I believe the 'if running'
check was redundant and that there was no case where calling stop()
when it wasn't running would cause any badness.
Change-Id: I717268f360aed823e603df8e687cd107aa69ae11
When FUL was enabled and the power was turned off from the lockscreen,
either manually or by timing out, the lockscreen would turn back on
and FUL would start.
I believe this is due to a recently-added 'force' flag, which this
commit removes.
Change-Id: I314125fe52afe1536ab5a4600f39f563e1d58991
Because a lid switch can be used to do many things, it's best
if the framework does not do anything by default when the lid is
opened or closed. The behavior of the lid switch should be
configured on a per-product basis in a config.xml resource overlay.
Bug: 6320088
Change-Id: I9f768dd11d76c3c17c49f46c92f993ee2ff1409f
Unlike the nav bar, it only uses a fixed size for determining
how to layout elements around it; it lets the status bar window
itself be whatever size it wants.
Change-Id: Id04278981ab38915280a47368fccc7ec14bb97ec
When switching users, bind to the correct instance of FaceLock.
Tried to get the facelock screen to show up when switching users, but it
doesn't. Power off/on works, but not switching between users on the
lockscreen. Maybe a timing issue? Or not calling some function to make
the overlay visible?
Change-Id: I9300971331c7f0ed93ae7da28170342629426b20
Because of changes in support of multi-user functionaity, the FUL
'eye blink' checkbox was no longer enabling liveliness detection.
It no longer makes sense to check the biometric flags (such as the
liveliness flag) inside of the Face Unlock service. Instead, that
flag is now passed in from lockscreen via the aidl interface when
startUi is called.
Change-Id: I591cf1924fbb24da7d54b94ef29824e5197d3b20
Rather than normal Activities (which have a host of problems
when used for this purpose), screen savers are now a
special kind of Service that can add views to its own
special window (TYPE_DREAM, in the SCREENSAVER layer).
Dreams are now launched by the power manager; whenever it is
about to turn the screen off, it asks the window manager if
it wants to run a screen saver instead. (http://b/5677408)
Also, the new config_enableDreams bool allows the entire
feature to be switched on or off in one place. It is
currently switched off (and the APIs are all @hidden).
Change-Id: Idfe9d430568471d15f4b463cb70586a899a331f7
This is the first step toward fix 5460649. All of the FUL functions
were pulled out of LockPatternKeyguardView into their own FaceUnlock
class. LockPatternKeyguardView now has an mFaceUnlock member, which
is new'd inside of the LockPatternKeyguardView constructor, passing
it some objects it needs to do FUL. FUL calls are now made from
LockPatternKeyguardView by doing mFaceUnlock.foo(). Some of the
function names were reduced to avoid redundancy (e.g.
mFaceUnlock.start() instead of mFaceUnlock.startFaceLock()).
This change is just a refactoring and is not intended to change
any functionality. There will be other cleanups in the near
future...this is basically just the minimum changes needed to get
the FUL functionality into its own class.
Change-Id: I7dc5b22857bbf1659238b0e2d113069f7bf9ffe7
Soon we'll switch this threshold to 720dp, once the
PhoneStatusBar is ready to support 600dp wide devices. For
now, however, restore the previous behavior.
Bug: 6300512
Change-Id: Ibedb8ffc1b677e3bbe9af230598adb7db278635b
Simplified input injection API down to just one call.
Removed all input state reading API. It was only used by the
window manager policy and required a permission that applications
could not obtain. READ_INPUT_STATE is now unused and deprecated.
Change-Id: I41278141586ddee9468cae0fb59ff0dced6cbc00
The status bar now extends behind the nav bar, and uses
fitsSystemWindows to ensure its content is not covered. We
always report a stable content insets (as if the nav bar is
visible) even if the nav bar is hidden, so the content doesn't
jump when transitioing. This does mean that if you only hide
the nav bar (and not the status bar), when in landscape you
will end up with a status bar whose right side still leaves
room for the nav bar. But why the hell would you want to do
that?
Also improve documentation on setSystemUiVisibility().
Change-Id: I8087d875f1214ef0085a91b5ed5c2f35ff2fc1b3
Extracted the input system from the window manager service into
a new input manager service. This will make it easier to
offer new input-related features to applications.
Cleaned up the input manager service JNI layer somewhat to get rid
of all of the unnecessary checks for whether the input manager
had been initialized. Simplified the callback layer as well.
Change-Id: I3175d01307aed1420780d3c093d2694b41edf66e
Move all lockscreen related settings to LockSettingsService.
LockPatternUtils uses this through IPC instead of Secure settings.
Migrate old settings to new database managed by LockSettingsService.
Passwords and patterns are stored in a new per-user location, except
for the primary user, for backward compatibility.
KeyguardViewMediator and LockPatternKeyguardView listen for changes
to user and updates the lockscreen.
Settings provider will look for Lock settings in the LockSettings
service now for the entries that used to be stored in Settings.
Change-Id: I956cd5b95e2d9d45a6401af7e270e6a5aa2dcc98
The status bar and navigation bar are two completely separate
elements, with their own semantics. The system bar now classifies
itself as a navigation bar, since that is really how it behaves.
This required rewriting the HDMI resizing code, so that it is
all done by PhoneWindowManager since that is what is responsible
for the size of the navigation bar (and thus now system bar). This
actually gets rid of a fair amount of code, and means we can also
do the same thing for a pure navigation bar.
Likewise the system bar now has the navigation bar ability to be
hidden when requested by system UI flags. To get the behavior
we want on Xoom, we only allow the nav bar to be hidden when it
will help provide a better aspect ratio for showing widescreen
videos.
Finally the nav/system bar now animates when hidden and shown.
Change-Id: Ie927154b68376a0b61802f99171ff56b8da92e7a
