Error: Gradle Task AssembleDebug Failed With Exit Code 1

You’re deep in development. Your code looks clean. You hit Run — and then it appears:

“error: gradle task assembledebug failed with exit code 1”

Everything stops. The frustration is real. Whether you’re a beginner building your first Android app or a senior developer managing a complex multi-module project, this error has a way of showing up at the worst possible moment.

Here’s the good news: this error is almost always fixable. The “exit code 1” itself isn’t a specific bug — it’s Gradle’s way of saying “something went wrong during the build process.” The actual problem is hiding in your build logs, your dependencies, your SDK configuration, or your code.

This guide covers every known cause and solution for this error — written for real developers who need real answers, not vague suggestions to “try cleaning the project.”

By the end of this article, you’ll understand exactly what triggers this error, how to diagnose it systematically, and how to prevent it from wrecking your workflow again.

What Is Gradle and Why Does AssembleDebug Fail?

Before jumping into fixes, it’s worth understanding what’s actually happening when this error fires.

Gradle is the build automation system Android Studio uses to compile, package, and produce your APK or AAB. When you hit the Run button or execute a build command, Gradle runs a series of tasks in sequence. One of the most important is assembleDebug — the task responsible for assembling your debug APK.

When Gradle reports “exit code 1,” it means the build process terminated abnormally. Something interrupted or blocked the completion of the assembleDebug task.

The tricky part? Exit code 1 is a generic failure signal. It doesn’t point to one specific problem. Think of it like a car dashboard warning light — it tells you something is wrong, but you still need to open the hood.

Common categories of root causes include:

• Java or Kotlin compilation errors
• Dependency version conflicts
• SDK or build tools version mismatches
• Corrupted Gradle cache or wrapper files
• Resource compilation failures (AAPT2 errors)
• Manifest merger conflicts
• ProGuard or R8 minification errors
• Memory allocation issues
• Plugin version incompatibilities

Each of these has its own set of symptoms and fixes — all covered below.

How to Read Gradle Error Logs the Right Way

Most developers panic when they see the exit code 1 message and start randomly trying fixes. That’s the wrong approach. The error message in the “Run” tab is just a summary. The real information is buried in the build output.

Step 1: Switch to the Build Output Tab

In Android Studio, click on Build > Build Output or look at the bottom panel and select the Build tab, not the Run tab. The Build tab shows the full Gradle output, including the actual failing task and the precise error.

Step 2: Search for “error:” or “FAILED”

Use Ctrl+F (or Cmd+F on Mac) inside the build output to search for the keyword error: or FAILED. This immediately jumps you to the root cause rather than the cascading failures that follow it.

Step 3: Look for the First Failure

Gradle errors often cascade — one failure causes several more downstream. Always scroll up to find the first error in the chain. That’s the one you need to fix first.

Step 4: Run Gradle from the Terminal

Sometimes Android Studio’s output truncates important details. Run the build manually from the terminal for more verbose output:

./gradlew assembleDebug –stacktrace

./gradlew assembleDebug –info

./gradlew assembleDebug –debug

The –stacktrace flag is especially helpful for identifying exactly which task failed and why.

Top Causes and Fixes for AssembleDebug Exit Code 1

Cause 1: Java or Kotlin Compilation Errors

This is the most common cause. If your code contains syntax errors, type mismatches, unresolved references, or missing imports, Gradle will fail during the compilation phase.

Signs in build output:

• error: cannot find symbol
• error: incompatible types
• Unresolved reference: SomeClassName
• error: package does not exist

How to fix it:

First, look at the exact file and line number mentioned in the error. Android Studio usually hyperlinks these in the build output. Click directly on the error to jump to the problematic line.

Common sub-issues include:

• Missing imports: If you see “cannot find symbol,” the class might not be imported. Use Alt+Enter in Android Studio to auto-import.
• API level issues: You might be calling an API that requires a higher minSdkVersion than what you’ve set. Either raise the minSdkVersion in your build. Gradle or add proper version checks using Build.VERSION.SDK_INT.
• Kotlin-Java interoperability errors: If you’re mixing Kotlin and Java files, null safety annotations and type conversions can cause issues at compile time.

Prevention tip: Enable real-time inspection in Android Studio (Settings > Editor > Inspections) so you catch these errors before building.

Cause 2: Dependency Conflicts

This is probably the second most common reason for the assembleDebug error, and it can be frustratingly difficult to diagnose.

