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
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
