Debugging log · Build

"Cannot fit requested classes in a single dex file"

The build failed with a message I hadn't seen in years: Cannot fit requested classes in a single dex file, followed by a method count just over 65,536. I'd only added one more library. That library was the straw — my app had been quietly sitting near an old, hard limit, and one more dependency pushed it over.

The short version: a single dex file can reference at most 65,536 methods (the "64K limit"). Your app plus its dependencies exceeded that. Enable multidex to split across several dex files, and trim unused dependencies and code so you're not carrying methods you don't need.

The error

Cannot fit requested classes in a single dex file
(# methods: 68421 > 65536)

That number is the total method references across your code and every library — not just methods you wrote. A handful of large SDKs can account for most of it, which is why adding one more tips you over a line you didn't know you were near.

What the 64K limit is

The dex format addresses methods with a 16-bit index, so a single dex file can reference no more than 65,536 of them. Your own code is usually a small fraction; the bulk comes from libraries — a big analytics or UI SDK can bring tens of thousands of method references on its own. The count is about references, not just your definitions, so pulling in a dependency that itself depends on several others adds up fast.

The fix — enable multidex

Multidex lets your app span multiple dex files, lifting the single-file ceiling. On modern minSdk (21+) it's essentially built in — you just turn it on:

android {
    defaultConfig {
        multiDexEnabled = true
    }
}

If your minSdk is below 21, you also need the support library and, depending on your setup, a MultiDexApplication base class:

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

With multidex on, the build splits classes across dex files and the error goes away. On API 21+ there's little downside; on older devices there's a small startup cost the support library manages.

Better: also shrink the count

Multidex removes the wall, but a bloated method count is worth reducing anyway — it affects app size and build time. Two levers:

Enable R8 shrinking for release. It removes unused code and methods, which can bring you back under the limit on its own and shrinks the app. (Add keep rules as needed — that's a separate, known gotcha.)
Audit heavy dependencies. A giant SDK pulled in for one feature can cost tens of thousands of methods. Use a lighter alternative, or depend on just the module you need instead of a whole bundle.

Reach for multidex first to unblock the build, then look at what's inflating the count. Often a single oversized dependency is most of it — replacing or slimming it is worth more than living with a method count that keeps creeping toward the ceiling.

How to see what's eating the budget

APK Analyzer in Android Studio breaks down method counts per package, so you can see which library dominates.
Check your dependency tree for heavy transitive SDKs you didn't add directly.
Confirm R8 is on for release — a debug-only measurement overstates the count because debug doesn't shrink.

Method counts above are examples — your own numbers come from the build output and APK Analyzer.