Back in 2013, we used a static Java singleton to access the application context anywhere in the project. In 2026, if you’re using Hilt, this is a one-liner — and a much safer one at that.
Why the Old Singleton Pattern Was Problematic
The classic ApplicationContextProvider approach stored a static Context reference, which could cause memory leaks and made unit testing painful. Hilt solves all of this out of the box.
Setup: Add Hilt to Your Project
In your project-level build.gradle.kts:
plugins {
id("com.google.dagger.hilt.android") version "2.51" apply false
}
In your app-level build.gradle.kts:
dependencies {
implementation("com.google.dagger:hilt-android:2.51")
ksp("com.google.dagger:hilt-compiler:2.51")
}
Annotate your Application class:
@HiltAndroidApp class MyApp : Application()
Getting Application Context Anywhere in Your Project
In any Hilt-injected class — a repository, a use case, a helper — simply inject it using @ApplicationContext:
class MyRepository @Inject constructor(
@ApplicationContext private val context: Context
) {
fun getAppName(): String = context.getString(R.string.app_name)
}
No static references, no singletons, no memory leak risks. Hilt manages the lifecycle and you get a clean, fully testable class.
Bonus: Injecting Context into a ViewModel
@HiltViewModel
class MyViewModel @Inject constructor(
@ApplicationContext private val context: Context
) : ViewModel() {
val appName = context.getString(R.string.app_name)
}
Note: Only use
@ApplicationContextfor resources, shared preferences, or system services — never for inflating views or anything UI-related. For UI work, always prefer the Activity or Fragment context.
Summary
Hilt’s @ApplicationContext annotation is the cleanest way to access context anywhere in your Android Kotlin project in 2025. It replaces fragile static singletons with a dependency-injected, lifecycle-aware, and testable alternative.
This is a 2025 Kotlin update to our original Android Get Application Context tutorial from 2013.
