Flutter 3.32.0 threading issue - everything running in the same thread is a bad thing

[srmncnk]

Steps to reproduce

We have an app with a long-living foreground service which creates another flutter engine.
Therefor we have the main (ui) engine and the long-living (service) engine, which used to run in a separate thread.

In the separate thread we were able to do tasks that require ui not being blocked, access to plugins and ability for native code to call back to Dart. And the fact that the engine was created from foreground service told the OS not to kill it - UI may have been killed but foreground service with its respective engine survived.

Now - with breaking changes introduced regarding threading in 3.29.0 - this completely breaks our app with zero chance to do any kind of workarounds.

We implemented GetThreadID via FFI from C++ to verify this.

Additionally, we also observed that plain Isolate spawn only one additional thread and they all are running there, regardless of how many they are.

Expected results

We expect that each engine runs in its own thread or at least has the exposed capability of spawning an additional thread. And that each isolate has its own thread.

Actual results

Every engine runs in the same (first) thread. Every spawned isolate runs in the same thread (though not the same as the thread all engine run in).

Code sample

Code sample

[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration

[Upload media here]

Logs

Logs

I/flutter (13589): 14:25:20.399 🖳′ 💡 UI isolate hash: 179506388 ∑26ms
I/flutter (13589): 14:25:20.399 🖳′ 💡 UI isolate thread ID: 13589 ∑27ms
I/flutter (13589): 14:25:20.410 🖳′ 💡 UI method channel thread ID: 13589 ∑38ms
I/flutter (13589): 14:25:21.436 🖥 💡 Service isolate hash: 447516949 ∑16ms
I/flutter (13589): 14:25:21.436 🖥 💡 Service isolate thread ID: 13589 ∑16ms
I/flutter (13589): 14:25:21.441 🖥 💡 Service method channel thread ID: 13589 ∑21ms
I/flutter (13589): #️⃣ tileServerWorker 0 isolate hash: 176808262, thread ID: 13960 ∑1ms
I/flutter (13589): #️⃣ tileServerWorker 1 isolate hash: 420286146, thread ID: 13960 ∑882µs
I/flutter (13589): #️⃣ tileServerWorker 2 isolate hash: 920345256, thread ID: 13960 ∑570µs
I/flutter (13589): #️⃣ tileServerWorker 3 isolate hash: 20492889, thread ID: 13960 ∑860µs

Flutter Doctor output

Doctor output

[✓] Flutter (Channel stable, 3.32.0, on Ubuntu 24.04.2 LTS 6.11.0-26-generic, locale en_US.UTF-8) [57ms]
    • Flutter version 3.32.0 on channel stable at /home/simon/fvm/versions/3.32.0
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision be698c48a6 (4 days ago), 2025-05-19 12:59:14 -0700
    • Engine revision 1881800949
    • Dart version 3.8.0
    • DevTools version 2.45.1

[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0) [900ms]
    • Android SDK at /home/simon/Android/Sdk
    • Platform android-35, build-tools 35.0.0
    • Java binary at: /home/simon/.sdkman/candidates/java/current/bin/java
      This JDK is specified in your Flutter configuration.
      To change the current JDK, run: `flutter config --jdk-dir="path/to/jdk"`.
    • Java version OpenJDK Runtime Environment Zulu17.54+21-CA (build 17.0.13+11-LTS)
    • All Android licenses accepted.

[✓] Chrome - develop for the web [14ms]
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop [133ms]
    • Ubuntu clang version 18.1.3 (1ubuntu1)
    • cmake version 3.28.3
    • ninja version 1.11.1
    • pkg-config version 1.8.1
    ! Unable to access driver information using 'eglinfo'.
      It is likely available from your distribution (e.g.: apt install mesa-utils)

[✓] Android Studio (version 2024.2) [12ms]
    • Android Studio at /home/simon/Development/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 21.0.3+-12282718-b509.11)

[✓] VS Code (version unknown) [11ms]
    • VS Code at /snap/code/current/usr/share/code
    • Flutter extension version 3.110.0
    ✗ Unable to determine VS Code version.

[✓] Connected device (3 available) [178ms]
    • EML L29 (mobile) • AEJ7N18A09001545 • android-arm64  • Android 10 (API 29)
    • Linux (desktop)  • linux            • linux-x64      • Ubuntu 24.04.2 LTS 6.11.0-26-generic
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 136.0.7103.113

[✓] Network resources [1,098ms]
    • All expected network resources are available.

• No issues found!

[srmncnk]

After digging around I found the switch, EnableMergedPlatformUIThread on Android in the manifest file. But setting this to false does not change the behaviour on Android with 3.32. Did not check on iOS.

<meta-data android:name="io.flutter.embedding.android.EnableMergedPlatformUIThread" android:value="false" />

[darshankawar]

@srmncnk Thanks for the report. Per #150525 (comment), please provide us a reproducible code sample that shows reported behavior.

[srmncnk]

@darshankawar Thanks for reaching out.

In the meantime, we were able to find the correct switch and this is what's now working for us with 3.32:

<meta-data android:name="io.flutter.embedding.android.EnablePlatformIsolates" android:value="false" />  <!-- Makes every plain isolate run in its own thread -->
<meta-data android:name="io.flutter.embedding.android.DisableMergedPlatformUIThread" android:value="true" /> <!-- Makes service isolate run in a separate thread -->

These switches are of utmost importance for us. Please do not deprecate or remove them as a lot of projects depend on it.

To ilustrate this, we've made a simple reproducible case (https://github.com/naviter/flutter_threading) for Android using FFI.
Key takeaways:

• we get the thread id from C++ using FFI
• thread ID from main isolate differs from thread id from foreground service - this is what we want and how it has been working before
• newly spawned isolates run in their own threads and don't use a threadpool under the hood - what we want and how it was before
• the plugin used for this is a very popular one and is used by a lot of projects; we use a different one (background_locator) and community still uses flutter_isolate - to name just a few

Why we are doing this: we need a continously running isolate (spawned by the second engine from the foreground service) that does things in background, has plugin access and plugin callbacks and is not killed due to being spawned from a foreground service. UI still needs to be snappy, but just reacts to whatever isolate from the second engine is doing.

[darshankawar]

Thanks for the update and repo. Using it, I was able to replicate the reported behavior in latest stable and master.

stable : 3.32.0
master : 3.33.0-1.0.pre.228