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
InputManager#getSwitchState() returns AKEY_STATE_UP(0=OPEN)
and AKEY_STATE_DOWN(1=CLOSE).
mLidOpen is opposite from a real lid status.
Change-Id: I40aa4e0defb95d82b6144ff6b7514f721bf9030f
Uses a static to keep track whether this is the first pass through the lockscreen
This will be true from when the process is instantiated until the lockscreen
is constructed for the first time, and then false afterwards.
When it is true, we suppress the biometric unlock (Face Unlock).
This avoids the problem of unpredictable and slow startup behavior for Face Unlock
on the first unlock after boot.
Change-Id: I70033af17ba3163d5fe07fc58096f01afaaaafd0
AudioService maintains a stack of registered media button event
receivers.
This change modifies the broadcasters of ACTION_MEDIA_BUTTON intents
let AudioService directly handle the corresponding key event instead
of trapping the intent sent by PhoneWindowManager, KeyguardViewBase
and PhoneFallbackEventHandler.
Because the key event may be sent through a PendingIntent,
AudioService now also implements the OnFinished interface to be
notified when the event was consumed so it can release the wake
lock held if it was held when the key event needed to be sent
(see where PassHeadsetKey was instanciated in PhoneWindowManager).
Change-Id: I2e8614df94af9d54edbf714ef443cc372d21827a
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
