💉 Core Concept · ~30 min read · Intermediate → Advanced

Dependency Injection & Hilt

Why manually constructing objects destroys testability — and how Hilt's compile-time dependency graph wires your entire app together without a single line of boilerplate you have to write yourself.

💉 DI Principles

🏗️ Hilt Components

🔭 Scopes

📦 Modules & Bindings

🧪 Testing

The problem with constructing your own dependencies

Every Android app has objects that depend on other objects. A ProductViewModel needs a ProductRepository. The repository needs a ProductDao and a ProductApiService. The API service needs a configured Retrofit instance. The Retrofit instance needs an OkHttpClient. The OkHttpClient needs an interceptor, a cache, and a certificate pinner.

If you build this yourself — inside the class that needs it — you end up with code like this in your ViewModel:

The "just construct it yourself" anti-pattern

class ProductViewModel : ViewModel() {
    private val repo = ProductRepositoryImpl(          // ❌ constructed here
        api = Retrofit.Builder()
            .baseUrl("https://api.example.com")
            .client(OkHttpClient.Builder()
                .addInterceptor(AuthInterceptor())
                .build())
            .addConverterFactory(GsonConverterFactory.create())
            .build()
            .create(ProductApiService::class.java),
        dao = AppDatabase.getInstance(context).productDao()  // needs Context!
    )
}

This is a disaster. The ViewModel is now tightly coupled to every implementation detail of every dependency it has. You can't test the ViewModel without a real network. You can't swap ProductRepositoryImpl for a fake in tests. If you need to change how OkHttpClient is configured, you have to find every place it's constructed. And the ViewModel needs a Context, which is a memory leak waiting to happen.

The root problem is that the ViewModel is responsible for obtaining its dependencies rather than simply receiving them. Dependency Injection inverts this: you declare what you need, and something external provides it.

🔌 Analogy

Think of electrical sockets. Your phone charger doesn't generate its own electricity — it just plugs into the wall and receives power. The charger declares its need (a 230V socket), and the infrastructure provides it. Dependency Injection works the same way: your class declares its needs (its dependencies), and the DI container provides them. The class doesn't need to know where the power comes from.

What is Dependency Injection?

Dependency Injection is a technique where an object receives its dependencies from outside rather than creating them internally. That's the entire idea. The dependencies are "injected" — passed in through a constructor, a property, or a method — rather than instantiated inside the class.

📋 Without DI vs With DI — who creates the dependencies?

Manual DI — before reaching for a framework

Before Hilt, before even Dagger, you can do DI manually — and understanding manual DI is the best way to understand what Hilt is actually doing for you. The pattern is simple: instead of a class constructing its own dependencies, you pass them in through the constructor.

Manual DI — constructor injection, the right way

// ✅ Each class declares its needs. Nobody constructs their own deps.

class ProductRepositoryImpl(
    private val api: ProductApiService,    // injected
    private val dao: ProductDao             // injected
) : ProductRepository

class GetProductUseCase(
    private val repo: ProductRepository    // injected (interface, not impl!)
)

class ProductViewModel(
    private val getProduct: GetProductUseCase  // injected
) : ViewModel()

// The "composition root" — one place that wires everything together
// In Hilt this is generated automatically. Manually it looks like this:
object AppContainer {
    private val okHttp = OkHttpClient.Builder().build()
    private val retrofit = Retrofit.Builder()
        .baseUrl("https://api.example.com")
        .client(okHttp)
        .addConverterFactory(GsonConverterFactory.create())
        .build()

    val api: ProductApiService = retrofit.create(ProductApiService::class.java)
    lateinit var db: AppDatabase

    fun init(app: Application) { db = AppDatabase.build(app) }

    fun productViewModel() = ProductViewModel(
        getProduct = GetProductUseCase(
            repo = ProductRepositoryImpl(api = api, dao = db.productDao())
        )
    )
}

// In tests: replace any piece trivially
val vm = ProductViewModel(
    getProduct = GetProductUseCase(repo = FakeProductRepository())
)

Manual DI works — Google's own Architecture Blueprints used it as a recommended approach for small apps. But it has real costs as apps scale: you write a lot of boilerplate, you have to manually handle scoping (ensuring you get the same Retrofit instance everywhere that needs one), and adding a new dependency to a class means updating every construction site. This is the problem Hilt (and Dagger before it) solves.

Hilt — DI for Android

