Bluetooth: Fix HFP SCO logic and documentation
AudioService: * Call setBtScoActiveDevice and setBluetoothScoOn both in AudioService's broadcast receiver so that these two methods must be triggerred in the same sequence as ACTIVE_DEVICE_CHANGED and AUDIO_STATE_CHANGED intents are sent and we no longer need to handle race condition by synchronously checking active device in setBluetoothScoOn * Default sco audio mode when no headset is active should be virtual voice call, as many HFP devices do not accept SCO audio without an ongoing call * Synchronize checkScoAudioState() method with mScoClients * Add helper functions connectBluetoothScoHelper and disconnectBluetoothScoHelper to call various SCO setup and tear down methods based on sco audio mode * Try raw, virtual call, and voice recognition mode when disconnecting externally started SCO * Add new sco state SCO_STATE_DEACTIVATING to allow back to back calling of startBluetoothSco and stopBluetoothSco Audio Manager: * Modified AudioManager logic so that removed devices callback is called before newly added devices BluetoothHeadset: * Modified BluetoothHeadset so that start and stop SCO using virtual voice call no longer need a parameter and will use active device by default * Modified documentation around various sco mangement APIs to match their expected behaviors Bug: 76114959 Test: VoIP calls sanity test cases Change-Id: Id50db88f4ff36069b0f392c81dd9d90c24cd2206
Loading
Please register or sign in to comment