(Will PR) MediaPlayer on Android is *not* thread safe, but it is used in multiple threads, causing subtle bugs

[fzyzcjy]

I can make a PR for this.

https://developer.android.com/reference/android/media/MediaPlayer says:

MediaPlayer is not thread-safe. Creation of and all access to player instances should be on the same thread.

However, I have made some logging and realize the call to MediaPlayer in this library is from multiple threads.

For example, I have seen:

1. mediaPlayer.reset (thread=6854, this=e3ed388, )
2. mediaPlayer.stop (thread=2, this=e3ed388, )

If you are interested, my logging code looks like:

    override fun start() {
        log("mediaPlayer.start")
        mediaPlayer.start()
    }

    private fun log(message: String) {
        MyFlutterLog.log(
            TAG,
            "$message " +
                    "(" +
                    "thread=${Thread.currentThread().id.toString(16)}, " +
                    "this=${myShortHash(this)}, " +
                    ")"
        )
    }

[Gustl22]

It depends from where it's called. Usually it helps if wrapping the call in the main loop handler. But we should think about running the asynchronous stuff also on the main thread.

[fzyzcjy]

UPDATE

The cause of multi-threading is not what I originally thought (I wrongly thought Flutter calls the kotlin code on non-ui threads). Instead, it is this:

class AudioplayersPlugin : FlutterPlugin, IUpdateCallback {

...
        methods = MethodChannel(binding.binaryMessenger, "xyz.luan/audioplayers")
        methods.setMethodCallHandler { call, response -> safeCall(call, response, ::methodHandler) }
...

    private fun safeCall(
        call: MethodCall,
        response: MethodChannel.Result,
        handler: FlutterHandler,
    ) {
        mainScope.launch(Dispatchers.IO) {
            try {
                handler(call, response)
            } catch (e: Exception) {
                response.error("Unexpected AndroidAudioError", e.message, e)
            }
        }
    }

The Dispatchers.IO says:

The CoroutineDispatcher that is designed for offloading blocking IO tasks to a shared pool of threads.
Additional threads in this pool are created and are shutdown on demand.

Thus, it is this safeCall that moves things to the non-UI threads.

[fzyzcjy]

ANOTHER UPDATE

ExoPlayer (related: #1526) says that, it should (usually) be called directly on the ui thread. Therefore, if we refactor into ExoPlayer, we can safely remove the safeCall without the worry that running things on ui thread may block anything.

[Gustl22]

Closing in favor of #1525