Do not enter silent mode when ALARM stream volume is changed
to 0 by volume down key: Only RING, NOTIFICATION and MUSIC
streams control silent mode.
Report correct volume (0) for NOTIFICATION stream when silent mode
is entered by changing NOTIFICATION stream volume to 0 with
volume down key.
Change-Id: I3e0816dfae40bc127cc30cca02cdca6ec19e30a4
The latest change in silent/vibrate mode selection via volume keys
was such that ringtone volume was not showing 0 when entering vibrate mode
by continuous press on vol down.
Issue 5530217.
Change-Id: I9ba817648e5dca40e0d19f5f606d7763ae61b1c6
In order to completely mute the ringer (no vibrate), introduce an extra
state beyond mute, which mutes the vibrator as well, if it was enabled.
Bug: 5530217
Change-Id: Ib1f299ee6bbca56c1aa7e1100662591362d08307
Make sure that ring or notification volume index
never reaches 0 unless in silent mode.
Conversely, enter silent mode when this volume is set to 0.
Change-Id: Iff5e5e972b607f4736e7a704b26b2dadb40074b0
Add a mechanism for AudioService to notify audio framework and audio HAL
that screen is turned on or off. This indication can be used by lower
audio layers to trigger low power audio playback mode.
Current implementaiton based on setParameters() method is experimental
and will be replaced by a different interface when ready.
Change-Id: Ie72ada0a8edec3d71b47681b9f51cb5bc839d45b
Extend RemoteControlClient class description with an example
of instance creation showing how the PendingIntent is created
and how it uses the same ComponentName as the one used
in AudioManager.registerMediaButtonEventReceiver()
Change-Id: I1af61ddbf5cfb9160ea5b814bed7b881d51b7eff
Extend RemoteControlClient class description with an example
of instance creation showing how the PendingIntent is created
and how it uses the same ComponentName as the one used
in AudioManager.registerMediaButtonEventReceiver()
Change-Id: If8f050f94b112f9680ba6bf32ba622bc648fb1d0
This partially reverts commit e47e8520fa48bd014287eda94ea39927de73d6bc.
(the other part of that change was already removed as part of a different
change)
Change-Id: Ica7c196ab1f74f96237e64d07580832f0d50022f
When a IRemoteControlClient dies, that client is set to null
in the stack of remote control entries (mRCStack). This is done
by calling registerRemoteControlClient() with a null client.
The bug is that registerRemoteControlClient(), after storing
the new client, uses it to let it know what the current
remote control display is. When that display is non null, the
client is sent the current display. So when a client died
when there was a display, the client reference was accessed
in the part of the method where we haven't yet checked whether
it is null or not.
The fix consists in moving the setting of the display on the
client (method plugRemoteControlDisplay) only after having
checked that the client is non-null.
Change-Id: Ic74d6cba9e3a3a16e78cd80a1ae5901abfeb3905
We need to hold a wakelock while playing the keyguard lock sound,
so that it actually completes before the CPU goes to sleep.
Change-Id: I144c345383afeb911ea461b2eb17b31183b6d092
Store the time at which a RemoteControlClient changes it playback
state, and send that time to the IRemoteControlDisplay.
This change will enable displays to implement strategies such as
timeouts (e.g. to not display transport controls for clients which have
been paused or stopped for a certain amount of time).
Change-Id: I902882500565743d455d56f6000efaf612cbe0a9
Update the implementation of the RemoteControlClient / Display
feature rely on PendingIntent as provided in the construction
of the RemoteControlClient instance.
The ComponentName that describes the target of the media button
events is set as the target of the Intent from which
a PendingIntent is constructed.
This ComponentName is still saved in the stack for persisting
the last media button event receiver.
This CL also updates the lockscreen IRemoteControlDisplay
implementation to use the PendingIntent supplied by the
application when sending transport control events. A (good)
side effect of doing this is that intent will be directly
targeted at the application.
Restoration of the media button event receiver
after reboot is not fully functional yet.
Change-Id: I2be82f2839e9dee1de02512437b3fb41cc386cde
When applying the new bitmap from the editor to the client,
recycle the old bitmap, and set the reference to the editor
bitmap to null.
Change-Id: I7d79e4b8410e5035fa51b20be4b1ada391c84c28
Do not identify the SCO connection client by the binder interface
passed when starting the connection as this binder changes if the
AudioManager proxy changes. Use the client PID instead.
This solves an issue with gTalk starting a SCO connection from one
AudioManager proxy and then changing audio mode from another thus
terminating the previously started SCO connection.
Change-Id: Ia3067fecc551fc15df3bf75ce0c43d181859e4f0
API change so RemoteControlClient is given a PendingIntent in
its constructor, which will be used for receiving media button
events from remote controls.
Leave the old constructors (but hidden) to not break
current functionality until the AudioManager and AudioService
implementations have been updated.
Change-Id: Ifa12c8036c948931adc386a827dce2936788e1cd
The Metadata class doesn't actually seem to be used with anything
in the SDK, and the API probably needs some work, so hide it.
Change-Id: Ifecf49130b90cbb4c588ad8104f1e7957978f789
The problem is that any app can change the audio mode and override
a mode previously set by another app. If two apps (gTalk and Phone) compete
for audio mode ownership, there is no mechanism to maintain coherency
in the actual audio mode selected.
Added a mechanism in AudioService to manage an audio mode request stack.
Any app requesting a mode different from NORMAL enters at the top of the stack
and the requested mode is applied. When an app sets mode back to NORMAL, it exits
the stack and the new mode corresponding to the request at the top of the
stack (if any) is applied.
Change-Id: I68d1755d0922f680df4a19bfc5ab924f5a5d8ccd
