# Multidex and the Dex Method Limit
DEX means Android app's (APK) executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app.
The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536 (64K)—including Android framework methods, library methods, and methods in your own code.
To overcome this limit requires configure your app build process to generate more than one DEX file, known as a Multidex.
# Enabling Multidex
In order to enable a multidex configuration you need:
- to change your Gradle build configuration
- to use a
MultiDexApplication
or enable the MultiDex in yourApplication
class
# Gradle configuration
In app/build.gradle
add these parts:
android {
compileSdkVersion 24
buildToolsVersion "24.0.1"
defaultConfig {
...
minSdkVersion 14
targetSdkVersion 24
...
// Enabling multidex support.
multiDexEnabled true
}
...
}
dependencies {
compile 'com.android.support:multidex:1.0.1'
}
# Enable MultiDex in your Application
Then proceed with one of three options:
Multidex by extending MultiDexApplication (opens new window)
Multidex by using MultiDexApplication directly (opens new window)
When these configuration settings are added to an app, the Android build tools construct a primary dex (classes.dex) and supporting (classes2.dex, classes3.dex) as needed.
The build system will then package them into an APK file for distribution.
# Multidex by extending Application
Use this option if your project requires an Application
subclass.
Specify this Application
subclass using the android:name
property in the manifest file inside the application
tag.
In the Application
subclass, add the attachBaseContext()
method override, and in that method call MultiDex.install()
:
package com.example;
import android.app.Application;
import android.content.Context;
/**
* Extended application that support multidex
*/
public class MyApplication extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
}
Ensure that the Application
subclass is specified in the application
tag of your AndroidManifest.xml:
<application
android:name="com.example.MyApplication"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name">
</application>
# Multidex by extending MultiDexApplication
This is very similar to using an Application
subclass and overriding the attachBaseContext()
method.
However, using this method, you don't need to override attachBaseContext()
as this is already done in the MultiDexApplication
superclass.
Extend MultiDexApplication
instead of Application
:
package com.example;
import android.support.multidex.MultiDexApplication;
import android.content.Context;
/**
* Extended MultiDexApplication
*/
public class MyApplication extends MultiDexApplication {
// No need to override attachBaseContext()
//..........
}
Add this class to your AndroidManifest.xml exactly as if you were extending Application:
<application
android:name="com.example.MyApplication"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name">
</application>
# Multidex by using MultiDexApplication directly
Use this option if you don't need an Application
subclass.
This is the simplest option, but this way you can't provide your own Application
subclass. If an Application
subclass is needed, you will have to switch to one of the other options to do so.
For this option, simply specify the fully-qualified class name android.support.multidex.MultiDexApplication
for the android:name
property of the application
tag in the 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>
# Counting Method References On Every Build (Dexcount Gradle Plugin)
The dexcount plugin (opens new window) counts methods and class resource count after a successful build.
Add the plugin in the app/build.gradle
:
apply plugin: 'com.android.application'
buildscript {
repositories {
mavenCentral() // or jcenter()
}
dependencies {
classpath 'com.getkeepsafe.dexcount:dexcount-gradle-plugin:0.5.5'
}
}
Apply the plugin in the app/build.gradle
file:
apply plugin: 'com.getkeepsafe.dexcount'
Look for the output data generated by the plugin in:
../app/build/outputs/dexcount
Especially useful is the .html chart in:
../app/build/outputs/dexcount/debugChart/index.html
# Remarks
# What is dex?
Dex is the name of the file format and encoding to which Android Java code is compiled. Early versions of Android would load and execute dex
binaries directly in a virtual machine named Dalvik. More recent versions of Android use the Android Runtime (ART), which treats dex
files as an intermediate representation and performs further compilations on it prior to running the application.
Dex is a very old file format, in terms of the lifespan of smartphones, and was designed for devices whose main memory was measured in tens of megabytes. The design limitations of those days have remained with us to this day.
# The problem:
The dex
file format encodes a limit to the number of methods that can be referenced in a single binary. Because the portion of the file format that stores the number of references is two bytes long, the maximum number of method references is 0xFFFF
, or 65535. If an application contains more than that number of method references, it will fail to compile.
# What to do about it:
Google has provided a way around this problem, called Multidex. It has compile-time and run-time components. As its name implies, at compile-time it will divide code between one or more dex
files. At runtime, it will teach the default ClassLoader
how to look up classes from these files.
This approach works well on newer devices, but has some substantial drawbacks. It can increase application startup time dramatically, and on older devices can cause Application Not Responding
failures.
Multidex, while effective, should be avoided if possible.
# How to avoid the limit:
Before configuring your app to enable use of 64K or more method references, you should take steps to reduce the total number of references called by your app code, including methods defined by your app code or included libraries. The following strategies can help you avoid hitting the dex reference limit:
- Review your app's direct and transitive dependencies - Ensure any large library dependency you include in your app is used in a manner that outweighs the amount of code being added to the application. A common anti-pattern is to include a very large library because a few utility methods were useful. Reducing your app code dependencies can often help you avoid the dex reference limit.
- Remove unused code with ProGuard - Configure the ProGuard settings (opens new window) for your app to run ProGuard and ensure you have shrinking enabled for release builds. Enabling shrinking ensures you are not shipping unused code with your APKs.
The first point requires diligence and discipline on the part of the developer. When incorporating third-party libraries, one must consider the size of the library. For example, two popular JSON libraries are Jackson and Gson. Functionally they are quite similar, but Gson tends to see greater use in Android. One reason is that Jackson weighs in around 9,000 methods, whereas Gson contributes 1,900.
There are several tools available to help developers keep track of the size of their application:
- dexcount-gradle-plugin (opens new window) reports the number of method references in your APK or AAR on each build
- dex-method-counts (opens new window) is a commandline tool that counts the number of method references in an APK
- www.methodscount.com (opens new window) is a web service which will count the method references in any APK that you upload.