Why Dagger Hilt Fails in Android Projects (The Same 3 Reasons Every Time)

If Dagger Hilt fails in your Android project, it almost never fails randomly.

It fails in the same three places, over and over again — not because Hilt is complex, but because its setup is unforgiving.
You can write code that looks correct, compiles without issues, and still crashes at runtime.

In this article, I’ll walk through the three most common real-world Hilt problems, show the exact symptoms you’ll see, and explain why they happen.

No DI theory.
No “Hello World” fluff.
Only real failure modes.

---

Problem #1: Hilt Plugin Missing (Gradle Looks Fine, App Crashes)

Symptom

You launch the app and immediately hit an exception, even though:

• Hilt dependencies are added

• @HiltViewModel is present

• Everything compiles

Root cause

The Hilt Gradle plugin is missing or misconfigured.

Hilt is not just a library — it’s a code generator wired into Gradle.
If the plugin doesn’t run, the generated components do not exist.

What usually went wrong

• You added hilt-android and hilt-compiler

• But forgot dagger.hilt.android.plugin

• Or defined it without apply false in the root project

• Or forgot to specify the version at the project level

Gradle sync may succeed.
The app still crashes.

Mental model

If the Hilt plugin is not applied, annotations do nothing.

---

Problem #2: @HiltAndroidApp Exists — But the Manifest Is Wrong

Symptom

• App crashes at startup

• Context injection fails

• Errors look unrelated to your actual code

Root cause

You created a custom Application class and annotated it correctly:

@HiltAndroidApp
class MyApp : Application()

But you forgot to register it in the AndroidManifest.

Why this breaks everything

Hilt generates its root component at the Application level.
If Android doesn’t know about your Application class, Hilt never gets initialized.

From Hilt’s perspective:

• There is no root

• No graph

• No injection

Fix

Declare your application explicitly in AndroidManifest.xml.

Mental model

Hilt does not bootstrap itself.
Android must create the Application first.

---

Problem #3: ViewModel Injection Without @AndroidEntryPoint

Symptom

Runtime crash:

Cannot create an instance of class XViewModel

Your code looks correct:

• @HiltViewModel is present

• Dependencies have @Inject

• App and repository work elsewhere

Root cause

The Activity (or Fragment) is not annotated with @AndroidEntryPoint.

You are requesting a Hilt-managed ViewModel from a class that is not part of the Hilt graph.

Why this fails

by viewModels() requires a Hilt ViewModel factory.
That factory is only available if the owner is a Hilt entry point.

No entry point → default factory → crash.

Fix

Annotate the Activity or Fragment:

@AndroidEntryPoint
class MainActivity : ComponentActivity()

Mental model

Hilt injection is a chain.
Break one link, and everything downstream fails.

---

The Pattern Behind All 3 Problems

All three issues share the same underlying cause:

Hilt is deterministic, not magical.

It requires:

1. A Gradle plugin

2. A registered Application

3. A continuous injection chain

Miss one — and Hilt fails loudly, often at runtime.

---

Final Takeaway

If Hilt feels “fragile” or “random”, it’s usually because:

• The build system is misconfigured

• The root component is missing

• Or the injection chain is broken

Once you internalize that Hilt is a compile-time graph generator, not a runtime framework, these problems stop appearing.

And when they do — you’ll know exactly where to look.