Introduction

In Android, a Drawable is the runtime object you use to display an image, shape, vector, or solid color. If the source lives in res/drawable, the usual job is not “creating” the drawable from scratch, but loading the correct resource safely for the current theme and API level.

Prefer ContextCompat.getDrawable

The standard modern way to load a drawable resource is ContextCompat.getDrawable. It handles theme-aware loading and avoids older deprecated patterns.

1import android.os.Bundle
2import android.widget.ImageView
3import androidx.appcompat.app.AppCompatActivity
4import androidx.core.content.ContextCompat
5
6class IconActivity : AppCompatActivity() {
7    override fun onCreate(savedInstanceState: Bundle?) {
8        super.onCreate(savedInstanceState)
9
10        val imageView = ImageView(this)
11        val drawable = ContextCompat.getDrawable(this, R.drawable.ic_launcher_foreground)
12
13        imageView.setImageDrawable(drawable)
14        setContentView(imageView)
15    }
16}

If the resource ID is valid, this returns a ready-to-use Drawable. If the resource cannot be found, the result is null, so handle that case when loading user-selected or optional assets.

Different Resource Types, Same Loading API

The same loading call works for several drawable resource types:

• bitmap files such as PNG or JPEG
• vector drawables defined in XML
• shape drawables defined in XML
• state list drawables for pressed and selected states
• color drawables referenced from resources

That consistency is why ContextCompat.getDrawable is usually enough for normal app code. Android chooses the correct underlying Drawable subclass for you.

Apply the Drawable to Views

Once loaded, the drawable can be applied to different widgets depending on the UI need.

1val icon = ContextCompat.getDrawable(this, R.drawable.ic_launcher_foreground)
2
3imageView.setImageDrawable(icon)
4button.background = icon
5textView.setCompoundDrawablesWithIntrinsicBounds(icon, null, null, null)

The runtime type may vary, but the usage pattern is stable because all of them inherit from Drawable.

Mutate Before Editing Shared State

A subtle Android behavior catches many developers: drawables loaded from resources may share a constant state. If you tint or modify one instance, another view using the same resource can change too.

Call mutate() before applying changes that should stay local to one view.

1import androidx.core.graphics.drawable.DrawableCompat
2
3val original = ContextCompat.getDrawable(this, R.drawable.ic_launcher_foreground)
4val tinted = original?.mutate()
5
6if (tinted != null) {
7    DrawableCompat.setTint(tinted, 0xFF008577.toInt())
8    imageView.setImageDrawable(tinted)
9}

This matters most when a single resource is reused in lists, toolbars, or stateful controls.

Loading Drawables in Custom Views

Inside a custom view, use the view context rather than trying to reach for a global resource loader. That keeps theming correct and makes the view reusable.

1import android.content.Context
2import android.graphics.Canvas
3import android.util.AttributeSet
4import android.view.View
5import androidx.core.content.ContextCompat
6
7class BadgeView @JvmOverloads constructor(
8    context: Context,
9    attrs: AttributeSet? = null
10) : View(context, attrs) {
11
12    private val badge = ContextCompat.getDrawable(context, R.drawable.badge_background)
13
14    override fun onDraw(canvas: Canvas) {
15        super.onDraw(canvas)
16        badge?.setBounds(0, 0, width, height)
17        badge?.draw(canvas)
18    }
19}

This is a real creation point in practice: you resolve the resource into a runtime drawable and draw it yourself.

When You Need a Bitmap Instead

Sometimes the caller does not actually need a Drawable. If later code will manipulate pixels directly, pass data into a Bitmap pipeline instead. Converting a drawable to a bitmap just because a tutorial said so adds work and can waste memory.

Use a drawable when the job is display-oriented. Use a bitmap when the job is pixel-oriented.

Theme and Resource Qualifiers Matter

A drawable resource name does not map to one file only. Android may choose a different file based on density, night mode, locale, or other qualifiers. That is another reason to load through the resource system rather than opening files manually.

For example, R.drawable.logo might resolve to different assets on different devices. The code stays the same, and the framework picks the right version.

Common Pitfalls

A common mistake is using deprecated APIs such as resources.getDrawable without a theme argument. That can break tinting or behave differently across API levels.

Another issue is forgetting that getDrawable may return null. If the resource is optional, code defensively instead of assuming success.

Developers also run into shared-state bugs by tinting a resource without calling mutate(). The effect often shows up only after the same drawable is reused somewhere else.

Finally, do not decode every image into memory if a simple drawable reference on an ImageView is enough. Let the platform handle the normal resource path unless you have a measured need for custom bitmap processing.

Summary

• Load drawable resources with ContextCompat.getDrawable.
• The same API works for bitmap, vector, shape, and state list resources.
• Call mutate() before local tint or state changes.
• Use the current context so theming and qualifiers resolve correctly.
• Only switch to bitmap processing when you truly need pixel-level work.