2

Trying to recreate OOM happening on a Samsung S4 (5.0.1) on an AVD (5.0). Both report MemoryClass 128, but I cannot reproduce the OOM condition on my AVD.

I ended up with a really extreme test bitmap of 6000x4000 (96MB with no inSampling. Sure, not a good idea for production, but this is for testing only) I'm using plain BitmapFactory.

The S4 consistently crashes while loading, not a surprise :)

The weird thing: on the AVD this consistently loads without any problem. I'm always able to allocate huge memory nearly to the limits of available MemoryClass, as if there's not fragmentation at all.

Shouln't devices with identical VM heap size behave similar? There should be no major differences in heap fragementation on both devices, as the App has been freshly installed and started.

I'm quite confused, because it looks like an AVD is not a useful device for testing, at least in terms of memory management in ART.

I might have some basic misunderstanding on MemoryClass and VM Heap size. Any ideas?

herb64
  • 21
  • 3
  • Just a piece of advice, the same thing happened with me, untill I put crashlytics by Fabric(Now Google bought it) into it and I came to know that the RAM free of normal Samsung phones are only about 200 to 400 MB out of 2 GB, Now to test it on emulator, try making a device with about 200 to 300 MB ram and run on that, OOM errors are pain in a developers life – Pulkit Sep 04 '17 at 06:37
  • have you trying to load bitmap using any 3rd party libs (glide/ picaso)? – Radhey Sep 04 '17 at 06:53
  • @Pulkit: Thanks for your advice. Yes, I already created a device with low RAM, e.g. Nexus5, API21, 200MB RAM, 64MB VM Heap - result: MemoryClass 256. And I can allocate even a bitmap of 7700x7700 almost eating up the full heap size without problems. I will definitely look into the crashlytics thing. – herb64 Sep 05 '17 at 07:41
  • @Radhey: I did not use 3rd party libs (yet), because I want to learn the basics. Sure, using readily available libraries is good. I did get my app running by downsampling the bitmap using inSampleSize, that's no problem. But I'm not satisfied by that, because I would like to calculate a kind of _sweet factor_ for sampling or changing depth to RGB565 etc.. Looking into Glide source code, they just seem to sample down to screen size by default or you can use overwrite, but then you are left again with the question which size to use :) I did not find any memory magic in the code... – herb64 Sep 05 '17 at 07:46
  • Amm, IDK why you want to spend time behind this!There are lots of other things still we need to explore in #Android. I mean well known apps (whats app ,instagram ,etc) uses these 3rd party libs for image display. .Anyway if you want to reproduce OOM , follow this ,https://stackoverflow.com/q/10200256/1848157 – Radhey Sep 05 '17 at 07:52
  • My post is not about bitmap loading itself, it's about the problem, that AVDs do not behave like real devices. And I want to understand, why the AVD does not crash in same situation. How can I otherwise be confident, that testing with AVDs is ok and the "real world" looks different. Of course, I should not allocate too much memory, but if I want to just display one large image, why not use the resources if available on a "large" phone for better quality if zooming in? Thank you for the link, going through this. – herb64 Sep 05 '17 at 08:06

0 Answers0