* changes:
Audio: use preferred device for strategy for communication route
AudioManager: Add communication device management APIs
AudioService: refactor communication route control
MediaRourter uses main thread for internal operations, and ANR could
happens if AudioService is not running when MediaRouter tried to get
BT A2DP status. This CL avoids such ANR by getting the info using
BroadcastReceiver insteead of AudioService.
Bug: 170327593
Test: manually
Change-Id: If9eba19481fceb0c86ff0117e8a604b64d7ebc49
Replaced use of forced usage for communication by set preferred device
for strategy to control communication route in audio policy manager.
Also do not use forced usage for record which was redundant with forced
usage for communication.
Bug: 161358428
Test: audio smoke tests
Change-Id: I665257fc5903b663096104b0424781d9799635a5
Merged-In: I665257fc5903b663096104b0424781d9799635a5
Add new APIs to manage the audio device used for communication
use cases (Cellular calls, VoIP and Video calls).
These APIs are meant to replace specific APIs like setSpeakerPhoneOn()
and provide a single generic way of configuring the audio device selected
for calls.
They will be used for newly added device types (e.g. BLE audio) instead
of adding new specific APIs.
They will also offer more options like for instance allowing to select the
earpiece (handset) device when a wired headset is connected.
The new APIs are:
- boolean setDeviceForCommunication(AudioDeviceInfo)
- void clearDeviceForCommunication()
- AudioDeviceInfo getDeviceForCommunication()
A listener is also added for applications to monitor current communication
device selection:
- OnCommunicationDeviceChangedListener
As well as listener registration and unregistration APIs:
- addOnCommunicationDeviceChangedListener()
- removeOnCommunicationDeviceChangedListener()
Bug: 161358428
Test: make && atest AudioCommunicationDeviceTest
Change-Id: I8028d842e4a8ca1abe0f87d03e3c5d57c46b9362
Merged-In: I8028d842e4a8ca1abe0f87d03e3c5d57c46b9362
Audio routing for communication use cases (cell, video and VoIP calls)
is controlled by separate APIs: setSpeakerPhoneOn(), startBluetoothSco()
and stopBluetoothSco().
Requests for speakerphone and bluetooth are managed by separate client
stacks although in the end they control a single routing state in audio
policy manager, which creates problems in case of conflicting requests
and race conditions.
This CL refactors the implementation by regrouping the Bluetooth Sco and
Speaker client stacks into a single one. This makes sure that no
conflicting routing request exist for a given client.
It also makes handling of race conditions and prioritization between
clients easier.
Finally, it prepares the introduction of a new API that will be the
single entry point for communication route control.
Also in this CL:
- Option to enable more debug log for communication route
- Fixes in BtHelper.receiveBtEvent()
1) Fix intent broadcast missing in case of transition from external
activation to internal activation.
2) Do not clear SCO requests when SCO audio is disconnected: this can
happen because current active communication route request is different
from SCO but pending requests must stay in the stack.
3) Do not clear SCO requests when the audio mode owner changes. Any Active
communication route requested by new audio mode owner will be honored
and pending requests will be restored when mode owner changes again.
Test: regression tests with cell and VoIP calls
Change-Id: If9d2f24b9def78ccd791294ed42d95ce30f0ba8b
Merged-In: If9d2f24b9def78ccd791294ed42d95ce30f0ba8b
Now service will only send onConnectedClientsOrInfoChanged to Manager
side. Add callback handling to dispatch correct callback base on below
scenarios.
1. onInfoChanged(SoftApInfo) will send when a. registration (non bridged) b. non
bridged and info changed
2. onInfoChanged(List) will send when a. registration b. info changed
3. onConnectedClientsChanged(List<WifiClient>) will send a. registration b. clients changed
4. onConnectedClientsChanged(SoftApInfo, List<WifiClient>) will send
a. when registration and client connected b. client changed on specific
instance. It will also need to handle when info changed(dismisssed), it
means that an instance shutdown. It needs to send empty list if previous
instance has client connected.
AP+AP Part 6 includes:
Support dual SoftApInfo callback
a. New callback onInfoChanged(List<SoftApInfo>) &
onConnectedClientsChanged(SoftApInfo, List<WifiClient>)
b. Callback refactoring
c. Support shutdown idle instance in bridged mode
Bug: 162686273
Bug: 175351193
Test: FrameworksWifiApiTests
Test: Manual Test, check the log and check SystemUI to confirm clients
update correctly.
Change-Id: Id587125edbb1167f58bba6b50a708be12888490f
