Builder's ~/.gradle/gradle.properties contains an empty org.gradle.jvmargs= and overrides every project's Gradle memory settings

[laboeni]

If you are looking for help, please confirm the following...

• I confirm I have searched the Docs, Codemagic Sample Projects, and GitHub Discussions.
• I confirm the software versions on my local computer match the ones in CI environment (e.g. Xcode version, Gradle version). See here
• I confirm I am able to do a fresh clone of the repository and build the project on my local computer.

Which mobile framework are you using?

Flutter (Dart)

Steps to reproduce

Environment

• Flutter Workflow Editor, Android build step: flutter build appbundle --release --flavor public
• Build ID / URL:
• Default macOS instance; VM reports 10 GB RAM, 3 CPUs; macOS 26.2 (25C56), Xcode 26.2 image
• Flutter 3.44.1 stable, Java 17.0.17 (zulu-17), Gradle 8.14, AGP 8.11.1

Steps to reproduce

1. Take any Flutter project whose android/gradle.properties contains the Flutter template default:
   org.gradle.jvmargs=-Xmx8G -XX:MaxMetaspaceSize=4G -XX:ReservedCodeCacheSize=512m -XX:+HeapDumpOnOutOfMemoryError
2. Add this pre-build script in the Workflow Editor:
   cat ~/.gradle/gradle.properties
   cat > /tmp/heap.gradle <<'EOF'
   println("Gradle daemon maxMemory=" + Runtime.getRuntime().maxMemory()/1024/1024 + " MB")
   EOF
   cd "$CM_BUILD_DIR/android" && ./gradlew help -q -I /tmp/heap.gradle
3. Start a build on the default macOS instance and read the pre-build output.
4. Let the Android build step run on an app large enough that R8 needs more than
   ~2 GB of heap.

Expected results

• ~/.gradle/gradle.properties either does not set org.gradle.jvmargs or sets a real value.
• The init script prints roughly "maxMemory=8192 MB", i.e. the project's -Xmx8G is honored.
• minifyPublicReleaseWithR8 completes.

Actual results

• ~/.gradle/gradle.properties on the builder contains:
  org.gradle.jvmargs=
  org.gradle.java.home=/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home
