Introduction

getString() is a Context method, so code that lives outside an Activity, Fragment, Service, or other context-aware Android component cannot call it directly. The fix is not to bypass Android's resource system, but to pass in the right dependency such as a Context or Resources object at the point where the string is needed.

Why getString() Needs a Context

Android resources are resolved through the app's current configuration, including locale, screen qualifiers, and theming context. That is why string lookup belongs to Context or Resources, not to arbitrary plain Kotlin or Java classes.

In other words, a utility class cannot safely guess which localized string should be returned unless you give it access to Android resources.

The Straightforward Solution: Pass Context

If a helper only occasionally needs a string, pass Context as a method argument:

fun buildWelcomeMessage(context: Context): String {
    return context.getString(R.string.welcome_message)
}

Usage:

val message = buildWelcomeMessage(requireContext())

This is simple and avoids storing a long-lived reference unnecessarily.

Pass Resources When You Do Not Need Full Context

If the code only resolves resources and does not need other context features, pass Resources instead:

fun buildErrorMessage(resources: Resources): String {
    return resources.getString(R.string.network_error)
}

Usage:

val message = buildErrorMessage(resources)

This narrows the dependency and makes the function easier to test.

Constructor Injection for Reusable Classes

For a class that needs resources repeatedly, inject the dependency in the constructor:

1class MessageFormatter(private val context: Context) {
2    fun formatUsernameRequired(): String {
3        return context.getString(R.string.username_required)
4    }
5}

If the class outlives an Activity, use the application context instead of the activity context:

1class MessageFormatter(appContext: Context) {
2    private val context = appContext.applicationContext
3
4    fun formatSaved(): String {
5        return context.getString(R.string.saved)
6    }
7}

That avoids leaking an activity instance.

ViewModel and Architecture Concerns

A common architectural mistake is calling getString() directly from a plain ViewModel. A regular ViewModel should ideally not depend on Android framework classes at all. Better options include:

• emit a resource id and let the UI resolve it
• inject a string provider abstraction
• use AndroidViewModel only when framework access is genuinely necessary

A simple abstraction looks like this:

1interface StringProvider {
2    fun get(resId: Int): String
3}
4
5class AndroidStringProvider(private val context: Context) : StringProvider {
6    override fun get(resId: Int): String = context.getString(resId)
7}

Then your non-UI code depends on StringProvider instead of on Context directly.

Formatting String Resources

Passing a context also lets you use localized format arguments correctly:

fun greeting(context: Context, name: String): String {
    return context.getString(R.string.greeting_format, name)
}

This is better than manual string concatenation because translators can reorder placeholders if needed for other languages.

What Not to Do

Avoid creating a random static global Context holder just so any class can call getString(). That pattern often hides lifecycle bugs and can leak activities.

Also avoid hardcoding strings because getString() is inconvenient. If the text belongs in resources, keep it there for localization and maintainability.

When code truly does not have access to a context, that is often a design signal: resource resolution belongs closer to the UI boundary or to an injected Android-facing adapter.

Common Pitfalls

• Trying to call getString() from a plain utility class with no Android dependency. The method belongs to Context, so pass the dependency explicitly.
• Storing an Activity context in a long-lived singleton. That can leak the activity after configuration changes.
• Using application context when a theme-dependent string or UI resource needs an activity-specific context. Choose the dependency intentionally.
• Letting a plain ViewModel depend directly on Android resources without a clear reason. Prefer a resource id or a small string-provider abstraction.
• Hardcoding user-facing text because resource access feels awkward. That breaks localization and usually signals the wrong abstraction boundary.

Summary

• 'getString() requires a Context or Resources object because Android resolves strings through app configuration.'
• The simplest fix is to pass Context or Resources into the function that needs the string.
• For reusable classes, inject the dependency instead of reaching for a global static context.
• Use application context for long-lived helpers when activity context is not required.
• If non-UI code needs localized strings often, introduce a small abstraction instead of coupling everything to Android APIs.