I couldn't find a satisfying answer to this, so here we go: what's the deal with Activity/Service.getApplication()
and Context.getApplicationContext()
?
In our application, both return the same object. In an ActivityTestCase
however, mocking the application will make getApplication()
come back with the mock, but getApplicationContext
will still return a different context instance (one injected by Android). Is that a bug? Is it on purpose?
I don't even understand the difference in the first place. Are there cases outside a test suite where both calls may come back with different objects? When and why? Moreover, why is getApplication
defined on Activity
and Service
, but not on Context
? Shouldn't there always be a valid application instance available from anywhere?
This question is related to
android
android-activity
android-service
android-context
It seems to have to do with context wrapping. Most classes derived from Context
are actually a ContextWrapper
, which essentially delegates to another context, possibly with changes by the wrapper.
The context is a general abstraction that supports mocking and proxying. Since many contexts are bound to a limited-lifetime object such as an Activity
, there needs to be a way to get a longer-lived context, for purposes such as registering for future notifications. That is achieved by Context.getApplicationContext()
. A logical implementation is to return the global Application
object, but nothing prevents a context implementation from returning a wrapper or proxy with a suitable lifetime instead.
Activities and services are more specifically associated with an Application
object. The usefulness of this, I believe, is that you can create and register in the manifest a custom class derived from Application
and be certain that Activity.getApplication()
or Service.getApplication()
will return that specific object of that specific type, which you can cast to your derived Application
class and use for whatever custom purpose.
In other words, getApplication()
is guaranteed to return an Application
object, while getApplicationContext()
is free to return a proxy instead.
To answer the question, getApplication() returns an Application object and getApplicationContext() returns a Context object. Based on your own observations, I would assume that the Context of both are identical (i.e. behind the scenes the Application class calls the latter function to populate the Context portion of the base class or some equivalent action takes place). It shouldn't really matter which function you call if you just need a Context.
Compare getApplication()
and getApplicationContext()
.
getApplication
returns an Application
object which will allow you to manage your global application state and respond to some device situations such as onLowMemory()
and onConfigurationChanged()
.
getApplicationContext
returns the global application context - the difference from other contexts is that for example, an activity context may be destroyed (or otherwise made unavailable) by Android when your activity ends. The Application context remains available all the while your Application object exists (which is not tied to a specific Activity
) so you can use this for things like Notifications that require a context that will be available for longer periods and independent of transient UI objects.
I guess it depends on what your code is doing whether these may or may not be the same - though in normal use, I'd expect them to be different.
Source: Stackoverflow.com