Android ANR with java.nio.CharBuffer.position(CharBuffer.java:870)

[Raymond Chan]

Hi support,

We sometimes see ANR with AdMob SDK, we are using "com.google.android.gms:play-services-ads:18.0.0"

DALVIK THREADS (282):
"main" prio=5 tid=1 Runnable
  | group="main" sCount=0 dsCount=0 flags=0 obj=0x711b0e78 self=0x72fa2b2c00
  | sysTid=8712 nice=-10 cgrp=default sched=0/0 handle=0x72fb818ed0
  | state=R schedstat=( 61612697003 7996621896 44504 ) utm=5576 stm=585 core=6 HZ=100
  | stack=0x7fded8f000-0x7fded91000 stackSize=8192KB
  | held mutexes= "mutator lock"(shared held)
  at java.nio.CharBuffer.position(CharBuffer.java:870)
  at java.nio.HeapCharBuffer.put(HeapCharBuffer.java:181)
  at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:814)
  at android.net.UriCodec.flushDecodingByteAccumulator(UriCodec.java:163)
  at android.net.UriCodec.appendDecoded(UriCodec.java:146)
  at android.net.UriCodec.decode(UriCodec.java:79)
  at android.net.Uri.getQueryParameter(Uri.java:1738)
  at com.google.android.gms.ads.internal.util.s.a(:com.google.android.gms.policy_ads_fdr_dynamite@21460000@21460000.297791526.297791526:59)
  at com.google.android.gms.ads.internal.webview.p.a(:com.google.android.gms.policy_ads_fdr_dynamite@21460000@21460000.297791526.297791526:15)
  at com.google.android.gms.ads.internal.webview.ag.run(:com.google.android.gms.policy_ads_fdr_dynamite@21460000@21460000.297791526.297791526:5)
  at android.os.Handler.handleCallback(Handler.java:883)
  at android.os.Handler.dispatchMessage(Handler.java:100)
  at pg.a(:com.google.android.gms.policy_ads_fdr_dynamite@21460000@21460000.297791526.297791526:0)
  at com.google.android.gms.ads.internal.util.f.a(:com.google.android.gms.policy_ads_fdr_dynamite@21460000@21460000.297791526.297791526:1)
  at pg.dispatchMessage(:com.google.android.gms.policy_ads_fdr_dynamite@21460000@21460000.297791526.297791526:0)
  at android.os.Looper.loop(Looper.java:214)
  at android.app.ActivityThread.main(ActivityThread.java:7397)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:935)

"Signal Catcher" daemon prio=5 tid=5 Runnable
  | group="system" sCount=0 dsCount=0 flags=0 obj=0x12c808f0 self=0x7263e7bc00
  | sysTid=8723 nice=0 cgrp=default sched=0/0 handle=0x7269dcbd50
  | state=R schedstat=( 27351354 8335730 66 ) utm=0 stm=2 core=5 HZ=100
  | stack=0x7269cd5000-0x7269cd7000 stackSize=991KB
  | held mutexes= "mutator lock"(shared held)
  native: #00 pc 00000000004108e8  /apex/com.android.runtime/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+140)
  native: #01 pc 00000000004f8040  /apex/com.android.runtime/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool, BacktraceMap*, bool) const+512)
  native: #02 pc 000000000051297c  /apex/com.android.runtime/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+828)
  native: #03 pc 000000000050b7a0  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+456)
  native: #04 pc 000000000050ac84  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool)+1964)
  native: #05 pc 000000000050a364  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char>>&)+844)
  native: #06 pc 00000000004c5778  /apex/com.android.runtime/lib64/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char>>&)+200)
  native: #07 pc 00000000004d9bb0  /apex/com.android.runtime/lib64/libart.so (art::SignalCatcher::HandleSigQuit()+1352)
  native: #08 pc 00000000004d8c5c  /apex/com.android.runtime/lib64/libart.so (art::SignalCatcher::Run(void*)+252)
  native: #09 pc 00000000000e6890  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
  native: #10 pc 0000000000084b6c  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
  (no managed stack frames)

Thanks!

[Mobile Ads SDK Forum Advisor Prod]

Hi Raymond,

Thank you for bringing this information to our attention.

Having looked over the information that you gave us. I would have a few suggestions. And thoughts. It would appear that this issue was found many years ago. And should have been fixed. One thing I saw or was wondering is if you are using.

• AdView.destroy() if so can it be possible to not use that?
• Also not sure if you are using any obfuscation on your code.
• Ids there any updates from 6.4.1 if so maybe update too? If possible.

If the issue still doesn't work. Is it possible to get a sample app for us to test on. As well as more stack traces. So that we can go over and look at what is being returned.

Regards,
William Pescherine
Mobile Ads SDK Team

ref:_00D1U1174p._5001UaSBUT:ref

[Raymond Chan]

Hi William,

Thanks for getting me back, with regards to your questions

1. Yes, we are calling AdView.destroy() in our code, may I know what will happen if we don't do that? We are not sure if that will cause memory leak.
2. Yes, we have used Proguard in our code
3. What do you mean by "updates from 6.4.1"? Which SDK are you referring to?

Best regards,

Raymond

[Mobile Ads SDK Forum Advisor Prod]

Hi Raymond,

 

Thank you for providing further details on your concern.

 

First off, calling AdView.destroy() is still preferable so as long as you will avoid referencing that already-destroyed ad view in the future. Otherwise, you run the risk of memory leaks when switching between activities. I would recommend keeping your AdView.destroy() calls in your code, and simply double-check for unintended referencing to such destroyed ad views.

 

Second, with regard to ProGuard: this might be the most likely suspect for this crash. ProGuard is prone to stripping necessary code from the AdMob SDK, in part due to the SDK using a lot of code reflection. You may try putting the following in your ProGuard file to see if it would fix the issue:

-keep public class com.google.android.gms.ads.** {

public *;

}

 

-keep public class com.google.ads.** {

public *;

}

 

-keep public class com.google.android.gms.internal.ads.** {

public *;

}

 

Lastly, with regard to SDK versions: I must apologize for the confusion here, as version 6.4.1 seems to be for the iOS AdMob SDK instead of the Android one. With that said, it is still a good idea to update to the latest version whenever possible (19.1.0 as of this writing), in order to avail of updates and fixes to the AdMob SDK.

 

Regards,

Ziv Yves Sanchez