Hilt 2.59: ComponentTreeDeps annotation missing from runtime artifacts - compilation fails with AGP 9.0

[paragbaxi]

After upgrading to Hilt 2.59 with AGP 9.0.0, the build fails because the Hilt Gradle plugin generates code referencing dagger.hilt.internal.componenttreedeps.ComponentTreeDeps, but this class does not exist in any Hilt 2.59 runtime artifact.

Environment

• Hilt version: 2.59
• AGP version: 9.0.0
• Gradle version: 9.3.0
• Kotlin version: 2.2.10
• KSP version: 2.2.10-2.0.2
• OS: macOS (also reproducible on Linux CI)

Steps to Reproduce

1. Configure project with AGP 9.0.0 and Hilt 2.59:
   // build.gradle.kts
   plugins {
   id("com.google.dagger.hilt.android") version "2.59"
   }
2. Run a clean build:
   ./gradlew clean assembleDebug

Expected Behavior

Build succeeds - generated Hilt code compiles against Hilt runtime.

Actual Behavior

Compilation fails with:

error: package dagger.hilt.internal.componenttreedeps does not exist
import dagger.hilt.internal.componenttreedeps.ComponentTreeDeps;
^

error: cannot find symbol
@ComponentTreeDeps(
^
symbol: class ComponentTreeDeps

Investigation

I verified the class is missing from all Hilt 2.59 artifacts:

Search all Dagger 2.59 JARs in Gradle cache

find ~/.gradle/caches -name "*.jar" -path "dagger" -path "2.59" -exec jar tf {} ; | grep -i componenttree

No results

Confirm the annotation doesn't exist

find ~/.gradle/caches -name "*.jar" -path "hilt" -path "2.59" -exec jar tf {} ; | grep componenttreedeps

No results

The Hilt Gradle plugin generates code that imports dagger.hilt.internal.componenttreedeps.ComponentTreeDeps, but this package/class does not exist in:

• hilt-android-2.59.jar
• hilt-core-2.59.jar
• hilt-android-compiler-2.59.jar
• Any other Dagger 2.59 artifact

Workaround

Downgrade to Hilt 2.58. Despite not officially supporting AGP 9.0, it builds and runs correctly:

// gradle/libs.versions.toml
googleDaggerHilt = "2.58" # Works with AGP 9.0

Root Cause Hypothesis

It appears the 2.59 release included the Gradle plugin changes for AGP 9.0 support (which generate ComponentTreeDeps references) but the corresponding runtime annotation class was not included in the published artifacts.

[paragbaxi]

Additional Investigation: Multiple Missing Annotations

We attempted a polyfill workaround by creating stub annotation classes. This revealed that multiple internal annotations are missing, not just ComponentTreeDeps:

Missing Annotations Discovered

Package	Class
dagger.hilt.internal.componenttreedeps	ComponentTreeDeps
dagger.hilt.internal.processedrootsentinel	ProcessedRootSentinel
dagger.hilt.internal.aggregatedroot	AggregatedRoot

Processor Expects Undocumented Properties

Even after creating stub annotations matching the generated code, the annotation processor expects additional properties not used in the generated code:

error: [Hilt] No property named aliasOfDeps was found in annotation ComponentTreeDeps
error: [Hilt] No property named uninstallModulesDeps was found in annotation ComponentTreeDeps
error: [Hilt] No property named earlyEntryPointDeps was found in annotation ComponentTreeDeps
error: [Hilt] No property named root was found in annotation AggregatedRoot

Verification

# What exists in hilt-core-2.59.jar under dagger/hilt/internal/:
jar tf hilt-core-2.59.jar | grep 'dagger/hilt/internal/'

# Results - these exist:
dagger/hilt/internal/GeneratedComponent.class
dagger/hilt/internal/GeneratedComponentManager.class
dagger/hilt/internal/GeneratedComponentManagerHolder.class
dagger/hilt/internal/Preconditions.class
dagger/hilt/internal/UnsafeCasts.class

# But NO: componenttreedeps/, processedrootsentinel/, aggregatedroot/

Conclusion

The polyfill approach is not viable because:

1. Multiple annotation classes are missing (not just one)
2. The processor expects properties beyond what the generated code uses
3. The full schema of required annotations is unknown

Workaround confirmed: Hilt 2.58 works with AGP 9.0 despite not officially supporting it.

[bcorso]

Confirm the annotation doesn't exist

find ~/.gradle/caches -name "*.jar" -path "hilt" -path "2.59" -exec jar tf {} ; | grep componenttreedeps

I think the issue with the above analysis is that the hilt-android artifact is an aar not a `jar file (https://repo1.maven.org/maven2/com/google/dagger/hilt-android/2.59/).

If you unzip the aar and look within classes.jar you should find the ComponentTreeDeps class:

$ jar tf hilt-android-2.59/classes.jar | grep ComponentTreeDeps
dagger/hilt/internal/componenttreedeps/ComponentTreeDeps.class

That said, I'm not really sure what's going on with your setup and why it behaves differently between 2.58 to 2.59. If you get any more information feel free to post here.

[paragbaxi]

Investigation Update: hiltJavaCompile Task Classpath Issue

Following up on @bcorso's insight - you're correct that the annotations ARE present in hilt-android.aar/classes.jar:

$ jar tf hilt-android-2.59/classes.jar | grep ComponentTreeDeps
dagger/hilt/internal/componenttreedeps/ComponentTreeDeps.class

$ jar tf hilt-android-2.59/classes.jar | grep ProcessedRootSentinel  
dagger/hilt/internal/processedrootsentinel/ProcessedRootSentinel.class

Root Cause Identified

The issue is in the Hilt Gradle plugin's hiltJavaCompile{Variant} task. This task compiles the generated *_ComponentTreeDeps.java files but its classpath does not include the classes from hilt-android.aar.

Generated Code That Fails

The plugin generates code at build/generated/hilt/component_trees/{variant}/:

// MyApplication_ComponentTreeDeps.java
package com.example.application;

import dagger.hilt.internal.componenttreedeps.ComponentTreeDeps;  // Line 4 - fails
// ...
@ComponentTreeDeps(  // Line 45 - fails
    rootDeps = { ... },
    // ...
)
public class MyApplication_ComponentTreeDeps {
}

// _com_example_application_MyApplication.java  
import dagger.hilt.internal.processedrootsentinel.ProcessedRootSentinel;  // fails

@ProcessedRootSentinel(  // fails
    roots = "com.example.application.MyApplication"
)

Dependency Resolution Analysis

# hilt-android IS on the main compile classpath
$ ./gradlew :app:dependencies --configuration freeDebugCompileClasspath | grep hilt-android
+--- com.google.dagger:hilt-android:2.59

# hilt-android IS on the annotation processor classpath  
$ ./gradlew :app:dependencies --configuration hiltAnnotationProcessorFreeDebug | grep hilt-android
\--- com.google.dagger:hilt-android:2.59

# BUT hiltCompileOnly is EMPTY by default
$ ./gradlew :app:dependencies --configuration hiltCompileOnlyFreeDebug
hiltCompileOnlyFreeDebug - Hilt aggregated compile only dependencies for 'freeDebug'
No dependencies

Even after manually adding hilt-android to hiltCompileOnly*:

// build.gradle.kts
configurations.matching { it.name.startsWith("hiltCompileOnly") }.configureEach {
    dependencies {
        add(this@configureEach.name, libs.google.dagger.hilt)
    }
}

The dependency shows up in the configuration but hiltJavaCompileFreeDebug still fails - suggesting the task doesn't use this configuration for its javac classpath.

Workarounds Attempted (All Failed)

Attempt	Result
Add hilt-android to ksp()	No effect - KSP processor config, not javac
Add to hiltCompileOnly* configurations	Dependency resolves but task still fails
Add to annotationProcessor* configurations	No effect
Modify task classpath via afterEvaluate { tasks.matching { it.name.startsWith("hiltJavaCompile") }.configureEach { classpath = ... } }	AGP 9.0 configuration resolution errors

Task Registration Details

The hiltJavaCompile{Variant} task appears to be registered by the Hilt Gradle plugin with its own classpath configuration that doesn't include hilt-android. The task dependencies show:

Registered task dependencies: app:freeDebugCompileClasspath
Registered task dependencies: app:kotlinCompilerPluginClasspathFreeDebug

But the actual javac invocation doesn't seem to use the full freeDebugCompileClasspath.

Potential Fix Location

Based on the task naming (hiltJavaCompile*) and the configurations created (hiltCompileOnly*, hiltAnnotationProcessor*), the fix likely needs to be in the Hilt Gradle plugin where it registers the HiltJavaCompileTask - it should include hilt-android (or at least the classes.jar from the AAR) on the javac classpath.

Looking at the Dagger source, this might be in HiltGradlePlugin.kt or wherever hiltJavaCompile tasks are configured.

Environment

• AGP: 9.0.0
• Gradle: 9.3.0
• Kotlin: 2.2.10
• KSP: 2.2.10-2.0.2
• Hilt: 2.59 (failing), 2.58 (works)
• macOS, Java 21

Why Hilt 2.58 Works

Hilt 2.58's Gradle plugin doesn't generate @ComponentTreeDeps or @ProcessedRootSentinel annotated code - these annotations are only used in the AGP 9.0 support added in 2.59.

Current Workaround

Staying on Hilt 2.58 with AGP 9.0 - works fine despite lacking official AGP 9.0 support.

[daduz-r]

I might be hitting a similar issue with Hilt 2.59:

error: cannot find symbol
import dagger.hilt.internal.processedrootsentinel.ProcessedRootSentinel;

The project also failed to compile for me with Hilt 2.57.2 and 2.58.

For context, I’m using Kotlin 2.2.21, Gradle 9.0 and KSP 2.3.4.

I was able to get the project compiling after removing the following lines from gradle.properties, although I’m not certain this is the root cause:

android.nonFinalResIds=false
android.enableJetifier=true

I hope this can help you with the resolution.

[bcorso]

@paragbaxi, thanks for the analysis.

I'm actually concerned about this part:

Why Hilt 2.58 Works

Hilt 2.58's Gradle plugin doesn't generate @ComponentTreeDeps or @ProcessedRootSentinel annotated code - these annotations are only used in the AGP 9.0 support added in 2.59.

It suggests something strange is going on because the @ComponentTreeDeps and @ProcessedRootSentinel should be generated in both version. It's what triggers the generation of the actual Dagger components, so if that never happens something should break.

Also, I'm suprised Hilt 2.58 even works with AGP 9 (unless you have also set android.newDsl=false) because some of the APIs we were using are removed in AGP 9.

Would you be able to create a minimal reproducible example project that demonstrates this behavior?

[SerggioZS]

I have the same problem in my project using Hilt 2.59 and Gradle 9.
Downgraded to 2.58 and it works!

[bcorso]

@SerggioZS can you clarify which version of AGP you are using? Also, are you using Gradle 9.0/9.1/9.2? IIUC, AGP 9 requires Gradle 9.1+.

[SerggioZS]

@bcorso

gradle-wrapper.properties
distributionUrl=https://services.gradle.org/distributions/gradle-9.1.0-bin.zip

root build.gradle
buildscript {

ext.kotlin_version = '2.3.0'

repositories {
    google()
    mavenCentral()
    gradlePluginPortal()
}
dependencies {
    classpath 'com.android.tools.build:gradle:9.0.0'
    classpath 'com.google.gms:google-services:4.4.4'
    classpath 'com.google.android.gms:oss-licenses-plugin:0.10.10'
    classpath "com.google.dagger:hilt-android-gradle-plugin:2.58"
}

}
plugins {
id 'com.google.devtools.ksp' version '2.3.4' apply false
id("org.jetbrains.kotlin.plugin.compose") version "$kotlin_version" apply false
id("com.google.firebase.appdistribution") version "5.2.0" apply false
}

[bcorso]

Thanks for the info @SerggioZS.

If someone can create a minimal repro project for this issue that would be great.

[memostark]

I had the same compilation issue and I can confirm that removing android.enableJetifier=true from gradle.properties fixed it.

[SerggioZS]

@memostark Can confirm. Disable jetifier from gradle.properties android.enableJetifier=false and the project compiles with Hilt 2.59.
@bcorso You can simply create a new empty project setup Hilt dependencies and set android.enableJetifier=true

[paragbaxi]

Confirmed: Disabling Jetifier fixes Hilt 2.59

Following up on my detailed investigation above - @memostark and @SerggioZS were right. Disabling Jetifier resolves the issue completely.

# gradle.properties
android.enableJetifier=false

Environment:

• AGP: 9.0.0
• Gradle: 9.3.0
• Kotlin: 2.2.10
• KSP: 2.2.10-2.0.2
• Hilt: 2.59 ✅ (now working)

Root Cause Hypothesis:

Jetifier rewrites bytecode to convert legacy Android Support Library references to AndroidX. With Hilt 2.59's new AGP 9.0 support, the hiltJavaCompile task generates code that imports from dagger.hilt.internal.*. Jetifier appears to be interfering with how these classes are resolved from hilt-android.aar, causing javac to fail with "cannot find symbol" despite the classes existing in the AAR.

This explains why my earlier investigation showed the annotations were present in classes.jar but javac couldn't see them - Jetifier was corrupting the classpath resolution.

Recommendation:

For projects with minSdk >= 21, Jetifier is unnecessary overhead since all modern dependencies are AndroidX-native. Consider documenting this in the Hilt release notes as a known issue for users who still have enableJetifier=true.

Thanks @memostark and @SerggioZS for identifying the workaround! 🙏

[ccodega]

I cannot disable jetifier, do you have any plan for a proper fix?

[bcorso]

Thanks @memostark and @SerggioZS for the workaround and thanks @paragbaxi for confirming it works!

I've updated the Dagger 2.59 release notes to mention this.

I cannot disable jetifier, do you have any plan for a proper fix?

In order to get a proper fix we would need to better understand why enabling the jetifier results in classes missing from the class path (it certainly doesn't seem like it should). IMO, this sounds like a bug in AGP.

Unfortunately, this flag is also deprecated in AGP 9 and will be completely removed in AGP 10 so I'm not sure how willing they would be to look into this.

[ccodega]

@bcorso I see the point but this will force apps using support library to migrate also for Hilt dependency, AGP upgrade to v10 I don't think it will be a strict requirement in the short term