[Tooling] Scudo memory grows when using breakpoints in Android Studio, causing slow hot reload

[Boris-K192]

Steps to reproduce

1. Open a Flutter Project in Android Studio Narwhal 3 Feature Drop | 2025.1.3 (Plugins: Flutter 88.0.0, Dart 251.27623.5)
2. Start a Pixel 9 Pro Emulator (Version 36.1.9-13823996) with Android 16 (vm.heapSize 512 MB, hw.ramSize 6144 MB)
3. Add some Dart Line Breakpoints with "Suspend execution" enabled and some with "Suspend execution" disabled and "Evaluate and log:" enabled with a Message string using $variables (here in sum 17 breakpoints)
4. Open the Flutter DevTools Window in Android Studio and select VM Tools -> Process Memory -> Tree Map
5. change something in the dart flutter code and save (with hot reload).
6. Immediately refresh the Tree Map several times, the "anon:scudo:primary" memory is growing to 3 GB+
7. Disable all breakpoints
8. change some code and init a hot reload again
9. see the difference in hot reload speed and memory consumption

Expected results

• Hot reload refreshes the app in short time under a second
• the memory doesn't grow that much and do not cause a crash or disconnect of the emulator session ( with vm.heapSize 256 MB and standard hw.ramSize)

Actual results

• hot reload time is to long for reassemble
• the scudo primary memory is growing too much which results in an app crash or disconnect the debugger

Code sample

Code sample

[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration

[Upload media here]

Logs

Logs

[Paste your logs here]

Flutter Doctor output

Doctor output

[Paste your output here]

[darshankawar]

1. Open a Flutter Project in Android Studio Narwhal 3 Feature Drop | 2025.1.3 (Plugins: Flutter 88.0.0, Dart 251.27623.5)

@Boris-K192 Thanks for detailed report. Does it only occur with this newest version of AS ? or you observed this in previous version as well ?

2. Start a Pixel 9 Pro Emulator (Version 36.1.9-13823996) with Android 16 (vm.heapSize 512 MB, hw.ramSize 6144 MB)

Does it only occur with emulator ? If not, can you check using physical device as well to see if same stacktrace is observed ?

[Boris-K192]

Does it only occur with emulator ? If not, can you check using physical device as well to see if same stacktrace is observed ?

@darshankawar
No. It's the same behavior on a physical Pixel 9 Pro with the latest Android updates and nearly the same reassemble time ~ 9000 ms vs, ~100 ms when breakpoints are disabled.

I noticed some disconnections of the emulator in previous versions of AS too but didn't investigate it further. I will check that on my laptop.

[darshankawar]

Thanks for the update. Keeping the issue open for team's tracking on reported behavior.

[pq]

@mboetger: this looks possibly vm-related. Did you mean to transfer it to the IDE issue repository?

[mboetger]

@mboetger: this looks possibly vm-related. Did you mean to transfer it to the IDE issue repository?

From Android Flutter triage - it looked IDE related to us. Feel free to move where you think appropriate.

[pq]

Thanks @mboetger!

@bkonyi: I'm inclined to think this is best tracked on flutter proper but curious what you think?