react-native-webrtc / react-native-incall-manager

Handling media-routes/sensors/events during a audio/video chat on React Native
ISC License
559 stars 195 forks source link

Android AppRTCBluetoothManager does not properly update bluetoothState when user disconnects their headset #243

Open davisk4rpi opened 7 months ago

davisk4rpi commented 7 months ago
"react-native": "0.72.4",
"react-native-incall-manager": "^4.2.0",
"react-native-webrtc": "118.0.7",

Issue

I am developing a one way live stream and there is no need to ever send the audio to the Viewer's device's Earpierce, so I am using media: 'video' and also auto: true.

Initially, if the Viewer has no connected Bluetooth headsets, audio routes to the SpeakerPhone. If they have a connected Bluetooth headset when the join the stream or if they connect one midway, it will route to the device.

The issue arises when the Viewer turn off their only available Bluetooth headset. The AppRTCBluetoothManager identifies that a device was removed and that it needs to call BluetoothAudioDeviceCallback#updateDeviceList but does not perform the state updates needed to appropriately re-route to the SpeakerPhone.

Based on the native logs, bluetoothManager.getState() remains equal to AppRTCBluetoothManager.State.SCO_CONNECTED. This mean the selected audio device is still equal to AudioDevice.BLUETOOTH despite there being no Bluetooth device available. As a result, the device defaults back to the Earpiece and the audio routing remains in a denormalized/broken state until the call is restarted.

Reproduction Steps:

Using InCallManager.start({ media: 'video', auto: true });

  1. Join call with no Bluetooth Device Connected, Audio Routes to the SpeakerPhone
  2. Connect a Bluetooth Device, Audio routes to new device
  3. Turn Bluetooth Device Off, Audio routes to Earpiece
  4. Attempt to reconnect Bluetooth Device, Audio remains routed to Earpiece

To get my app working, I used patch-package to add bluetoothState = State.HEADSET_UNAVAILABLE; when newBtDevice === null. Im not sure how this would effect other use cases, but its a pretty simple change that appears to be handling my issue.

  private class BluetoothAudioDeviceCallback extends AudioDeviceCallback {
    ...
    private void updateDeviceList() {
      final AudioDeviceInfo newBtDevice = getScoDevice();
      boolean needChange = false;
      if (bluetoothAudioDevice != null && newBtDevice == null) {
        needChange = true;
        // NEW LINE
        bluetoothState = State.HEADSET_UNAVAILABLE;
      } else if (bluetoothAudioDevice == null && newBtDevice != null) {
        needChange = true;
      } else if (bluetoothAudioDevice != null && bluetoothAudioDevice.getId() != newBtDevice.getId()) {
        needChange = true;
      }
      if (needChange) {
        updateAudioDeviceState();
      }
    }
  }
santhoshvai commented 2 weeks ago

@davisk4rpi Can you submit a PR please, looks like a valid fix