Hilt is Google's DI library for Android, built on top of Dagger 2. Dagger is a compile-time DI framework — rather than using reflection at runtime (like Spring), it generates plain Java code at build time that wires your dependencies. Hilt is Dagger with a pre-configured setup designed specifically for Android's component hierarchy.

Here's what makes Hilt different from doing Dagger manually: Hilt knows about Android components — Application, Activity, Fragment, ViewModel, Service, BroadcastReceiver. It provides pre-built Dagger components for each one, handles their lifecycles automatically, and generates the boilerplate Dagger code that previously required you to write dozens of lines per component. You annotate. Hilt generates. You ship.

Setup — three annotations to rule them all

Hilt setup — the three entry point annotations

// 1. @HiltAndroidApp — on your Application class. Required. Triggers Hilt's code generation.
@HiltAndroidApp
class MyApp : Application()

// 2. @AndroidEntryPoint — on Activity, Fragment, View, Service, BroadcastReceiver
//    Tells Hilt: "inject fields annotated with @Inject into this class"
@AndroidEntryPoint
class ProductActivity : AppCompatActivity() {
    // Field injection (only when constructor injection isn't possible)
    @Inject lateinit var analytics: AnalyticsLogger

    private val vm: ProductViewModel by viewModels()
}

@AndroidEntryPoint
class ProductFragment : Fragment()  // parent Activity must also be @AndroidEntryPoint

// 3. @HiltViewModel — on ViewModel. Hilt provides @Inject constructor args automatically.
@HiltViewModel
class ProductViewModel @Inject constructor(
    private val getProduct: GetProductUseCase,
    savedState: SavedStateHandle          // Hilt provides this automatically
) : ViewModel()

Modules — teaching Hilt how to build things

For types you control (your own classes with @Inject constructors), Hilt figures out how to build them automatically. But for types you don't control — third-party libraries, interfaces, classes that need configuration — you write a Module that tells Hilt exactly how to create them.

A module is a class annotated with @Module and @InstallIn. The @InstallIn annotation says which Hilt component this module belongs to — which determines its scope and lifetime. Inside the module, @Provides functions tell Hilt how to construct a type. @Binds functions tell Hilt which implementation to use for an interface.

Modules — @Provides for instances, @Binds for interfaces

// Network module — provides third-party objects Hilt can't construct itself
@Module
@InstallIn(SingletonComponent::class)   // lives for the app's entire lifetime
object NetworkModule {

    @Provides
    @Singleton                          // one instance, shared everywhere
    fun provideOkHttp(): OkHttpClient =
        OkHttpClient.Builder()
            .addInterceptor(AuthInterceptor())
            .certificatePinner(/* ... */)
            .build()

    @Provides
    @Singleton
    fun provideRetrofit(okHttp: OkHttpClient): Retrofit =  // Hilt injects okHttp here
        Retrofit.Builder()
            .baseUrl(BuildConfig.API_URL)
            .client(okHttp)
            .addConverterFactory(GsonConverterFactory.create())
            .build()

    @Provides
    @Singleton
    fun provideProductApi(retrofit: Retrofit): ProductApiService =
        retrofit.create(ProductApiService::class.java)
}

// Database module
@Module
@InstallIn(SingletonComponent::class)
object DatabaseModule {

    @Provides
    @Singleton
    fun provideDatabase(@ApplicationContext app: Context): AppDatabase =
        Room.databaseBuilder(app, AppDatabase::class.java, "app.db").build()

    @Provides
    fun provideProductDao(db: AppDatabase): ProductDao = db.productDao()
}

// Repository module — binds interface to implementation (the key architecture move)
@Module
@InstallIn(SingletonComponent::class)
abstract class RepositoryModule {

    @Binds
    @Singleton
    abstract fun bindProductRepository(
        impl: ProductRepositoryImpl      // impl class has @Inject constructor
    ): ProductRepository               // interface returned — callers get the interface
}

📌 @Provides vs @Binds

@Provides — you write the function body that creates the object. Used for third-party types or objects that need configuration.
@Binds — tells Hilt "when someone asks for interface X, give them implementation Y." More efficient than @Provides because Hilt generates less code. The function must be abstract. The implementation must have an @Inject constructor.

The Hilt component hierarchy

Hilt comes with a fixed set of components, each tied to an Android lifecycle. Every component is a child of the one above it — a child component can access bindings from its parent, but not vice versa. This hierarchy determines two critical things: the scope of a binding (how long the instance lives) and the visibility of a binding (which classes can receive it).

