If you’ve read my previous post about breaking Android’s 65K limit (and if you hadn’t, what are you waiting for?), you’re already pretty familiar with Android’s 65K limit, why it exists and how to solve it. Which means you’ve been itching to know what the future of multidexing has in store (and what does a tooth-fairy-supporting candy-on-a-stick has to do with it).

As small recap to start with, if you will:

Since its’ inception, Android ran a virtual machine called Dalvik. The Dalvik VM ran a compiled file called dex (Dalvik Executable) which has a tiny limitation – even though the file contains the entire code for the application, its id field was limited to 4 hexadecimal digits. So when an application had over 0xffff methods (=65,536 in decimal), the dex file simply could not be created, meaning applications with so many methods could not be created.

That posed a problem as applications became more and more diverse and complex, and as many developers looked to speed their development process by not doing everything from scratch, but by using more and more third-party libraries (SDKs) that help them achieve their goals faster.

Android released a support library which helps you create an application with over 65K methods. In a nutshell, the compilation process to of Java bytecode to dex was enhanced so that once the limit is reached, a secondary dex file is created. The support library then offered a static method Multidex.install which is called when the app is being launched and tells the class loader to look for methods in places other than the one dex file is expects.

However, we’ve seen the solution is not ideal. Issues ranging from prolonged compilation time to a static process repeating every single time the app is launched made the multidex solution a workaround compromise rather than something Android developers could truly trust. What might be the most burning issue is the lack of ability to predex (compile the not-likely-to-change parts of your app to dex only once; Again, for more information, take a look at part 1).

Continue Reading