Common Unity Android Build Errors and How to Fix Them

If you develop for mobile long enough, you will see a CommandInvokationFailure: Gradle build failed error in the Unity console. The top-level message is almost never useful on its own — it is a wrapper. The actual cause sits several lines lower in the raw Gradle output.

To find it, expand the error in the Unity Console and scroll past Unity's red header. Look for lines prefixed with FAILURE: or > Task :launcher:.... This raw output will point to the exact file, dependency, or configuration that broke.

This is especially common after integrating SDKs such as Firebase Analytics or Google Mobile Ads (AdMob), both of which introduce their own Gradle dependency trees.

Here is a typical pattern you will see when two dependencies require different versions of the same library:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':launcher:checkDebugDuplicateClasses'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable
  > Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules:
      kotlin-stdlib-1.6.21 (org.jetbrains.kotlin:kotlin-stdlib:1.6.21)
      kotlin-stdlib-jdk8-1.8.0 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.0)

Unity builds an Android project by merging the main manifest with the manifests from all included plugins. If two plugins define conflicting XML attributes — for example, different android:theme values for the same activity — the merger fails.

Before you can edit the manifest, you need to expose it. In Player Settings > Publishing Settings, enable Custom Main Manifest. Unity will generate an editable Plugins/Android/AndroidManifest.xml file. You can then use the tools:replace node marker to instruct the compiler which attribute to use when a conflict exists.

Once you have identified the specific attribute causing the merge conflict in the Gradle log, apply the override in your custom manifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">
    <application>
        <activity android:name="com.unity3d.player.UnityPlayerActivity"
                  android:theme="@style/UnityThemeSelector"
                  tools:replace="android:theme">
        </activity>
    </application>
</manifest>

Manually managing .aar files and Gradle version strings is error-prone across multiple SDKs. The External Dependency Manager for Unity (EDM4U) resolves AndroidX and Play Services version conflicts before the Gradle build starts.

Step 1 — Force Resolve: If a build fails after updating a package, go to Assets > External Dependency Manager > Android Resolver > Force Resolve. This re-downloads and reconciles all declared Android dependencies. This is the right first step for most dependency conflicts.

Step 2 — Custom Main Gradle Template (if Force Resolve is not enough): If dependency versions are still conflicting after Force Resolve, enable Custom Main Gradle Template in Player Settings > Publishing Settings. With a writable mainTemplate.gradle, EDM4U can inject resolved version numbers directly into the Gradle file rather than relying solely on its pre-build resolution pass. Some projects also need to enable Custom Gradle Properties Template to set android.useAndroidX=true.

Step 3 — Jetifier (for legacy support-library conflicts only): If you see errors specifically referencing android.support.* classes — meaning an older plugin that has not been migrated to AndroidX — enable Use Jetifier in Assets > External Dependency Manager > Android Resolver > Settings. Jetifier rewrites legacy android.support bytecode to its androidx equivalents at build time. It is not a general-purpose fix for all Gradle conflicts; it specifically targets support-library / AndroidX incompatibilities.

After adding several SDKs — Firebase, AdMob, IAP, Play Services — you may encounter a build error that has nothing to do with manifests: Cannot fit requested classes in a single dex file.

Android's Dalvik Executable (DEX) format has a 64K method reference limit per file. Large SDK collections frequently exceed this. Before enabling multidex, you should first try to reduce unnecessary dependencies and strip unused code (see Managed Code Stripping). If your app genuinely requires more than 64K methods, you must enable multidex support, which splits compiled code across multiple DEX files.

If your minSdkVersion is set to 21 or higher (Android 5.0+), multidex is supported natively and is enabled by default. However, if your project targets API 20 or lower, or if you still face multidex-related build errors, you can explicitly configure it. Enable Custom Main Gradle Template in Player Settings > Publishing Settings if not already enabled, then add multiDexEnabled true to the defaultConfig block:

Unity ships validated versions of the JDK, Android SDK, NDK, and Gradle wrapper tied specifically to your Editor version. You can inspect and control which toolchain Unity uses via Edit > Preferences > External Tools.

In that panel you will find checkboxes for JDK Installed with Unity, Android SDK Tools Installed with Unity, Android NDK Installed with Unity, and Gradle Installed with Unity. If any of these are unchecked and pointing to a system-installed or Android Studio version, you risk internal build script errors that may not clearly reference the external path as the cause.

Unless you are maintaining a highly customised native Android pipeline, keep all four options checked. Manually bumping the Gradle wrapper version in gradle-wrapper.properties, pointing to a system JDK, or mismatching the NDK version are common sources of cryptic build failures that are difficult to trace.

Each additional SDK increases the risk of dependency collisions and DEX size growth. After any significant integration work, reviewing your overall build footprint is a useful habit. See the companion article on how to reduce Unity mobile game build size for tools like the Build Report and managed code stripping that help you understand what each SDK contributes to your final APK.