Android projects often include dozens of third-party libraries. These libraries bring their own transitive dependencies — and sometimes two libraries depend on different versions of the same package. Gradle can’t resolve this conflict, and the build fails.

Signs in build output:

• Duplicate class found in modules
• Could not resolve com.example:library:x.x.x
• Conflict with dependency
• Program type already present

How to fix it:

Run the dependency tree to see what’s conflicting:

./gradlew app:dependencies

This prints a full tree of all dependencies and their versions. Look for lines with (*) which indicate where Gradle has overridden a version, and -> which shows version resolution.

To force a specific version of a conflicting library, use a resolution strategy in your build.gradle:

configurations.all {

    resolutionStrategy {

        force ‘com.google.guava:guava:31.0.1-android’

    }

}

Alternatively, you can exclude a transitive dependency:

implementation(‘com.some.library:core:1.0.0’) {

    exclude group: ‘com.conflicting.lib’, module: ‘module-name.’

}

For the “Duplicate class” error specifically (common after adding AndroidX or migrating from the old support library), add this to your gradle.properties:

android.useAndroidX=true

android.enableJetifier=true

Cause 3: SDK Version or Build Tools Mismatch

Android development requires alignment between several version-sensitive components: the compile SDK version, the build tools version, the target SDK version, and the minimum SDK version. If these are out of sync — or if the required version isn’t installed on your machine — the build will fail.

Many development errors are caused by configuration mismatches or missing dependencies. Similar issues also occur in online platforms when authentication or services fail, as explained in our Failed to Connect to Steam Error Code 211 fix guide.

Signs in build output:

• Failed to find Build Tools revision x.x.x
• Minimum supported Gradle version is x.x
• compileSdkVersion is not installed
• The SDK Build Tools revision x.x.x is too low

How to fix it:

Open your module-level build. gradle and check your Android configuration block:

android {

    compileSdk 34

    defaultConfig {

        minSdk 24

        targetSdk 34

    }

}

Then go to Tools > SDK Manager in Android Studio and ensure that:

• The SDK Platform for your compileSdk version is installed
• The Build Tools version you’re referencing is installed
• Your Android Studio version supports the Gradle version you’re using

If you’re getting Gradle wrapper version errors, check your gradle/wrapper/gradle-wrapper.properties file and update the distribution URL to a compatible version.

The Android developer documentation maintains a compatibility matrix between Android Gradle Plugin (AGP) versions and Gradle versions. Mismatches here are a very frequent source of exit code 1 errors — especially after updating Android Studio.

Cause 4: Corrupted Gradle Cache

Gradle maintains a local cache to speed up builds. But this cache can become corrupted — especially after interrupted downloads, network failures, or abrupt shutdowns. When Gradle tries to use a corrupted cached artifact, the build fails.

Signs:

• The error appears suddenly after it was working fine
• Build fails on a task that has nothing to do with your recent changes
• Error mentions .gradle or cache directory paths

How to fix it:

The fastest fix is to invalidate the Android Studio cache:

Go to File > Invalidate Caches / Restart and select all options.

For a deeper fix, manually delete the Gradle cache:

On Mac/Linux:

rm -rf ~/.gradle/caches/

On Windows:

Delete: C:\Users\YourName\.gradle\caches\

Then sync your project again. Gradle will re-download everything fresh.

Also try:

./gradlew clean

./gradlew assembleDebug

A clean build forces Gradle to recompile everything instead of using potentially broken incremental build outputs.

Cause 5: AAPT2 Resource Errors

AAPT2 (Android Asset Packaging Tool 2) is responsible for compiling your app’s resources — layouts, drawables, strings, and other XML files. If any resource file has an error, AAPT2 will fail and take your entire build down with it.

Signs in build output:

• AAPT2 error: check logs for details
• Android resource linking failed
• resource not found
• error: attribute X not found
• duplicate value for resource ‘color/…’

How to fix it:

Resource errors are usually very specific. The build output will tell you exactly which file and which line caused the problem.

Common sub-causes:

• Invalid XML: A malformed layout file with a missing closing tag or invalid attribute. Use Android Studio’s layout validator to check your XML files.
• Referencing non-existent resources: You’re referencing @color/primary_dark in a layout but the color isn’t defined in your colors.xml.
• Duplicate resource IDs: Two resource files define the same name. This often happens after merging branches or copy-pasting from another project.
• Wrong namespace: Using app: attributes without declaring the app namespace in the root element of your layout.

Check the specific file mentioned in the error output. Fix the resource issue and rebuild.

Cause 6: Manifest Merger Failed

