AdMob Mediation Adapter Version Conflict in Unity Android - Gradle Dependency Resolution and Adapter Matrix Fix - How to Fix

Unity Android builds fail during Gradle merge, Dex merge, or dependency resolution, and the log mentions duplicate classes, version alignment, or conflicting requests for Google Play services or Mobile Ads artifacts. Editor play mode may still work because the failure is in Android packaging, not C# compilation.

This guide gives a deterministic fix path: align Google Mobile Ads SDK for Unity, mediation network adapters, and Android Resolver output so Gradle resolves one consistent dependency graph.

Who is affected and fastest fix

You are likely affected if:

Gradle reports Duplicate class for com.google.android.gms, com.google.firebase, or Mobile Ads packages
you recently added or upgraded a mediation adapter .unitypackage or Maven dependency
gradlew :launcher:dependencies shows two different versions of play-services-ads or related artifacts
the build fails at mergeReleaseJavaResource, mergeDex, or checkDebugDuplicateClasses

Fastest safe fix: upgrade or reinstall the Google Mobile Ads Unity plugin to a current release, then remove stale *.aar / *.jar copies under Assets/Plugins/Android that duplicate Maven-resolved dependencies, run External Dependency Manager for Unity (EDM4U) Android Resolver → Force Resolve, and rebuild. If conflicts remain, align each mediation adapter version to the adapter matrix for your Mobile Ads SDK version (see official mediation docs below).

Official references:

Android mediation networks and adapters (Google AdMob)
Unity mediation guidance (Google AdMob)

Root cause

Mediation pulls third-party SDKs (meta, app, ironSource, and others depending on your stack) into the same Android app as Google Mobile Ads. Each adapter expects a compatible range of:

play-services-ads (Mobile Ads SDK on Android)
AndroidX libraries
partner SDK artifacts

When one adapter pins an older ads artifact while another plugin or manual .aar pins a newer one, Gradle cannot pick a single version, or it merges two copies of overlapping classes. Unity projects also accumulate legacy local AARs from old plugin imports; those files win over Maven resolution in confusing ways until you delete duplicates.

Fix 1 - Establish one Mobile Ads plugin baseline

In the Unity Package Manager or imported plugin folder, confirm you have exactly one primary integration path for Google Mobile Ads (official Google Mobile Ads Unity plugin recommended for new work).
Note the plugin version and the Mobile Ads SDK version it bundles or declares for Android (release notes).
Remove duplicate ad SDK integrations (older AdMob .unitypackage stacks, duplicate GoogleMobileAds folders, or third-party wrappers that also embed ads).

Success check: a single GoogleMobileAds API surface in your project and one clear plugin version in Project Settings or release notes.

Fix 2 - Clean duplicate Android plugins

In Assets/Plugins/Android, search for play-services or mobileads in filenames.
If you see manually copied *.aar / *.jar files that duplicate what EDM4U should fetch, remove the copies after backing up the project (zip first).
Remove obsolete support-library artifacts if your project has migrated to AndroidX (mixed support/AndroidX is a frequent duplicate-class source).

Caution: do not delete Gradle template files unless you know you can restore them; focus on duplicate third-party binaries.

Fix 3 - External Dependency Manager (EDM4U) resolution

Open Assets → External Dependency Manager → Android Resolver → Settings.
Enable options that match your Unity/Gradle stack (commonly Jetifier if libraries still reference old support packages; enable patch mainTemplate.gradle when using custom templates).
Run Force Resolve and wait for completion without errors.
If resolution fails, open the console log and identify the first conflicting artifact pair; fix that pair before chasing later errors.

Success check: Resolver finishes cleanly and mainTemplate.gradle / launcherTemplate.gradle (if used) list coherent implementation lines without duplicate coordinates for the same module.

Fix 4 - Align mediation adapters to the matrix

In the AdMob mediation UI, note which networks you enabled.
Open the official mediation network documentation for each enabled partner and find the adapter version compatible with your Mobile Ads SDK version.
Import adapter packages at those versions. Avoid “latest” unless you verify against the matrix the same day.
Re-run Force Resolve after each adapter change.

If a partner distributes Unity packages that bundle Maven coordinates, do not also drop in parallel AARs for the same SDK.

Fix 5 - Custom Gradle templates (advanced)

If you must edit mainTemplate.gradle:

Prefer implementation lines generated by EDM4U over hand-rolled version pins.
If you use a Bill of Materials (BOM) pattern for Play services, apply it once and consistently; mixing BOM pins with unrelated explicit versions is a common conflict source.
Use configurations.all { resolutionStrategy { force ... } } only as a temporary bridge while you fix the underlying adapter mismatch; document the forced versions in your repo README.

Official Gradle documentation for dependency resolution is on Gradle docs; use it when you need precise resolutionStrategy syntax.

Verification checklist

After changes:

Android Resolver completes with no errors.
Run ./gradlew :launcher:dependencies (or Unity-exported Gradle project equivalent) and confirm one winning line for com.google.android.gms:play-services-ads (and related modules) per configuration.
Build Release with minify settings matching your production pipeline; R8 can surface duplicate classes that Debug hid.
Launch on a physical device, open Ad Inspector from test ads flow, and confirm mediation adapters initialize without adapter load errors in logcat.

Alternative fixes

Alternative A - Temporarily disable mediation networks

To bisect, disable all but AdMob in mediation and confirm a clean build. Re-enable networks one at a time to find the conflicting adapter.

Alternative B - Upgrade Unity Editor Android toolchain

Older Unity versions ship older Gradle/AGP defaults. If you are on an end-of-life Unity stream, upgrading to a supported LTS often reduces Jetifier and dependency edge cases. Pair with Google Play 16 KB memory page size requirement blocks release guidance when updating NDK/AGP.

Alternative C - Isolate CI versus local resolver output

If CI builds fail but local succeeds, ensure EDM4U-generated Gradle files are committed or regenerated in CI before Gradle runs, and that CI does not restore an old Plugins/Android cache with stale AARs.

Prevention tips

pin Mobile Ads plugin and adapter set versions in your release checklist
run Force Resolve after any monetization package upgrade
forbid engineers from dropping hand-copied play-services AARs into Plugins/Android
keep mediation adapter versions documented next to your AdMob app id configuration
add a lightweight Gradle dependency diff step in CI comparing dependencies output between builds

FAQ

Why does Editor work but Android build fails

Editor does not run the Android Gradle merge. Conflicts appear when Java/Kotlin bytecode merges for the player.

Can I fix this only by raising compileSdkVersion

Raising compileSdkVersion helps API surface mismatches but does not remove duplicate classes. You still need one coherent dependency graph.

Does Multidex solve duplicate class errors

No. Multidex splits methods across dex files; duplicate classes are still invalid. Fix dependencies first.

Should I use Gradle BOM for all Google libraries

BOM can help when applied consistently. Mixed BOM plus unrelated explicit versions often worsens conflicts until you simplify.