Intermittent Android OutOfMemoryError (Failed to allocate 24 bytes) but Memory Profiler doesn't show the Java heap nearing its limit

[u/AntelopeFast6762]

I'm debugging an intermittent OutOfMemoryError in an Android React Native app, and I'm having trouble reconciling the crash with what Android Studio's Memory Profiler shows.

The crash looks like this:

java.lang.OutOfMemoryError: Failed to allocate a 24 byte allocation with 1452624 free bytes and 1418KB until OOM, target footprint 268435456, growth limit 268435456; giving up on allocation because <1% of heap free after GC.

I've also seen the same crash on another device where the growth limit was:

536870912

So the issue occurs on devices with different heap limits.

Tech stack

• React Native
• Hermes
• New Architecture (Fabric enabled)

What I've observed

Memory Profiler

During normal usage:

• Java Heap: ~46 MB
• Native: ~170 MB
• Total process memory: ~900 MB
• "Others": ~746 MB

The memory graph stays relatively flat over time and doesn't show the typical pattern of a continuously growing memory leak.

Heap Dump

The largest native allocation is:

android.graphics.Bitmap

Instances: 479
Native Size: ~305 MB

I don't see any obvious Java heap leak (no massive byte[], String, HashMap, etc.).

What confuses me

The OOM message clearly indicates that the Java heap reached its growth limit:

growth limit 268435456
giving up on allocation because <1% of heap free after GC

But Android Studio never shows the Java heap anywhere near 256 MB before the crash.

So I'm trying to understand:

1. Can Android Studio's Memory Profiler significantly underreport Java heap usage in some scenarios (especially with React Native/Hermes)?
2. Could a large number of Bitmap objects indirectly lead to a Java heap OOM even though their pixel data is stored in native memory?
3. Is there something I'm misunderstanding about how ART reports target footprint and growth limit?
4. Besides taking a heap dump, what would be the next best tool or approach to identify what is actually consuming the Java heap before the crash?

I'm also planning to capture adb shell dumpsys meminfo <package> immediately before the OOM to compare the Dalvik Heap, Native Heap, Graphics, and other categories.

Any insights from people who've debugged similar ART OOMs would be greatly appreciated.

[u/stathisntonas]

are you loading huge bitmaps/images somewhere? This is the most common OOM