As per this thread, platforms messages are relayed on and must be responded to on the main thread.
This should probably be documented, both at the platform-channels page and in code documentation if relevant (FlutterResult, somewhere in FlutterBinaryMessenger, FlutterTextureRegister.textureFrameAvailable for a start).
I started trying to write something to go into the platform-channels page at least but then realized that this is probably something that would warrant code examples at least in the page, if not an entire example project (unfortunately I don't have time right now to help with either of those).
If it is something that might be considered for adding to the roadmap to be changed at some point, then maybe minimal documentation would be enough.
This is what I started, if it's useful feel free to use it:
## Threading in platform-specific code
Platform messages (including MethodChannel calls) are relayed and must be replied to
on the platform's main thread. Any tasks that run in background threads must relay
back to the main thread before responding.
This can be accomplished several different ways on each platform. A simple solution on
iOS is post tasks to [`Dispatch Queues`], while on android [`AsyncTask`] can
be used to process data and then handle the response from the initial thread.
[AsyncTask]:https://developer.apple.com/documentation/dispatch
[Dispatch Queues]:https://developer.android.com/reference/android/os/AsyncTask.html
As per this thread, platforms messages are relayed on and must be responded to on the main thread.
This should probably be documented, both at the platform-channels page and in code documentation if relevant (FlutterResult, somewhere in FlutterBinaryMessenger, FlutterTextureRegister.textureFrameAvailable for a start).
I started trying to write something to go into the platform-channels page at least but then realized that this is probably something that would warrant code examples at least in the page, if not an entire example project (unfortunately I don't have time right now to help with either of those).
If it is something that might be considered for adding to the roadmap to be changed at some point, then maybe minimal documentation would be enough.
This is what I started, if it's useful feel free to use it: