In my experience extending an instance of the Application class, and using it to store some global variables, *is* an acceptable approach in various scenarios. Whether it is the right approach depends largely on your application and the specific circumstances. Remember that Android is an embedded and small footprint environment. Keeping track of some application state-wide variables up at the Application object so it can be referenced via multiple activities is probably reasonable. Storing bitmaps being manipulated in an activity probably isn't. The idea being that when a call comes in and your activity is paused or ended to free up other resources, the big chunks of data you are storing in your extended application instance are not freed up. So if you are not responsible in the choices you make in your implementation, then your app can negatively impact the user's phone over all. To my knowledge it *is* possible for the kernel to kill your entire application under extreme resource starved conditions, but like you I've yet to see it happen. So I guess the short answer to your question is I see nothing wrong with your approach, so long as it is used with discretion. At the same time, I don't see packing and unpacking activity level variables as a major hassle or concession, and, I see scenarios where doing so would be beneficial over your approach (such as those I discussed earlier where the variable I am trying to keep up with is large enough to have a negative impact on the OS overall, or, as I will discuss in the future, when the variable is a pointer to an activity specific async task that is performing long running i/o on a background thread). I hope that answers your question. And thanks again for taking the time to share it. You made a really good point.