The Android docs sum it up as
a general abstraction for “something that can be drawn.”
as circular a definition as you’re ever likely to come across. And the rest of the description isn’t much better. So for the first 18 months of my Android career I avoided drawables, mostly because I was not at all clear just what they heck they were. But in late 2010 I found myself working on an app that actually needed them, and finally reached that understanding. Here it is, for the benefit of any other confused Android devs out there.
Lots of Android widgets (not App Widgets) have a graphical component. A button has chrome that makes it look like a button; a TextView has a background, which may simply be a color, or may be something more elaborate. And what’s interesting about these graphics is that they often are – or at least should be – more dynamic than you might think. Colors change depending on whether a widget has focus. Buttons often have a visible pressed state. Different screen sizes and densities require backgrounds to adapt.
As a result, it’s not very helpful to use a simple graphics primitive – like a color value, or a static bitmap – for the graphical aspect of a widget. What’s needed is a middleware layer: a software object which you can give graphical instructions for different circumstances, and which will then manage them accordingly. Guess what? That’s a Drawable.