📋 Hilt component hierarchy — lifetime and scope

Scopes — how long does a dependency live?

By default, every time Hilt provides a dependency, it creates a new instance. If five classes ask for a ProductRepository, they each get their own instance. Most of the time that's wasteful — you want one Retrofit instance, one database, one shared repository. That's what scope annotations are for: they tell Hilt to create one instance and reuse it for the lifetime of a specific component.

Annotation	Component	Lifetime	Use for
@Singleton	SingletonComponent	App lifetime	Retrofit, OkHttp, Room DB, Repositories
@ActivityRetainedScoped	ActivityRetainedComponent	Survives rotation	State shared between ViewModel and Activity
@ViewModelScoped	ViewModelComponent	ViewModel lifetime	Use cases, helpers scoped to one screen's ViewModel
@ActivityScoped	ActivityComponent	Activity instance	Destroyed on rotation — rarely needed
@FragmentScoped	FragmentComponent	Fragment lifetime	Things only needed while a fragment is alive
(none)	Any	New each time	Lightweight stateless helpers, factories

⚠️ Scope Mismatch — a common bug

A @Singleton scoped object cannot depend on a @ActivityScoped object. The singleton lives longer than the Activity — Hilt will fail at compile time if you try. The rule: a dependency can only be injected into the same scope or a shorter-lived scope. Think of it as: you can't keep a reference to something that might be destroyed before you are.

@Inject constructor — the cleanest way

For classes you own, you almost never need a module. Just annotate the constructor with @Inject and Hilt figures out how to build it — it looks at the constructor parameters, finds providers for each one, and wires them up. No boilerplate, no module needed.

@Inject constructor — Hilt does the rest

// Hilt sees @Inject constructor, reads the params, and knows how to build this.
// ProductApiService and ProductDao must also be providable (via @Inject or a Module).
class ProductRepositoryImpl @Inject constructor(
    private val api: ProductApiService,
    private val dao: ProductDao
) : ProductRepository

class GetProductUseCase @Inject constructor(
    private val repo: ProductRepository   // Hilt looks up the @Binds for this interface
)

@HiltViewModel
class ProductViewModel @Inject constructor(
    private val getProduct: GetProductUseCase,
    private val savedState: SavedStateHandle  // Hilt provides this for free in ViewModels
) : ViewModel()

// That's it. No factory. No ViewModelProvider.Factory. No wiring code anywhere.
// In your Fragment:
private val vm: ProductViewModel by hiltViewModel()  // Hilt + Compose
// or
private val vm: ProductViewModel by viewModels()        // Hilt + Fragment

Qualifiers — when you need two of the same type

Sometimes you need Hilt to provide two different instances of the same type — say, two different OkHttpClients: one with auth interceptors for your main API, and one without for a public CDN. Since the type is the same, Hilt can't distinguish them automatically. Qualifiers solve this: they're annotations that tag a binding with extra identity so Hilt can find the right one.

Qualifiers — distinguishing two bindings of the same type

// 1. Define your qualifier annotations
@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class AuthenticatedClient

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class PublicClient

// 2. Provide both — tagged with their qualifier
@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides @Singleton @AuthenticatedClient
    fun provideAuthOkHttp(): OkHttpClient =
        OkHttpClient.Builder().addInterceptor(AuthInterceptor()).build()

    @Provides @Singleton @PublicClient
    fun providePublicOkHttp(): OkHttpClient =
        OkHttpClient.Builder().build()
}

// 3. Inject by qualifier — Hilt knows which one to provide
class ProductApiService @Inject constructor(
    @AuthenticatedClient private val client: OkHttpClient
)

class ImageLoader @Inject constructor(
    @PublicClient private val client: OkHttpClient
)

Testing with Hilt

The main testing benefit of DI is that you can replace any real dependency with a fake one. Hilt provides first-class support for this with @TestInstallIn — which replaces a production module with a test module across all tests — and @UninstallModules + @BindValue for per-test overrides.

📋 Hilt test replacement — swap the real thing for a fake

Hilt testing — replacing modules and injecting fakes

// FakeProductRepository — instant, deterministic, no network
class FakeProductRepository : ProductRepository {
    var products = listOf(Product("p1", "Laptop", 999.0))

