Introduction

In Jetpack Compose, the standard way to get an Android Context is LocalContext.current. That gives a composable access to the current ambient Android environment so it can perform tasks such as showing a toast, loading resources, or starting an activity.

Use LocalContext.current

The normal pattern is short:

1import android.widget.Toast
2import androidx.compose.material3.Button
3import androidx.compose.material3.Text
4import androidx.compose.runtime.Composable
5import androidx.compose.ui.platform.LocalContext
6
7@Composable
8fun ToastButton() {
9    val context = LocalContext.current
10
11    Button(onClick = {
12        Toast.makeText(context, "Hello from Compose", Toast.LENGTH_SHORT).show()
13    }) {
14        Text("Show Toast")
15    }
16}

This is the Compose equivalent of accessing context in classic Android UI code.

What Kind of Context You Are Getting

LocalContext.current usually gives you the context associated with the current composition environment. In many cases that is an Activity context, but you should not rely on that unless the code genuinely needs an Activity.

If you only need resource access or a system service, treat it as a Context and keep the dependency narrow.

That matters because not every place in Android should assume it owns an Activity reference.

Starting an Activity

A common use case is launching another screen.

1import android.content.Intent
2import androidx.compose.material3.Button
3import androidx.compose.material3.Text
4import androidx.compose.runtime.Composable
5import androidx.compose.ui.platform.LocalContext
6
7@Composable
8fun OpenDetailsButton() {
9    val context = LocalContext.current
10
11    Button(onClick = {
12        val intent = Intent(context, DetailsActivity::class.java)
13        context.startActivity(intent)
14    }) {
15        Text("Open Details")
16    }
17}

If you are using Compose Navigation, prefer navigation APIs for screen changes inside the app. Use raw Context-based activity launching when that is actually the right tool.

Do Not Store Context Long-Term Without a Reason

A common mistake is capturing LocalContext.current into some long-lived object or view model. In Compose, it is usually better to use the context at the point of need rather than treating it like general application state.

If you need an application-scoped context deliberately, derive it explicitly:

val appContext = LocalContext.current.applicationContext

That is safer than accidentally retaining an Activity context longer than intended.

Use the Right Abstraction When Possible

Context is powerful, but it is not always the best dependency to pass around. For example:

• use string resources APIs for UI text
• use Compose navigation instead of manual activity launches when appropriate
• inject platform services at a higher layer when that keeps composables cleaner

Compose works best when the UI layer stays declarative and only dips into Android context where necessary.

Side Effects Still Need Care

Accessing context inside a composable does not mean every platform operation should run during every recomposition. Expensive or one-time work should still be controlled with the appropriate Compose side-effect APIs so that getting the context remains cheap and the actual platform action happens only when intended.

Previews Are a Special Case

Compose previews can also provide a context, but preview behavior is not the same as running inside the full app process. If some context-dependent call behaves strangely only in previews, check whether the code assumes a real activity or runtime environment that the preview does not fully emulate.

Common Pitfalls

• Forgetting that LocalContext.current is the standard way to access context in a composable.
• Holding on to an Activity context longer than needed.
• Using raw Context navigation when Compose Navigation is the cleaner abstraction.
• Pulling too many platform concerns directly into composables instead of isolating them.
• Assuming every use of context needs an Activity rather than a plain Context or applicationContext.

Summary

• In Jetpack Compose, use LocalContext.current to get the current Android context.
• This is useful for toasts, intents, resources, and system-service access.
• Prefer the narrowest context usage that solves the problem.
• Avoid storing context in long-lived state unless you intentionally need application scope.
• Use higher-level Compose APIs when they fit better than direct context calls.