Why Android Images Cause OOM: Memory Usage, DPI, and Glide Tips

Background

Different Android versions allocate bitmap memory in different ways. Loading a high‑resolution image without proper down‑sampling can cause Out‑Of‑Memory (OOM) crashes. This summary explains how to calculate image memory usage, how Android density buckets affect the allocation, and how to avoid OOM when loading static or network images.

Key Concepts

Screen size – diagonal length in inches (1 inch = 2.54 cm).

Screen pixel density (ppi) – pixels per inch; Android defines six density buckets: ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi.

Screen resolution – pixel count in width × height (e.g., 4896 × 6528).

Screen Density Mapping

Android groups densities with a scaling ratio of 3 : 4 : 6 : 8 : 12 : 16. The diagram below shows the relationship.

Code Verification

A simple layout contains an ImageView that displays a background image. The activity converts the drawable to a Bitmap and logs its memory usage.

The image is placed in res/drawable‑nodpi/, a folder whose resources are not scaled or compressed.

Static Image Memory Consumption

A 5.48 MB image with dimensions 4896 × 6528 contains 31,961,088 pixels. In ARGB_8888 format each pixel occupies 4 bytes, so the bitmap uses:

31,961,088 pixels × 4 bytes = 127,844,352 bytes ≈ 122 MB

Android supports four bitmap configurations (see Bitmap.Config). The default ARGB_8888 allocates 4 bytes per pixel.

Impact of Resource Folder on Memory

Placing the same image in different density‑specific folders on a Vivo X21 (480 dpi) shows similar native memory usage for hdpi, xhdpi and xxhdpi. The xxxhdpi folder consumes the most memory (≈ 200 MB native).

Network Image Loading with Glide

Glide provides two common loading styles:

No callback

Glide.with(context)
    .load(url)
    .apply(requestOptions.override(width, height))
    .into(imageView);

With callback (SimpleTarget)

Glide.with(context)
    .asBitmap()
    .load(url)
    .apply(requestOptions)
    .into(simpleTarget);

If SimpleTarget is created with explicit width/height, Glide caches the image at that size; if both dimensions are 0, the original pixel dimensions are cached.

Typical network images (e.g., 1920 × 1080) occupy about 7.9 MB (1920 × 1080 × 4 bytes), so the difference between specifying dimensions and using the original size is often negligible.

Crash Causes and Solutions

Loading the 5.48 MB static image without down‑sampling creates a bitmap of ~122 MB, which triggers OOM on devices with limited RAM. Example log:

AndroidRuntime: java.lang.RuntimeException: Canvas: trying to draw too large (127844352 bytes) bitmap.

From Android 8.0 onward bitmap memory is allocated on the native heap, allowing the allocation to grow until the system runs out of memory, which may not surface as a Java OOM exception.

**Solution**: avoid using SimpleTarget with default dimensions. Instead, apply a down‑sampling strategy and limit the requested size to the device’s screen width × height:

Glide.with(context)
    .asBitmap()
    .load(url)
    .apply(new RequestOptions()
        .downsample(DownsampleStrategy.AT_MOST)
        .override(screenWidth, screenHeight))
    .into(imageView);

This reduces memory consumption from > 300 MB to roughly 340 MB in the demo and prevents crashes.

Conclusion

Do not place high‑resolution static images indiscriminately in density‑specific drawable‑* folders; doing so can cause abnormal native memory consumption.

When using Glide (or similar libraries), explicitly set the target width and height based on the device’s screen dimensions instead of loading the original image size. Applying DownsampleStrategy.AT_MOST further safeguards against OOM crashes.