fix: prevent "codec is released already" crash on Android

[tobias-ottenweller-knowunity]

• Add AtomicBoolean flag to ensure stop() executes only once
• Check isStopped flag in MediaCodec callbacks before processing
• Null out decoder/extractor references before releasing
• Wrap release operations in try-catch for safety

Description

Checklist

• The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
• I have followed the Contributor Guide when preparing my PR.
• [ ] I have updated/added tests for ALL new/updated/fixed functionality.
• [ ] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• [ ] I have updated/added relevant examples in examples or docs.

Breaking Change?

• Yes, this PR is a breaking change.
• No, this PR is not a breaking change.

Related Issues

Fixes #477
as #478 crashed for me, this is another attempt resolving the underlying issue

[berkanaslan]

Tested, it fixes PlatformException "codec is released already" exception

[scenteno]

tested and it solves the issue.

[DorraY]

I hope this can be merged asap, this error is making the plugin unreliable.

[lavigarg-simform]

Closing in favor of #495

Thanks @tobias-ottenweller-knowunity, and thanks to everyone who tested this. This PR pinned down the real cause of the codec is released already crash (#477 / #478).

Root cause (confirmed here)

stop() runs twice:

1. When extraction reaches EOF, inside the decode callback.
2. Again from dispose().

Because decoder is never set to null, the second decoder.stop() runs on an already-released codec and throws.

We're folding the Android codec fixes into #495. It builds on what you did here, with one more addition-

It closes a race this PR's guard can't reach

The AtomicBoolean makes stop() idempotent, so it fully fixes the sequential case — EOF stop, then dispose stop. That is the case your testers were hitting, which is why it has been stable in the field.

The remaining gap is concurrency. The guard only protects re-entry into stop(); it is not held while the codec is in use:

• The decode callbacks (onOutputBufferAvailable) run on the codec's own thread and call into the codec.
• dispose() → stop() → decoder.release() runs on the platform thread.

If release() happens while a callback is still in flight, that callback touches a released codec and throws the same exception.

To reproduce:

await controller.preparePlayer(path: longFile, shouldExtractWaveform: true);
// dispose while extraction is still running, before EOF
controller.dispose();

The atomic does not serialize the callback against the release.

Since #495 is a superset of this change, I am going to close this in favor of it. The diagnosis and field validation here were what made it possible to get it right, credit to you and the testers.