The OutOfMemory issue is a pretty big problem, but I'd say it's quite lazy to just dismiss it as something the framework needs to fix so that you can effectively do your job. I ran into this problem a lot early on in my Android development, and as I studied it further I found tons of resources and information to make it work in all cases and there are plenty of creative solutions documented in blogs and discussed on StackOverflow about it as well. Half the time you can get around this error by recycling your bitmaps when you're done with them and/or rethinking your approach to needing really large bitmaps in memory at the same time. There are two things I've done commonly in apps to get around this.
(1) If I'm just expanding included resource files (compressed images) into bitmaps for display, I write my own intelligent cache. Backed by a simple HashMap, I can even include in my cache keys the desired height and width and downsample intelligently and cache the downsampled version. Funny enough, when I presented this to my coworker, he had just done almost the exact same thing and we had never discussed it. In one case I needed to categorize my images to flush some and not others from the cache, so I just wrapped a bunch of instances of the same BitmapCache into a BitmapCacheManager class and it worked like a charm.
(2) To get around the fact that you can't just set the source path of an ImageView to a web url, you can use a custom class that wraps ImageView and just handles downloading the image on a background thread. I wrote a pretty complicated system that pumps the urls to a queue and broadcasts a notification when each download completes, but a single google search pointed me to an awesome apache licensed library that does exactly the same thing (and is admittedly cleaner than mine).
It's totally doable. I never looked at it as a limitation of the framework - I actually saw it as an opportunity to do something more challenging than just drawing within the lines of the framework.
Author here. Thanks for reading. I concede that its possible to manage Bitmaps without issue. But I'd argue there are tons of resources (and SO questions) because the system in place is such a mess. Recycling bitmaps manually is a non-functional(and not elegant) solution for many use cases and really should be unnecessary in a environment featuring a GC. (though i understand why the implementation is the way it is).
I feel like it is a limitation of the framework. The problem exists because of limitations of the OS and the solutions for the problems (tiered memory-disk caches, custom remote image widgets) are "challenging" because of the limits. The problem itself (build the cache or remote widget) isn't conceptually or technically hard, its only hard because of the tools at our disposal.
There's a good video from a recent Google I/O on memory management where they explain the recycle method, their reason for requiring it, and that it won't be necessary in 2.3 and up. I still always recycle everything manually just to be defensive, but supposedly it's not required anymore in API 10+. Whenever you see a framework object with a recycle method it's because the memory is allocated outside of the dalvik heap, so it's not part of the GC cleanup process.
The real bitch of this, and what I think you were getting at, is the lack of accurate memory debugging tools. I read a really long post on SO about a guy who tested all of the various ways of testing memory consumption through DDMS, adb, etc, and all the numbers he got were conflicting.
(1) If I'm just expanding included resource files (compressed images) into bitmaps for display, I write my own intelligent cache. Backed by a simple HashMap, I can even include in my cache keys the desired height and width and downsample intelligently and cache the downsampled version. Funny enough, when I presented this to my coworker, he had just done almost the exact same thing and we had never discussed it. In one case I needed to categorize my images to flush some and not others from the cache, so I just wrapped a bunch of instances of the same BitmapCache into a BitmapCacheManager class and it worked like a charm.
(2) To get around the fact that you can't just set the source path of an ImageView to a web url, you can use a custom class that wraps ImageView and just handles downloading the image on a background thread. I wrote a pretty complicated system that pumps the urls to a queue and broadcasts a notification when each download completes, but a single google search pointed me to an awesome apache licensed library that does exactly the same thing (and is admittedly cleaner than mine).
https://github.com/loopj/android-smart-image-view
It's totally doable. I never looked at it as a limitation of the framework - I actually saw it as an opportunity to do something more challenging than just drawing within the lines of the framework.