Out of memory error: Java heap memory on Android Studio

Question

How do I fix java.lang.OutOfMemoryError: Java heap space when compiling my Android project?

I get this after I upgraded to version 1 of Android Studio. But, I don't think this is the problem. Most likely when I start upgrading my app to SDK 21 (before this was SDK 20). But I wasn't so sure either.

I've googled around for some fix, but couldn't find one that works. Most of the fix are for Eclipse IDE.

This is the full logcat error that I get when compiling:

warning: Ignoring InnerClasses attribute for an anonymous inner class
(net.lingala.zip4j.unzip.Unzip$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(net.lingala.zip4j.unzip.Unzip$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(net.lingala.zip4j.util.ArchiveMaintainer$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(net.lingala.zip4j.util.ArchiveMaintainer$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(net.lingala.zip4j.zip.ZipEngine$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.

UNEXPECTED TOP-LEVEL ERROR:
java.lang.OutOfMemoryError: Java heap space
    at com.android.dx.rop.code.RegisterSpec$ForComparison.toRegisterSpec(RegisterSpec.java:642)
    at com.android.dx.rop.code.RegisterSpec.intern(RegisterSpec.java:73)
    at com.android.dx.rop.code.RegisterSpec.make(RegisterSpec.java:90)
    at com.android.dx.cf.code.RopperMachine.run(RopperMachine.java:323)
    at com.android.dx.cf.code.Simulator$SimVisitor.visitLocal(Simulator.java:612)
    at com.android.dx.cf.code.BytecodeArray.parseInstruction(BytecodeArray.java:412)
    at com.android.dx.cf.code.Simulator.simulate(Simulator.java:94)
    at com.android.dx.cf.code.Ropper.processBlock(Ropper.java:787)
    at com.android.dx.cf.code.Ropper.doit(Ropper.java:742)
    at com.android.dx.cf.code.Ropper.convert(Ropper.java:349)
    at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:280)
    at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:137)
    at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:93)
    at com.android.dx.command.dexer.Main.processClass(Main.java:729)
    at com.android.dx.command.dexer.Main.processFileBytes(Main.java:673)
    at com.android.dx.command.dexer.Main.access$300(Main.java:82)
    at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:602)
    at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
    at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
    at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
    at com.android.dx.command.dexer.Main.processOne(Main.java:632)
    at com.android.dx.command.dexer.Main.processAllFiles(Main.java:505)
    at com.android.dx.command.dexer.Main.runMultiDex(Main.java:332)
    at com.android.dx.command.dexer.Main.run(Main.java:243)
    at com.android.dx.command.dexer.Main.main(Main.java:214)
    at com.android.dx.command.Main.main(Main.java:106)

 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:dexDebug'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
    C:\Users\piracyde25\android-sdks\build-tools\21.1.1\dx.bat --dex --no-optimize --multi-dex --main-dex-list C:\Users\piracyde25\workspace\Baucar\app\build\intermediates\multi-dex\debug\maindexlist.txt --output C:\Users\piracyde25\workspace\Baucar\app\build\intermediates\dex\debug --input-list=C:\Users\piracyde25\workspace\Baucar\app\build\intermediates\tmp\dex\debug\inputList.txt
Error Code:
    3
Output:
    warning: Ignoring InnerClasses attribute for an anonymous inner class
    (net.lingala.zip4j.unzip.Unzip$1) that doesn't come with an
    associated EnclosingMethod attribute. This class was probably produced by a
    compiler that did not target the modern .class file format. The recommended
    solution is to recompile the class from source, using an up-to-date compiler
    and without specifying any "-target" type options. The consequence of ignoring
    this warning is that reflective operations on this class will incorrectly
    indicate that it is *not* an inner class.
    warning: Ignoring InnerClasses attribute for an anonymous inner class
    (net.lingala.zip4j.unzip.Unzip$2) that doesn't come with an
    associated EnclosingMethod attribute. This class was probably produced by a
    compiler that did not target the modern .class file format. The recommended
    solution is to recompile the class from source, using an up-to-date compiler
    and without specifying any "-target" type options. The consequence of ignoring
    this warning is that reflective operations on this class will incorrectly
    indicate that it is *not* an inner class.
    warning: Ignoring InnerClasses attribute for an anonymous inner class
    (net.lingala.zip4j.util.ArchiveMaintainer$1) that doesn't come with an
    associated EnclosingMethod attribute. This class was probably produced by a
    compiler that did not target the modern .class file format. The recommended
    solution is to recompile the class from source, using an up-to-date compiler
    and without specifying any "-target" type options. The consequence of ignoring
    this warning is that reflective operations on this class will incorrectly
    indicate that it is *not* an inner class.
    warning: Ignoring InnerClasses attribute for an anonymous inner class
    (net.lingala.zip4j.util.ArchiveMaintainer$2) that doesn't come with an
    associated EnclosingMethod attribute. This class was probably produced by a
    compiler that did not target the modern .class file format. The recommended
    solution is to recompile the class from source, using an up-to-date compiler
    and without specifying any "-target" type options. The consequence of ignoring
    this warning is that reflective operations on this class will incorrectly
    indicate that it is *not* an inner class.
    warning: Ignoring InnerClasses attribute for an anonymous inner class
    (net.lingala.zip4j.zip.ZipEngine$1) that doesn't come with an
    associated EnclosingMethod attribute. This class was probably produced by a
    compiler that did not target the modern .class file format. The recommended
    solution is to recompile the class from source, using an up-to-date compiler
    and without specifying any "-target" type options. The consequence of ignoring
    this warning is that reflective operations on this class will incorrectly
    indicate that it is *not* an inner class.

    UNEXPECTED TOP-LEVEL ERROR:
    java.lang.OutOfMemoryError: Java heap space
        at com.android.dx.rop.code.RegisterSpec$ForComparison.toRegisterSpec(RegisterSpec.java:642)
        at com.android.dx.rop.code.RegisterSpec.intern(RegisterSpec.java:73)
        at com.android.dx.rop.code.RegisterSpec.make(RegisterSpec.java:90)
        at com.android.dx.cf.code.RopperMachine.run(RopperMachine.java:323)
        at com.android.dx.cf.code.Simulator$SimVisitor.visitLocal(Simulator.java:612)
        at com.android.dx.cf.code.BytecodeArray.parseInstruction(BytecodeArray.java:412)
        at com.android.dx.cf.code.Simulator.simulate(Simulator.java:94)
        at com.android.dx.cf.code.Ropper.processBlock(Ropper.java:787)
        at com.android.dx.cf.code.Ropper.doit(Ropper.java:742)
        at com.android.dx.cf.code.Ropper.convert(Ropper.java:349)
        at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:280)
        at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:137)
        at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:93)
        at com.android.dx.command.dexer.Main.processClass(Main.java:729)
        at com.android.dx.command.dexer.Main.processFileBytes(Main.java:673)
        at com.android.dx.command.dexer.Main.access$300(Main.java:82)
        at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:602)
        at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
        at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
        at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
        at com.android.dx.command.dexer.Main.processOne(Main.java:632)
        at com.android.dx.command.dexer.Main.processAllFiles(Main.java:505)
        at com.android.dx.command.dexer.Main.runMultiDex(Main.java:332)
        at com.android.dx.command.dexer.Main.run(Main.java:243)
        at com.android.dx.command.dexer.Main.main(Main.java:214)
        at com.android.dx.command.Main.main(Main.java:106)