Every Android library you add to your project has its own AndroidManifest.xml. During the build, Gradle merges all of these manifests into a single one for your app. If there are conflicts — like two libraries declaring the same permission in incompatible ways, or a minSdkVersion conflict — the merger fails.

Signs in build output:

• Manifest merger failed with multiple errors
• uses-sdk:minSdkVersion X cannot be smaller than version Y declared in library
• Attribute application@label value=… from AndroidManifest.xml is also present in…

How to fix it:

View the merged manifest by opening AndroidManifest.xml in Android Studio and clicking the Merged Manifest tab at the bottom. This shows you a visual diff of all merging decisions and flags conflicts in red.

To resolve specific conflicts, use manifest merge tools/attributes directly in your AndroidManifest.xml:

To override a library’s minSdkVersion:

<uses-sdk tools:overrideLibrary=” com.conflicting.library” />

To replace an attribute from a library:

<application

    android:label=”@string/app_name”

    tools:replace=”android: label”>

Always add xmlns:tools=”http://schemas.android.com/tools” to your manifest root element when using these attributes.

Cause 7: ProGuard or R8 Minification Errors

When you build a release APK (and sometimes in debug builds with minification enabled), Gradle runs ProGuard or its successor R8 to shrink and obfuscate your code. These tools can strip out classes or methods that your app needs at runtime, causing build failures or runtime crashes. Build failures like this often appear alongside other system or platform-level errors. If you’re dealing with general launch or execution issues, you can also check our guide on Steam Error Code 2 fix, which explains how system-level conflicts and server problems can stop applications from running properly.

Signs in build output:

• ProGuard returned with error code 1
• R8: Missing class…
• Warning: there were unresolved references to classes or interfaces
• ERROR: Missing classes detected while running R8

How to fix it:

If you don’t need minification during debug builds, ensure it’s disabled:

buildTypes {

    debug {

        minifyEnabled false

        shrinkResources false

    }

}

For release builds where you need minification, add proper keep rules to your proguard-rules.pro file:

# Keep a specific class

-keep class com. example.MyImportantClass { *; }

# Keep all model classes

-keep class com.example.models.** { *; }

# Keep classes used by reflection

-keepclassmembers class * {

    @com.example.annotations.* <methods>;

}

Most popular libraries provide their own ProGuard rules. Check the library’s documentation for the recommended rules to add.

Cause 8: Out of Memory / Heap Space Errors

Large projects with many modules, resources, or annotation processors can exhaust the JVM heap space allocated to Gradle during builds.

Signs in build output:

• OutOfMemoryError: Java heap space
• GC overhead limit exceeded
• Expiring Daemon because JVM heap space is exhausted

How to fix it:

Increase the heap size allocated to Gradle. In your gradle.properties file:

org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=1024m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Adjust the -Xmx value based on your machine’s available RAM. For large projects, 4GB to 8GB is common.

Also enable the Gradle daemon if it’s not already enabled (it usually is by default):

org.gradle.daemon=true

And consider enabling parallel execution for multi-module projects:

org.gradle.parallel=true

org. gradle.caching=true

Cause 9: Plugin Version Incompatibility

The Android Gradle Plugin (AGP) must be compatible with the version of Gradle you’re using, the version of Android Studio, and sometimes with specific third-party plugins. An incompatible plugin version is a very common cause of build failures after upgrading Android Studio.

Signs in build output:

• Plugin [id: ‘…’, version: ‘…’] was not found
• The Android Gradle plugin supports only Gradle X.X and higher
• An exception occurred applying the plugin request

How to fix it:

Check your project-level build. gradle or build. gradle.kts:

plugins {

    id ‘com.android.application’ version ‘8.2.0’ apply false

    id ‘org.jetbrains.kotlin.android’ version ‘1.9.0’ apply false

}

Cross-reference the AGP version with the official compatibility table from the Android developer documentation. Each AGP version requires a specific minimum Gradle version.

Also check your gradle-wrapper.properties:

distributionUrl=https\://services.gradle.org/distributions/gradle-8.2-bin.zip

Make sure this version is compatible with your AGP version.

Cause 10: Kotlin Version Mismatch

If you’re using Kotlin, mismatches between the Kotlin Gradle plugin version and other Kotlin-dependent libraries (like Kotlin Coroutines, Serialization, or Compose) will cause build failures.

Signs in build output:

• Cannot inline bytecode built with JVM target X into bytecode that is being built with JVM target Y
• Kotlin: Type inference failed
• The module was compiled with an incompatible version of Kotlin