• Because Gradle gives GRADLE_USER_HOME properties precedence over the project file
  (https://docs.gradle.org/current/userguide/build_environment.html), the empty value wins.
  Gradle then starts the daemon with no -Xmx at all and the JVM falls back to 1/4 of
  physical RAM. The init script prints about "maxMemory=2560 MB" on the 10 GB VM.
• The Android step fails:
  ERROR: R8: java.lang.OutOfMemoryError: Java heap space
  Execution failed for task ':app:minifyPublicReleaseWithR8'.

  A failure occurred while executing com.android.build.gradle.internal.tasks.R8Task$R8Runnable
  > Compilation failed to complete

• The same commit builds locally, and also builds locally with the daemon capped at exactly
  2.5 GB, so the extra margin the CI daemon lacks is decisive.

Notes

• The file is not created by our repository or by the Flutter tool; it appears to be written
  by the Codemagic build agent to pin org.gradle.java.home.
• This affects every project relying on org.gradle.jvmargs in android/gradle.properties.
  Discussions Gradle jvmargs property from gradle.properties is not recognized in codemagic build #2427 and ERROR: R8: java.lang.OutOfMemoryError: Java heap space #2632 show the same unexplained symptom.
• Question: was the empty line introduced recently? Builds of the same code passed on
  2026-09-04 and fail since 2026-09-11.

Build id (optional)

6aa416da63758923bfadb401

[dtrdic]

Hello @laboeni 👋

The java.lang.OutOfMemoryError: Java heap space is indeed caused by the Gradle/R8 process running out of Java heap.

Your android/gradle.properties contains org.gradle.jvmargs=-Xmx8G, but Gradle also loads properties from the Gradle user home (~/.gradle/gradle.properties). Since the build machine currently has org.gradle.jvmargs= defined there, that value takes precedence over the project-level setting. As a result, the -Xmx8G from your project isn't being used.

As a workaround, you can set the following environment variable in your Codemagic environment variables:
JAVA_TOOL_OPTIONS: "-Xmx4g"

This will force the JVM heap size to 4 GB and should resolve the R8 Java heap space error.

Let me know how it goes.

Btw you can also read more about the JavaHeapSpace issue in the blog post here--> https://blog.codemagic.io/java-heap-space-error-and-how-codemagic-helps-to-remediate-it/

[laboeni]

Hi, thanks for confirming the cause.

We'll set JAVA_TOOL_OPTIONS=-Xmx4g as a stopgap. It only works because the daemon
currently gets no -Xmx at all, so it is a workaround for a defect on the build machine
rather than a fix. Three questions and one request:

1. Will the agent stop writing an empty org.gradle.jvmargs= into
   /Users/builder/.gradle/gradle.properties? Gradle gives the user-home file precedence
   over the project's, so an empty value there silently discards the memory settings of
   every project that relies on android/gradle.properties, which is the Flutter template
   default. Omitting the key when there is no value would fix this for everyone.

2. Since when has this line existed? The same commit built fine on 2026-09-04 and failed
   from 2026-09-11 on. If the agent or the default image changed in that window, we'd
   like to know so we can judge the risk for our other workflows.

3. Our VM reported 10 GB RAM and 3 CPUs, while the docs list the Mac mini M2 at
   8 cores / 12 GB. Is that expected for the default instance? It matters here because
   the JVM's fallback heap is a quarter of RAM.

Request: please document this in "Common Android issues" and answer discussions #2427 and
#2632, which describe the same symptom without an explanation. The linked blog post also
states that an -Xmx larger than the machine's capacity "will be disregarded". The JVM does
not do that; what discarded our value was the file above. That sentence sends people
looking in the wrong place, so it would be worth correcting.

Thanks.

[dtrdic]

Hello @laboeni 👋

Thanks for the detailed follow-up.

Regarding the timeline: the empty org.gradle.jvmargs= entry in ~/.gradle/gradle.properties is not something that was introduced around September 11.. it has been part of the build environment forever. Nothing was deployed between September 4 and September 11 that would cause your issue.

What likely changed is the amount of memory available to the JVM during a particular build. The build is running on shared infrastructure, so the resources available to a particular build can vary. In your case, the JVM isn't receiving the project's -Xmx8G setting because the empty org.gradle.jvmargs= in the Gradle user-home properties takes precedence. It therefore falls back to the JVM's default heap sizing based on the memory available to the build environment.

This means the same commit can succeed when there is enough available memory/headroom and fail when R8 reaches a higher peak memory usage than the JVM heap available to it. In your reproduction, the JVM reports a maximum heap of around 2.5 GB, which explains why the build can hit java.lang.OutOfMemoryError: Java heap space during R8.

So our usual recommendation for java.lang.OutOfMemoryError: Java heap space has been to set:

JAVA_TOOL_OPTIONS: "-Xmx4g"

Regarding the 10 GB RAM / 3 CPUs output, our default machines are indeed Mac mini M2 machines with 8-Core CPU / 12 GB RAM. But as i stated before, the important thing to keep in mind is that these are shared build machines, so multiple builds can run on the same physical host in parallel. The resources reported from inside the build environment can therefore be lower than the physical host's total CPU and memory resources.

So the 10 GB / 3 CPUs you're seeing is not necessarily the specification of the underlying Mac mini, but the resources available to that particular build environment. This is expected with our shared infrastructure.

Java heap space it's an old error and we have documented it already here as well under common android issues

That said, your finding regarding the empty org.gradle.jvmargs= overriding the project's setting is useful additional information that isn't currently covered there, so I'll pass this feedback to the team for review.

Thank you again for reporting

[laboeni]

Thanks, that explains it fully. With the heap defaulting to a quarter of the VM's RAM and
the VM size varying per build, our R8 step sat right at the threshold, so the same commit
could pass or fail depending on the machine. We've set JAVA_TOOL_OPTIONS=-Xmx4g and will
keep it permanently.