Most image-related out-of-memory crashes are not caused by one enormous photo. They come from a thousand small decisions: a list cell that asks for “whatever size the server has,” a signed URL that defeats the cache, a singleton that keeps thumbnails alive long after the user left the screen. Each decision looks harmless in review, and each one shows up later as a crash cluster in your production dashboards.

This post is a field guide for senior Android engineers. It organizes the problem into three levers, Reduce , Reuse , and Recycle , and for each one it covers idiomatic Kotlin, the library knobs that matter, and the failure modes that actually reach production. The framing follows the Android Developers session “Actionable strategies for reducing your app’s Bitmap memory footprint” from Android Dev Summit 2026; the code, numbers, and scenarios below are my own.

1. Start with the arithmetic

A decoded bitmap is just a grid of pixels.…