    override fun getProduct(id: String) = flowOf(products.first { it.id == id })
    override suspend fun addToCart(id: String) = "cart-123"
}

// TestModule — replaces RepositoryModule for ALL tests in this test class
@TestInstallIn(
    components = [SingletonComponent::class],
    replaces = [RepositoryModule::class]
)
@Module
abstract class TestRepositoryModule {
    @Binds @Singleton
    abstract fun bindFakeRepository(fake: FakeProductRepository): ProductRepository
}

// Test class — Hilt injects the fake automatically
@HiltAndroidTest
class ProductViewModelTest {
    @get:Rule val hiltRule = HiltAndroidRule(this)
    @get:Rule val mainDispatcher = MainDispatcherRule()

    @Inject lateinit var fakeRepo: FakeProductRepository

    @Before fun setup() = hiltRule.inject()

    @Test
    fun `loading shows Success state`() = runTest {
        val vm = ProductViewModel(
            getProduct = GetProductUseCase(fakeRepo),
            savedState = SavedStateHandle(mapOf("productId" to "p1"))
        )
        val state = vm.uiState.value
        assertThat(state).isInstanceOf(ProductUiState.Success::class.java)
    }
}

Common mistakes

Over-using field injection

Hilt supports field injection — annotating a lateinit var inside a class with @Inject. It looks convenient, but it's worse than constructor injection in almost every way. With field injection: dependencies aren't visible from the constructor signature, fields are nullable until injected (making it easy to use them before injection), and you can't easily inject fakes in unit tests without running Hilt. Use constructor injection everywhere you can. Field injection is only necessary for classes you don't construct yourself — Activities, Fragments, Services.

Injecting Activity Context into Singleton-scoped objects

A @Singleton object lives for the app's lifetime. An Activity is destroyed on rotation. If you inject Activity Context into a singleton, the singleton holds a reference to a destroyed Activity — a classic memory leak. Hilt provides @ApplicationContext and @ActivityContext qualifiers. Use @ApplicationContext for singleton-scoped objects, and only use @ActivityContext inside Activity-scoped or shorter-lived components.

Context injection — always use the right qualifier

// ❌ Don't do this — Context could be an Activity (memory leak in a @Singleton)
class AppDatabase @Inject constructor(private val context: Context)

// ✅ Do this — @ApplicationContext is always the Application, safe in @Singleton
class AppDatabase @Inject constructor(
    @ApplicationContext private val context: Context
)

// Or use the @Provides function pattern in a module:
@Provides @Singleton
fun provideDatabase(@ApplicationContext app: Context): AppDatabase =
    Room.databaseBuilder(app, AppDatabase::class.java, "app.db").build()

Making everything @Singleton

Singleton scope means one instance for the entire app lifetime. Overusing it has real costs: memory that's never released, state that's harder to reason about, and initialization that all happens up front. Use @Singleton for genuinely shared infrastructure — network client, database, repositories. For things scoped to a screen, use @ViewModelScoped. For truly stateless helpers, use no scope at all.

Assisted Injection — runtime + injected params together

Sometimes a class needs both injected dependencies and parameters that only exist at runtime — things you can't know at compile time, like a product ID entered by the user, or a chat room ID passed via deep link. @AssistedInject solves this: Hilt injects what it knows about (the repository, the API service) while you supply the runtime values through a generated factory.

@AssistedInject — mixing injected and runtime parameters

// 1. Annotate the constructor — @Inject for injected params, @Assisted for runtime ones
class ChatViewModel @AssistedInject constructor(
    private val repo: ChatRepository,         // injected by Hilt
    private val analytics: AnalyticsLogger,   // injected by Hilt
    @Assisted private val roomId: String       // supplied at runtime
) : ViewModel() {

    // 2. Define the factory interface inside the class
    @AssistedFactory
    interface Factory {
        fun create(roomId: String): ChatViewModel
    }
}

// 3. Inject the factory into your Fragment — Hilt provides it automatically
@AndroidEntryPoint
class ChatFragment : Fragment() {
    @Inject lateinit var factory: ChatViewModel.Factory

    private val roomId by navArgs<ChatFragmentArgs>()

    private val vm: ChatViewModel by viewModels {
        // Use the assisted factory as a ViewModelProvider.Factory
        viewModelFactory { initializer { factory.create(roomId.id) } }
    }
}

