* feat: Continue to record audio when receiving a phone call (try to prevent interruptions)
Uses `setPrefersNoInterruptionsFromSystemAlerts` to prevent system alerts (like phone calls) from interrupting the audio session which records audio from the microphone.
* fix: Add `try`
* feat: Allow returning of ImageProxy in a Frame Processor
* chore: Clean up
* fix: Missing space
* Update useFrameProcessor.ts
* Revert "Update useFrameProcessor.ts"
This reverts commit 9c645489cdfdf2079972669756a2cd20cc81e25e.
* Calculate a format's video dimensions based on supported resolutions and photo dimensions
* Add Android fallback strategy for recording quality
* Ensure that session props are not ignored when app is resumed
* Simplify setting Android video dimensions in format
* Modify Android imageAnalysisBuilder to use photoSize
* Update onHostResume function to reference android preview issue
* Add missing Android capture errors
* Fix AVWriter status 1 crash followup
* Update RecordingSession.swift
removing trailing semicolon to make linter happy
* Update RecordingSession.swift
Set hasRunningWritingAttempt to true
* Update RecordingSession.swift
* Update RecordingSession.swift
* Update RecordingSession.swift
* Update RecordingSession.swift
Make the linter hate me again
* Update RecordingSession.swift
fixes#930
markAsFinished has to be called within the finishWritingWithCompletionHandler.
Moving that 2 lines allowed me to spam start / stop for hundreds of time without a single crash.
Accessing previewView.bitmap was throwing an error because it wasn't being done on the main thread.
Any access to previewView needs to be done on the main (UI) thread. This commit fixes the issue by
ensuring this access is now run on the main thread.
Fixes#547
This commit fixes#758. I was having the same issue and looked into it a bit. I found
[this StackOverflow answer](https://stackoverflow.com/a/60585382) which described a
solution to the same problem. Rather than manually calculate the focus point, we can
get the PreviewView to do it for us. This fixes the issue because the PreviewView
factors in any scaling or resizing of the view on the screen, which we weren't doing
before. The only potential issue is that this needs to run on the UI thread
(which is what the `withContext` is doing), but I've tested it with frame processors
enabled and disabled, and have found no issues in either case.
