How to Fix KAPT "unrecognized Attribute name MODULE" in Android/Kotlin Builds

By the end of this page, you will understand what this KAPT error usually means: a compatibility problem between the Java toolchain, Kotlin/KAPT, Gradle, Android Gradle Plugin, or an annotation processor. You will learn how to isolate the failing dependency, check version alignment, and apply practical fixes such as upgrading Kotlin or Gradle plugins, using a supported JDK, and testing annotation processors one by one.

This error is usually not caused by your app code directly. It typically appears when annotation processing runs with a combination of tools that do not fully agree with each other.

In Android projects, KAPT sits between several moving parts:

• Gradle runs the build
• Android Gradle Plugin (AGP) integrates Android builds into Gradle
• Kotlin plugin compiles Kotlin code
• KAPT runs Java-style annotation processors for Kotlin sources
• JDK / javac provides compiler internals used by processors
• Libraries like Dagger, Room, Hilt, Moshi, Glide, Data Binding, or others may generate code during build time

The key clue in your stack trace is this part:

kaptDebugKotlin

That means the failure happens during annotation processing, not during app execution.

The deeper clue is:

unrecognized Attribute name MODULE

This usually points to compiler metadata or bytecode attributes that an older tool does not understand. In practice, that often means one of these:

• Kotlin/KAPT is too old for the JDK in use
• An annotation processor is too old
• AGP, Gradle, and Kotlin versions are out of sync
• A library compiled with newer Java/module metadata is being processed by older tooling
• The project upgrade changed compileSdkVersion, but build tools were not upgraded alongside it

Why this matters in real programming:

• Modern builds rely heavily on generated code

Think of your Android build as an assembly line.

• Gradle is the factory manager
• Kotlin and Java compilers are machines on the line
• KAPT is a special machine that reads annotations and creates extra parts
• Annotation processors are custom attachments installed on that machine

If you upgrade one machine, but leave an attachment too old, the line breaks. The message may look strange, but the root issue is often simple: one tool speaks a newer format, another tool only understands the older format.

So when you see a KAPT crash like this, imagine:

“One build tool is reading data produced by another tool, but they disagree on the format.”

That is why the fix is often to align versions, use a supported JDK, or update/remove the processor causing the crash.

The main skill here is not a language syntax feature, but a build debugging workflow.

A typical Android project uses versions like this:

