fix(android): stop resurrecting stopped recorders on stream disconnect

[christian-apollo]

Fixes #1088

Problem

On Android, a stopped AudioRecorder keeps its oboe input stream open (stop() only calls requestStop()), and onErrorAfterClose() unconditionally reopens and restarts the stream on ErrorDisconnected. Any audio route change — e.g. a Bluetooth headset connecting or disconnecting — therefore turns the microphone back on after stop(). Since the stream holds a shared_ptr to the recorder (shared_from_this()), the resurrected stream also keeps the recorder alive forever once JS drops it (reference cycle).

onErrorAfterClose additionally runs on oboe's detached error thread and mutates mStream_ (via cleanup()/openAudioStream()) with no synchronization against start()/stop() on the JS thread. On 0.12.x, where the callbacks were raw pointers, this race produced a production SIGSEGV in oboe::AudioStream::fireDataCallback (full tombstone in #1088): the destructor lost the race, the error thread reopened a stream pointing at the freed recorder, and the next mic buffer crashed.

Changes

• stop() fully closes and resets the stream, so a stopped recorder has no open stream — no callbacks can fire, no error-restart can resurrect it, and the recorder→stream→recorder reference cycle is broken. start() already reopens the stream on demand when mStream_ is null.
• onErrorAfterClose():
  • takes the same callbackMutex_/fileWriterMutex_/adapterNodeMutex_ locks as start()/stop(), serializing all mStream_ mutation;
  • bails out when the recorder is idle, so stopped recorders stay stopped;
  • bails out when the erroring stream is no longer mStream_ — the detached error thread can arrive late, after stop()/start() already replaced the stream, and previously would tear down the healthy new stream (without re-running prepare()).
• isRecording() null-checks mStream_, which the error thread can reset concurrently; pause()/resume() take the recorder locks for the same reason (resume() also null-checks before mStream_->start(0)).

Deadlock safety

Closing the stream while holding the recorder mutexes is safe:

• onAudioReady only ever uses Locker::tryLock on these mutexes, so the data callback never blocks on them and close()'s wait for in-flight callbacks is bounded.
• oboe error-callback threads are detached (AudioStreamAAudio::internalErrorCallback, oboe 1.9.3), so close() never joins a thread that might be blocked on these locks; a blocked error thread simply proceeds afterwards and bails on the idle/stale-stream checks.

Testing

• Compiled for arm64-v8a and running in production as a patch-package patch on 0.12.2 (the same fix plus destructor locking, which main no longer needs thanks to shared_from_this()).
• Stopped-recorder + Bluetooth route-change no longer restarts the mic; repeated route changes during active recording recover as before via the (now guarded) reopen path.

🤖 Generated with Claude Code

[mdydek]

Suggested change

	if (isIdle()) {
	return;
	}
	if (isIdle() || isPaused()) {
	return;
	}

[mdydek]

it would be good idea to also dispatch other RECORDER_ERROR events here