The Quick FixHilt throws this error when it encounters a dependency but has no instructions on how to build it. Think of Hilt as a factory; if you don't provide the blueprint, the assembly line stops. Follow this hierarchy to fix it:
- For your own classes: Add
@Inject constructor() to the class.- For interfaces: Use @Binds in a Hilt Module to link the interface to an implementation.- For external libraries: Use @Provides in a Hilt Module for classes like Retrofit, Room, or OkHttp.- For Modules: Ensure your module has both @Module and @InstallIn annotations.## Why Does This Error Happen?Dagger/Hilt is a compile-time framework. Unlike reflection-based tools that find dependencies while the app is running, Hilt validates everything while you build your APK. If a single 'link' in your dependency graph is missing, the whole compilation fails. This prevents runtime crashes but results in the dreaded MissingBinding message during build time.
Scenario 1: Forgetting the @Inject AnnotationThis is the most frequent culprit. You might have a class ready to go, but Hilt doesn't know it's allowed to instantiate it. Simply adding the annotation solves this for 90% of custom classes.
// ❌ Hilt is blind to this class
class AnalyticsService {
fun logEvent(name: String) { }
}
// ✅ Hilt now knows how to create this instance
class AnalyticsService @Inject constructor() {
fun logEvent(name: String) { }
}
Scenario 2: Injecting InterfacesYou cannot 'construct' an interface. When you ask Hilt to inject AuthRepository, it needs to know which specific implementation to use. You provide this mapping using an abstract class and the @Binds annotation. This is more memory-efficient than @Provides because Hilt doesn't need to generate a separate factory class.
interface AuthRepository {
fun login(): Boolean
}
class AuthRepositoryImpl @Inject constructor() : AuthRepository {
override fun login() = true
}
@Module
@InstallIn(SingletonComponent::class)
abstract class RepositoryModule {
@Binds
abstract fun bindAuthRepository(
impl: AuthRepositoryImpl
): AuthRepository
}
Scenario 3: Third-Party Libraries (Retrofit & Room)You can't add @Inject to code you didn't write. If you're using Retrofit, you must tell Hilt exactly how to configure the builder. Use the @Provides annotation inside an object module for these cases.
@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {
@Provides
fun provideRetrofit(): Retrofit {
return Retrofit.Builder()
.baseUrl("https://api.example.com/v1/")
.addConverterFactory(GsonConverterFactory.create())
.build()
}
}
Scenario 4: The Scope MismatchSometimes the binding exists, but it's in the wrong component. If you define a binding in ActivityComponent but try to inject it into a Service or a WorkManager, Hilt will fail. Double-check your @InstallIn value. SingletonComponent is available everywhere, while ActivityComponent is restricted to Activities.
Troubleshooting Checklist- Clean the Project: Run ./gradlew clean. Generated Dagger code often gets stale after refactoring.- Check Constructor Params: If your class takes three arguments, Hilt must know how to provide all three. If even one is missing, the whole class fails to bind.- Verify KSP/KAPT: If you recently switched to KSP, ensure you've replaced kapt "com.google.dagger:hilt-compiler:..." with ksp "com.google.dagger:hilt-compiler:..." in your build.gradle.- Qualifiers: If you have two different String constants being injected, you must use @Named or custom qualifiers to help Hilt distinguish between them.## VerificationTo verify the fix, open the Build output window in Android Studio. A successful fix will result in a "BUILD SUCCESSFUL" message in the logs. If you're curious, you can explore the build/generated/source/kapt folder to see the actual Java code Hilt wrote for you.
