AI-powered crash analysis is now available on all plans — including Free.Read the crash analysis guide

Mobile Audio Crash Debugging: Android & iOS Guide

NFNourin Mahfuj Finick··9 min read

title: "Mobile Audio Crash Debugging: Android & iOS Guide" description: "Debug mobile audio crashes on Android & iOS. Fix AudioTrack, AVAudioEngine, Bluetooth routing, buffer underruns, and codec failures with proven techniques." author: "Nourin Mahfuj Finick" date: "2026-07-15" tags: ["mobile", "crash", "debugging", "audio", "voice", "ios", "android"] slug: "mobile-audio-voice-crash-debugging"

Why Audio Crashes Are Uniquely Hard to Debug

Mobile audio crash debugging presents a set of challenges that set it apart from other crash categories. Audio processing operates under hard real-time constraints — a single dropped buffer at 48 kHz means audible glitches, and a crash on the audio thread can bring down the entire app. Audio APIs on both Android and iOS are deeply tied to hardware codecs, Bluetooth stacks, telephony layers, and OS-level audio routing policies, creating failure surfaces that span multiple system services. When your music player crashes during Bluetooth handoff, or your VoIP app dies mid-call because of an audio session interruption, the stack trace rarely tells the whole story. This guide covers the most common audio crash patterns across both platforms and gives you practical debugging techniques you can use today.

Android Audio Crash Patterns

AudioTrack and AudioRecord Crashes

AudioTrack is the primary API for playing PCM audio on Android, and it crashes in predictable but painful ways. The most common exception is IllegalStateException with the message "AudioTrack not initialized" — this happens when you call play() or write() before checking the state returned by the constructor. AudioTrack initialization can silently fail if the requested sample rate, channel config, or encoding format isn't supported by the device's hardware mixer. Always check getState() == AudioTrack.STATE_INITIALIZED before using the instance.

AudioRecord has similar initialization pitfalls. On some Samsung and Xiaomi devices, requesting 44.1 kHz recording when the hardware natively supports 48 kHz causes AudioRecord to return STATE_UNINITIALIZED. The fix is to query supported rates via AudioManager.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE) and fall back gracefully:

int sampleRate = 44100;
AudioTrack track = new AudioTrack.Builder()
    .setAudioFormat(new AudioFormat.Builder()
        .setSampleRate(sampleRate)
        .build())
    .build();
if (track.getState() != AudioTrack.STATE_INITIALIZED) {
    // Fall back to 48000 or query AudioManager for supported rates
    sampleRate = Integer.parseInt(audioManager.getProperty(
        AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE));
    track = new AudioTrack.Builder()
        .setAudioFormat(new AudioFormat.Builder()
            .setSampleRate(sampleRate)
            .build())
        .build();
}

MediaPlayer Crashes and the State Machine

Android's MediaPlayer uses an explicit state machine, and calling methods from the wrong state throws IllegalStateException. The classic trap: calling start() before prepare() completes, or calling getCurrentPosition() after reset(). On some MediaTek-powered devices, MediaPlayer crashes with a native SIGSEGV in libmediaplayerservice.so when the underlying media extractor encounters a corrupted file — a crash that never shows up on stock Android emulators. For production apps, prefer ExoPlayer which handles state transitions more gracefully and provides better error recovery for streaming audio.

Audio Focus Conflicts

Audio focus on Android determines which app gets to play sound. Calling AudioManager.requestAudioFocus() returns AUDIOFOCUS_REQUEST_GRANTED or AUDIOFOCUS_REQUEST_FAILED, but the real danger is losing focus mid-playback. If you don't implement OnAudioFocusChangeListener, your app continues writing to AudioTrack after losing focus, which on some devices triggers a native crash in AudioFlinger. The listener must handle AUDIOFOCUS_LOSS (stop and release), AUDIOFOCUS_LOSS_TRANSIENT (pause), and AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK (lower volume). Failing to release the audio track on AUDIOFOCUS_LOSS is the single most common audio crash we see in production at BugsPulse.

iOS Audio Crash Patterns

AVAudioEngine and Thread Safety

AVAudioEngine is Apple's modern audio graph API, and almost all crashes trace back to thread safety violations. The engine's real-time rendering thread must never be blocked. Calling connect(), disconnectNodeOutput(), or detachNode() from any thread other than the audio thread while the engine is running causes sporadic com.apple.coreaudio.avfaudio crashes with "required condition is false: _engine->_state == AVAudioEngineStateRunning." The fix is to call stop() before modifying the graph, or schedule changes through installTap(onBus:bufferSize:format:block:) which executes on the render thread:

// SAFE: modify graph while stopped
engine.stop()
engine.connect(player, to: reverb, format: nil)
engine.connect(reverb, to: engine.mainMixerNode, format: nil)
try engine.start()
 
// SAFE for tap operations: they execute on render thread
reverb.installTap(onBus: 0, bufferSize: 1024, format: nil) { buffer, when in
    // Process buffer on audio thread — no UIKit, no locks, no allocation
}

AVAudioSession Configuration Crashes

AVAudioSession governs how your app interacts with the system audio environment. Setting the category to .playAndRecord without activating the session first causes mysterious crashes deep in AudioToolbox. The pattern that works:

let session = AVAudioSession.sharedInstance()
do {
    try session.setCategory(.playAndRecord, mode: .voiceChat,
        options: [.allowBluetooth, .defaultToSpeaker])
    try session.setActive(true)
} catch {
    // Log and report to crash monitoring
}

Audio route changes — when a user plugs in headphones or connects to a Bluetooth device — fire AVAudioSession.routeChangeNotification. If your audio engine is running and you're not listening for this notification, the route change can cause the engine to stop silently, then crash when you try to play again. Always observe route change notifications and reconfigure the engine when the output changes.

Bluetooth Audio Routing Failures

Bluetooth audio crashes are among the most frustrating because they're hardware- and accessory-dependent. On Android, SCO (Synchronous Connection Oriented) for calls uses a different protocol than A2DP (Advanced Audio Distribution Profile) for music. When a call starts while music is playing over A2DP, the system switches to SCO — if your app doesn't handle this, AudioTrack.write() returns an error code that cascades into a crash.

On iOS, Bluetooth audio routing is managed by AVAudioSession and CoreBluetooth simultaneously. If your app holds a CoreBluetooth connection to a BLE device while also using AVAudioSession with .allowBluetooth, the system can deadlock when trying to route audio. The fix is to set AVAudioSession.CategoryOptions.allowBluetoothA2DP explicitly when you only need high-quality stereo, avoiding the SCO/HFP code path that causes conflicts.

A common production pattern: detect Bluetooth state changes through BluetoothAdapter.getProfileProxy() on Android or CBCentralManager state on iOS, and gracefully pause and resume your audio pipeline instead of letting the OS force-route mid-buffer:

val bluetoothManager = context.getSystemService(BluetoothManager::class.java)
bluetoothManager.adapter?.getProfileProxy(context, object : BluetoothProfile.ServiceListener {
    override fun onServiceConnected(profile: Int, proxy: BluetoothProfile) {
        if (profile == BluetoothProfile.A2DP) {
            // A2DP connected — safe to play high-quality audio
        }
    }
    override fun onServiceDisconnected(profile: Int) {
        if (profile == BluetoothProfile.A2DP) {
            // A2DP disconnected — pause playback, reconfigure audio
            audioTrack.pause()
        }
    }
}, BluetoothProfile.A2DP)

VoIP Audio Session Interruptions

VoIP apps face unique audio crash challenges because they must integrate with telephony frameworks — CallKit on iOS and TelecomManager on Android. On iOS, an incoming cellular call triggers AVAudioSessionInterruptionNotification and your audio session is deactivated. If your app doesn't handle the interruption by properly stopping the audio engine, it crashes on resume with "required condition is false: IsFormatSampleRateAndChannelCountValid(format)."

The correct interruption handler:

NotificationCenter.default.addObserver(forName: AVAudioSession.interruptionNotification,
    object: nil, queue: .main) { notification in
    guard let type = notification.userInfo?[AVAudioSessionInterruptionTypeKey] as? UInt,
          let interruptionType = AVAudioSession.InterruptionType(rawValue: type) else { return }
    
    if interruptionType == .began {
        // Interruption began — stop audio engine
        engine.stop()
    } else if interruptionType == .ended {
        guard let options = notification.userInfo?[AVAudioSessionInterruptionOptionKey] as? UInt else { return }
        if AVAudioSession.InterruptionOptions(rawValue: options).contains(.shouldResume) {
            try? session.setActive(true)
            try? engine.start()
        }
    }
}

On Android, VoIP audio uses AudioManager.MODE_IN_COMMUNICATION. When a GSM call arrives, the telephony stack takes over and your audio session is suspended. If you're using AudioRecord with VOICE_COMMUNICATION as the audio source, failing to call stop() and release() during the telephony callback produces a native crash in the audio HAL layer.

