Incorrectly getting error: There are multiple contributed bindings with the same bound type
See original GitHub issueHi folks I’m getting pretty certain that there is a bug in the version of anvil that brought in contributes subcomponent. I first saw it in sample app and now in our main app when integrating our anvil wrapping library. Generally what happens is I run the application and everything is fine, next I make a change. I rerun through android studio and I get a duplicate binding for a random class. Always a class that is a ContributesBinding and always a class that is in a file different than the class name. In my sample I moved all contributes bindings to their own file and the error has not happened since.
This is the trace. I’ve been a bit overwhelmed with life/baby and unable to make a sample for you but just wanted to let you know its still happening, its happened 5 times to me this am. Doing a clean fixes it every time. We are on kotlin 1.5.31. It surprises me no one else has hit/is reporting the same. I don’t believe my setup is atypical
com.squareup.anvil.compiler.api.AnvilCompilationException: Back-end (JVM) Internal error: There are multiple contributed bindings with the same bound type. The bound type is com.dropbox.common.feature_gating.`annotation`.FeatureGatingRegistrar. The contributed binding classes are: [com.dropbox.skeleton_sandbox.app.RealNoAuthFeatureGatingRegistry, com.dropbox.skeleton_sandbox.app.RealNoAuthFeatureGatingRegistry]
File is unknown
at com.squareup.anvil.compiler.codegen.BindingModuleGeneratorKt.findHighestPriorityBinding(BindingModuleGenerator.kt:375)
at com.squareup.anvil.compiler.codegen.BindingModuleGeneratorKt.access$findHighestPriorityBinding(BindingModuleGenerator.kt:1)
at com.squareup.anvil.compiler.codegen.BindingModuleGenerator.flush$lambda-13$getContributedBindingClasses(BindingModuleGenerator.kt:248)
at com.squareup.anvil.compiler.codegen.BindingModuleGenerator.flush(BindingModuleGenerator.kt:256)
at com.squareup.anvil.compiler.codegen.CodeGenerationExtension.analysisCompleted$flush(CodeGenerationExtension.kt:99)
at com.squareup.anvil.compiler.codegen.CodeGenerationExtension.analysisCompleted(CodeGenerationExtension.kt:110)
The first time I hit this issue was in github.com/dropbox/kaiken the next time was while integrating the newest version of Kaiken into our internal code base. I’m not sure if Kaiken has something that is an atypical config, the only thing I can think of is we have a code generator that plugs into Anvil
Issue Analytics
- State:
- Created 2 years ago
- Comments:13 (4 by maintainers)

Top Related StackOverflow Question
I think I have a repo case with Kaiken sample: https://github.com/dropbox/kaiken/tree/main/sample/sample-with-di. Download the repo, open in studio, sync and press “play” for
sample.sample-with-di.appIt should deploy onto your device Change the following line to@BindsInstance app: Applicationfrom@BindsInstance app: SkeletonOwnerApplication,https://github.com/dropbox/kaiken/blob/9c11e112ded52ad0dfafae88c5bad20c0b706058/sample/sample-with-di/app/src/main/java/com/dropbox/kaiken/sample/advancedsample/app/AdvancedKaikenSampleApplication.kt#L47
Press play again. It should give following error:
Clean and it should work again. Change back and same error Clean again error goes away
I don’t think this is related to
@ContributesSubcomponent. The same goes for #349, obviously. The@ContributesSubcomponentissue (#459) is a problem because it’s trying to bind different classes to the same interface type. In this issue and #349, Anvil thinks we’re trying to bind the same implementation to the same interface two times.Early in the compilation, Anvil looks for files with
@ContributesBindingannotations, and generates lightweight “hint” files from them. Later, when generating components, Anvil looks for these hint files in order to get a list of bound types.The file path is something like this:
build/anvil/src-gen-debug/anvil/hint/binding/com/example/com_example_Parmesan.kt, with the important part being that it’s in the binding package. We get the fqName of each bound type by looking for “_reference” properties like this one:So either there’s a duplicate file, a daemon thinks there’s a duplicate file, or perhaps we’re handling multiple source sets incorrectly (this is part of the issue with #459).
So if you’re getting an error that the same concrete type is bound multiple times…
output should be something like:
./gradlew --stopand then try again?com_example_Parmesan_reference. a. If yes, where are they? Is the build fixed if you delete them all?We can fix this issue (or band-aid the symptom) by ignoring duplicate FqNames when doing this “multiple contributed bindings” check and generating the code. That’s pretty simple. But obviously it would be nice to know why it’s happening first.