Android Speech SDK 1.51.2 crashes inside libMicrosoft.CognitiveServices.Speech.core.so

Question

Android Speech SDK 1.51.2 crashes inside libMicrosoft.CognitiveServices.Speech.core.so

YanTao Shen 0

We are investigating an intermittent native crash in the Android Azure Speech SDK.

Environment:

Speech SDK 1.51.2
Android 15 and 16
arm64-v8a
Custom PullAudioInputStreamCallback backed by AudioRecord
PCM 16 kHz, 16-bit, mono

Two production events from different devices have the same top frames:

#00 libMicrosoft.CognitiveServices.Speech.core.so + 0x48802c

#01 libMicrosoft.CognitiveServices.Speech.core.so + 0x487f94

One event occurred after several rapid continuous-recognition retries while TTS was being interrupted. Another occurred in the background shortly after leaving a speech-enabled screen.

Before closing the recognizer, we call stopContinuousRecognitionAsync() and wait for its Future. If it times out, we retain the recognizer and audio resources instead of closing them. Resources are closed only after stop completes.

Could the Speech SDK team please help with these questions?

Can Microsoft symbolize offsets 0x48802c and 0x487f94 for Android arm64 SDK 1.51.2?
Does completion of the stop Future guarantee that SDK worker threads will no longer access the recognizer or custom audio stream?
Is there a required shutdown order for AudioRecord, PullAudioInputStream, Connection, and SpeechRecognizer?
Is this a known issue fixed in a newer SDK version or private hotfix?

We can provide sanitized Crashlytics evidence, SDK diagnostic logs, and a tombstone if required.

Disclosure: ChatGPT helped organize the wording. I reviewed and validated the technical details against our production Crashlytics data.

0 comments

1 answer

Your answer

Answer 1

Hi YanTao,

This pattern points to a native lifecycle/race condition around stopping and tearing down recognition, especially because the crashes occur after rapid recognition retries and TTS interruption.

There are two important points:

Speech SDK 1.46 included a fix for a crash caused by a race condition during timeout-based recognition stopping.

Speech SDK 1.51 fixed additional native teardown issues, including WebSocket teardown crashes and a crash during connection deallocation. SDK 1.50 also fixed an Android EventLoggerCallback crash.

SDK 1.51.2 specifically fixed a SIGABRT crash in speech synthesis, but the release notes do not identify your exact two offsets as a known Android recognition crash.

Your shutdown logic should therefore be stricter: do not reuse a recognizer after a timed-out stop. stopContinuousRecognitionAsync() completes when input processing has stopped, but Microsoft does not document it as a guarantee that every native worker thread has completely finished using every associated object.

For a custom PullAudioInputStream, also keep the stream alive until recognition has stopped, then close the stream and AudioRecord, and finally close the recognizer. The SDK documentation explicitly requires the custom stream's Close() to release its external resources.

I would use this lifecycle:

start recognizer
    ↓
stopContinuousRecognitionAsync()
    ↓
wait for completion
    ↓
close PullAudioInputStream
    ↓
stop/release AudioRecord
    ↓
close SpeechRecognizer
    ↓
create a completely new recognizer/stream for the next attempt

Most importantly, remove the “retain recognizer after stop timeout and retry with the same instance” path. That is the part of the current design most likely to expose a native use-after-stop/race condition.

Also test with Speech SDK 1.51.2 or later, because several relevant native crash fixes have landed across 1.46–1.51.2.