Buffer Underrun and Overrun

Buffer management is the silent killer of audio stability. An underrun occurs when the audio hardware consumes data faster than your app provides it — the result is silence, a glitch, or on aggressive implementations, a crash. An overrun happens when you write data faster than the hardware can consume it, overflowing internal buffers.

On Android, AudioTrack writes are blocking by default in WRITE_BLOCKING mode. If your production thread blocks for more than a few hundred milliseconds, the system can kill your process as an ANR. The solution is to use WRITE_NON_BLOCKING mode with a dedicated audio thread that polls getPlaybackHeadPosition() to determine how much buffer space is available:

audioTrack.setPlaybackPositionUpdateListener(new AudioTrack.OnPlaybackPositionUpdateListener() {
    @Override
    public void onPeriodicNotification(AudioTrack track) {
        // Safe to write more data here — called every N frames
        writeNextBuffer();
    }
});
audioTrack.setPositionNotificationPeriod(bufferSizeInFrames);

On iOS, AVAudioEngine manages its own ring buffer internally, but custom audio units created with AudioUnitRender() require manual buffer management. The kAudioUnitProperty_MaximumFramesPerSlice property determines buffer slice size — requesting a slice larger than the hardware supports causes a -10863 error (kAudioUnitErr_TooManyFramesToProcess). Always query the hardware's maximum frames per slice and respect it. For more on threading pitfalls that exacerbate buffer issues, see our guide on mobile thread safety and race condition crashes.

Codec Crashes: MediaCodec and VTDecompressionSession

Audio codec crashes happen when encoding or decoding audio data. On Android, MediaCodec is notoriously fragile with specific input formats. A common crash: configuring MediaCodec with AAC-LC at 44.1 kHz when a specific Qualcomm DSP firmware version only supports 48 kHz. The codec accepts the configuration but crashes with MediaCodec.CodecException during queueInputBuffer(). Always validate codec capabilities with MediaCodecList.findDecoderForFormat() before creating the codec:

MediaCodecList codecList = new MediaCodecList(MediaCodecList.ALL_CODECS);
String decoderName = codecList.findDecoderForFormat(format);
if (decoderName == null) {
    // Fall back to software decoder or alternative encoding
    format.setInteger(MediaFormat.KEY_SAMPLE_RATE, 48000);
    decoderName = codecList.findDecoderForFormat(format);
}

On iOS, VTDecompressionSession handles compressed audio decoding. Invalid or truncated AAC/Opus bitstreams cause kVTVideoDecoderBadDataErr (-12911), which in a poorly handled callback can crash the session permanently. Always check VTDecompressionSessionDecodeFrame() status and set a VTDecompressionOutputCallback that handles error frames gracefully without propagating the failure to the rendering pipeline.

Debugging Tools and Production Monitoring

For local debugging, Android provides dumpsys media.audio_flinger which shows every active audio track and record session on the device. Use this to confirm whether your app's audio session is actually registered with AudioFlinger:

adb shell dumpsys media.audio_flinger

On iOS, the AVAudioSession route description (session.currentRoute.outputs) tells you exactly where audio is routing, and session.isOtherAudioPlaying reveals focus conflicts. Enable the Audio-All category in Xcode's diagnostic logging to capture CoreAudio errors.

But local debugging won't catch the full spectrum of audio crashes that happen on real devices in the field — different Bluetooth chipsets, OEM audio HAL implementations, and carrier-specific telephony stacks. That's where production crash monitoring becomes essential. A crash reporting tool that captures the full state of your audio pipeline — active AudioTrack/AudioEngine status, current audio route, Bluetooth profile state, and audio focus status — lets you reproduce and fix crashes that never show up in your test lab.

Conclusion

Mobile audio crash debugging requires understanding the full audio stack — from hardware codecs and Bluetooth profiles to OS-level audio session management. Android's AudioTrack, AudioRecord, and MediaPlayer APIs demand careful state management and audio focus handling. iOS's AVAudioEngine and AVAudioSession require strict thread safety and interruption handling. Across both platforms, Bluetooth routing, VoIP telephony integration, buffer management, and codec configuration create failure surfaces that generic crash reports miss.

For production monitoring that captures audio-specific crash context — including audio route, Bluetooth state, and audio session diagnostics — try BugsPulse free. Set up in minutes and get real-time alerts when audio crashes impact your users.