标签：#gradle

Originally published on indiecore.net . I made a throwaway Unity 6000.4.0f1 project on a Mac, built a release APK from it, and then broke it four different ways to see what the console would say. The APK took 155 seconds in the Gradle stage and came out at 27 MB. Every failure below is from a log on this laptop, not from a thread I read. The reason for doing it that way: the message everybody searches for says nothing about the project that produced it, and I wanted to know exactly where the part that does say something had gone. The error you searched for However you phrased it — unity gradle build failed , unity error gradle build failed , unity commandinvokationfailure gradle build failed , unity android build failed gradle , unity 6 gradle build failed , unity 2022 gradle build failed , unity firebase gradle build failed — you got here from the same eleven words in the console: CommandInvokationFailure: Gradle build failed. /Applications/Unity/Hub/Editor/6000.4.0f1/PlaybackEngines/AndroidPlayer/OpenJDK/bin/java -classpath "/Applications/Unity/Hub/Editor/6000.4.0f1/PlaybackEngines/AndroidPlayer/Tools/gradle/lib/gradle-launcher-8.13.jar" org.gradle.launcher.GradleMain "-Dorg.gradle.jvmargs=-Xmx4096m" "assembleRelease" Environment Variables: XPC_FLAGS = 0x0 CLAUDE_CODE_ENTRYPOINT = claude-vscode ANDROID_NDK_ROOT = /Applications/Unity/.../AndroidPlayer/NDK LANG = C.UTF-8 Sixty-seven of those variables in my log, and I counted them because I kept scrolling through them looking for the reason. There isn't one in there. Unity started a Java process, the process exited 1, and this block is Unity reporting which process it started. It would look identical if the failure were a missing semicolon or a full disk. Which is why the answers on the first page of results are all different from each other, and why none of them worked for you. They are answers to different questions that produce the same sentence. Where the cause actually is Here is the shape of the whole log for

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason. Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always... Instead, Gradle greets you with something like this: Execution failed for task ':app:checkDebugDuplicateClasses'. Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar Duplicate class ... At first glance, the error looks straightforward: there are duplicate classes . Easy enough, right? Not exactly. In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different. Let's break down what's actually happening and, more importantly, how to fix it. Why this error happens Every Android library included in your project contains compiled Java or Kotlin classes. When Gradle builds your application, it combines all of those libraries into a single APK or AAB. If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged. Instead of guessing, it stops the build with a Duplicate class error. The difficult part is that the dependency causing the conflict usually isn't the one shown in the error. Very often, it's another package pulling in an older or incompatible version behind the scenes. The most common causes After seeing this error many times, these are usually the culprits. 1. Two libraries depend on different versions of the same package This is by far the most common scenario. For example:

This week's Java roundup for June 15th, 2026, features news highlighting: point releases of Spring Tools, Helidon, JobRunr and Gradle; the June 2026 edition of Open Liberty; the first milestone release of Apache TomEE 11.0; the first beta release of Hibernate ORM 8.0; Quarkus emergency maintenance releases to address CVE-2026-50559; and four open-source projects join the Commonhaus Foundation. By Michael Redlich