Debugging log · Build

"Cannot fit requested classes in a single dex file"

One afternoon I added a couple of libraries to an app that had been building fine for months, hit run, and the build died at the dex step with a number I recognized instantly: 65536. That figure is the fingerprint of one of Android's oldest gotchas — the 64K method-reference limit — and the fix depends entirely on why you crossed it.

The error

Cannot fit requested classes in a single dex file (# methods: 68123 > 65536)
Execution failed for task ':app:mergeDexDebug'.
> com.android.tools.r8.internal... The number of method references
  in a .dex file cannot exceed 64K.

The exact task name varies (mergeDexDebug, mergeExtDexDebug, etc.) but the "cannot exceed 64K" line is the constant. Note it counts method references, not just your own methods — every framework and library call you touch is counted too, which is why a small app can trip it.

Why the limit exists

The Dalvik/DEX bytecode format uses a 16-bit index to reference methods, and 2¹⁶ is 65,536. It's a structural limit of the file format, not a quota you can raise. Modern apps blow past it easily because a single innocent-looking dependency can drag in a large transitive tree — Google Play Services, Guava, or a kitchen-sink SDK can each add thousands of method references on their own.

Fix 1 — enable multidex

Multidex lets your app span multiple dex files instead of one. How you enable it depends on your minSdk.

minSdk 21 or higher (almost everyone today)

On Android 5.0+ the runtime (ART) handles multiple dex files natively, so you often just need to turn it on:

android {
    defaultConfig {
        multiDexEnabled = true
    }
}

In many modern setups this is already effectively handled, and simply crossing the limit with a 21+ minSdk triggers multidex automatically. If it doesn't, the one line above is all you need — no extra dependency, no Application subclass.

minSdk below 21

Older devices need a support library to load the extra dex files at startup:

dependencies {
    implementation "androidx.multidex:multidex:2.0.1"
}

Then either extend MultiDexApplication, or call MultiDex.install(this) in your Application's attachBaseContext(). Without that install step the app builds but crashes on launch on pre-21 devices.

Fix 2 — shrink instead of split (often better)

Multidex makes the error go away, but if you're only slightly over the limit, the real problem is that you're shipping methods you don't use. Turning on R8 shrinking removes them and can drop you back under 64K with a smaller, faster app as a bonus:

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
        }
    }
}

Beyond that, audit what pulled you over. Prefer implementation over api so dependencies don't leak transitively, import only the specific Play Services modules you need rather than the umbrella artifact, and drop libraries you added for a single helper. A method-count problem is often a dependency-hygiene problem wearing a disguise.

If it still fails after enabling multidex

• Do a clean build — stale dex outputs can linger. ./gradlew clean then rebuild.
• Check you edited the right module — multiDexEnabled goes in the app module, not a library module.
• Pre-21 crash on launch? You enabled multidex but skipped the MultiDex.install / MultiDexApplication step.
• Still ballooning? Run a dependency report and look for one artifact contributing most of the references before reaching for more dex files.

Version numbers above are examples — check for the current multidex release when you add it.