ANR was caused by "SharedPreferences"?

[LazyBonesLZ]

After integrated Max SDK v11.3.3, ANR rate seems too high, I checked some stack traces info and log , and found some details log contained keywords "com.applovin.sdk.impl.isFirstRun", could you help to find if ANR is related with it? stack trace like this:

com.github.anrwatchdog.ANRError$$$_Thread: main (state = WAITING)
    at java.lang.Object.wait(Native Method)
    at java.lang.Thread.parkFor(Thread.java:1220)
    at sun.misc.Unsafe.park(Unsafe.java:299)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:813)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:973)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
    at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:202)
    at android.app.SharedPreferencesImpl$EditorImpl$1.run(SharedPreferencesImpl.java:363)
    at android.app.QueuedWork.waitToFinish(QueuedWork.java:88)
    at android.app.ActivityThread.handleStopActivity(ActivityThread.java:4609)
    at android.app.ActivityThread.access$1300(ActivityThread.java:218)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1758)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loop(Looper.java:145)
    at android.app.ActivityThread.main(ActivityThread.java:6934)
    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:1404)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1199)

FYI, details info was collected by ANRWatchDog and ACRA SDK, the follow screenshot is part of the details info:

[thomasmso]

@LazyBonesLZ - Thanks for reporting this. We can investigate, but in the meantime you can initialize our SDK (basically, any calls to AppLovinSdk.getInstance(...) in a bg thread to work around this.

[LazyBonesLZ]

@LazyBonesLZ - Thanks for reporting this. We can investigate, but in the meantime you can initialize our SDK (basically, any calls to AppLovinSdk.getInstance(...) in a bg thread to work around this.

Hi, thanks for your reply. You mean I should initialize SDK in a thread but not on main thread?

following is my code:

BaseApplication.runOnUiThread(()->{
                        AppLovinSdk.getInstance( mainActivity ).setMediationProvider( "max" );
                        AppLovinSdk.initializeSdk( mainActivity, new AppLovinSdk.SdkInitializationListener() {
                            @Override
                            public void onSdkInitialized(final AppLovinSdkConfiguration configuration)
                            {
                                // AppLovin SDK is initialized, start loading ads

                            }
                        } );

                    });

[thomasmso]

That's the opposite of what I'm suggesting, you can run code in a background thread using AsyncTasks, ExecutorService, WorkManager, etc. You're running code in the UI/Main thread here.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 5 days since being marked as stale.