IAP 5 android build Execution failed for task ‘:launcher:checkReleaseDuplicateClasses’ on new empty project

Monetization & Growth In-App Purchases
,
1

Steps to reproduce:

  1. Make new android empty project.
  2. Install IAP 5 from package manager.
  3. Build android APK
    —> Fail
  4. Install EDM4U
  5. Force resolve
  6. Build android APK
    —> Fail
  7. Install Unity Advertisement Legacy from package manager (so to let EDM4U resolve something)
  8. Force resolve
  9. Build android APK
    —> Success

Actual Result:
Android APK not able to build with only Unity IAP 5 and EDM4U enabled inside a new empty project.

Expected Result:
Android APK should be able to build successfully with just Unity IAP 5 and EDM4U inside a new empty project without having to bring in another random package (Unity Advertisement Legacy) to “kick start” EDM4U resolving and settings.

2

Hi @zreamsoft

Thanks for flagging this — really helpful writeup! :raising_hands:

This is a Kotlin stdlib version clash, not an IAP bug.

Explanation:
Unity IAP 5 pulls in Play Billing 9.0.0 → modern kotlin-stdlib:1.8.22, which collides with the older split kotlin-stdlib-jdk7/jdk8:1.6.21 still being pulled in elsewhere in the dependency tree. Google Play Billing 9.0.0 pulls in a mix of modern and 4-year-old transitive libraries:

Kotlin 1.8 merged those jdk7/jdk8 classes into the main stdlib, so you get duplicates, and checkDuplicateClasses fails.

Your Solution
The Ads Legacy + Force Resolve trick works, but it’s just EDM4U pinning Kotlin to one version as a side effect. It masks it rather than fixing it.

Cleaner fix, no extra packages:

  1. Project Settings ▸ Player ▸ Android ▸ Publishing Settings ▸ Build → enable Custom Base Gradle Template.
  2. Add this to the end of Assets/Plugins/Android/baseProjectTemplate.gradle
allprojects {
    configurations.all {
        resolutionStrategy {
            force 'org.jetbrains.kotlin:kotlin-stdlib:1.8.22'
        }
        exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk7'
        exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk8'
    }
}
  1. Clean build and rebuild.

Hope that helps!

3

Thank you for investigating this issue. We are now on the right track to the real problem.

I did a little bit of research and it is said that excluding jdk7 and jdk8 this way might cause problems with old third-party plugin that still depends on them even though jdk7 and jdk8 has been merged into the new kotlin stdlib so they will throw up with Could not resolve or Missing artifact error.

Is this true and if so do we have an even better solution around this?

4

Great question, and good instinct to check.

TLDR; For this specific case, excluding is actually safe

(the jdk7/jdk8 classes were merged into the main kotlin-stdlib, so nothing goes missing, and exclude only prunes the tree — it doesn’t trigger “could not resolve” for other libraries; those errors usually come from forcing a non-existent version).

But you’re right that there’s a lower-risk approach that removes the worry entirely: align the versions instead of removing the artifacts.

Since Kotlin 1.8 merged jdk7/jdk8 into kotlin-stdlib, the kotlin-stdlib-jdk7/jdk8:1.8.22 artifacts still exist on Maven — they’re now empty shims that just depend on kotlin-stdlib:1.8.22 (verified in their POMs). So if we bump all three to the same version, the duplicates vanish and any old plugin that explicitly references the jdk7/jdk8 coordinates still resolves cleanly:

allprojects {
    configurations.all {
        resolutionStrategy {
            force 'org.jetbrains.kotlin:kotlin-stdlib:1.8.22'
            force 'org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.8.22'
            force 'org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.22'
        }
    }
}

This is the safest option for a project that might pull in older plugins: nothing is removed, everything just lands on one consistent Kotlin version.
(If you ever want central control of the Kotlin version, importing platform("org.jetbrains.kotlin:kotlin-bom:1.8.22") does the same alignment via a BOM.)

The earlier exclude version is fine too and equivalent in practice, this one is just belt-and-braces.