When I start a LiveKit session, Bluetooth automatically disconnects on the tablet.
I have a Kotlin app and a website, and Bluetooth does not work on tablets with either of them.
What is the easiest way to reproduce this? I don’t have a tablet but I tried on my Android phone with Bluetooth connected and joining https://meet.livekit.io/ from both my desktop and device. The Bluetooth connection did not drop.
Do you see anything in the logs? If so, can you share the output of this as a file, and maybe we can pass it to someone who knows more about it?
adb logcat -v threadtime
Unfortunately, I’m not sure how you would be able to reproduce the test, as these are projects that are still under development and are not publicly available. I also don’t have any error logs.
But to provide more details:
The tests are being conducted on Android kiosk-type tablets. The goal is for a person to have a voice-to-voice conversation with an AI, which is why we are using LiveKit. We are also using an avatar from Beyond.
When I start a voice-to-voice session with the AI without using Bluetooth, everything works perfectly. However, if I connect a Bluetooth headset or earbuds, no sound comes out of the headset—the sound continues to come from the tablet’s speakers. If I use a wired headset, everything works correctly.
So the issue only occurs with Bluetooth.
This only happens when I start a LiveKit session. The tablet switches to call mode, and the audio is routed through the internal speakers instead of the Bluetooth device.
@Dwain_ABRIVARD, The detail that the tablet switches to call mode and then plays through the speaker is the tell. A LiveKit session sets the Android audio mode to MODE_IN_COMMUNICATION (AudioSwitchHandler.kt#L142-L146). In that mode Android carries voice over the Bluetooth SCO/HFP profile, not the A2DP media profile. So music plays to the earbuds but a LiveKit call does not, and a wired headset always works because it needs no SCO. That points at Android routing, not a LiveKit bug.
On kiosk tablets two things cause the fall back to the speaker. First, Android 12+ needs the BLUETOOTH_CONNECT runtime permission before an app can select a Bluetooth headset; without it the switcher cannot move audio there and stays on the speaker. The SDK README lists only RECORD_AUDIO and CAMERA (README), so this one is easy to miss. Bluetooth is already first in the default device order (AudioSwitchHandler.kt#L353-L355), so if it is not being picked, permission is the first suspect.
Second, many kiosk tablets have weak or no HFP/SCO support, so any communication-mode call drops to the speaker. You can confirm this with no LiveKit logs: place a normal phone or WhatsApp call on the same tablet and headset. If that call also stays on the speaker, the tablet’s SCO is the cause, and the same limit explains why the browser fails too. Grant BLUETOOTH_CONNECT first, then run that call test.