// In Compose with Hilt:
@Composable
fun ChatScreen(roomId: String) {
    val factory = hiltViewModel<ChatViewModel>()   // won't work directly with @Assisted
    // Use assisted factory from EntryPointAccessors or pass via nav arg into SavedStateHandle
}

✅ Assisted vs SavedStateHandle

If the runtime parameter is a navigation argument (product ID, user ID from deep link), prefer SavedStateHandle — Hilt fills it automatically in @HiltViewModel constructors and it survives process death. Use @AssistedInject for runtime values that are not navigation arguments and aren't part of saved state — like a live WebSocket token or a config object created at call time.

@EntryPoint — injecting into classes Hilt doesn't own

Hilt can inject into Activities, Fragments, ViewModels, and Services automatically. But some Android classes it doesn't manage — ContentProvider, legacy utility classes, or any class you can't annotate with @AndroidEntryPoint. For these, you define an entry point: an interface that declares what you want, installed into a Hilt component. You then retrieve it manually using EntryPointAccessors.

@EntryPoint — accessing Hilt bindings from unmanaged classes

// 1. Declare what you need as an @EntryPoint interface
@EntryPoint
@InstallIn(SingletonComponent::class)
interface AnalyticsEntryPoint {
    fun analyticsLogger(): AnalyticsLogger
    fun crashReporter(): CrashReporter
}

// 2. Access it from any non-Hilt class using EntryPointAccessors
class LegacyHelper(private val context: Context) {
    private val analytics: AnalyticsLogger by lazy {
        EntryPointAccessors
            .fromApplication(context, AnalyticsEntryPoint::class.java)
            .analyticsLogger()
    }
}

// 3. Common real-world case: ContentProvider
class AppContentProvider : ContentProvider() {
    private val db: AppDatabase by lazy {
        @EntryPoint
        @InstallIn(SingletonComponent::class)
        interface DbEntryPoint { fun db(): AppDatabase }

        EntryPointAccessors
            .fromApplication(context!!, DbEntryPoint::class.java)
            .db()
    }
}

@HiltWorker — injecting into WorkManager

WorkManager creates Worker instances itself, so you can't use a normal @Inject constructor. Hilt has a dedicated solution: @HiltWorker combined with @AssistedInject. The worker gets its Hilt dependencies injected alongside the standard Context and WorkerParameters that WorkManager provides.

@HiltWorker — dependencies injected into WorkManager workers

