Android: no 'error' event, so addRecordingErrorListener never fires there

[abretonc7s]

iOS declares and emits an error event for failures that happen while recording is already running — the kind that cannot reject a call because the call already returned. AudioStudioModule.swift:

private let errorEvent: String = "error"
...
func audioStreamManager(_ manager: AudioStreamManager, didFailWithError error: String) {
    sendEvent(errorEvent, [ "message": error ])
}

Android's Events(...) block lists no equivalent:

Events(
    Constants.AUDIO_EVENT_NAME,
    Constants.AUDIO_ANALYSIS_EVENT_NAME,
    Constants.RECORDING_INTERRUPTED_EVENT_NAME,
    Constants.MAX_DURATION_REACHED_EVENT_NAME,
    Constants.TRIM_PROGRESS_EVENT,
    Constants.DEVICE_CHANGED_EVENT,
    Constants.AUDIO_STREAM_CHUNK_EVENT,
    Constants.AUDIO_STREAM_PROGRESS_EVENT,
    Constants.AUDIO_STREAM_COMPLETE_EVENT,
    Constants.AUDIO_STREAM_ERROR_EVENT
)

AUDIO_STREAM_ERROR_EVENT is for the streaming/decoding API, not for a live recording going wrong.

Impact

addRecordingErrorListener() (added alongside the #420 fix) is typed as cross-platform but is inert on Android. A caller who subscribes to detect a degraded recording gets silence there, which reads as "healthy" — the more dangerous failure mode, since it is the exact signal they added the listener to receive.

The doc comment says iOS-only, but a doc comment is weaker than the type.

Suggested fix

Add the event to Android's Events(...) and emit it wherever a live recording degrades without failing a call. Worth auditing what those sites are — Android's silent-failure paths are not necessarily the same as iOS's.

Once both platforms emit, drop the iOS-only caveat from the listener's docs.

Related

• iOS interruption resume: compressed M4A continues growing but primary WAV stops growing #420 — the iOS stalled-WAV fix that motivated the listener
• Android: failed recording initialization leaks AudioRecord and MediaRecorder until the next attempt #446 — recorder leak on failed initialization