Canardoux
[BUG]: iOS: Resume after call interruption appears to overwrite recording file — expected behavior or implementation issue?
Flutter Sound Version :
Version: 9.16.3 Flavor: FULL
Result of the command: 'flutter pub deps | grep flutter_sound' ├── flutter_sound 9.16.3 │ ├── flutter_sound_platform_interface 9.16.3 │ ├── flutter_sound_web 9.16.3 │ │ ├── flutter_sound_platform_interface...
Severity
✅ Result is not what expected ?
Platforms you faced the error
✅ iOS
✅ Real device
Describe the bug We're encountering a situation on iOS where resuming a recording after an incoming phone call interruption appears to overwrite the file that was already being recorded, instead of appending to it.
We’re unsure whether this is a bug or just a limitation or undocumented behavior of how Flutter Sound handles interruptions and resumeRecorder() on iOS. We'd really appreciate some clarification.
What we’re doing
- We're using startRecorder(toFile: ...) with Codec.aacADTS.
- Audio sessions are managed via the audio_session plugin (through a wrapper AudioSessionManager).
- We handle interruptionEventStream, calling pauseRecorder() when an interruption starts, and resumeRecorder() when it ends.
- After a phone call interruption and resuming, we find that the output file only contains the post-call part — the pre-call audio seems lost.
- This does not happen if we manually pause and stop the session before the call. In that case, the file is preserved and resumed correctly.
- On Android, this flow works fine and appends as expected.
To Reproduce
Steps to reproduce the behavior:
- Start recording using startRecorder(toFile: ...)
- Receive an incoming phone call (without manually pausing before)
- Take the call and end it
- Call resumeRecorder()
- Stop and check the file — it only contains audio after the call
Questions:
- Is resumeRecorder() safe to call after a phone call interruption on iOS?
- Could the underlying AVAudioRecorder be silently invalidated by iOS and resumed as if starting a fresh file?
- Are we expected to stop the recorder entirely and start a new file in such cases?
- Is this expected behavior, and if so, would you recommend any pattern to avoid data loss?
Logs
Unfortunately, we don't yet have logs at Level.debug, but we can reproduce the issue reliably and are happy to provide detailed logs if needed.
Thank you for your Problem Report. No this is not expected. This is probably a bug in Flutter Sound. Someone else reported recently an other issue when the phone receives a phone call : the pause/resume didn’t work correctly. I don’t remember if it was iOS or Android.
Someone should try to understand those issues.
Same here! I am totaly fit with the problem. What is your plan about that bug @Larpoux ? It is a critical bug because the users loss their records completely. May you share a roadmap about the bug please?
@ismail-go I think Larpoux is actually focusing on the 10.x version. I'd like to have a look at it myself sometime. Maybe by a pr.
Right now we solve the problem on iOS by stopping the recording on an interrupt event. After the interruption ends, we start a new recording to a new file. At the end, we merge our m4a files into one file. To do this, we use native code on iOS via method channels.
@ismail-go , @neuhausjulian
I didn’t understood that this issue was so important for you. I am going to work on it tomorrow and I will tell you what is going on. Sorry for the bug if there is any.
@ismail-go , @neuhausjulian , I am able to reproduce the issue without any difficulty. Still not sure if this is a bug in Flutter Sound, in iOS or (perhaps) in audio_session. I will work on that tomorrow
Hey @Larpoux,
Thanks a lot for your quick replies and for jumping into this so fast — that’s already much more than we expected and truly appreciated 🙌
You're right, the issue can be quite critical, especially in scenarios like ours where recordings sometimes run for hours. That makes it much more likely that a phone call interrupts at some point, and losing a long segment of audio would obviously be a huge problem for users. So yes, it’s urgent in that sense.
That said, we’ve implemented a workaround on our side: we now stop the recording on interruption and start a new one afterward, then merge the resulting .m4a files via native iOS code using method channels. So for us, it's no longer an urgent blocker, but we still weren’t sure if this behavior was just iOS being iOS, or if we were using Flutter Sound in a wrong way — or if it's a legit bug.
Either way, we know this is an open source project and that everything has to fit into a realistic scope of time, effort, and priority. You're already going above and beyond, and we really appreciate that 🙏
If we can contribute in any way — whether that’s sharing logs, testing fixes — happy to help out!
Thanks again, Julian
I have bad news : this is not a bug in Flutter Sound nor audio_session but a bug in iOS. See StackOverflow.
I have no idea of any bypass solution. The only solution proposed on StackOverflow is to concatenate all the pieces like @neuhausjulian does. But I really don't want to do that in Flutter Sound :
- The risk to introduce new bugs with a so heavy solution is too high
- The Event Handler when there is an incoming call is managed by audio_session, and I have no knowledge that the app goes background.
Here is a quote from Apple:
"The behavior you described is a bug and unfortunately
there's nothing in the API that you can change to work around
to actually append to the original recording.
The interruption is resulting in capturing only the audio recorded after the
interruption.
You could try and stop the recording after the interruption then creating a new file
after which would at least not cause the user to loose any information,
but the result would be two separate files."
The only way to achieve this with AVAudioRecorder is to create multiple files
and merge them.
Sorry, I give-up. But if you have any idea of what I can do, please tell me.