Skip to main content

Fixing "Resolution Failed" & Gradle Errors in IronSource Unity Integration

 There are few things more frustrating in mobile development than being ready to build your APK, only to be halted by the Mobile Dependency Resolver. If you are integrating IronSource LevelPlay into Unity, you have likely encountered the dreaded "Resolution Failed," Win32Exception, or vague Gradle fetching errors.

These errors are rarely about your C# code. They are infrastructure collisions between Unity’s internal build system, the Android SDK, and the External Dependency Manager for Unity (EDM4U).

This guide provides a rigorous technical breakdown of why these resolutions fail and offers a definitive, step-by-step path to fixing them for production environments.

The Root Cause: Why Resolution Fails

To fix the error, you must understand the architecture of the failure. The IronSource SDK relies on the Google Mobile Dependency Resolver (EDM4U) to fetch Android archives (.aar) and Java libraries (.jar) from Maven repositories.

When you click "Force Resolve," EDM4U executes a background process involving a Gradle daemon. The failure usually stems from three specific bottlenecks:

  1. Windows MAX_PATH Limitation: The standard Windows API has a 260-character path limit. Gradle caches are deeply nested. When the path exceeds this limit during extraction, the process throws a Win32Exception and crashes silently.
  2. AndroidX vs. Support Library Conflicts: Modern IronSource adapters require AndroidX. If your project still references the legacy android.support libraries, Gradle cannot reconcile the dependency tree.
  3. Gradle Daemon Locking: Unity sometimes loses the handle on the Gradle daemon, or the daemon locks a file that Unity is trying to overwrite, resulting in a generic "Resolution Failed."

Step 1: Enforcing Long Paths (Windows Users)

If you are on Windows, this is the most common cause of persistent resolution failures. Gradle creates deep hash-based directory structures that easily exceed 260 characters.

You must enable Long Paths in the Windows Registry.

  1. Open the Registry Editor (regedit).
  2. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.
  3. Find the entry named LongPathsEnabled.
  4. Set the value to 1.

If the key does not exist, create it as a DWORD (32-bit) Value.

PowerShell Alternative: You can execute this command in PowerShell as Administrator to apply the fix immediately:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1

After applying this, restart your computer. This single change resolves approximately 60% of Win32Exception errors in Unity builds.

Step 2: Configuring the Unity Project for AndroidX

IronSource LevelPlay requires AndroidX. If your Unity project is not configured to use Jetifier (the tool that migrates support libraries to AndroidX), dependency resolution will fail due to duplicate classes.

  1. In Unity, go to File > Build Settings > Player Settings.
  2. Navigate to Player > Publishing Settings.
  3. Check Custom Gradle Properties Template. This creates a file at Assets/Plugins/Android/gradleTemplate.properties.

Open gradleTemplate.properties and ensure the following lines are present. If they are missing, append them:

org.gradle.jvmargs=-Xmx4096m
android.useAndroidX=true
android.enableJetifier=true

Why this matters: android.enableJetifier=true tells Gradle to rewrite binaries that still use android.support packages to use androidx.* packages automatically. Without this, IronSource adapters (like Facebook/Meta or AdMob) will cause build collisions.

Step 3: The Custom Main Gradle Template

The most robust way to handle dependencies is to stop relying on Unity's automatic manifest generation and take control of the Gradle build script.

  1. In Player Settings > Publishing Settings, check Custom Main Gradle Template.
  2. This generates Assets/Plugins/Android/mainTemplate.gradle.

Open this file. We need to ensure that the repositories are correctly defined to fetch IronSource and its mediated network SDKs.

Locate the repositories block inside buildscript and allprojects. Ensure both look like this:

// Assets/Plugins/Android/mainTemplate.gradle

repositories {
    google()
    mavenCentral()
    // JCenter is deprecated but some older adapters still reference it.
    // Only include if absolutely necessary, otherwise remove.
    // jcenter() 
    
    // specific repo for IronSource if required by specific mediation versions
    maven { url 'https://android-sdk.is.com/' }
}

If you are using Unity 2022.2 or newer, these repositories might be located in settingsTemplate.gradle instead. The logic remains the same: ensure google() and mavenCentral() are prioritized.

Step 4: Correcting the Dependency Resolution Strategy

If the "Force Resolve" button still fails, we need to modify how EDM4U interacts with the Android SDK.

  1. Go to Assets > External Dependency Manager > Android Resolver > Settings.
  2. Uncheck Enable Auto-Resolution. This prevents Unity from freezing every time a script recompiles.
  3. Set Patch mainTemplate.gradle to True.

Crucial: When "Patch mainTemplate.gradle" is checked, EDM4U will not download AARs into your Assets/Plugins/Android folder. Instead, it injects the dependency lines directly into your mainTemplate.gradle file.

This is cleaner and prevents file-locking issues. Your dependencies block in mainTemplate.gradle should end up populated automatically, looking similar to this:

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    
    // EDM4U will inject these lines:
    implementation 'com.google.android.gms:play-services-ads-identifier:18.0.1'
    implementation 'com.google.android.gms:play-services-appset:16.0.2'
    implementation 'com.ironsource.sdk:mediationsdk:7.3.0'
    // ... other adapters
}

If you see implementation lines here, the resolver has successfully done its job. You do not need to click "Force Resolve" if the dependencies are written here; Gradle will download them during the actual build process (Build & Run).

Deep Dive: Handling "Duplicate Class" Errors

After fixing the resolution, you might hit a build error stating: Duplicate class found in modules jetified-ironSource.jar and jetified-admob.jar.

This happens when two different SDKs try to include the same underlying library (often a Google Play Services library).

To fix this, you must identify the conflict in the generated Dependencies.xml files usually located in Assets/IronSource/Editor/.

However, the programmatic fix is to force a specific version of the conflicting library in your mainTemplate.gradle. Add this block to the bottom of the file:

configurations.all {
    resolutionStrategy {
        // Force a specific version if different SDKs request different versions
        force 'com.google.android.gms:play-services-ads-identifier:18.0.1'
        
        // Fail on version conflict to see exactly what is clashing
        failOnVersionConflict()
    }
}

Use force cautiously. It overrides the requested versions of all plugins, which is powerful but requires you to ensure compatibility.

Edge Case: The "Gradle Failed to Fetch" Timeout

Sometimes the error is simply Gradle failed to fetch dependencies. This is often a network timeout or a localized Gradle daemon issue.

The Fix:

  1. Navigate to Edit > Preferences > External Tools.
  2. Uncheck JDK Installed with Unity and Gradle Installed with Unity.
  3. (Optional but recommended) Point them to a manually installed OpenJDK 11 and a standalone Gradle distribution (version 7.0+).

However, before reinstalling, try clearing the Gradle cache. Close Unity and delete the contents of this folder:

  • Windows: C:\Users\<YourUser>\.gradle\caches
  • Mac: ~/.gradle/caches

Restart Unity and attempt the build again. This forces Gradle to re-download fresh artifacts rather than using potentially corrupted cached files.

Conclusion

Fixing IronSource resolution errors in Unity is about moving away from "Auto-Resolution" magic and taking ownership of the Gradle build pipeline. By enabling Long Paths, enforcing AndroidX via Jetifier, and patching the mainTemplate.gradle directly, you eliminate the fragility of the default resolver process.

Once these configurations are set, they tend to remain stable, allowing you to focus on game logic rather than fighting the build system.

Labels: