From the plugin package developer perspective:
Since you are using a package that is causing this, I’ll mention that I was causing the same issue in my package.
In my case, I was using the wrong (or old) method channel. I had saved an instance of a method channel from when the service (broadcast receiver) was running, and tried to use that to communicate with the running application.
When cleaning up the service (or Broadcast receiver), I had destroyed the Flutter Engine and therefore detached the Flutter JNI from the C++ engine. So when I went to use that method channel, which uses the detached Flutter JNI, you get the error:
Tried to send a platform message to Flutter, but FlutterJNI was detached from native C++.
I just had to use the FlutterEngine provided by the FlutterActivity (or FlutterFragment or Application) to get a new MethodChannel.
In my case, I am working on a Flutter package plugin (on Android). What this means is inside the plugin code, I should not any caching of methodChannels accidentally:
public void onAttachedToEngine(@NonNull FlutterPluginBinding flutterPluginBinding) {
final MethodChannel methodChannel = new MethodChannel(flutterPluginBinding.getBinaryMessenger(), "example-method-channel-name");
}
Your issue
In your dependency’s case, it might be that they do not support usage in a service: they do some caching / singletons and re-use method channels or Flutter JNIs that are no longer attached. They might assume that the plugin is instantiated once, and not re-instantiated when the service runs (or app starts whilst service is already running). They might register callbacks to receive data from the OS, and then not unregister the old one when a new plugin with a new Flutter Engine is created.
There is no quick fix, and the package has to be built to support this.