Devices that limit to 16 MiB of (java heap + native bitmap storage)
Devices that limit to 24 MiB of (java heap + native bitmap storage)
24 MiB tends to be the high res devices, and can be detected with Runtime.getRuntime().maxMemory(). There's also 32MiB devices now, and some of the rooted phones have 64MiB by default. Previously, I confused my self several times trying to work out what was happening. I think all devices count bitmaps into the heap limit. But it's wildly difficult to make any sweeping generalizations about the android fleet.
@Carl - I took a dictionary with 180k words avg length 10 chars (15M to store as Java strings), and crammed it into 400k. :) The issue is that it's really really hard to reduce bitmap memory since any proprietary storage format would be incompatible with the native rendering code. That, and it seems very silly to make memory artificially expensive on a device that has half a gig of physical ram. And where native code can allocate 1+G with no complaints from the OS. It's just a way of punishing Java developers.
@Carl. From what I can tell, it's pure chaos. Though in general, the mods and rooted phones tend to increase the heap limits, typically to 64M. The decision to so severely limit Java heap size was brain-dead retarded and results in horrible user experiences.
From deployments in the wild, I've found the following devices:
It does force us as developers to take a hard look at our use of memory. I am presently developing an app that has a very large data set that must reside entirely on the heap (because of an intensive search process), and my original String array-based implementation took up 15 MB of heap for that data alone (each String ref in the array takes 32 bytes of data). After nearly hitting the 24 MB limit that a lot of current devices still impose, I designed a custom data structure that takes only 3.5MB to hold exactly the same information. Now my app will run even on a device with a 16MB limit.
Since anyone can release their own version of Android, it seems quite believable that there could be versions out there that implement different policies for limiting heap memory, including those that you describe above. CyanogenMod, for example, allows users to set the heap limit themselves, so I don't see why there could not be an OS release that implements the policies regarding limits that you describe. I'd be interested to know whether there are any official guidelines in this regard. If not, then we're subject to the whims of those OS variants.
The size of the java heap is Runtime.getRuntime().totalMemory().
There is no easy way to measure the size of the native bitmap storage. The overall native heap can be measure with Debug.getNativeHeapAllocatedSize(), but only the bitmaps count toward the limit (i think).
This is a VERY nasty issue on Android, and very confusing. This limit and it's behaviors are poorly documented, complicated, and extremely non-intuitive. They also vary across devices and OS versions, and have several known bugs. Part of the problem is that the limits are not precise - due to heap fragmentation, you will hit OOM well before the actual limit and must conservatively leave a meg or two of buffer. Even worse, I've got several devices where there is a native segfault (100% a bug in Android itself) that occurs before you get the java OOM exception, making it doubly important to never reach the limit since you can't even catch the native crash. For more details on my investigations, check out this post. In the same post, I explain how to measure usage against the limit and avoid crashes.