AppLovin Ads - Multiple Crashes and ANRs - Input Dispatch TIMEOUT with Interstitial Activity

Solar2D Monetization (in-app purchases, ads, etc.)
#1

Hello AppLovin,

We are seeing a huge spike in CRASH/ANRs on GooglePlay that seem to be resulting from our use of AppLovin Ads  (Input Dispatch TIMEOUT).  This is pushing our ANR/Crash rates up to 3-4% which is significantly harming our store standing.  This has a significant financial hit on us.

Background: We updated our all our apps last month (if that helps you figure out version we’re running). These (AppLovin Ads).zip PDFs from Dropbox link below are the detailed errors that appear and are caused in some part by AppLovin Ads or perhaps how we use it. We don’t know. Again this is for only a sampling of 4 of our games, and we have 14 in with similar issues.

Download link:

https://www.dropbox.com/sh/q3al7hyykl71f2e/AAA_uIDodj9v4LHa51zkzCmHa?dl=0

Here’s break down count vs description:

19 com.applovin.adview.AppLovinInterstitialActivity

1 Input dispatching timed out

Again, please follow the detailed PDF for each of these errors. If you need code, have question or whatever we’ll be pleased to share all and in detail.

Can you help? What do you need?

Thanks!

Alex

#2

Hi!

Concerning your issue, a bug submission at https://portal.coronalabs.com/bug-submission with a sample to reproduce would be really cool.

In the mean time, I’ll try to catch these crashes on our sample and see if we can make some kind of a hotfix.

Will monitor this thread and also post updates.

#3

We are having the same exact problem with the Applovin PAID plugin, not the free one.

Here is one of the errors that appears several hundred times in our ANR/Crash report log on Google Play. I also personally tested on our Samsung Galaxy Note 8, and have noted the crash issue with regards to the Applovin plugin. When an ad is trying to appear, it crashes.

java.lang.NullPointerException: at plugin.applovin.paid.LuaLoader$Show$1.run (LuaLoader.java:1052) at android.os.Handler.handleCallback (Handler.java:739) at android.os.Handler.dispatchMessage (Handler.java:95) at android.os.Looper.loop (Looper.java:135) at android.app.ActivityThread.main (ActivityThread.java:5311) at java.lang.reflect.Method.invoke (Native Method) at java.lang.reflect.Method.invoke (Method.java:372) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:908) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:703)

It should also be noted that the same issue is occuring as well with the Admob paid plugin. Please check both & please fix this immediately & update us on the status please.

#4

Ours is PAID as well.  All our plugins are paid.  We’re paying for all the Professional and PAID plugins and most are throwing crashes and ANRs :frowning:

#5

Applovin plugin (both free and paid) update just went public. Make sure that you are using Corona Simulator version >=3183 to get it.

A fix for JBean’s crash was already included in that fix.
 

Btw, firerabbit.info, we’ve fixed all of the plugins that you’ve got problems with and shared those problems on this forum. Some were fixed awhile ago, but we still haven’t got any feedback from you on any of those plugins. You’ve updated your builds, but still getting those crashes and anrs, I understand you correctly?

#6

I can confirm upon testing this morning with the latest daily build 3268 that the ads for both Applovin and Admob are now working, and the crashes are not occuring anymore. We have updated our apps.

I’ll update the thread if anything else comes up, thank you for fixing these up!

Is it possible, since there have been so many issues w/plugins, that Corona perhaps digs in, and makes sure all plugins are updated against google’s updates, so we can avoid this in the future?

This has been an issue since January of 2018, and we were unable to figure out what it was on our end, until we realized it had something to do with the plugin.

Thank you

#7

As always, if you have more issues or concerns - feel free to share them!

We are actually in the process of digging in for quite some time. The problem is: some issues are hard to come by just by looking at code and most of them aren’t reproducible (like, maybe 1 crash on 1000 launches with some specific race condition and stuff - we just cannot simulate those conditions). That’s why user feedback are so important for us right now and just by looking at some logs we can eliminate issues pretty quick.

Beside our hard focus on maintaining core and plugins lately, alert, a little inside info: we started working on a new instrument with a code name Crash Hunter. Can’t say anything about it, but, well, you can guess what it will be used for. In the nearest future we won’t be that much dependent on user feedback alone and can fix our legacy stuff much faster (like, maybe even faster then you’ll come across it), and also prevent new stuff from breaking.

A lot of work is going on in that field, it’s very important for us to offer a reliable platform for our users. We just don’t ready to speak public about it for now. Stay tuned!

#8

Another crash error we received in the last 24 hours after updating with the latest daily build. Between the apps that we have in our portfolio that are unity based vs corona based, Corona has way more ANR & crash issues than unity on average.

 

java.lang.IllegalStateException :

 

at android.app.FragmentManagerImpl.checkStateLoss (FragmentManager.java:1438)

 

at android.app.FragmentManagerImpl.popBackStackImmediate (FragmentManager.java:581)

 

at android.app.Activity.onBackPressed (Activity.java:2537)

 

