AudioService: refactor communication route control
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
3 files changed