OutOfMemoryError when decoding a bitmap byte array

[Sam Lu]

Google Play Services: 7.8.0

On Android 4

Fatal Exception: java.lang.OutOfMemoryError

       at android.graphics.BitmapFactory.nativeDecodeByteArray(BitmapFactory.java)

       at android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:522)

       at android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:540)

       at com.google.android.gms.ads.internal.p.a.f.b(SourceFile:655)

       at com.google.android.gms.ads.internal.p.a.f.a(SourceFile:634)

       at com.google.android.gms.ads.internal.util.at.deliverResponse(SourceFile:126)

       at com.android.volley.ExecutorDelivery$ResponseDeliveryRunnable.run(SourceFile:99)

       at android.os.Handler.handleCallback(Handler.java:725)

       at android.os.Handler.dispatchMessage(Handler.java:92)

       at android.os.Looper.loop(Looper.java:175)

       at android.app.ActivityThread.main(ActivityThread.java:5279)

       at java.lang.reflect.Method.invokeNative(Method.java)

       at java.lang.reflect.Method.invoke(Method.java:511)

       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)

       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)

       at dalvik.system.NativeStart.main(NativeStart.java)

[Vu Chau (MobileAds SDK Team)]

Hi Sam,

Thanks for relaying this crash to the team.  While we look into it, do also send us additional info (most importantly steps or a sample project) that lead to this crash as it becomes available.  We will want to reproduce this crash locally in order to troubleshoot it.

Thanks,

Vu Chau

Mobile Ads SDK Team

[Sam Lu]

It's an OutOfMemory error while decoding data to a Bitmap. You don't need the reproduce steps for fixing it. The problem happens when user's device available memory is low. Please try to add a try/catch for the decoding code so it won't crash our apps. Thanks.

[Winson Tan]

I encounter similar error when use DFP native ads

I am following the guide from https://developers.google.com/mobile-ads-sdk/docs/dfp/android/native

Keep receiving this out of memory error from google sdk

I have 196 crashes from this error affecting 109 users

Very serious problem causing my app to crash

Fatal Exception: java.lang.OutOfMemoryError

       at android.graphics.BitmapFactory.nativeDecodeByteArray(BitmapFactory.java)

       at android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:522)

       at android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:540)

       at com.google.android.gms.ads.internal.p.a.f.b(SourceFile:655)

       at com.google.android.gms.ads.internal.p.a.f.a(SourceFile:634)

       at com.google.android.gms.ads.internal.util.at.deliverResponse(SourceFile:126)

       at com.android.volley.ExecutorDelivery$ResponseDeliveryRunnable.run(SourceFile:99)

       at android.os.Handler.handleCallback(Handler.java:730)

       at android.os.Handler.dispatchMessage(Handler.java:92)

       at android.os.Looper.loop(Looper.java:176)

       at android.app.ActivityThread.main(ActivityThread.java:5419)

       at java.lang.reflect.Method.invokeNative(Method.java)

       at java.lang.reflect.Method.invoke(Method.java:525)

       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1046)

       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:862)

       at dalvik.system.NativeStart.main(NativeStart.java)

My gradle for google service lib is compile 'com.google.android.gms:play-services:8.1.0'

I am using Crashlytics for crash report

Devices affected :

46% GT N7105

35% GT I9305

10% GT I9300

9% Other

Operating Systems affected:

32% 4.4.2

27% 4.3

22% 4.1.2

19% Other

Winson

[Vu Chau (MobileAds SDK Team)]

Hi Winson,

Thanks for letting us know! Do you have any other detail that can help us reproduce the crash, e.g. SDK version, steps, and ad unit ID?

Vu Chau

Mobile Ads SDK Team

[Winson Tan]

hi Vu Chau,

I will reply you in another email using company email due to confidential issue

Winson

--

---
You received this message because you are subscribed to a topic in the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-admob-ads-sdk/BJSyuUj91KE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-admob-ads...@googlegroups.com.
To post to this group, send email to google-adm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Lu]

Hi Vu,

Do you have any updates about this OOM crash issue.

We now have received more than 1000+ crash due to this issue.

As I mentioned, you don't need any more information for fixing it. 

The stack trace is enough for your team to fix it. 

Add a try/catch so it won't crash our apps, please

Sam

[Vu Chau (MobileAds SDK Team)]

Hi Sam,

We do have existing work on OutOfMemory issues and I did relay your report instance to the rest of the team.  

Will let you know as soon as there's more information,

Vu Chau

Mobile Ads SDK Team

[Ondřej Čermák]

We're getting a lot of OutOfMemoryErrors with this stack trace pointing to AdMob library trying to load a bitmap. Currently we have over 1000 reports from some 200k users.

After reproducing the error (usually with a rotation on a tablet) and examining the heap dump, we've discovered that there're unnecessarily large bitmaps loaded in the memory, taking a significant amount of it. For example, we've recovered a bitmap that was 12MB in memory, with resolution of 1280x2276, on a device with resolution 1280x800. We only show a non-fullscreen banner ads, so there's no point for the bitmap to be that large. Also it drains user's FUP for no reason.

And it's not just one case, we reproduced the error on a second device with similar results. This time it was 3 bitmaps in memory (larger than the resolution of the device), and 2 of them were even exactly the same. See the attached images of some of the recovered bitmaps and how it actually looks on the device.

[Andrew Brogdon (Mobile Ads SDK Team)]

Thanks for posting this, Ondřej. It's gotten some discussions going this morning on how we can reduce both bandwidth and memory usage for our native publishers. There are a few things I wanted to make sure you were aware of, and a couple questions I'd like to ask:

- The out of memory crash is something we're currently working on fixing. I don't have an ETA, but it will definitely get corrected.

- We should not be returning any portrait images for app install ads that are wider than the device is. We don't currently have a cap on the height, but the width shouldn't be more than the device is physically able to display.

- We don't currently have a similar restriction on native content ads, so it's possible you might be seeing some that are entirely too large.

- If you're not already using it, the NativeAdOptions.Builder class has a method to restrict native ads to a single image. You can also use native ad options to prioritize landscape images over portrait, though not every app install ad has landscape image assets to offer.

- We're working on some ways to get more landscape images assets into the creatives, which will also help here.

- Can you tell me on what device you did the debugging you mention? I'm particularly interested in the screen dimensions and density.

- Have you seen any native content ad image assets that were wider than the device's width?

Sorry to respond with so much text, but I wanted to make sure I covered everything. :)

-Andrew

[Ondřej Čermák]

Hi Andrew, thanks for your reply. My responses are in text below.

On Friday, January 8, 2016 at 9:13:34 PM UTC+1, Andrew Brogdon (Mobile Ads SDK Team) wrote:

Thanks for posting this, Ondřej. It's gotten some discussions going this morning on how we can reduce both bandwidth and memory usage for our native publishers. There are a few things I wanted to make sure you were aware of, and a couple questions I'd like to ask:

- The out of memory crash is something we're currently working on fixing. I don't have an ETA, but it will definitely get corrected.

- We should not be returning any portrait images for app install ads that are wider than the device is. We don't currently have a cap on the height, but the width shouldn't be more than the device is physically able to display.

- We don't currently have a similar restriction on native content ads, so it's possible you might be seeing some that are entirely too large.

Currently we don't use content ads, so that should be fine. 

- If you're not already using it, the NativeAdOptions.Builder class has a method to restrict native ads to a single image. You can also use native ad options to prioritize landscape images over portrait, though not every app install ad has landscape image assets to offer.

We use AdMob through HeyZap SDK, so I'm not sure if they use this method or not. About the landscape images - how would that help us? Anyway, I don't think we have this option available through HeyZap, but we can definitely ask them if they could expose it.

 

- We're working on some ways to get more landscape images assets into the creatives, which will also help here.

- Can you tell me on what device you did the debugging you mention? I'm particularly interested in the screen dimensions and density.

We were able to reproduce (and get heap dump) on Samsung Galaxy Note 10.1. GT-N8010 (Android 4.1.2, 1280 x 800) and Samsung Galaxy Tab 10.1 WiFi, GT-P7500 (Android 4.0.3; 1280 x 800).

 

- Have you seen any native content ad image assets that were wider than the device's width?

No, because we don't use content ads, sorry.

[Ondřej Čermák]

Just to clarify a bit my previous response. 

- We don't use content ads and disable them via HeyZap which should disable it in AdMob, but apparently sometimes we do get them (that's why there was this image of a "house").

- You said that app install ads shouldn't be wider than the device, but if the device is 1280x800 and you're sending portrait image, it shouldn't be wider than 800px, but in our case, it was 1280px.

Ondra

[Andrew Brogdon (Mobile Ads SDK Team)]

- We use AdMob through HeyZap SDK, so I'm not sure if they use this method or not. About the landscape images - how would that help us? Anyway, I don't think we have this option available through HeyZap, but we can definitely ask them if they could expose it.

A landscape image would more naturally fill the space your layout creates for the image asset, and (assuming the width restriction is working, which judging by your other comments may not be the case) would cause you to receive a smaller overall image (if width is the restricting factor, an image orientation that's wider than it is tall will produce a smaller overall image size). At any rate, I'd imagine it's something HeyZap should offer their publishers if they're looking to mediate our native ads.

- We don't use content ads and disable them via HeyZap which should disable it in AdMob, but apparently sometimes we do get them (that's why there was this image of a "house").

I'm not familiar with how HeyZap works, but that's certainly unusual. Our API makes it fairly straightforward to request one and not the other, so I'd ask them about it. 

- You said that app install ads shouldn't be wider than the device, but if the device is 1280x800 and you're sending portrait image, it shouldn't be wider than 800px, but in our case, it was 1280px.

You're right -- I must have switched the dimensions around in my head when I read your initial post. I'll check with engineer who wrote the code to enforce that restriction and make sure he sees your data.

As I said, we're working on the OutOfMemoryError, and I'll post in this thread when we get it corrected. Thanks to your info, we're also now looking at ways we could extend our NativeAdOptions API to allow publishers to specify the general size of image they'd prefer, so it's possible you might see that in a future release.

-Andrew

[Winson Tan]

hi Andrew,

Regarding the "width shouldn't be more than the device is physically able to display", 

information from my DFP team, we are using custom template with image size 1242 x 2208.

We have a team who are in charge of DFP configuration and ads content. They are not tech savvy guys but more like sales person, they have no idea what are the image size should be uploaded as there are no clear information in the DFP console. 

They might reusing same ads image in website for mobile as well. Some ads image are provided from different sponsors. Therefore would result in many different size of ads images.

Due to confidentiality, I did have a private email conversation with Vu Chau regarding this issue

Hope these information can help improve the services

regards,

Winson

[Andrew Brogdon (Mobile Ads SDK Team)]

Thanks for the extra info, Winson. 

On the odd chance it helps, people using custom template ads and uploading their own creatives have a few more options when it comes to image size. You could, for example, upload several creatives for a single line item in an order, and use custom targeting information sent from the mobile app to select one. You could have a custom targeting parameter called "my_image_size" or something, set it to "small," "medium," or "large," when building your request, and use that to target the creatives in the line item.

-Andrew

[ankur...@innovationm.com]

Hello,

has this problem resolved?

[Andrew Brogdon (Mobile Ads SDK Team)]

We don't have a complete fix for this in production yet. I'll be sure to update the thread when we do, though.

Thanks!

-Andrew

[Sunny]

Hi Andrew,

I got the same error.

Do you have any updates?

Google Play Services: 8.7.03

On Android 6.0

java.lang.OutOfMemoryError: Failed to allocate a 10238412 byte allocation with 9256528 free bytes and 8MB until OOM

at dalvik.system.VMRuntime.newNonMovableArray(Native Method)

at android.graphics.BitmapFactory.nativeDecodeByteArray(Native Method)

at android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:522)

at android.graphics.BitmapFactory.decodeByteArray(BitmapFactory.java:545)

at maps.au.a$5.b(:com.google.android.gms.alldynamite:655)

at maps.au.a$5.a(:com.google.android.gms.alldynamite:634)

at maps.be.k$b.a(:com.google.android.gms.alldynamite:126)

at maps.f.e$a.run(:com.google.android.gms.alldynamite:99)

at android.os.Handler.handleCallback(Handler.java:739)

at android.os.Handler.dispatchMessage(Handler.java:95)

at android.os.Looper.loop(Looper.java:148)

at android.app.ActivityThread.main(ActivityThread.java:5451)

at java.lang.reflect.Method.invoke(Native Method)

at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)

at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

[phobos....@gmail.com]

Any update? I'm still seeing this in 11.2? Is it still being worked on or should I look for workarounds?

[Banty Kumar]

Did you happen to find any solution or workaround for this?