CI failing in Android build as out of memory

[gnprice]

Starting Monday around 48 hours ago, our CI runs have all been failing with a "Java heap space" error in the android suite, like this:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:compileDebugKotlin'.
> Error while evaluating property 'friendPathsSet$kotlin_gradle_plugin_common' of task ':app:compileDebugKotlin'.
   > Could not resolve all files for configuration ':app:debugCompileClasspath'.
      > Failed to transform armeabi_v7a_debug-1.0.0-1b328e5729f5f67e0c5eef98e71346eab09362d4.jar (io.flutter:armeabi_v7a_debug:1.0.0-1b328e5729f5f67e0c5eef98e71346eab09362d4) to match attributes {artifactType=android-classes-jar, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-api}.
         > Execution failed for JetifyTransform: /home/runner/.gradle/caches/modules-2/files-2.1/io.flutter/armeabi_v7a_debug/1.0.0-1b328e5729f5f67e0c5eef98e71346eab09362d4/b10386682e6ae1fede7cec7ff90ed6852c8a3d64/armeabi_v7a_debug-1.0.0-1b328e5729f5f67e0c5eef98e71346eab09362d4.jar.
            > Java heap space

So the JVM under Gradle is running out of memory.

The workaround is we'll increase the limit of memory Gradle is allowed to use, in #1324.

It turns out the increase in needed memory is real steep, though — the limit was 1.5 GiB and it was running fine, and now (as @PIG208 determined in #1324) even 2.5 GiB isn't enough. (The PR makes it 3 GiB.) So it'd be good to spend a bit of time trying to pin down what caused the change, to see if there's something to fix upstream.

Chat thread: https://chat.zulip.org/#narrow/channel/516-mobile-dev-help/topic/Execution.20failed.20for.20task.20'.3Aapp.3AcompileDebugKotlin'/near/2076887

[gnprice]

After some further investigation:

The failures started when this upstream PR landed:

• Remove default for stripped option in engine/src/flutter/tools/gn, don't strip by default on android flutter/flutter#161546

A CI run succeeded using the upstream commit just before that one; and then the next CI run used that upstream commit, and CI failed consistently from there.

That PR is intentionally adding another step that happens in Android builds, when the Android NDK gets downloaded. Discussion on this upstream issue:

• 12% regression in android compilation time flutter/flutter#162675

which is about the effect on run times; it's unsurprising that it also affects memory use.

---

It's a bit unfortunate that Flutter Android builds in a CI environment are now substantially more memory-hungry (was <1.5 GiB, now >2.5 GiB), and presumably slower too. But so be it — the new step serves a valuable purpose: flutter/flutter#60240 (comment)

And a mitigating factor is that this seems to only affect running in a more or less fresh environment, like in CI — when I tried to reproduce on my desktop, the build consistently worked even with the old 1.5 GiB limit.

[gnprice]

Update: #1324 increasing the limit to 3 GiB made CI pass most of the time (instead of never), but it's been flaky:
https://chat.zulip.org/#narrow/channel/243-mobile-team/topic/Gradle.20out.20of.20memory/near/2082072

In #1331 we bumped the limit further, to 4 GiB. We'll monitor to see if flakes continue.

[gnprice]

Well, here's one failure of this kind after the bump to 4 GiB:
https://github.com/zulip/zulip-flutter/actions/runs/13152142737/job/36817594452?pr=1327

I'll make a separate issue thread to better track the flakiness.

(edit: Never mind: #1360 (comment))