ANR, possibly iap v3 related?

ANR Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50000010 }

Two reports (so far) of this (both on Galaxy Tab3 Lite, btw fwiw).  Any ideas?

Looks like the main thread is waiting on the GLThread, which in turn is waiting on some boolean result from loading/initing GoogLe IAP v3, and another thread (“Thread-495”) is waiting on same boolean, which apparently exceeds it’s allotted time thus ANR’s.

I make no claim of understanding Corona’s internals, but it seems “weird” that something named “GLThread” (presumably the OpenGLES rendering thread) would be loading the IAP plugin - is that a clue?   or red herring?

I don’t have much more information than that, such as what user was attempting to do at time crash occurred, just an anonymous ANR.  But I see there’s a touch event, followed by some IAP activity, so I’m suspecting/fearing that the user was in the process of initiating a purchase when it crashed.  (ouch)

I guess one question I’d ask is:  is it “safe” to call store.purchase from within a button handler?  (or do you need to do the “wrap in closure, timer.performWithDelay” trick?)  Is it my touch event being delayed by store that’s causing the ANR?  I thought store requests were asynchronous (thus the point of having a listener)??

Thanks.

relevant (?) snippets (ellipses added) from much larger report

"main" prio=5 tid=1 MONITOR | group="main" sCount=1 dsCount=0 obj=0x40ce49a0 self=0x40cd4880 | sysTid=5394 nice=-11 sched=3/0 cgrp=[fopen-error:2] handle=1074009564 | state=S schedstat=( 0 0 0 ) utm=599 stm=187 core=0 at com.ansca.corona.events.EventManager.addEvent(EventManager.java:~25) - waiting to lock \<0x41320610\> (a com.ansca.corona.events.EventManager) held by tid=12 (GLThread 481) at com.ansca.corona.CoronaRuntimeTaskDispatcher.send(CoronaRuntimeTaskDispatcher.java:118) at com.ansca.corona.input.InputDeviceServices$InputDeviceContextEventHandler.onAxisDataReceived(InputDeviceServices.java:606) at com.ansca.corona.input.InputDeviceContext.endUpdate(InputDeviceContext.java:263) ... "Thread-495" prio=5 tid=14 MONITOR | group="main" sCount=1 dsCount=0 obj=0x416ee2c0 self=0x63e92510 | sysTid=5443 nice=0 sched=3/0 cgrp=[fopen-error:2] handle=1714368320 | state=S schedstat=( 0 0 0 ) utm=0 stm=0 core=0 at com.ansca.corona.events.EventManager.addEvent(EventManager.java:~25) - waiting to lock \<0x41320610\> (a com.ansca.corona.events.EventManager) held by tid=12 (GLThread 481) at com.ansca.corona.CoronaRuntimeTaskDispatcher.send(CoronaRuntimeTaskDispatcher.java:118) at network.NetworkRequest$LuaCallback.call(NetworkRequest.java:624) at network.NetworkRequest$AsyncNetworkRequestRunnable.run(NetworkRequest.java:1930) at java.lang.Thread.run(Thread.java:856) ... "GLThread 481" prio=5 tid=12 WAIT | group="main" sCount=1 dsCount=0 obj=0x4131cc40 self=0x5ac63760 | sysTid=5409 nice=0 sched=3/0 cgrp=[fopen-error:2] handle=1539684200 | state=S schedstat=( 0 0 0 ) utm=2614 stm=993 core=0 at java.lang.Object.wait(Native Method) - waiting on \<0x4171f880\> (a java.util.concurrent.atomic.AtomicBoolean) at java.lang.Object.wait(Object.java:364) at plugin.google.iap.v3.LuaLoader.init(LuaLoader.java:168) at plugin.google.iap.v3.LuaLoader.access$1200(LuaLoader.java:34) at plugin.google.iap.v3.LuaLoader$InitWrapper.invoke(LuaLoader.java:400) at com.ansca.corona.JavaToNativeShim.nativeTouchEvent(Native Method) at com.ansca.corona.JavaToNativeShim.touchEvent(JavaToNativeShim.java:339) ...

We can’t tell from just that.  It could be IAPv3 or it could be networking or it could be something else that you filtered out.  Its too hard to tell just from that.

Trying to save reader some headache in a first post by filtering stuff that didn’t appear significant.  Both whole reports in attached zip.  Thanks in advance for any suggestions.

…and another, attached, if it’ll help reveal any pattern.  different title (“ANR keyDispatchingTimedOut”), but same configuration of threads (main waiting on glthread, who just reloaded iap plugin now waiting on some atomicboolean…), this time on a ALCATEL ONE TOUCH 4030X (Beetle_GSM)

We can’t tell from just that.  It could be IAPv3 or it could be networking or it could be something else that you filtered out.  Its too hard to tell just from that.

Trying to save reader some headache in a first post by filtering stuff that didn’t appear significant.  Both whole reports in attached zip.  Thanks in advance for any suggestions.

…and another, attached, if it’ll help reveal any pattern.  different title (“ANR keyDispatchingTimedOut”), but same configuration of threads (main waiting on glthread, who just reloaded iap plugin now waiting on some atomicboolean…), this time on a ALCATEL ONE TOUCH 4030X (Beetle_GSM)

Did you figure this out?

Nope, I just removed the IAP - may not be practical for everyone, but solved my ANR completely.

Did you figure this out?

Nope, I just removed the IAP - may not be practical for everyone, but solved my ANR completely.

I’m getting lots of ANR’s and they definitely appear to be related to iap v3

I’m getting lots of ANR’s and they definitely appear to be related to iap v3