Hilt is a very opinionated framework for achieving dependency injection for your Android applications. Since its opinionated  it comes with a standard way of integrating dependency injection and hence takes away lots of boilerplate code that usually comes with integrating Dagger to any project.

Hilt is built on top of Dagger and hence it comes with all the compile-time checks and runtime performances Dagger provides. And of course if you are comfortable and happy using your current Dagger setup you don't have to use Hilt.

Adding to your project

buildscript {
    ext.hilt_version = '2.32-alpha'
    dependencies {
        classpath "com.google.dagger:hilt-android-gradle-plugin:$hilt_version"
Project's root build.gradle file
apply plugin: 'kotlin-kapt'
apply plugin: 'dagger.hilt.android.plugin'

android {

dependencies {
    implementation "com.google.dagger:hilt-android:$hilt_version"
    kapt "com.google.dagger:hilt-compiler:$hilt_version"
app/build.gradle file

Enable Java 8 in your project

android {
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
app/build.gradle file


  • @HiltAndroidApp - All apps that use Hilt should have an Application class with the @HiltAndroidApp annotation.
  • @AndroidEntryPoint - Use this annotation to inject dependencies to other Android classes like Activities, fragment, broadcast receivers etc
  • @HiltViewModel - for denoting a ViewModel
  • @Inject - Use this annotation to obtain the required dependencies. Note that the injected var cannot be private.
  • The @Inject annotation is also used to define bindings to dependencies ie annotate constructors of the dependencies that can be constructor-injected with the @Inject annotation to let Hilt know how to provide that dependency.
  • @Module - Modules enables you to provide bindings for dependencies that cannot be constructor-injected mainly implementation of interfaces, or class from an external library etc.
  • @InstallIn - Additional annotation for Modules so that Hilt knows which all Android classes each module will be used in. See below for some generated components that we can use @InstallIn for.
  • @Binds - This function annotation helps Hilt to bind which implementations to be injected in case of interfaces. The annotation function's return type denotes the interface type and the function parameter denotes which specific implementation to use.
  • @Provides - This function annotation helps Hilt to provide dependencies of classes from an external library or ones built with a builder pattern. The function return type denotes the type of the dependency that is provided, the function parameters denotes any other dependencies required to build the provided type, the function body tells Hilt how to construct the particular dependency. Note that the function body is executed every time a dependency of that type is provided.
  • @Qualifier - Qualifiers are used when you want to provide different implementations of the same type.

Predefined qualifiers in Hilt

Hilt provides some predefined qualifiers for context namely @ApplicationContext and @ActivityContext

Generated components for Android

Hilt provides some generated components that can be used to InstallIn dependencies from your Module. They are:

  • SingletonComponent - injected for Application and BroadcastReceivers
  • ActivityRetainedComponent
  • ViewModelComponent - injected for ViewModel
  • ActivityComponent - injected for Activity
  • FragmentComponent - injected for Fragment
  • ViewComponent - injected for View
  • ViewWithFragmentComponent - injected for View annotated with @WithFragmentBindings
  • ServiceComponent - injected for Service
Note: There is no generated component for BroadcastReceivers since Hilt injects broadcast receivers from the SingletonComponent


  • Hilt only supports activities that extend ComponentActivity, such as AppCompatActivity
  • Hilt only supports fragments that extend androidx.Fragment
  • Hilt does not support retained fragments

Check the resources below for more details about component lifecycles and scopes