Repository navigation
iOS: When Bluetooth device is available, incoming call defaults to receiver/earpiece when answered #614
Description
Bug report
-
I've checked the example to reproduce the issue.
-
Reproduced on:
-
Android
-
iOS
Description
When a BT device is connected, outbound calls will automatically connect to the BT audio route.
But for inbound calls, the audio gets routed to the receiver/earpiece instead of BT.
When I print out the events for RNCallKeepDidChangeAudioRoute, I receive a bunch of them once I answer the call. Sometimes they start off as BT, but it gets overrode by subsequent events showing receiver as the audio route. These events are triggered outside of my app.
Steps to Reproduce
Connect your device to BT device. Place an inbound call to CallKit app. Answer the call. Notice the audio route is not BT.
Versions
- Callkeep: 4.3.3
- React Native: 0.66.3
- iOS: 15.4.1
- Android: N/A
- Phone model: iPhone 11
Logs
Paste here
Activity
AbdulBsit commentedon Mar 24, 2023
It's the default behaviour of iOS
vishaldaher commentedon Aug 13, 2024
@AbdulBsit observed same.
Is there any workaround to route audio to bluetooth device even when user answers call from iPhone?
AbdulBsit commentedon Aug 13, 2024
@vishaldaher on
didActivateAudioSessionafter call answer you can check for bluetooth device, if present just override it usingRNCallKeep.setAudioRoutemethod, I would suggest to keep it as it is, as this is a default platform behaviour for iOSvishaldaher commentedon Aug 13, 2024
Thanks for Quick reply @AbdulBsit :)
I tried
RNCallKeep.setAudioRoutebut its not working. I am also agree with your suggestion to keep this as is as its default behaviour.octaviotastico commentedon Jul 31, 2026
We encountered a similar timing problem in an Expo SDK 56 application using React Native 0.85.3 and CallKit.
When an inbound call was answered, iOS could emit several route changes around didActivateAudioSession. An application-level route request made too early could be overridden by a later CallKit event, leaving the call on the receiver instead of the Bluetooth route.
Our local fix was to queue route changes until didActivateAudioSession, then apply the latest requested route. We also changed RNCallKeep's iOS rejection path to pass e.description as an NSString instead of the caught NSException, because current React Native TurboModules can crash while converting that exception to a JS error. PR #845 addresses the latter library issue.
The activation timing described here is valuable context for making route selection reliable on current React Native versions.