AppLovin/AppLovin-MAX-SDK-Android

java.lang.IllegalStateException: Failed to load new ad - this instance is already destroyed for ad unit ID

Closed this issue · 8 comments

MAX SDK Version

12.1.0

Device/Platform Info

Android

Current Behavior

The app is crashing, and checking the logcat it says:

FATAL EXCEPTION: main
Process: com.adfone.aditup.staging, PID: 24960
 java.lang.IllegalStateException: Failed to load new ad - this instance is already destroyed for ad unit ID: 46fb000303d5239c
at com.applovin.impl.mediation.ads.MaxFullscreenAdImpl.loadAd(SourceFile:201)
at com.applovin.impl.mediation.ads.MaxFullscreenAdImpl.loadAd(SourceFile:182)
at com.applovin.mediation.ads.MaxRewardedAd.loadAd(SourceFile:113)
at com.adfone.cover.architecture.ui.containers.providers.managers.ApplovinAdManager.loadAd$lambda$0(ApplovinAdManager.kt:82)
at com.adfone.cover.architecture.ui.containers.providers.managers.ApplovinAdManager.$r8$lambda$j4XvL_MRYmXar7-ttACTf78IrVg(Unknown Source:0)
at com.adfone.cover.architecture.ui.containers.providers.managers.ApplovinAdManager$$ExternalSyntheticLambda0.run(Unknown Source:2)
at android.os.Handler.handleCallback(Handler.java:958)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.app.ActivityThread.main(ActivityThread.java:8177)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)

I understand that on the latest version v12.1.0 a crash was fixed, but I am able to replicate it.

Expected Behavior

The app doesn't crash

How to Reproduce

Update SDK to v12.1.0

  • Call showRewardedAd twice

Additional Info

No response

@rosebm - This is expected behaviour. Whilst we might not crash in production builds, we will crash in dev builds if you attempt to call loadAd() on an ad instance that you have destroy()ed.

Hi @thomasmso This is completely unacceptable. This breaks a lot of our QA tests. A crash should NEVER be "expected behavior" regardless of the environment. I would really hope you guys prioritize fixing this for all environments so we can bump up your sdk as this is a blocker for us to release as of now.

@MKelman - In this case, I would admit we should document the limitations of the destroy() and loadAd() API when used together - we'll call that out in our docs (cc @PLP-Consulting).

However, the alternative of not throwing an exception would be to either fail the ad loads or print some logs, which might've been easily missed. Would you be able to update your integration to avoid the crash?

@thomasmso how sure are you that it wont throw an error in production? We could print some logs so it doesn't crash but we also dont want to lose revenue from not showing ads in our app in parts that it should show ads.

We check for the FLAG_DEBUGGABLE flag first before throwing the exception. But yeah, def. something to fix as to not lose revenue.

@thomasmso but you're saying the ultimate fix is something we need to do on our end? We need to be able to call loadAd after destroyAd though. We have different features that after one feature loads an ad and destroys the ad, we need to load another ad.

@MKelman - We'd recommend using the same instance of the MaxRewardedAd without destroying it in the first place.

@thomasmso we'll continue to look into your solution.