Is it because of one jar library I used (zip4j)? I did try to remove it, but the OOM error still occurs. Any idea how to fix this?

Edit:

I've also edited gradlew file to increase the -Xmx size.

GRADLE_OPTS="$GRADLE_OPTS \"-Xdock:name=$APP_NAME\" \"-Xdock:icon=$APP_HOME/media/gradle.icns\" \"-Xmx2048M \"-XX:MaxPermSize=512M\" \"-XX:ReservedCodeCacheSize=512M\""

Nothing changes.

Edit 2:

Also did this fix but couldn't help it too:

Try the following:

Ctrl + Alt + S -> Compiler -> Gradle

InVM Options field write:

-Xmx2048m -XX:MaxPermSize=512m

Check heap dump ...you also can add android:largeHeap="true" — Prachi, Dec 12 '14 at 06:44
@Prachi nothing helps. I can't even compile and run it, how am I suppose to check the heap dump? — emen, Dec 12 '14 at 07:14
I have tried this [Solution](https://stackoverflow.com/a/55429299/10288513) and it worked for me. — Gourav Samre, Mar 30 '19 at 07:49
If anyone comes across this problem and is on AS 3.5+ on Mac, you can try [this GitHub](https://github.com/gradle/gradle/issues/8139#issuecomment-543050424) solution. Among the ocean of different answers here on SO, this was what worked for me (and many others by comment's the reactions). — Ícaro, Feb 19 '20 at 21:41

score 33 · Answer 1 · answered Jan 13 '15 at 21:17

33

This is old, but just add this to the build file

dexOptions {
    javaMaxHeapSize "2g"
}

answered Jan 13 '15 at 21:17

Graeme

1,080
1
10
29

Graeme thanks! Parameters in 'gradle.properties' were for unknown reason always ignored. This helped perfectly! – Menion Asamm Nov 18 '16 at 18:24
If using *dx* from the command line, you need to pass the flag *-JXmx2g*: `dx -JXmx2g --dex ...` – sffc Jan 06 '17 at 04:47
Modified to "4g" and the outofmemory error happens from time to time. – zwcloud Oct 29 '19 at 09:43

score 25 · Answer 2 · answered Oct 18 '17 at 06:42

I had a similar issue on Android Studio 2.3.3. APK packaging would fail saying Java heap space when building from Android Studio and trying to process a 300MB .so library. In my case two things were needed to fix it. Your build.gradle should contain something like that:

android {
    dexOptions {
        javaMaxHeapSize "4G"
    }
}

At the root of your project you need to have a file named gradle.properties containing the following:

# That's needed for java to be able the create the APK with our 300MB native  library
# Basically we grant java a 4GB heap.
org.gradle.jvmargs=-Xmx4608m

emen · Accepted Answer · 2016-04-14T08:47:20.017

9

I've finally solved it by limiting the Google Play service in gradle dependency.

The problem however was caused by the Google Play service, and by simply change it to a specific library, it is now solved.

 com.google.android.gms:play-services-base:6.5.87

UPDATE

More info on android guides

edited Apr 14 '16 at 08:47

answered Dec 18 '14 at 02:36

emen

5,201
10
52
88

score 8 · Answer 4 · answered Feb 25 '19 at 22:54

8

Build => Clean Project

then

Build => Rebuild Project

When I do this, it always fixes for me.

answered Feb 25 '19 at 22:54

Ferit Kartal

81
1
2

1

I see this advice in a lot of issues and it's true that a rebuild can fix most of them. What bothers me is why we have to clean first? Isn't rebuild automatically do a clean? – rtsketo Nov 26 '20 at 12:53

score 4 · Answer 5 · answered Apr 14 '16 at 08:42

4

assign more memory to Gradle in the project's gradle.properties file.For example:

org.gradle.jvmargs=-Xmx1024m

answered Apr 14 '16 at 08:42

HongGang Jing

41
2

Just to reiterate, this needs to go in the `gradle.properties` file, not `build.gradle`. – arlomedia Nov 06 '20 at 02:06

score 3 · Answer 6 · answered Jul 05 '16 at 08:31

3

i'm using Windows OS. I solved this by updating _JAVA_OPTIONS to '-Xmx1024m'

Win + X, choose SYSTEM
Choose 'Advanced system settings'
Choose 'Environment Variables'
Create / Edit a variable named as '_JAVA_OPTIONS'
update variable value as -Xmx1024m

click to see snapshot

answered Jul 05 '16 at 08:31

Weng Hong Wong

66
4

Solved my problem. bundletool was reporting memory errors +1. – jtth Aug 07 '19 at 00:36

score 3 · Answer 7 · answered Apr 09 '19 at 17:43

Here is what I did:

1st step: In your App, go to GRADLE SCRIPTS -> GRADLE.PROPERTIES -> change org.gradle.jvmargs=-Xmxm to org.gradle.jvmargs=-Xmx4G

2nd Step: In your App, go to GRADLE SCRIPTS -> build.gradle -> in the android{

//add this line:

dexOptions {
   javaMaxHeapSize = "4G"
   }
}

score 2 · Answer 8 · answered Dec 12 '14 at 07:54

2

you have changed the wrong arguments, you should increase the size on -XX:MaxPermSize=512M to -XX:MaxPermSize=2048M or so :) because the android emulator uses a lot of RAM.

answered Dec 12 '14 at 07:54

aurelius

3,454
6
32
65

Same error :( Should I add more memory to the maxperm? – emen Dec 12 '14 at 08:01
yes, do that and see what happens :) BTW: how much RAM do you have on your machine? – aurelius Dec 12 '14 at 08:35
This is not correct, XX:MaxPermSize is used to store "data needed by the virtual machine to describe objects that do not have an equivalence at the Java language level. For example objects describing classes and methods are stored in the permanent generation." (http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html) I can hardly think of any scenario where AimanB's code and Android Studio would require more than 512MB of RAM to store Classes (*not* Objects) and Methods. The problem lie elsewhere – Kai Dec 12 '14 at 08:36
1

You have a point there. Maybe the best thing now would be to create a dump with jvisualVM (it's in the bin folder of your jdk) and then analyze it with MAT, which is free and better for analyzing dumps. – aurelius Dec 12 '14 at 08:41
start the jvisualVM before you start the emulator, and you can see in the left side of jvisualVM's window the active processes, start then the emulator, you will see in JVM the emulator's process and open the monitor tab, you will see how much heap will allocate for the process. After your java android process crashes create a dump with JVM and then open that dump with MAT and investigate all the leaks. – aurelius Dec 12 '14 at 08:44

score 2 · Answer 9 · answered Aug 20 '15 at 08:47

2

The answers above are for gradle builds (or the general -Xmx). In case someone gets here for a non-gradle project, I solved the issue by increasing the maximum heap size of DEX in android studio settings => Build, Execution, Deployment => Compiler => Android Compilers

answered Aug 20 '15 at 08:47

chef

481
4
8

I found this config in File - > other Settings -> Default Settings -> Build, Execution, Deployment -> Compiler -> Android Compilers – mianlaoshu Mar 01 '17 at 09:57

twenk11k · Answer 10 · 2019-10-30T07:27:46.737

This issue also may happen with usage of the debug build of Proguard. To solve it change minifyEnabled and shrinkResources to false.

android {
...
buildTypes {
    release {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android.txt')
    }

    debug {
        minifyEnabled false
        shrinkResources false
        proguardFiles getDefaultProguardFile('proguard-android.txt')
    }
} }

score 0 · Answer 11 · answered Jun 02 '20 at 10:09

None of the answers worked for me but finally I found something that worked in my case:

Automatically managing paging files size

In windows:

Under "Advanced System Settings"
Advanced Tab
Performance section, settings...
Advanced Tab
Virtual memory... Change...
Select Automatically manage paging files size for all drives

I don't remember why I had this unchecked but this was causing trouble in my gradle builds (with flutter).

score 0 · Answer 12 · answered May 14 '21 at 05:34

0

Open gradle.properties files in the root of you project

Comment it out: # org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Yes! Just remove # in front of the line Hahahaha!

answered May 14 '21 at 05:34

ItSNeverLate

81
2
4

score 0 · Answer 13 · answered May 24 '21 at 14:43

0

You can do this with the UI in Android Studio, with friendly defaults

answered May 24 '21 at 14:43

Daniel Wilson

16,545
10
76
108

score -2 · Answer 14 · answered Dec 24 '19 at 09:03

-2

Just add this to the gradle file:

android{
testOptions {
        ....
        unitTests.all {
            jvmArgs "-Xmx2g" // to avoid outOfMemory exception
        }
        ....
    }
}

answered Dec 24 '19 at 09:03

Houssin Boulla

1,764
1
13
16

Out of memory error: Java heap memory on Android Studio

14 Answers14

Linked