react-native-camera

feat(Ios): handle audio interruptions (#2565)

* This update tries to improve audio recording interruptions on iOS due to phone calls or background music.

- Use a more generic event to handle session interruptions. This removes the need to listen to foreground/background events, and stopping the session this way was actually redundant/wrong (see https://forums.developer.apple.com/thread/61406). This also makes session stopping detection more reliable (calls, suspension due to a call or notification, etc., which would previously not set the recording interrupted flag on every case)

From the above docs: "No, incorrect. You _never_ need to stop your capture session. The capture session automatically stops itself when your app goes to the background and resumes itself when you come back to the foreground."

- Allow for `captureAudio` updates to also update the audio connections internally so the prop can be correctly updated on the fly without remounting.

- add onAudioInterrupted and onAudioConnected events so the UI can handle scenarios where audio is wanted but not available. This should also help in keeping the preview active even if audio is interrupted and we have captureAudio={true}. Lastly, it can be used to detect if we can record audio or not due to the dummy implementation of the audio permission on iOS always returning true.

- check, activate, and release audio sessions (if captureAudio) so we can detect early if audio is available before attempting to connect the input. This will also allow us to detect if we can record even if there was already a call before opening the camera.

- use proper observer for session error instead of of the strong self block. No benefit, but makes code more readable and allows access to instance variables

- getDeviceOrientationWithBlock might fire more than once under some circumstances, ending up taking a picture or video twice. Add a lock and additional check to prevent this.

* no need for change check,

* do not resume audio if we were hinted not to (e.g., music playback happening)

* start session here also on session queue.

* check for session running before trying to record or capture.
This should fix a possible race condition where both the session start call happens at the same time as the record call

* no need to set orientation on constructor, and set it on session queue to prevent race conditions

* move device init and checks also to session queue. This prevents possible double initializations.