AudioService is currently notified of wired headset and A2DP
sink connection states via broadcast intents from WiredAccessoryObserver
and BluetoothA2dpService. This is a problem as there is no guaranty that
AudioService can take actions upon the change before other apps are notified.
For instance, the Play On feature requires the UI to be refreshed when a device
is inserted/removed and we must guaranty that the UI component can read
new A2DP enable state from AudioManager after it receives a device connection state
change intent.
- Added hidden methods to AudioManager so that WiredAccessoryObserver
and BluetoothA2dpService can notify AudioService of device connection directly.
- The wired accessories connection intents are now sent by AudioService.
- The A2DP state change intent is delayed by BluetoothA2DPService when
ACTION_AUDIO_BECOMING_NOISY is sent by AudioService
- ACTION_AUDIO_BECOMING_NOISY intent is not sent when disconnecting A2DP
while a wired headset is present and vice versa.
Bug 6485897.
Change-Id: Ie160b3ee5f451132065530772b868593c90afd94
Two types of USB audio devices are defined:
- USB audio device: the audio device in USB device mode while
the Android device is in USB host mode.
- USB audio accessory: the audio device in USB host mode while
the Android device is in USB device mode.
Renamed intents for analog and digital docks to avoid confusion:
- ACTION_USB_ANLG_HEADSET_PLUG to ACTION_ANALOG_AUDIO_DOCK_PLUG
- ACTION_USB_DGTL_HEADSET_PLUG to ACTION_DIGITAL_AUDIO_DOCK_PLUG
Factorized code in AudioService broadcast receiver.
Change-Id: I1b6d0257a9d68ecb9495c78c98bac8c67fec7891
commit 5e64321e broke the headset detection on stingray.
This is because the name passed with the UEvent upon headset insertion/removal is
different from the dev path (h2w). It actually indicates the type of headset connected.
The fix consists in using the dev path received with the UEvent to find the corresponding
entry in uEventInfo.
Change-Id: I8481cfa17a7af3c8f5d83fc87d0f7c0d2c981098
A new switch was introduced in AndroidAtHome to deal with a race
condition between the WiredAccessoryObserver and the HW composer HAL.
When the new switch ("hdmi_audio") is present, we want to pay
attention to it instead of paying attention to the old switch
("hdmi"). This change checks at startup for the presence or absence
of the new switch and uses it if available, otherwise it falls back on
classic behavior.
see change ID I960cfc2f3e8df5342e7248a26fd313fdad2ca322 for the kernel
side changes.
see bug 6023647 for a discussion of the issue.
Change-Id: I009e443f25662e7beb233e892ca71034b05ebfc2
Signed-off-by: John Grossman <johngro@google.com>
HDMI audio hotplug is treated as a "headset" in the audio services. When a headset is unplugged,
WiredAccessoryObserver sends an AUDIO_BECOMING_NOISY broadcast so that applications can take
appropriate action (e.g. pausing audio if headphones were unplugged).
However, on Tungsten, when you unplug HDMI audio, the Music2 service was getting the NOISY intent
and pausing the transmitter media player. We could add Tungsten-specific code to Music2 to
disable this behavior, but it's probably better to disable this broadcast entirely because
applications on Tungsten probably shouldn't treat HDMI hotplug in the same way they treat
headphone hotplug on phones.
Fixed bug in WiredAccessoryObserver preventing correct detection of
docks with digital audio connection (S/PDIF)
Change-Id: I96eeebc53952625d75133ce0af68f4f219bce41d
In the init loop, when all the accessories are detected the
state of previous accessory is overridden by the state of the
next accessory. Adding the one line change keeps the state of
all the detected accessories intact.
Change-Id: I4347d8daa27800426dcfb23aac199bed4add67de
Signed-off-by: Praveen Bharathi <pbharathi@motorola.com>
