Common Android memory issues

These tips can help reduce the memory footprint during your Android builds.


  1. They don't work reliably within the cloud environment regardless of memory configuration. We have some workarounds available here


  1. Start with limiting the Java heap size. There are several envars to do this.  _JAVA_OPTIONS is for Oracle JVM which is most likely the one you're using. If your config doesn't have lots of service images give a hefty amount of heap freedom for testing. _JAVA_OPTIONS: -Xmx3g tells Java the heap size cannot grow larger than 3GB which is 75% of the default medium resource class. If there are many other services running in the job you might to go with 2g which leaves more room for other services.


  1. Make sure they are running Gradle with --no-daemon. The daemon runs by default and is helpful when running locally as it speeds up recompilation. This is not needed in CI since every compilation is fresh. It takes up more memory for no benefit. You can pass --no-daemon directly to the gradlew script or set org.gradle.daemon=false in your file.
  2. By default, Gradle will spawn a worker process for every available CPU. CircleCI Cloud will erroneously report within to jobs that they have 32 available. With the default resource class, they actually only have access to 2. Setting --max-workers=2 will limit Gradle from spawning too many workers.

    Many options for configuring gradle can also be applied through the gradle fie
    testOptions {
    unitTests.all {
      maxHeapSize = "1024m"


  1. By default, Kotlin will spawn a daemon alongside Gradle. This is similar to the Gradle daemon and isn't necessary for CI. Kotlin can be told to run within the same memory allocation as Gradle by setting GRADLE_OPTS=-Dkotlin.compiler.execution.strategy=in-process 


Still hitting memory issues? Increase the resource class.

Was this article helpful?
8 out of 11 found this helpful


1 comment

Please sign in to leave a comment.