buildscript {
    ext.kotlin_version = '1.5.31'
    dependencies {
        classpath 'com.android.tools.build:gradle:7.0.4'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

And app/module dependencies may include KAPT processors:

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
    id 'org.jetbrains.kotlin.kapt'
}

android {
    compileSdkVersion 31
}

dependencies {
    implementation "com.google.dagger:hilt-android:2.38.1"
    kapt "com.google.dagger:hilt-compiler:2.38.1"

    implementation "androidx.room:room-runtime:2.3.0"
    kapt "androidx.room:room-compiler:2.3.0"
}

If you update only compileSdkVersion and leave older build tools in place, you may trigger failures during code generation.

A safer pattern is:

android {
    compileSdkVersion 31
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

Or, depending on your project setup, ensure Gradle uses a supported JDK version in gradle.properties or Android Studio settings.

Example of what to inspect

Check these pieces together:

• compileSdkVersion
• Android Gradle Plugin version
• Gradle wrapper version
• Kotlin plugin version
• JDK version used by Gradle
• Every dependency

Use this small debugging checklist as a traceable process.

Suppose your project contains:

android {
    compileSdkVersion 31
}

buildscript {
    ext.kotlin_version = '1.4.10'
    dependencies {
        classpath 'com.android.tools.build:gradle:4.1.0'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

dependencies {
    kapt "androidx.room:room-compiler:2.2.5"
}

What happens step by step

1. Gradle starts the Android build.
2. Kotlin sources reach the kaptDebugKotlin task.
3. KAPT invokes Java compiler internals to run annotation processors.
4. One processor or one toolchain component reads metadata it does not understand.
5. javac throws an internal assertion error.
6. Gradle wraps it in higher-level exceptions like:
   • InvocationTargetException
   • WorkExecutionException
   • TaskExecutionException
7. The actual useful clue is near the bottom of the stack trace:

AssertionError: annotationType(): unrecognized Attribute name MODULE

How to interpret it

• Top of stack trace: build task failed
• Middle of stack trace: KAPT worker failed
• Bottom/root cause: compiler/annotation processing compatibility problem

Practical debug sequence

This kind of troubleshooting appears often in real Android projects.

1. Upgrading target or compile SDK

A team raises compileSdkVersion to support a new Android release, but keeps an older Kotlin plugin. The project compiles until KAPT hits generated code and crashes.

2. Adding a library that uses annotation processing

A developer adds Room, Dagger, Hilt, Glide, or another processor-based library. The app code looks fine, but the build fails because the processor version is incompatible.

3. Switching JDK versions

A machine upgrade changes the Gradle JDK from Java 8 to Java 11 or 17. Older tooling may break during annotation processing.

4. CI builds failing but local builds succeeding

A local machine uses one JDK and CI uses another. Since compiler internals differ by version, KAPT may fail only in one environment.

5. Multi-module Android projects

One module may depend on generated code from another. A single outdated processor in one module can break the whole build chain.

In real codebases, developers usually handle this with a few standard patterns.

Version alignment

Teams keep these versions compatible as a set:

• Gradle wrapper
• Android Gradle Plugin
• Kotlin plugin
• JDK
• Annotation processors

Instead of upgrading just one piece, they upgrade the toolchain together.

Guarded upgrades

A common workflow is:

1. Upgrade compileSdkVersion
2. Upgrade AGP
3. Upgrade Kotlin plugin
4. Verify Gradle wrapper
5. Run build
6. Upgrade processor libraries if needed

Isolating annotation processors

In large projects, developers identify processors by searching for kapt dependencies:

kapt "androidx.room:room-compiler:..."
kapt "com.google.dagger:hilt-compiler:..."
kapt "com.github.bumptech.glide:compiler:..."

Then they disable them one by one to find the failing one.

Using supported JDKs

A common build-stability rule is to pin the Gradle JDK used by the project instead of relying on the system default.

Prefer KSP when supported

Some libraries support KSP instead of KAPT. Teams may migrate because KSP is often faster and less dependent on old Java annotation-processing behavior. This is not always possible, but it is a common long-term improvement.

Clean rebuild after upgrades

Developers often run:

1. Assuming the Android SDK upgrade is the only change needed

Updating only this:

android {
    compileSdkVersion 31
}

may not be enough.

You may also need to upgrade:

• Kotlin plugin
• AGP
• Gradle wrapper
• annotation processors
• JDK

2. Looking only at the top of the stack trace

This part is not the root cause:

Execution failed for task ':dependencies:android:kaptDebugKotlin'

The more useful line is deeper:

unrecognized Attribute name MODULE

Always scroll to the lowest meaningful cause.

3. Ignoring the JDK used by Gradle

You may think your project uses one Java version, but Gradle may use another.

Check with:

./gradlew -version

4. Upgrading one processor but not its runtime library

Broken example:

implementation "androidx.room:room-runtime:2.2.5"
kapt "androidx.room:room-compiler:2.5.0"

These should usually be kept in matching or compatible versions.

Safer pattern:

Quick diagnosis

• Error in kaptDebugKotlin usually means annotation processing failure
• unrecognized Attribute name MODULE usually means tool/version incompatibility
• Check the root cause at the bottom of the stack trace

Check these versions together

• compileSdkVersion
• Android Gradle Plugin
• Gradle wrapper
• Kotlin plugin
• JDK used by Gradle
• All kapt dependencies

Useful commands

./gradlew -version
./gradlew clean assembleDebug --stacktrace
./gradlew build --refresh-dependencies

What to try first

1. Clean and rebuild
2. Verify Gradle JDK
3. Upgrade Kotlin plugin
4. Upgrade AGP and Gradle wrapper
5. Upgrade annotation processor libraries
6. Disable kapt dependencies one by one to isolate the failing one

Common processor libraries to inspect

• Room
• Dagger / Hilt
• Glide
• Moshi codegen
• AutoValue
• Data Binding related generators

Good practice

• Keep runtime and compiler artifacts aligned
• Pin a supported JDK for the project

What does kaptDebugKotlin mean?

It is the Gradle task that runs Kotlin annotation processing for the debug build variant.

Is this caused by Android 12 or Android S directly?

Usually not directly. The Android SDK upgrade often exposes an existing incompatibility in your build toolchain.

What is the most likely root cause of unrecognized Attribute name MODULE?

A mismatch between JDK/compiler internals and one of Kotlin, KAPT, AGP, or an annotation processor.

Should I upgrade Kotlin first or the annotation processor first?

Start by checking overall compatibility. In practice, upgrading Kotlin, AGP, and processor libraries together is often the safest path.

How do I find which library is failing?

Search for all kapt dependencies and temporarily disable them one by one until the build passes.

Can the JDK version alone cause this?

Yes. If Gradle uses an unsupported or unexpected JDK, KAPT may fail with low-level compiler errors.

Would switching from KAPT to KSP help?

Sometimes, yes. If your libraries support KSP, it can reduce some annotation-processing compatibility issues.

Why is the error message so unclear?

Because the failure occurs inside compiler internals, then gets wrapped by Gradle and KAPT exceptions before reaching the final output.

• Gradle Wrapper — Controls the Gradle version used by the project.
• Android Gradle Plugin — Integrates Android builds with Gradle and must match compatible Gradle versions.
• Kotlin Gradle Plugin — Provides Kotlin compilation and KAPT support.
• KAPT — Kotlin annotation processing, the exact build stage where this error occurs.
• Annotation Processing — The mechanism used by libraries that generate code during builds.
• JDK Compatibility — The Java version used by Gradle can affect compiler internals and build stability.
• KSP — A Kotlin-first alternative to KAPT for supported libraries.
• Dependency Version Alignment — Keeping related libraries and plugins on compatible versions.
• Clean Build and Cache Invalidation — Useful when stale generated files or cached artifacts affect builds.
• Android compileSdkVersion — Often upgraded together with the surrounding toolchain.