How to fix it:

Ensure your Kotlin version is consistent. Define it in one place and reference it everywhere:

In build. gradle.kts (project level):

plugins {

    kotlin(“android”) version “1.9.20” apply false

}

In your app’s build.gradle:

android {

    kotlinOptions {

        jvmTarget = “17”

    }

}

Make sure all Kotlin-related libraries (coroutines, serialization, etc.) use versions compatible with your Kotlin Gradle plugin version.

Systematic Debugging Checklist

When you hit exit code 1, follow this checklist in order before trying random fixes:

Step 1: Read the full build output. Don’t rely on the summary message alone.

Step 2: Find the first error in the build log, not the last one.

Step 3: Run ./gradlew assembleDebug –stacktrace from the terminal for full error details.

Step 4: Run ./gradlew clean and try building again to rule out incremental build issues.

Step 5: Invalidate caches in Android Studio (File > Invalidate Caches).

Step 6: Check for recent changes — what did you add or modify right before the error appeared?

Step 7: Check if the error is in your code, your resources, your manifest, or your Gradle configuration.

Step 8: Search the exact error message (not the exit code 1 part, but the specific error text) online or in official documentation.

Step 9: If using version control, try reverting recent changes one by one to identify the breaking change.

Step 10: If all else fails, delete the .gradle folder in your project root and the build folders, then sync and rebuild from scratch.

Advanced Scenarios and Edge Cases

The Error Only Happens on CI/CD, but Not Locally

This is a classic environment mismatch problem. Your CI server might be using:

• A different JDK version
• A different Android SDK version
• Missing environment variables
• Different Gradle properties

Fix: Ensure your CI environment matches your local setup. Pin the Java version, install the exact SDK versions your project needs, and commit your gradle-wrapper.properties so all environments use the same Gradle version.

The Error Happens After Pulling From Git

A team member may have changed build.gradle, updated a dependency, or modified the Gradle wrapper. After pulling:

1. Run File > Sync Project with Gradle Files
2. Check the diff on build.gradle and gradle-wrapper.properties
3. Ensure the SDK version they’re using is installed on your machine
4. Delete your local .gradle cache if needed

The Error Appears Randomly Without Code Changes

This usually points to a corrupted cache, a flaky network dependency download, or a resource conflict introduced by a library update. Clean the cache aggressively:

./gradlew clean

rm -rf ~/.gradle/caches/modules-2/

Then rebuild.

Multi-Module Project Failures

In multi-module projects, the error might originate in a library module but only manifest when the app module tries to consume it. Always check which module failed, not just which task.

Run module-specific builds to isolate the problem:

./gradlew :library-module:assembleDebug

./gradlew :app:assembleDebug

How to Prevent This Error in the Future

Prevention is always better than debugging. Here are proven strategies:

Keep dependencies updated but controlled. Use the Gradle Versions Plugin to check for available updates. Don’t update all dependencies at once — update in small batches and test after each.

Use a consistent JDK version. Define the JDK in Android Studio (File > Project Structure > SDK Location) and document it for your team. JDK 17 is the current recommendation for modern Android development.

Commit your Gradle wrapper. The gradle/wrapper/gradle-wrapper.jar and gradle-wrapper.properties files should always be committed to version control. This ensures everyone on your team uses the same Gradle version.

Use version catalogs. Android Studio supports Gradle version catalogs (libs.versions.toml) for centralized dependency management. This prevents version drift across modules.

Set up build scans. The Gradle Build Scan plugin (./gradlew assembleDebug –scan) provides a detailed web-based report of your build, including performance data and failure causes. It’s invaluable for debugging complex build failures.

Run lint and tests before committing. Catching code issues before they reach the build stage prevents compilation-related exit code 1 errors.

Final Thoughts

The “error: gradle task assembleDebug failed with exit code 1” is one of the most searched Android development errors for a good reason — it’s broad, it’s frustrating, and it shows up constantly. But it’s rarely unsolvable.

The key is to stop reacting to the generic exit code message and start reading the actual build output. Every cause covered in this guide — from simple compilation errors to complex dependency conflicts and manifest merges — leaves a specific trace in your Gradle logs. Find that trace, match it to the corresponding fix, and your build will be running again in minutes.

The developers who waste hours on this error are usually the ones who keep trying random fixes without reading the logs. The developers who fix it quickly are the ones who know where to look.

Now you’re in the second group.

Build smarter. Debug faster. Ship more.

FAQ