Unable to execute dex: method ID not in [0, 0xffff]: 65536

Question

I have seen various versions of the dex erros before, but this one is new. clean/restart etc won't help. Library projects seems intact and dependency seems to be linked correctly.

Unable to execute dex: method ID not in [0, 0xffff]: 65536 Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536 

or

Cannot merge new index 65950 into a non-jumbo instruction 

or

java.util.concurrent.ExecutionException: com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536 

tl;dr: Official solution from Google is finally here!

http://developer.android.com/tools/building/multidex.html

Only one small tip, you will likely need to do this to prevent out of memory when doing dex-ing.

dexOptions {         javaMaxHeapSize "4g" } 

There's also a jumbo mode that can fix this in a less reliable way:

dexOptions {         jumboMode true } 

Update: If your app is fat and you have too many methods inside your main app, you may need to re-org your app as per

http://blog.osom.info/2014/12/too-many-methods-in-main-dex.html

Answer 1

Update 3 (11/3/2014)
Google finally released official description.

---

Update 2 (10/31/2014)
Gradle plugin v0.14.0 for Android adds support for multi-dex. To enable, you just have to declare it in build.gradle:

android {    defaultConfig {       ...       multiDexEnabled  true    } } 

If your application supports Android prior to 5.0 (that is, if your minSdkVersion is 20 or below) you also have to dynamically patch the application ClassLoader, so it will be able to load classes from secondary dexes. Fortunately, there's a library that does that for you. Add it to your app's dependencies:

dependencies {   ...   compile 'com.android.support:multidex:1.0.0' }  

You need to call the ClassLoader patch code as soon as possible. MultiDexApplication class's documentation suggests three ways to do that (pick one of them, one that's most convenient for you):

1 - Declare MultiDexApplication class as the application in your AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android"     package="com.example.android.multidex.myapplication">     <application         ...         android:name="android.support.multidex.MultiDexApplication">         ...     </application> </manifest> 

2 - Have your Application class extend MultiDexApplication class:

public class MyApplication extends MultiDexApplication { .. } 

3 - Call MultiDex#install from your Application#attachBaseContext method:

public class MyApplication {     protected void attachBaseContext(Context base) {         super.attachBaseContext(base);         MultiDex.install(this);         ....     }     .... } 

---

Update 1 (10/17/2014):
As anticipated, multidex support is shipped in revision 21 of Android Support Library. You can find the android-support-multidex.jar in /sdk/extras/android/support/multidex/library/libs folder.

---

Multi-dex support solves this problem. dx 1.8 already allows generating several dex files.
Android L will support multi-dex natively, and next revision of support library is going to cover older releases back to API 4.

It was stated in this Android Developers Backstage podcast episode by Anwar Ghuloum. I've posted a transcript (and general multi-dex explanation) of the relevant part.

Answer 2

As already stated, you have too many methods (more than 65k) in your project and libs.

Prevent the Problem: Reduce the number of methods with Play Services 6.5+ and support-v4 24.2+

Since often the Google Play services is one of the main suspects in "wasting" methods with its 20k+ methods. Google Play services version 6.5 or later, it is possible for you to include Google Play services in your application using a number of smaller client libraries. For example, if you only need GCM and maps you can choose to use these dependencies only:

dependencies {     compile 'com.google.android.gms:play-services-base:6.5.+'     compile 'com.google.android.gms:play-services-maps:6.5.+' } 

The full list of sub libraries and it's responsibilities can be found in the official google doc.

Update: Since Support Library v4 v24.2.0 it was split up into the following modules:

support-compat, support-core-utils, support-core-ui, support-media-compat and support-fragment

dependencies {     compile 'com.android.support:support-fragment:24.2.+' } 

Do note however, if you use support-fragment, it will have dependencies to all the other modules (ie. if you use android.support.v4.app.Fragment there is no benefit)

See here the official release notes for support-v4 lib

---

Enable MultiDexing

Since Lollipop (aka build tools 21+) it is very easy to handle. The approach is to work around the 65k methods per dex file problem to create multiple dex files for your app. Add the following to your gradle build file (this is taken from the official google doc on applications with more than 65k methods):

android {     compileSdkVersion 21     buildToolsVersion "21.1.0"      defaultConfig {         ...         // Enabling multidex support.         multiDexEnabled true     }     ... }  dependencies {   compile 'com.android.support:multidex:1.0.1' } 

The second step is to either prepare your Application class or if you don't extend Application use the MultiDexApplication in your Android Manifest:

Either add this to your Application.java

@Override   protected void attachBaseContext(Context base) {     super.attachBaseContext(base);     MultiDex.install(this);   } 

or use the provided application from the mutlidex lib

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android"     package="com.example.android.myapplication">     <application         ...         android:name="android.support.multidex.MultiDexApplication">         ...     </application> </manifest> 

---

Prevent OutOfMemory with MultiDex

As further tip, if you run into OutOfMemory exceptions during the build phase you could enlarge the heap with

android {     ...     dexOptions {         javaMaxHeapSize "4g"     } } 

which would set the heap to 4 gigabytes.

See this question for more detail on the dex heap memory issue.

---

Analyze the source of the Problem

To analyze the source of the methods the gradle plugin https://github.com/KeepSafe/dexcount-gradle-plugin can help in combination with the dependency tree provided by gradle with e.g.

.\gradlew app:dependencies 

See this answer and question for more information on method count in android