at android.app.Activity.onKeyUp (Activity.java:2511)

 

at com.ansca.corona.CoronaActivity.onKeyUp (CoronaActivity.java:3525)

 

at android.view.KeyEvent.dispatch (KeyEvent.java:2715)

 

at android.app.Activity.dispatchKeyEvent (Activity.java:2764)

 

at com.ansca.corona.input.RaiseKeyEventTask$1.run (RaiseKeyEventTask.java:90)

 

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

 

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

 

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

 

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

 

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

 

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

 

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

#9

Engineers are working on that issue. That’s the tough one, but updated Corona Sim build with a fix should be available asap.

#10

@karpovpw: Did that crash issue get resolved yet & are we able to build?

#11

No, it did not. Our engineers are working on it.

#12

Has that issue been resolved yet?

This is hurting our business to have these crashes b/c Google now accounts for the % of crashing in apps to determine ranking. 

#13

We have had 486 reports in the last 7 days of this crash. PLEASE FIX IT ASAP.

 

java.lang.IllegalStateException :

 

at android.app.FragmentManagerImpl.checkStateLoss (FragmentManager.java:1323)

 

at android.app.FragmentManagerImpl.popBackStackImmediate (FragmentManager.java:493)

 

at android.app.Activity.onBackPressed (Activity.java:2304)

 

at android.app.Activity.onKeyUp (Activity.java:2282)

 

at com.ansca.corona.CoronaActivity.onKeyUp (CoronaActivity.java:3482)

 

at android.view.KeyEvent.dispatch (KeyEvent.java:3232)

 

at android.app.Activity.dispatchKeyEvent (Activity.java:2512)

 

at com.ansca.corona.input.RaiseKeyEventTask$1.run (RaiseKeyEventTask.java:90)

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

at dalvik.system.NativeStart.main (Native Method)

#14

Yikes

#15

For anyone wondering, the discussion of these crashes was continued in this thread: https://forums.coronalabs.com/topic/70693-frequent-android-crashes/

Not that we just ignored it or something.  :rolleyes:

#16

@karpovpw - What version of Applovin SDK is the paid applovin plugin using? It was recently updated, so we want to make sure that the plugin is using the latest SDK.

#17

At the moment of plugin update the latest version of AppLovin SDK was 7.8.6 - that’s the one included in our plugin.

We can’t just release our plugin with new version of SDK straight away, a lot of work has to be done in dev & QA departments before we release updated plugin to public use. It’s most important to distribute a stable SDK inside our plugins.

Right now plugin with SDK version 8.0 is being worked on, if that’s the answer you’re gonna ask next. It will be available as soon as all needed QA and development processes will be done.

#18

@karpovpw:

With all due respect, the paid plugin had issues from January untl about late march, early April when you guys fixed those crash issues. It makes us a bit concerned about using Corona as a platform going forward when we can’t rely on the paid plugins to be maintained properly.

I realize that some errors can’t be reproduced, and are device and OS specific, but these errors caused catastrophic issues for our apps, and some of them were down-ranked as a result.

This is something we take very seriously as business owners, and having been in the app industry for many years, this is unacceptable.

We’ve never had any issues with other 3rd party plugins with other engines, or the amount of crash issues that we’ve seen in google play compared to our Corona apps (We are speaking of the android platform only. iOS has never been an issue).

One of our apps that receives over 20,000 downloads a day had a failure rate of over 20% due to the Applovin plugin crashing on devices that had the newer OS installed. That is pretty significant and we incurred a loss of revenue because of this. 

So we hope that maintenance and regular testing of these plugins are performed to avoid issues like this in the future. Appreciate your hard work as always, but this was a very frustrating thing to deal with on behalf of our entire team.

#19

Well, the SDKs for plugins are updated asap, considering the need of work in dev & QA departments to include them in our plugins.

Crashes and other issues are being fixed as soon as we know about them. Right now user feedback is practically the only way for us to know about those issues, due to impossibility of reproduction for most of them by QA process. That’s the big problem and we are aware of it, that’s why I gave you a little inside info about work on a new system.

But right now the only way to fix a bug, which comes to some user is, well, a feedback from that user. To speed up the process and to notify us about you issues, you can use this forum, bug submission or intercom.

If we’ve had a feedback about crashes in January, we have been fixed them straight away in January. But then again, that is a serious and obvious problem to be dependent on user feedback in such things, hence we directed a lot of our effort to build up a system, which can greatly improve our products stability and trouble-free operation. User satisfaction is the number one priority for us, so we’re taking to heart latest issues with Android and learn a lot from them.

#20

@karpovpw: Thank you, we appreciate you all taking steps toward making this process more effiicient for yourselves, and more stable for us users.

I realize that it’s not easy to repro these issues, but in hindsight, I have learned a huge lesson, not to rely so much on plugin maintenance, and also check the stability of the apps myself. Unfortunately, I was not in possession of a new android device until recent, so I am going to have to make sure we always have the latest test devices in the event this happens again.

Thank you