It happens in the blink of an eye. Before, you are an happy Android developer, head down on your (or your company’s) application, adding the coolest libraries to provide more functionalities and to write simpler code. Afterwards, you stare at the dreaded output that states:

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

And you are stuck, unable to create the DEX file for the APK. You have no idea of its meaning, nor the slightest clue about how to get around it. All you can do is going all in for the most logic option: panic.

Getting to know your enemy

After you try all the usual tricks (which involve, in order: cleaning the project, restarting the IDE, building via command line, restarting your laptop and your friend’s too, and going out to see if in 10 minutes the problem disappears on its own), you face the hard truth: the problem is here to stay. So it might as well be worth knowing what is causing it.

There are a ton of different posts on the problem: this, this one, this one as well; oh, and that and this one too. So, what’s happening here?

Basically, it seems like you’ve hit something which is commonly (and improperly) referred to as the Dalvik 65K methods limit. In short (thanks fadden):

You can reference a very large number of methods in a DEX file, but you can only invoke the first 65536, because that’s all the room you have in the method invocation instruction. […] the limitation is on the number of methods referenced, not the number of methods defined. If your DEX file has only a few methods, but together they call 70,000 different externally-defined methods, you’re going to exceed the limit.

There you go. Your application (or again, your company’s) has too many methods, both written by you or bundled inside the libraries’ JAR files. For this reason, the dx tool cannot write some methods addresses because it simply won’t fit the space reserved for that particular field in the DEX file (which, in turn, contains the compiled Java classes). For this reason, this problem should be referred to as the DEX 65K methods limit.

And yes, you got it right. This issue won’t disappear even when Android will switch to the new ART runtime, unless Google decides to “fix” the DEX format or ditch it for another one.