Is it safe to save the app context to a static variable in Android?

Question

I know that usage of static variables on Android is quite risky, especially if you reference them to activities. However, if I have a class that extends Application (let\'s

Answer 1

It's safe to do this in Application#onCreate() because the Application is created before any activity. If your app gets killed in the background, the Application instance will be recreated and your global will be set before any activity runs.

It's important to note that you should never set global variables from an activity. If you do, your app could fail in the following way:

1. Set global in activity A
2. Navigate to activity B
3. App goes into background
4. Framework kills app and process
5. App is restored
6. Framework creates activity B. Activities in the backstack are not created until you navigate back to them, so the global is not set!
7. Activity B attempts to use global, and boom... NullPointerException

Answer 2

It should be safe. Also the following note from the API docs could be relevant to you:

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

Answer 3

This is the warning when you create a Context context; in android-studio :

Do not place Android context classes in static fields; this is a memory leak and also breaks Instant Run.

A static field will leak contexts.

Non-static inner classes have an implicit reference to their outer class.

If that outer class is for example a Fragment or Activity, then this reference means that the long-running handler/loader/task will hold a reference to the activity which prevents it from getting garbage collected. Similarly, direct field references to activities and fragments from these longer running instances can cause leaks.

ViewModel classes should never point to Views or non-application Contexts.

Answer 4

Interesting comment popped up from Studio when I was tidying up nasty static contexts:

"This is a leak (and also breaks Instant Run)."

So with the launch of Instant Run, we have the case where Android developers are not planning on saving static variables. Whilst instant run is not (yet) on my agenda, it is useful to know that there is a specific example where it is not only bad practice, but the use case where it is wrong is identified.

Answer 5

is it safe to save the app context to a static variable?

Presently, yes, it appears to be safe, though I would not have getAppContext() return Context, but instead return App or Application.

That being said, the fact that the core Android team did not set it up this way in the first place suggests that perhaps there may be hidden issues of which we are unaware, or that in the future this approach may introduce problems.

As the acronym of the saying goes, YMMV. :-)

---

EDIT

if so , is it also safe for any other class to have any kind of reference to the application context ?

I have no idea what you mean by "safe" here.

but if i use multiple processes , i will get totally different references to App class on each process , right?

If you use multiple processes, you should be slapped with a trout. But, yes, you should get distinct App instances per process.