为何Gradle能区分构建变体资源却无法识别变体Application类？

Great question—let’s break down why you’re seeing this discrepancy between resources and your Application class, plus how to fix it.

The Core Difference: How Gradle Processes Resources vs. Java/Kotlin Classes #

1. Resources are built for variant-specific overrides #

Gradle’s Android plugin treats resources (drawables, layouts, strings, etc.) with a priority-based merging system. When you have a resource with the same name in main/res and debug/res, the debug variant’s resource automatically replaces the main one during compilation.

This works because resources are referenced via generated R class IDs, not direct file paths. The plugin handles merging at build time, so there’s never a "duplicate resource" conflict (unless you have conflicting qualifiers, but that’s a separate edge case).

2. Classes are compiled as a unified set (no automatic overrides) #

Java/Kotlin classes, on the other hand, are compiled from all active source sets for a variant. For the debug variant, that means main/java + debug/java are both included in the classpath. If you have the same fully qualified class name (e.g., com.yourapp.MyApplication) in both main and debug, Gradle sees two identical classes and throws the "duplicate class" error.

Unlike resources, there’s no built-in override system for classes—every class with the same package + name is treated as a duplicate, regardless of which source set it comes from.

How to Fix the Duplicate Class Error #

Here are the most common and clean solutions:

Option 1: Remove the main variant’s Application class #

Delete the MyApplication class from main/java, then add a separate version in debug/java and release/java (and any other variants you need).

Then, update each variant’s AndroidManifest.xml (create one in debug/manifest and release/manifest if you don’t have them) to reference the variant-specific class:

<!-- debug/AndroidManifest.xml -->
<application
    android:name=".MyDebugApplication"
    ...>
</application>

<!-- release/AndroidManifest.xml -->
<application
    android:name=".MyReleaseApplication"
    ...>
</application>

This ensures only one MyApplication-style class is included per variant.

Option 2: Use manifest placeholders to dynamically set the Application class #

Keep a base Application class in main/java, then create variant-specific subclasses in debug/java and release/java:

// main/java/com/yourapp/BaseApplication.kt
open class BaseApplication : Application() {
    // Shared logic here
}

// debug/java/com/yourapp/DebugApplication.kt
class DebugApplication : BaseApplication() {
    // Debug-only logic here
}

// release/java/com/yourapp/ReleaseApplication.kt
class ReleaseApplication : BaseApplication() {
    // Release-only logic here
}

Then, in your app-level build.gradle (or build.gradle.kts), define a placeholder for each variant:

// build.gradle
android {
    buildTypes {
        debug {
            manifestPlaceholders = [applicationClass: ".DebugApplication"]
        }
        release {
            manifestPlaceholders = [applicationClass: ".ReleaseApplication"]
        }
    }
}

Update your main AndroidManifest.xml to use the placeholder:

<!-- main/AndroidManifest.xml -->
<application
    android:name="${applicationClass}"
    ...>
</application>

This way, Gradle replaces the placeholder with the correct class name for each variant, and you only have one active Application class per build.

Option 3: Exclude the main class from variant source sets #

If you want to keep the main class as a fallback, you can exclude it from specific variants. For example, in build.gradle:

android {
    sourceSets {
        debug {
            java {
                exclude 'com/yourapp/MyApplication.kt'
            }
        }
    }
}

This tells Gradle to ignore the main MyApplication class when compiling the debug variant, so only the debug version is used. This is less clean than the first two options, but works if you need a fallback.

内容的提问来源于stack exchange，提问作者max