The getAudioRoutes changes the selected audio route

[nagyszili]

Bug report

• I've checked the example to reproduce the issue.

• Reproduced on:

• Android

• iOS

Description

If there is an active session and I call the getAudioRoutes() it changes the audio route, because there is a setCategory executed in the getAudioInputs

react-native-callkeep/ios/RNCallKeep/RNCallKeep.m

Line 516 in 1c798d6

BOOL isCategorySetted = [myAudioSession setCategory:AVAudioSessionCategoryPlayAndRecord withOptions:AVAudioSessionCategoryOptionAllowBluetooth error:&err];

https://developer.apple.com/documentation/avfaudio/avaudiosession/1616583-setcategory?language=objc

There is any workaround to avoid this type of behavior?

Steps to Reproduce

1. Start a call
2. Get the audioRoutes: call getAudioRoutes()
3. Set an other audio route: call setAudioRoute()
4. Get the audioRoutes again and this will change the setted audio route

Versions

- Callkeep: 4.3.2
- React Native: 0.64
- iOS: 15.2
- Android:
- Phone model: iPhone 6s Plus, iPhone 12

[rcidt]

I submitted a PR with a fix to this issue @nagyszili can you please test?

[octaviotastico]

We ran into a closely related issue in an Expo SDK 56 application using React Native 0.85.3 and the New Architecture.

On iOS, querying audio routes while CallKit was changing the AVAudioSession could cause the selected route to change unexpectedly. Our local fix was to avoid application-level route changes until didActivateAudioSession, and to keep route inspection separate from route selection.

We also found that failed route operations could crash the app when RNCallKeep passed an NSException directly to a Promise rejection. Passing e.description as an NSString fixed that React Native TurboModule crash. PR #845 addresses that rejection issue, while the timing and session activation behavior still need to be handled by the route flow.

This issue is useful context for both fixes because it shows how route inspection and session activation can interact during an active call.