# What is Context in Android?

As an Android developer, you work with Context daily. But have you ever wondered what Context actually is and why it’s essential? Let's dive into some common scenarios and break them down together.

## Accessing String Resources

Imagine you've added a string in your resources file like this:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725584753674/90643e98-c806-4e6e-b1f3-9fcc6b62cf51.png align="center")

Now, you want to access this string in your code. Here's what that might look like:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725584773408/dd39dc82-4192-4fea-bd1f-37f4945ca415.png align="center")

To get this string, you first need to use Context. But why?

### Why Context is Necessary

Android stores resources like strings, drawables, and colors using its framework. When you create a resource file, the Android framework handles its storage. But when you want to retrieve this file, you need to ask the system for it. Here’s where **Context** comes in.

**Context** is your gateway to the Android system—it allows you to communicate with the operating system to access resources, services, and more.

Think of it like communicating with a friend. To reach them, you use your mobile phone, which acts as a bridge. Similarly, **Context** is the bridge between your app and the Android system.

**In summary: Context is the bridge between you and the operating system.**

## Why Views Need Context

Every view in Android requires **Context**. Why? Because views often need to access system resources—like colors, strings, or the current app mode (light or dark). To retrieve these resources, the view needs to communicate with the system, which is done through **Context**.

## Different Types of Context in Android

Android provides five main types of **Context**:

* Application Context
    
* Activity Context
    
* Service Context
    
* BroadcastReceiver Context
    
* Content Provider Context
    

You're probably most familiar with **Application** and **Activity** contexts, as they're the ones you use most frequently. However, each type serves a different purpose and provides access to different system resources.

### Misconceptions About Memory Leaks

A common concern when using **Context** is avoiding memory leaks. Let’s go through two scenarios:

**Scenario 1: Accessing SharedPreferences in an Activity**

If you use `getApplicationContext()` to access **SharedPreferences**, will it cause a memory leak? **No, it won’t.**

**Scenario 2: Holding a Reference to an Activity in the Application Class**

If you hold a reference to an **Activity** in your **Application** class, will it cause a memory leak? **Yes, it will.** The garbage collector can’t reclaim the memory used by the **Activity** if the **Application** class holds a reference to it, leading to a memory leak.

This highlights the importance of using the right **Context** in the right situation.

## Responsibilities of Different Contexts

Each type of **Context** has specific responsibilities. For example:

* The **Application Context** cannot start a dialogue. Let’s see what happens when you try:
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725584809934/3f66fb92-60af-46f6-858f-f7a682b85138.png align="center")

When you run this code, you’ll get the following error:

**android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running?**

This shows that each **Context** type has specific limitations and responsibilities. Here’s a table that outlines what each type of **Context** can and cannot do:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725584830733/9f83aa34-eadb-4595-b52a-b6acabd28f2c.png align="center")