Introduction

Multiple dex files define Lcom/myapp/R$array; means the Android build produced the same generated resource class twice. The important clue is the class name: R$array is a generated resource class, so the problem is usually duplicate packaging, duplicate modules, or duplicate generated resources rather than ordinary app logic.

This is often confused with the 65K method-count problem, but it is different. Multidex splits methods across dex files; it does not allow two dex inputs to define the same class name.

What the Error Actually Means

Android compiles classes and then merges them into dex bytecode. Every class name must be unique during that merge. If two inputs both contain com.myapp.R$array, the build fails immediately.

Since R classes are generated, the usual causes are:

• the same library is included twice
• an app module and library module share the same package or namespace
• stale generated build output is still being packaged
• an old jar or aar incorrectly includes generated R classes

Check for Duplicate Dependencies First

The first useful diagnostic is the dependency tree:

./gradlew app:dependencies

Look for the same library arriving through multiple paths, especially in older projects that mix local jars with Gradle dependencies.

For example, this is suspicious:

1dependencies {
2    implementation files("libs/mylibrary.jar")
3    implementation "com.example:mylibrary:1.2.0"
4}

If both artifacts contain overlapping classes, dex merging will complain.

Make Sure Modules Have Unique Namespaces

If a library module and the app both generate com.myapp.R, their resource classes can collide. In modern Android builds, assign each module its own namespace:

android {
    namespace "com.example.featurelibrary"
}

In older builds, the manifest package name played a similar role. Either way, separate modules should not all generate the same R package unless that duplication is intentional and controlled.

Clean Out Stale Build Artifacts

After refactoring packages or modules, stale generated files can keep old R classes around. A full clean is worth doing:

./gradlew clean

Then rebuild from scratch. If the error appeared after renaming packages or moving resources, stale output is a realistic explanation.

If the problem survives a clean build, compare the exact artifact list that goes into the app module. The remaining cause is usually a dependency or namespace problem rather than random build corruption.

Why Multidex Usually Is Not the Fix

Developers often change multidex settings because the message mentions multiple dex files:

defaultConfig {
    multiDexEnabled true
}

That only helps with method-count limits. It does not solve duplicate class definitions. If two inputs define the same class, the build still fails.

Watch for Packaged R Classes

In a healthy Android build, generated R classes come from the current build system. You normally should not check them into source control or ship them inside reusable jars.

If an old jar contains com.myapp.R$array, it can collide with the app's own generated resources. This is especially common in legacy Android projects that predate modern Gradle and AAR conventions.

Common Pitfalls

• Enabling multidex and expecting it to fix a duplicate-class error.
• Including the same library as both a jar and a Gradle dependency.
• Letting multiple modules generate the same R package or namespace.
• Ignoring stale build output after package or module refactors.
• Packaging generated Android R classes inside reusable artifacts.

Summary

• This error means dex merging found two definitions of the same generated R$array class.
• The usual causes are duplicate dependencies, duplicate namespaces, or stale/generated artifacts.
• Audit the dependency tree, clean the build, and verify module namespace settings.
• Do not ship generated R classes inside jars or duplicate libraries in multiple ways.
• Multidex is usually unrelated to the real fix.