// 1. Annotate the Worker with @HiltWorker and use @AssistedInject
@HiltWorker
class SyncWorker @AssistedInject constructor(
    @Assisted context: Context,
    @Assisted params: WorkerParameters,
    private val repo: ProductRepository,     // injected by Hilt
    private val analytics: AnalyticsLogger    // injected by Hilt
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            repo.syncAll()
            analytics.track("sync_success")
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// 2. Initialize WorkManager with Hilt's WorkerFactory in your Application
@HiltAndroidApp
class MyApp : Application(), Configuration.Provider {
    @Inject lateinit var workerFactory: HiltWorkerFactory

    override val workManagerConfiguration
        get() = Configuration.Builder()
            .setWorkerFactory(workerFactory)
            .build()
}

// 3. Disable default WorkManager initializer in AndroidManifest.xml
// <provider android:name="androidx.startup.InitializationProvider"
//     tools:node="remove" />

Multi-bindings — injecting collections of dependencies

Sometimes you want to provide a set or map of implementations — for example, a list of analytics providers where each feature can register its own, or a map of screen validators keyed by screen name. Multi-bindings let different modules contribute to a single Set<T> or Map<K, V> without any module knowing about the others. This is how plugin-style architectures are built with Hilt.

Multi-bindings — @IntoSet and @IntoMap

// ── @IntoSet: each @Provides contributes one element to a Set<T> ──

@Module
@InstallIn(SingletonComponent::class)
object AnalyticsModule {

    @Provides @IntoSet
    fun provideFirebaseAnalytics(): AnalyticsTracker = FirebaseAnalyticsTracker()

    @Provides @IntoSet
    fun provideMixpanel(): AnalyticsTracker = MixpanelTracker()
}

// Inject the full Set — Hilt assembles it from all @IntoSet contributions
class CompositeAnalytics @Inject constructor(
    private val trackers: Set<@JvmSuppressWildcards AnalyticsTracker>
) {
    fun track(event: String) = trackers.forEach { it.track(event) }
}

// ── @IntoMap: contribute to a Map<Key, Value> ──

// First define a key annotation
@MapKey
annotation class ScreenKey(val value: String)

@Module
@InstallIn(SingletonComponent::class)
object ValidatorModule {

    @Provides @IntoMap @ScreenKey("checkout")
    fun provideCheckoutValidator(): ScreenValidator = CheckoutValidator()

    @Provides @IntoMap @ScreenKey("profile")
    fun provideProfileValidator(): ScreenValidator = ProfileValidator()
}

// Inject the map — look up validator by screen name at runtime
class ValidationService @Inject constructor(
    private val validators: Map<String, @JvmSuppressWildcards ScreenValidator>
) {
    fun validate(screen: String, data: Any) = validators[screen]?.validate(data)
}

Lazy<T> and Provider<T> — deferred and repeated creation

By default, Hilt creates a dependency the moment it's needed. Two wrappers let you change this behaviour. Lazy<T> defers construction until the first time you call .get() — and then caches the result. Provider<T> gives you a factory: every call to .get() returns a new instance (ignoring any scope on the binding). Both are injected exactly like any other dependency — just wrap the type.

Lazy and Provider — when and how to use them

class ReportService @Inject constructor(
    // Lazy: HeavyPdfRenderer is only created if generateReport() is actually called
    private val pdfRenderer: Lazy<HeavyPdfRenderer>,

    // Provider: each call to .get() returns a fresh ReportBuilder instance
    private val reportBuilderProvider: Provider<ReportBuilder>
) {
    fun generateReport(data: ReportData): ByteArray {
        val builder = reportBuilderProvider.get()    // fresh instance every time
        builder.populate(data)
        return pdfRenderer.get().render(builder)   // HeavyPdfRenderer created once, here
    }

    fun healthCheck() {
        // pdfRenderer.get() is never called here — HeavyPdfRenderer is never constructed
    }
}

// Practical use: Lazy is great for expensive @Singleton objects that are only needed
// in certain code paths. Avoids paying the init cost on every app start.
// Provider is great when you explicitly need unscoped, fresh instances on demand.

How this connects to system design interviews

DI comes up in system design interviews in two ways. First, interviewers expect you to describe how your architecture is wired — and "I'd use Hilt to inject the Repository into the ViewModel, with a Singleton-scoped Retrofit provided by a NetworkModule" is a much stronger answer than "I'd just pass things in somehow." Second, testability questions often hinge on DI: "How would you test the checkout flow without hitting the real payment API?" The answer is always "inject a fake PaymentRepository through the same Hilt binding, replacing the real module with a test module."

The deeper point is that DI is what makes everything else work. Clean Architecture, MVVM, testable Use Cases — all of these depend on the ability to swap implementations. A Repository interface is meaningless if the ViewModel constructs its own ProductRepositoryImpl. Hilt is the mechanism that turns architectural intentions into architectural reality.

🎯 Interview Summary

DI principle — classes declare dependencies, don't construct them. Enables swapping real implementations for fakes in tests.
@AssistedInject — mix injected deps with runtime params (e.g. roomId). Use SavedStateHandle instead when it's a nav argument.
@EntryPoint — access Hilt bindings from classes Hilt doesn't manage (ContentProvider, legacy helpers). Use EntryPointAccessors.fromApplication().
@HiltWorker — inject deps into WorkManager workers. Requires HiltWorkerFactory in Application and disabling default WorkManager init.
Multi-bindings — @IntoSet assembles a Set<T>, @IntoMap assembles a Map<K,V> from contributions across modules. Good for plugin registries.
Lazy<T> — defers creation until first .get(), then caches. Provider<T> — new instance on every .get(), ignores scope.
@HiltAndroidApp — on Application. Triggers Hilt's code generation.
@AndroidEntryPoint — on Activity/Fragment/Service. Enables field injection.
@HiltViewModel + @Inject constructor — ViewModel gets all deps injected automatically, including SavedStateHandle.
@Provides — function body creates the instance. For third-party types.
@Binds — maps interface to implementation. More efficient than @Provides.
@InstallIn — determines which component (and thus lifetime) a module belongs to.
Scopes — @Singleton (app), @ViewModelScoped (screen), unscoped (new each time).
@TestInstallIn — replaces a production module with a test module across all tests.
@ApplicationContext vs @ActivityContext — use @ApplicationContext in @Singleton objects to avoid memory leaks.