If you’ve ever used Hilt in a Jetpack Compose app, you’ve probably written code like this:

class MyRepository @Inject constructor(
    @ApplicationContext private val context: Context
)

And then paused for a second and thought:

“Okay… but where is this @ApplicationContext coming from?”
 “Who creates it?”
 “And how does Hilt magically inject it at runtime?”

This article answers those questions deeply and practically — without buzzwords, without hand-waving, and without unsafe patterns.

We’ll cover:

• Why ViewModels should not receive Context
• How Hilt resolves @ApplicationContext at runtime
• The exact dependency flow from Compose → ViewModel → Repository
• Why this approach is clean, safe, and testable
• What code Hilt generates behind the scenes (conceptually)
• Common mistakes and how to avoid them

Why Passing Context to ViewModel Is a Bad Idea

Let’s start with the mistake most Android developers make at least once:

class MyViewModel(private val context: Context) : ViewModel()

This looks harmless — until it isn’t.

Jetpack ViewModels are designed to outlive UI components like Activities and Fragments. An Activity context, however, is tied to the Activity lifecycle.

If a ViewModel holds an Activity context:

• The Activity cannot be garbage collected
• Memory leaks occur
• Configuration changes become dangerous
• Testing becomes harder

This is why Android’s architecture guidelines are very clear:

ViewModels should not hold a Context.

But what if you need access to:

• SharedPreferences
• DataStore
• ConnectivityManager
• Location services
• File system APIs

You do need a Context — just not in the ViewModel. This is where repositories and Application context come in.

The Clean Architecture Rule

Here’s the mental model that solves this cleanly:

So the rule is simple:
 If something needs a Context, it belongs below the ViewModel layer.

The Correct Dependency Flow

In a modern Compose app using Hilt, the flow looks like this:

Compose Screen
   ↓
ViewModel (no Context)
   ↓
Repository (Application Context)
   ↓
Android System Services

The ViewModel never touches Context.
 The Repository owns it.
 The Application provides it.

So… Where Does @ApplicationContext Come From?

This is the part that feels like magic — but isn’t.

@HiltAndroidApp Creates the Root Component

@HiltAndroidApp
class MyApp : Application()

When you add this annotation, Hilt:

• Generates a base class for your Application
• Creates a singleton Application-level component
• Stores the Application instance inside it

At runtime, Android creates your Application before anything else.

That Application instance is a Context.

Hilt Has a Built-In Context Provider

Inside Hilt’s internal codebase (not yours), there is a binding equivalent to:

@Provides
@Singleton
@ApplicationContext
fun provideApplicationContext(app: Application): Context = app

You never write this.
 You never import it.
 But it exists and is always available once @HiltAndroidApp is present.

So when Hilt sees:

@ApplicationContext Context

It knows exactly what to inject:
 ➡ the Application instance

Repository Requests the Context

class UserRepository @Inject constructor(
    @ApplicationContext private val context: Context
)

At compile time:

• Hilt validates that a binding exists
• It generates a factory class for MyRepository

Conceptually, the generated code looks like:

class MyRepository_Factory(
    private val contextProvider: Provider<Context>
) {
    fun get(): MyRepository {
        return MyRepository(contextProvider.get())
    }
}

At runtime:

• contextProvider.get() returns the Application
• The repository receives a safe, long-lived context

ViewModel Receives the Repository

@HiltViewModel
class UserViewModel @Inject constructor(
    private val repository: UserRepository
) : ViewModel()

The ViewModel:

• Has no idea where the context comes from
• Has no Android dependency
• Is fully testable with fake repositories

Compose retrieves it like this:

val viewModel = hiltViewModel<UserViewModel>()

Hilt handles everything else.

A Real Example: SharedPreferences

Repository:

class UserPreferencesRepository @Inject constructor(
    @ApplicationContext context: Context
) {
    private val prefs =
        context.getSharedPreferences("user_prefs", Context.MODE_PRIVATE)

    fun saveUsername(name: String) {
        prefs.edit().putString("username", name).apply()
    }

    fun loadUsername(): String =
        prefs.getString("username", "Guest") ?: "Guest"
}

The ViewModel remains clean:

@HiltViewModel
class UserViewModel @Inject constructor(
    private val repository: UserPreferencesRepository
) : ViewModel() {

    val username = MutableStateFlow("")

    fun load() {
        username.value = repository.loadUsername()
    }
}

Notice what’s missing?

No Context in the ViewModel.
 That’s the whole point.

Why This Is Safe (And Recommended)

Let’s address the usual concerns.

Will this leak memory?
 No. Application context lives as long as the app process.

Will this break on rotation?
 No. ViewModels are lifecycle-aware; repositories aren’t tied to UI.

Is this officially recommended?
 Yes. This matches Google’s own Compose + Hilt samples.

Is this future-proof?
 Yes. This is the architecture Android is moving toward, not away from.

What If You Forget @HiltAndroidApp?

Your app will crash early with a clear error:

Hilt Activity must be attached to an @HiltAndroidApp Application

This happens because:

• No ApplicationComponent is created
• No Context binding exists
• Dependency graph cannot be resolved

This is Hilt protecting you — not failing silently.

The One Rule to Remember

Context belongs to the data layer, not the state layer.

If you follow this rule:

• Your architecture scales
• Your code stays testable
• Your app avoids subtle lifecycle bugs

Conclusion

@ApplicationContext isn’t magic.
 It’s a well-defined dependency provided by Hilt at the Application level, injected safely into the data layer, and kept far away from your UI state.

Once you understand this flow, Compose + Hilt stops feeling mysterious — and starts feeling predictable.

If this helped you, consider sharing it with the next developer who asks:
 “But where does the Context come from?”