Repository navigation
Breaking changes compromises this plugin with flutter 3.29+ #352
Description
Flutter introduced flutter/flutter#150525 with version 3.29.
This means that Dart code is executed in the same thread as the platform channel (Java/Kotlin/Swift/ObjC code).
But implicitly this is true for all instances of FlutterEngine. For this plugin, which utilizes another FlutterEngine to spawn long living backgroud task in a foreground service, this means that the core functionality is compromised - running a new ForegroundTask will make it run in the same thread as the main Isolate, causing potential delays and stutters to ui, if anyone is doing any heavy lifting in the background (which is likely the main purpose of this plugin).
More details of this are being discussed flutter/flutter#169339 and in the upper issue. Currently the workaround is to opt-in to two flags - DisableMergedPlatformUIThread (and possibly EnablePlatformIsolates?). This will restore the previous state and FlutterEngine will continue to work as before - but these flags are bound to be deprecated at some point, at which this plugin will be potentially compromised and not have a workaround anymore.
Activity
thorito commentedon Aug 26, 2025
Any progress on this issue?
srmncnk commentedon Sep 25, 2025
@Dev-hwang @thorito If anybody is at FlutterCon Berlin ATM, feel free to ping me for a chat.
bcliang commentedon Jan 13, 2026
@srmncnk @thorito with
DisableMergedPlatformUIThreadnow removed, what did your teams decide to do? Our use case is real-time sensor data processing (data received over BLE), where the BLE comm is all handled within the foreground task. For now, we've pinned our flutter sdk to version3.35.7srmncnk commentedon Jan 13, 2026
@bcliang We did not update yet. Waiting for the dart team as they promised to implement isolate thread pinning: dart-lang/sdk#46943
What would semi-solve our problems, but we'd still need to refactor a lot of code, unfortunatelly.
FWIW - are you using BLE via FFI / JNIgen? If not (if you're still using platform channels), then you still tap into the platform thread, regardless from where the Dart call comes from.
bcliang commentedon Jan 13, 2026
Thanks. Having that
dedicatedThreadparameter seems like it would solve our issue.Also, thank you for highlighting the bit about BLE in the platform thread. We started with low level calls but in recent updates had migrated to using
flutter_blue_plus,which does use a platform channels implementation. Still, I think we need to stick with a a separate isolate to handle the more expensive signal processing tasksppamorim commentedon Apr 18, 2026
@srmncnk @bcliang I wrote this document alongside a initial implementation in my fork. Would be this a way to solve that issue in the original repository too?
You can check the whole change proposal too if you find it interesting here (dead link, sorry).
srmncnk commentedon Apr 19, 2026
I only read the TL;DR (one my way to a trail run right now), but my immediate feedback would be this:
ppamorim commentedon Apr 19, 2026
Thank you for the feedback, I will review that soon.
I implemented a solution that hacks the ffi for the callbacks, it's in the list of issues reported.
srmncnk commentedon Apr 20, 2026
@ppamorim Did you use NativeCallable? https://api.dart.dev/dart-ffi/NativeCallable/NativeCallable.listener.html
ppamorim commentedon Apr 20, 2026
@srmncnk Updated the implementation with
NativeCallable. Please note this implementation is just me testing waters for a final solution, I am totally open to change if you have a better suggestion that would solve this with less code.Thank you for the feedback.
srmncnk commentedon Apr 20, 2026
@ppamorim If it works, it's a viable alternative - that is, if you're conformable not having a dedicated thread. Personally I am still waiting for dart thread pinning to be done.
ppamorim commentedon Apr 20, 2026
I am pretty much waiting for that too, we might need to keep the suggested implementation for those apps that aren't on the minimum version that will add support to dart thread pinning. Would reporting my analysis and suggestion to the dart team so they can use as context for their implementation?
srmncnk commentedon Apr 20, 2026
@ppamorim I'd say that making noise on all the relevant issues would help. Probably not a lot, but worth a try.
ppamorim commentedon Apr 30, 2026
@srmncnk I just did some fine tuning into my fix and tested against the
stableflutter version, everything appears to be working fine.