danysantiago
commented
2 years ago This is very strange, its as if Hilt produced a bad metadata class and thus fails to read it at the root, if we can find the which metadata class was wrongly produced we might be able to better understand the issue.
Ideally creating a sample repro would be amazing, but I can see that being hard, and since sharing your project is not possible my other suggestion to you would be to attach a debugger to Hilt to try and figure out the issue. This comment has some instructions but I'll try to add to them.
- First, you indeed need to have the sources available, one easy way to do that is to depend on Hilt compiler for the main classpath (additional to the
kaptone):compileOnly 'com.google.dagger:hilt-compiler:2.43.1'The sources you should up in the IDE in the 'External Libraries' section. - Now you might want to put a breakpoint in AggregatedDepsMetadata#create, which if stopped on, the variables in scopes will likely contain the metadata with the issue which then points to a
@Moduleor@EntryPointthat might be the cause. It might be possible the compiler stops there a lot, if that's the case it might be worth changing the breakpoint to not stop but just log theTypeElement elementparameter, so that the last item logged before the crash will point you somewhere. You have to get a bit detective here and gather as much info as possible. - Next you have to run Gradle and KAPT in debug mode to be able to attach a debugger, just use this command:
./gradlew clean app:hiltJavaCompileDebug --no-daemon -Dorg.gradle.debug=true, note that you might need to update the task, I usedapp:hiltJavaCompileDebugthere but yours might be different. Usually using the failing task would be good enough. - Once Gradle is started in debug mode you need to attach a debugger, for this part, take a look at the the comment linked above. Specifically the part about creating the 'Remote Template'.
That's it for now! Hopefully this will help you discover which metadata file is causing the crash. Note that once you find the type element you can further inspect the source and the originating @Module or @EntryPoint by looking at the generate metadata classes in their folders in build/generated/source/kapt or build/generated/hilt. Please do report back with as much info as you can gather to help us debug this.
domhys
Chang-Eric
bcorso
I'm doing a migration from Dagger (with dagger-android) to Hilt. After completing all the steps from the migration guide, I'm getting a Null dependency error during compilation (full stacktrace at the end). At this point I'm not able to obtain any meaningful error message so I've got no idea what to fix.
What I've tried to do:
My setup: As this is a proprietary software, I'm not able to share the full source code, but my setup is pretty standard:
I'm aware that this is a hard bug to track down without any source code, but I'm posting for two reasons: