New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input dispatching timed out ANRs & ANR rate survey #29

Open
neuronix opened this Issue Nov 30, 2017 · 582 comments

Comments

Projects
None yet
@neuronix
Copy link

neuronix commented Nov 30, 2017

Hi guys,

I am mirorring my post from the Starling forum here with Daniel's permission.

We have ANRs on Android in all our apps and would like to know if it's maybe our apps particularly, or if it's AIR related.

Could you please check your Google Dev Console and go to "Android Vitals" > "Overview".

The first section is "Bad Behaviors".

Please share the following values (no need to mention the app, just pick the biggest app you have or the average of all your apps please):

  • ANR Rate (around 2.6% on our apps)
  • Crash Rate (1.1-1.8% on our apps)

The main ANR we are experiencing is "Input dispatching timed out" triggered by "com.adobe.air.customHandler.callTimeoutFunction". There are heaps of topics on it on the web, and they only proper response by Adobe is that we should avoid doing heavy calculations on user input.

But all our apps use Starling, and Starling defers all user inputs to next frame so this should not be an issue.

@skolesnyk

This comment has been minimized.

Copy link

skolesnyk commented Nov 30, 2017

App with Air 27, Starling 1.8, Feathers 2.x
ANR: 0.20%
Crash rate: 0.23%

@Seb-AS

This comment has been minimized.

Copy link

Seb-AS commented Nov 30, 2017

Hi,

Our App(Starling 1.8-AIR 26/21):

ANR Rate : 4%
Crash Rate: 5%

39 reports last 7 days:

Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50000010 (has extras) }

"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 obj=0x74de5000 self=0xb7d81f78
| sysTid=21001 nice=-6 cgrp=bg_non_interactive sched=0/0 handle=0xb6f01bec
| state=S schedstat=( 883042412234 69541281861 500913 ) utm=83394 stm=4910 core=1 HZ=100
| stack=0xbe568000-0xbe56a000 stackSize=8MB
| held mutexes=
#00 pc 000000000000f9b0 /system/lib/libc.so (syscall+28)
#1 pc 00000000000138ab /system/lib/libc.so (pthread_join+90)
#2 pc 00000000001fa2a5 /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#3 pc 00000000001fa34b /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#4 pc 00000000001c98d5 /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#5 pc 00000000001c3901 /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#6 pc 00000000003477df /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#7 pc 00000000003cee7b /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#8 pc 00000000003d10ed /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#9 pc 000000000012ebeb /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#10 pc 0000000000130b27 /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#11 pc 00000000001349b1 /data/app/air.com.app1-1/lib/arm/libCore.so (???)
#12 pc 00000000001215e3 /data/app/air.com.app1-1/lib/arm/libCore.so (Java_com_adobe_air_customHandler_callTimeoutFunction+10)
#13 pc 00000000001bbc1f /data/dalvik-cache/arm/data@app@air.com.app1-1@base.apk@classes.dex (Java_com_adobe_air_customHandler_callTimeoutFunction__II+90)
at com.adobe.air.customHandler.callTimeoutFunction (Native method)
at com.adobe.air.customHandler.handleMessage (customHandler.java:22)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:135)
at android.app.ActivityThread.main (ActivityThread.java:5912)
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:1405)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1200)

10 reports last 7 days:

Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)

"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x415a4ca8 self=0x414de570
| sysTid=22564 nice=-6 sched=0/0 cgrp=apps handle=1074331988
| state=S schedstat=( 0 0 0 ) utm=4477 stm=515 core=2
#00 pc 0000000000021910 /system/lib/libc.so (__futex_syscall3+8)
#1 pc 000000000000ef94 /system/lib/libc.so (__pthread_cond_timedwait_relative+48)
#2 pc 000000000000eff4 /system/lib/libc.so (__pthread_cond_timedwait+64)
#3 pc 0000000000013007 /system/lib/libc.so (pthread_join+74)
#4 pc 00000000001fa2a5 /data/app-lib/air.com.app1-1/libCore.so
at com.adobe.air.customHandler.callTimeoutFunction (Native Method)
at com.adobe.air.customHandler.handleMessage (customHandler.java:22)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:136)
at android.app.ActivityThread.main (ActivityThread.java:5017)
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:779)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:595)
at dalvik.system.NativeStart.main (Native Method)

@neuronix

This comment has been minimized.

Copy link

neuronix commented Nov 30, 2017

Thanks to both of you! Since both apps have such different rates, could you give a little extra info?

  • Do you have little or a lot of user inputs ?
  • Do you have any input intense situations like tapping or dragging on the screen?
  • Do you have ANEs included in the app (notably ads) ?
@Seb-AS

This comment has been minimized.

Copy link

Seb-AS commented Nov 30, 2017

Do you have little or a lot of user inputs ?
Yes, we have.
Do you have any input intense situations like tapping or dragging on the screen?
Yes, we have.
Do you have ANEs included in the app (notably ads) ?
Ads: AdCel, AdColony, SuperAwesome
Some District Anes.(Contacts/mediaPlayer/flurry/more)
Goviral
Custom Anes.

@neuronix

This comment has been minimized.

Copy link

neuronix commented Nov 30, 2017

Thanks @Seb-AS, will be interesting to compare with @skolesnyk's app regarding the amount of user inputs.

@skolesnyk

This comment has been minimized.

Copy link

skolesnyk commented Nov 30, 2017

Scrolling lists, tapping on Sound Player play/pause buttons, text entry.
There's FacebookAPI ANE integration, so some users switch to Facebook native app or browser and then back to the app.
Using about 14 ANEs, mostly Distriqt, but also BranchIO, Fyber (with 2 ad networks): showing interstitials without user's action and showing Fyber Offerwall after user's interaction with UI.

@MathiasFabian

This comment has been minimized.

Copy link

MathiasFabian commented Dec 1, 2017

App with Air 25, Starling 2.2
ANR: 7.5%
Crash rate: 4.0%

Broadcast of Intent { act=android.intent.action.SCREEN_ON flg=0x50000010 }
Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50000010 }
Broadcast of Intent { act=org.herozero.NOTIFICATION_DELAYED
and a lot of Input dispatching timed out errors

App with Air 25, Starling 1.8
ANR: 2.6%
Crash rate: 2.2%

Broadcast of Intent { act=android.intent.action.SCREEN_ON flg=0x50000010 }
Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50000010 }
and a lot of Input dispatching timed out and keyDispatchingTimedOut errors

Do you have little or a lot of user inputs ?
Yes, in both apps.
Do you have any input intense situations like tapping or dragging on the screen?
First app has more taps, second a lot of swiping.
Do you have ANEs included in the app (notably ads) ?
Both Apps use a lot of distriqt ANEs (Application, Billing, Facebook, ...) and for ads the Appodeal ANE.

@neuronix

This comment has been minimized.

Copy link

neuronix commented Dec 1, 2017

Thank you @MathiasFabian for sharing!

@PrimaryFeather this issue seems to be plaguing a lot if not just about all AIR apps. Could you get someone from the AIR team to look into this?

@calibrae

This comment has been minimized.

Copy link

calibrae commented Dec 1, 2017

App with Air 22 and Starling 1.9
ANR: 2.79%
Crash 0.51%

Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 5. Wait queue head age: 5502.9ms.)

Do you have little or a lot of user inputs ?
No.
Do you have any input intense situations like tapping or dragging on the screen?
Yes, the app is an educational game for kids
Do you have ANEs included in the app (notably ads) ?
Distriqt Extension Files for Android app only.

@chichilatte

This comment has been minimized.

Copy link

chichilatte commented Dec 1, 2017

  • AIR 23 (we tried 27 but ANR frequency was similar)
  • Starling 1.8
  • Crashes: 1.35%
    Our main crash is "java.lang.NullPointerException" at com.adobe.air.AIRWindowSurfaceView.onKeyUp (AIRWindowSurfaceView.java:395)
  • ANRs: 0.6%
    We've had 49 ANRs recently, 39 of which were the same as your main one @neuronix:
    "Input dispatching timed out" at com.adobe.air.customHandler.callTimeoutFunction.
    The description for it:
    Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 2. Wait queue head age: 5926.5ms.)
    Actually, all of our ANRs are variations of "Input dispatching timed out". Not sure if that's normal.

EDIT: The Google Play Console was being extremely flakey – our most common ANR error was in fact Broadcast of Intent { act=android.intent.action.SCREEN_OFF ...
They accounted for 77% of all ANRs, the rest being Input dispatching timed out.
One thing to note is that the stack traces for both errors mention com.adobe.air.customHandler.callTimeoutFunction
EDIT2: The Play Console is definitely flakey for us – using the same filters and time period as i used previously it's saying 90% of our ANR errors are Input dispatching timed out, 10% Broadcast of Intent { act=android.intent.action.SCREEN_OFF ....
Could it be these are the same error? We've spoken to Google and they say their tech team are having a look.


  • We don't have a lot of user inputs, just a tap or drag once every few secs. No intense periods.
  • ANEs: GoViral, RateBox, Distriqt Firebase. No ads ANEs.

We can replicate the ANRs but it takes a while and they seem to happen randomly. We're completely flummoxed. The ANRs can happen on a completely static screen with only very occasional input. I suspected a memory leak but Scout says no.

@marchbold

This comment has been minimized.

Copy link

marchbold commented Dec 1, 2017

Concerned our ANEs are mentioned here, if this is related to us we will chase down the issue immediately, though I'm fairly confident it's not.

Is anyone having this issue without distriqt's ANEs?

@neuronix

This comment has been minimized.

Copy link

neuronix commented Dec 1, 2017

@marchbold we use Milkman ANEs, I don’t think it’s related to your ANEs in particular, my gut feeling is an issue in the Android/AIR input handling.

@marchbold

This comment has been minimized.

Copy link

marchbold commented Dec 1, 2017

Yeah, that's my feeling too, just was a little concerned when saw our extensions mentioned several times. We did actually do a thorough review of our ANEs to identify any potential causes when we encountered this issue in our apps and couldn't find anything.

Our largest app:

  • ANR rate: 2.15%
  • Crash rate: 0.55%

ANRs are mainly due to two causes:

  • Broadcast of Intent { act=android.intent.action.SCREEN_OFF ...
  • Input dispatching timed out (Waiting because the touched window has not finished ...

Similar logs to the ones above.

We use Fyber Ads ANE

Crashes are mainly related to Fyber:

  • java.lang.NullPointerException com.fyber.ads.videos.a.b.a RewardedVideoClient.java
  • signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
@chichilatte

This comment has been minimized.

Copy link

chichilatte commented Dec 4, 2017

Our most common crashes over last 60 days:

  • 36% java.lang.NullPointerException at com.adobe.air.AIRWindowSurfaceView.onKeyUp (AIRWindowSurfaceView.java:395)
  • 28% java.lang.NullPointerException at com.adobe.air.AIRWindowSurfaceView.surfaceChanged
  • 23% variations of signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
  • 6% signal 11 (SIGSEGV), code 2 (SEGV_ACCERR)
@dcampano

This comment has been minimized.

Copy link

dcampano commented Dec 4, 2017

We are also seeing very similar ANR rates and similar causes:

  • Broadcast of Intent { act=android.intent.action.SCREEN_OFF ...
  • Broadcast of Intent { act=android.intent.action.SCREEN_ON ...
  • Input dispatching timed out (Waiting because the touched window has not finished ...

Here are some stats on our app:

  • ANR Rate: 3.4%
  • Crash Rate: 1.08% (some of these coming from a purchase extension so this could get lowered)
  • ~50k daily active users
  • AIR 27, Starling 1.6, Feathers 2.1.1
  • GoViral Facebook ANE, some Distriqt ANES. We ripped out all advertising ANEs as we thought these might be causing issues but it didn't help our ANR rate at all.

We also don't think that these ANRs are extension related. When we have had some other ANRs caused by extensions we were able to see a clear stacktrace to the extension code.

Do you have little or a lot of user inputs? Typically 1 or 2 taps every few seconds
Do you have any input intense situations like tapping or dragging on the screen? No
Do you have ANEs included in the app (notably ads) ? Answered above

@darriuk

This comment has been minimized.

Copy link

darriuk commented Dec 11, 2017

We're seeing ANRs and crashes above the bad behaviour thresholds in our app.
• ANR rate: 0.73%
• Crash rate: 1.47%
• Air 23.0, Starling 1.8.1, Feathers 2.2

Do you have little or a lot of user inputs ?
Not that much user input.

Do you have any input intense situations like tapping or dragging on the screen?
Tapping, yes, but never really intense tapping. Also dragging the screen on some pages. ANRs have happened when neither tapping nor dragging was being done by the user, and no intense computation was being done by our app.

Do you have ANEs included in the app (notably ads) ?
Yes, but no ads:
• Milkman GoViral, RateBox
• Distriqt – androidsupport.V4, Core, Firebase, Crash, GoogleIdentity, Notifications, playservices.Auth, playservices.Base, playservices.Identity, Resources
• pl.mateuszmackowiak.nativeANE.properties.SystemProperties.ane

Typical ANR reports:

Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago

Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)

Typical crash traces:

java.lang.NullPointerException: 
  at com.adobe.air.AIRWindowSurfaceView.onKeyUp (AIRWindowSurfaceView.java:395)
  at android.view.KeyEvent.dispatch (KeyEvent.java:2907)
  at android.view.View.dispatchKeyEvent (View.java:7543)
java.lang.NullPointerException: 
  at com.adobe.air.AIRWindowSurfaceView.surfaceChanged (AIRWindowSurfaceView.java:735)
  at android.view.SurfaceView.updateWindow (SurfaceView.java:731)
  at android.view.SurfaceView.onWindowVisibilityChanged (SurfaceView.java:322)
@Ankit-Adobe

This comment has been minimized.

Copy link

Ankit-Adobe commented Dec 13, 2017

Hi,
Could you please a log a bug at http://tracker.adobe.com/ and attach a sample application where this issue is reproducible.

Thanks,
Ankit | Adobe AIR Engineering

@neuronix

This comment has been minimized.

Copy link

neuronix commented Dec 13, 2017

Hi @Ankit-Adobe, Thanks for joining the conversation. There is already a bug in the tracker here: https://tracker.adobe.com/#/view/AIR-4198519

We have tried to reproduce the bug but without success so far. Could you give us more information on when/how this error is triggered? It always seems to originate from com.adobe.air.customHandler.callTimeoutFunction

@cgascons

This comment has been minimized.

Copy link

cgascons commented Dec 20, 2017

Hi guys, we are having the exact same errors on all our apps, we have also updated the forum topic (https://forum.starling-framework.org/topic/anrs-crash-rate-survey?replies=5#post-109884) and voted and commented on the tracker url provided.

ANR rate: 3.60%
Crash rate: 0.90%
• Air 26.0, Starling 2.2 (2017-06-27), Feathers 3.1.2 (January 2017)

Thanks,

@chichilatte

This comment has been minimized.

Copy link

chichilatte commented Dec 20, 2017

Just a note to say i made an edit to my original post above (the main ANR error was wrong)

@PrimaryFeather

This comment has been minimized.

Copy link
Contributor

PrimaryFeather commented Dec 21, 2017

Just a thought (actually an idea of Robby Campano): could it be that the ANRs we are seeing are the result of users hitting the screen while the apps are restoring from a context loss? After all, this takes some time, and the textures are restored synchronously, i.e. all input will be blocked.

I could switch the texture restoration to being asynchronous, but it's been reported that this is not entirely reliable on some Android hardware. Could be worth a shot, though — this requires only a small change inside the AssetManager (I think). Then I could make this an "opt-in" flag.

Any comments?

@cgascons

This comment has been minimized.

Copy link

cgascons commented Dec 21, 2017

As a matter of fact I was just testing that, these are the results:

Turns out that, -when the user locks the device- the app has a harder time recovering from a context loss when the app is in foreground rather than in background. At least it took significantly more time on my device (Samsung Galaxy S6).

If I send the app to background, then lock the device, unlock it back, and bring it to foreground again the restoration is still visible, but it takes none to very short time.

When I try it the other way around (app was in foreground when the device got locked), while the app is restoring, I can still play around and click stuff when, according with what you just said, all the input should be blocked. I have to say though, that I can't really tell an exact restoration time for each example, since sometimes my device takes longer because, I don't know, it doesn't like my face :)

I'm not entirely sure if I'm missing something but I can definitely mess around with the app when recovering from the context loss. That said, I still haven't been able to reproduce the ANR itself on my phone while debugging.

@PrimaryFeather

This comment has been minimized.

Copy link
Contributor

PrimaryFeather commented Dec 21, 2017

Thanks for the additional info, Christian!

I'm not entirely sure if I'm missing something but I can definitely mess around with the app when recovering from the context loss.

You're totally right: it depends on the size of the textures being restored. I imagine it takes a while loading a 4k*4k texture, for example; and during that time, input will be blocked. Loading several smaller ones should not be that much of an issue, because there's a gap for AS3 to process stuff between each upload process.

@cgascons

This comment has been minimized.

Copy link

cgascons commented Dec 21, 2017

I see, perhaps what I'm about to suggest isn't doable, but what if the whole Stage was left untouchable as soon as the restoration begins, and it gets back to touchable as soon as the TEXTURES_RESTORED event gets dispatched? Could that be an option? I understant that during that restoration time no ANR's could be generated since the touch events would not be triggered, right?

@PrimaryFeather

This comment has been minimized.

Copy link
Contributor

PrimaryFeather commented Dec 21, 2017

Hm, no, that wouldn't help. Since it's a synchronous operation, all of AS3 stops accepting input — and that includes the mouse events of the classic Flash (which Starling otherwise queues). The only solution would be to avoid that synchronous (time consuming) operation.

Again, I don't know if that's really the issue — it's just a possibility.

@neuronix

This comment has been minimized.

Copy link

neuronix commented Dec 21, 2017

I do not think this is related to context loss. ANRs occur during gameplay periods according to our user reports. However it seems to occur after a period without user inputs:

Case 1: match 3 game, users report freezing often after waiting to think on a move (5s maybe)
Case 2: timer based game, users report freezing always when about 4-5s left out of 15, so again probably a short pause between inputs.

@PrimaryFeather

This comment has been minimized.

Copy link
Contributor

PrimaryFeather commented Dec 22, 2017

ANRs occur during gameplay periods according to our user reports.

Aha, that's useful information — thanks!

@megajogos

This comment has been minimized.

Copy link

megajogos commented Dec 20, 2018

Hi Guys,

We updated our apps with Adobe Air 32, but the ANR, wake Locks and crashes are still very high.

What are the work around to minimize this errors:

  • Sound loop with volume zero?
  • Kill the app after some minutes in background using JobScheduler?
  • Use another sound player?
  • SoundMixer.stopAll() on deactivate?

Please help!

@pis0

This comment has been minimized.

Copy link

pis0 commented Dec 20, 2018

using sdk 32.0.0.81...

NativeApplication.nativeApplication.executeInBackground = false;

APP DEACTIVATE:
stopAllSounds();
NativeApplication.nativeApplication.systemIdleMode = SystemIdleMode.NORMAL;
System.pause();

APP ACTIVATE:
System.resume();
NativeApplication.nativeApplication.systemIdleMode = SystemIdleMode.KEEP_AWAKE;
unmuteSounds();

I don't use SoundMixer.stopAll()... I only use a SoundChannel pool with 20 as the max length.. ( as default we cannot use more than 32 SoundChannels )... stopAllSounds() means save the current sound position and close the channel of all sounds playing..

feedback:

  • low wake locks;
  • no Crashes/ANRs related to AudioTrackWrapper..

BUT.. air.com.pipastudios.release.praiabingo.AppEntry ANRs are still high..

this is my new ANR villain (as I said in a past post):

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x7445cbf0 self=0xe6f85400
  | sysTid=7803 nice=-10 cgrp=default sched=0/0 handle=0xe9c71534
  | state=R schedstat=( 5136687676 12569361 1530 ) utm=479 stm=34 core=4 HZ=100
  | stack=0xff7b4000-0xff7b6000 stackSize=8MB
  | held mutexes=
  #00  pc 0000000000b4a404  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (???)
  #01  pc 0000000000b495e7  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (LzmaDec_DecodeToDic+528)
  #02  pc 0000000000b4abb7  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (LzmaDec_DecodeToBuf+86)
  #03  pc 00000000006a3de9  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN12ScriptPlayer12CompressInfo11InflateLZMAEPKhiPhiPj+140)
  #04  pc 00000000006a7617  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN12ScriptPlayer11PushDataBufEPKhiPbb+1638)
  #05  pc 00000000006a53d7  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN12ScriptPlayer13PushImageDataEPKhib+442)
  #06  pc 00000000006ff255  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN10CorePlayer20UrlStreamWriteNotifyEP9URLStreamPKhj+104)
  #07  pc 00000000006ff1a7  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN10CorePlayer14UrlStreamWriteEP9URLStreamPKhj+454)
  #08  pc 000000000071f141  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN9URLStream11StreamWriteEPKhj+180)
  #09  pc 0000000000570a8d  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN18PlatformFileStream3RunEv+116)
  #10  pc 0000000000528fa3  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN24AndroidURLStreamProvider14RequestUrlImplEv+226)
  #11  pc 00000000006fb9f9  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN10CorePlayer8LoadFileERK13UrlResolutionR10ScriptAtomPKcjjS6_P15MovieClipLoaderPP17UrlStreamSecuritybS6_PN7avmplus9DomainEnvEPv+1664)
  #12  pc 00000000006fbc89  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN10CorePlayer9LoadMovieEPKc13E8BitEncodingPP17UrlStreamSecuritybPN7avmplus9DomainEnvE+468)
  #13  pc 00000000008a805f  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN7runtime19ContentPlayerObject18loadInitialContentEPN7avmplus6StringE+134)
  #14  pc 00000000008a213d  /data/app/air.com.pipastudios.release.praiabingo-2/lib/arm/libCore.so (_ZN7avmplus8NativeID56runtime_ContentPlayer_protected_loadInitialContent_thunkEPNS_9MethodEnvEjPi+8)
  at com.adobe.air.Entrypoints.EntryMainWrapper (Native method)
  at com.adobe.air.Entrypoints.EntryMain (Entrypoints.java:139)
  at com.adobe.air.AndroidActivityWrapper.LaunchApplication (AndroidActivityWrapper.java:1167)
  at com.adobe.air.AndroidActivityWrapper.onSurfaceInitialized (AndroidActivityWrapper.java:1416)
  at com.adobe.air.AIRWindowSurfaceView.surfaceChanged (AIRWindowSurfaceView.java:790)
  at android.view.SurfaceView.updateWindow (SurfaceView.java:644)
  at android.view.SurfaceView$3.onPreDraw (SurfaceView.java:162)
  at android.view.ViewTreeObserver.dispatchOnPreDraw (ViewTreeObserver.java:944)
  at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:2205)
  at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1254)
  at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:6344)
  at android.view.Choreographer$CallbackRecord.run (Choreographer.java:874)
  at android.view.Choreographer.doCallbacks (Choreographer.java:686)
  at android.view.Choreographer.doFrame (Choreographer.java:621)
  at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:860)
  at android.os.Handler.handleCallback (Handler.java:751)
  at android.os.Handler.dispatchMessage (Handler.java:95)
  at android.os.Looper.loop (Looper.java:154)
  at android.app.ActivityThread.main (ActivityThread.java:6121)
  at java.lang.reflect.Method.invoke! (Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:889)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:779)


I recently uploaded the app with the new released sdk 32.0.0.89, just for curiosity.. AudioTrackWrapper ANRs were back, but these ANRs related to LzmaDec_Decode were very low.. so I imagine it's something that need to be fix in the SDK level as well.

@Oldes

This comment has been minimized.

Copy link

Oldes commented Dec 20, 2018

@pis0 where did you get the SDK 32.0.0.89? I think that the version from labs does not have the code like the version linked here -> #29 (comment)

@viveknegi1 which version is supposed to be the best now?

@pis0

This comment has been minimized.

Copy link

pis0 commented Dec 20, 2018

@pis0 where did you get the SDK 32.0.0.89? I think that the version from labs does not have the code like the version linked here -> #29 (comment)

https://www.adobe.com/devnet/air/air-sdk-download.html

@leossmith

This comment has been minimized.

Copy link

leossmith commented Jan 2, 2019

After updating from AIR 29 to 31, we see a huge increase in ANRs for Input dispatching timed out. This doubled our % ANR which already gave us a penalty with Google. The apps has a total of 9 Text Inputs in like 5 Screens so it is not heavy on input.

Is there a fix for this?

I am adding the log

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x73d22f28 self=0xec984400
  | sysTid=25479 nice=-10 cgrp=default sched=0/0 handle=0xef66c534
  | state=S schedstat=( 7977858543 102506671 1873 ) utm=747 stm=50 core=0 HZ=100
  | stack=0xff13d000-0xff13f000 stackSize=8MB
  | held mutexes=
  #00  pc 00000000000176b8  /system/lib/libc.so (syscall+28)
  #01  pc 00000000000b6e49  /system/lib/libart.so (_ZN3art17ConditionVariable16WaitHoldingLocksEPNS_6ThreadE+92)
  #02  pc 00000000003f3b1b  /system/lib/libart.so (_ZN3artL12GoToRunnableEPNS_6ThreadE+230)
  #03  pc 00000000003f3a0d  /system/lib/libart.so (_ZN3art12JniMethodEndEjPNS_6ThreadE+8)
  #04  pc 00000000001d9e81  /system/framework/arm/boot.oat (Java_java_util_zip_ZipFile_getEntryFlag__J+100)
  at java.util.zip.ZipFile.getEntryFlag (Native method)
  at java.util.zip.ZipFile.getZipEntry (ZipFile.java:540)
  at java.util.zip.ZipFile.-wrap2 (ZipFile.java)
  at java.util.zip.ZipFile$1.nextElement (ZipFile.java:530)
- locked <0x090c69dc> (a java.util.zip.ZipFile)
  at java.util.zip.ZipFile$1.nextElement (ZipFile.java:508)
  at com.adobe.air.ApplicationFileManager.readFileName (ApplicationFileManager.java:281)
  at com.adobe.air.Entrypoints.EntryMainWrapper (Native method)
  at com.adobe.air.Entrypoints.EntryMain (Entrypoints.java:139)
  at com.adobe.air.AndroidActivityWrapper.LaunchApplication (AndroidActivityWrapper.java:1167)
  at com.adobe.air.AndroidActivityWrapper.onSurfaceInitialized (AndroidActivityWrapper.java:1416)
  at com.adobe.air.AIRWindowSurfaceView.surfaceChanged (AIRWindowSurfaceView.java:790)
  at android.view.SurfaceView.updateWindow (SurfaceView.java:644)
  at android.view.SurfaceView$3.onPreDraw (SurfaceView.java:162)
  at android.view.ViewTreeObserver.dispatchOnPreDraw (ViewTreeObserver.java:944)
  at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:2205)
  at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1254)
  at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:6344)
  at android.view.Choreographer$CallbackRecord.run (Choreographer.java:874)
  at android.view.Choreographer.doCallbacks (Choreographer.java:686)
  at android.view.Choreographer.doFrame (Choreographer.java:621)
  at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:860)
  at android.os.Handler.handleCallback (Handler.java:751)
  at android.os.Handler.dispatchMessage (Handler.java:95)
  at android.os.Looper.loop (Looper.java:154)
  at android.app.ActivityThread.main (ActivityThread.java:6121)
  at java.lang.reflect.Method.invoke! (Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:889)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:779)
@rewb0rn

This comment has been minimized.

Copy link

rewb0rn commented Jan 3, 2019

The only reliable fix right now is to use an ANE to play sounds, instead of using the Action Script 3 built in API. Given that the ANRs you are seeing are the ones that are discussed here.

@leossmith

This comment has been minimized.

Copy link

leossmith commented Jan 3, 2019

@rewb0rn I am not even using sound on this app. This is caused from the Input dispatching timed out ANR (this topic before hijacked for sound ). This was really low in AIR29 and jumped after updating to 31. The apps average ANR was 0.30% and it jumped to 0.65%. As the threshold for penalty is 0.47% we already lose thousands of downloads everyday.

I added the log if it helps.

@rewb0rn

This comment has been minimized.

Copy link

rewb0rn commented Jan 3, 2019

The ANRs for "Input dispatching timed out" in this thread are directly related to playing sound in an Air app on Android, the topic was not hijacked. Sounds are the only known reason for these ANRs so far.

If you are not using any sound in your app, then something else might be going on but it is not happening for us. We are using Air 31.0.0.96 for Windows SDK with a sound ANE and our ANR rate is currently at 0.04%.

@leossmith

This comment has been minimized.

Copy link

leossmith commented Jan 3, 2019

I could be wrong about the first topic as I hadn't this problem since ages. Last time it occurred was AIR 21 or something. I will try AIR32 to see if this makes any difference.

@megajogos

This comment has been minimized.

Copy link

megajogos commented Jan 7, 2019

Hey Guys,

Witch Adobe AIR SDK is better right now? 32 or 31?

We have deployed one app with adobe air 32 and the ANR rate is worse than the version with adobe air 31.

@neuronix

This comment has been minimized.

Copy link

neuronix commented Jan 8, 2019

@viveknegi1 @surajgup AIR SDK 32.0.0.89 has been released however this topic is still in the "known issues" list. Have you been able to make any progress? Do you need anymore information?

@pis0 I was away for a while and did not upgrade past 32.0.0.68. Which SDK would you recommend for our next update? The live 32.0.0.89 or the previous beta 32.0.0.81?

@premiumsB

This comment has been minimized.

Copy link

premiumsB commented Jan 8, 2019

Holidays are over where are @surajgup and @viveknegi1 ??

@leossmith

This comment has been minimized.

Copy link

leossmith commented Jan 9, 2019

Same here. AIR31 was worst than 29 and 32 (32.0.0.89) was worst than 31. And now my app got a penalty and downloads dropped lol. Unfortunately due to one ANE I can't go back to 29.

image

@premiumsB

This comment has been minimized.

Copy link

premiumsB commented Jan 9, 2019

@leossmith Your message doesn't make sense
"Same here. AIR31 was worst than 29 and 32 (32.0.0.89) was worst than 31. "

@rewb0rn

This comment has been minimized.

Copy link

rewb0rn commented Jan 10, 2019

@premiumsB I think he means it got worse from 29 to 30 and it got worse again from 31 to 32.

@leossmith You can use a Sounds ANE, for example the one by Distriqt, and use the ANE to play sounds instead of the AS3 sound API. This reduced ANRs to almost 0 on our apps.

@httpwebmedia

This comment has been minimized.

Copy link

httpwebmedia commented Jan 11, 2019

@viveknegi1 and @surajgup Are you guys still work for Adobe ????? It starts to be urgent to get a stable release now we are waiting for this for months!!!

@leossmith

This comment has been minimized.

Copy link

leossmith commented Jan 11, 2019

@rewb0rn you are correct.

AIR29 - I had an average of 0.44% ANR
AIR31 - Jumped to 0.66%
AIR32 - Jumped to 0.87%

I am not using any sounds in this app so I have no idea why I get this errors. However after some research, it looks like _ZN3art17ConditionVariable16WaitHoldingLocksEPNS_6ThreadE+92 is a UI rendering related issue.

@Gratsonia

This comment has been minimized.

Copy link

Gratsonia commented Jan 16, 2019

@rewb0rn I could not find a library to play sounds from the distriqt

@Elintondm

This comment has been minimized.

Copy link

Elintondm commented Jan 17, 2019

Could I play sounds from my library with this lib?
Or I have to play the sound file (mp3, wav, etc.)?

Have a migration guide to from adobe player to com.distriqt.MediaPlayer ?

@danerhardolsson

This comment has been minimized.

Copy link

danerhardolsson commented Jan 17, 2019

Hey @Elintondm

No, you cannot play from the library. In my experience though, you can add your sounds files to your "included files" and access them by reading from the applicationDirectory.

It's not advanced at all as long as you get the basics under control.

I'm actually in the process of implementing distriqts MediaPlayer right now and I could help you out briefly if you'd like.

@Faketa

This comment has been minimized.

Copy link

Faketa commented Jan 17, 2019

My fix is to pause all currently playing sounds on deactivate event and resume them on activate. With version 34.0.0.81 I don`t get any ANR or crashes related to Audio.

@danerhardolsson

This comment has been minimized.

Copy link

danerhardolsson commented Jan 17, 2019

@Faketa And your other vitals are beneath the thresholds?

My current vitals are as such:
Wake Locks: 0,03%
ANR: 2,68%
Crashes: 0,84%

@Faketa

This comment has been minimized.

Copy link

Faketa commented Jan 17, 2019

After the fix, my Vitals summary doesn`t contains any values related to mentioned in this thread issues. Of corse I have other problems which are reflected in Vitals. I reccommend you to use the fix and you will see. If you use Starling I can give you complete solution.

@rewb0rn

This comment has been minimized.

Copy link

rewb0rn commented Jan 17, 2019

@Faketa: In my test app I can reproduce ANRs on my device by having the game in auto play mode without any deactivate / activate event. I just keep the game in foreground for the whole session and after some hours the game will freeze. So I doubt this is related to anything you do on deactivate / activate. What is your Google Play rate on ANRs? Please note that the ANR will read "Input dispatched timed out", from the title it is not obvious that they are related to audio, but they are.

@Faketa

This comment has been minimized.

Copy link

Faketa commented Jan 17, 2019

@rewb0rn at this moment I can't tell you because my app don't generate any excessive ANR`s and it's beta version (~120 installs per day)
Could you please provide me with the longest time your app is being okay when is in foreground?

@rewb0rn

This comment has been minimized.

Copy link

rewb0rn commented Jan 17, 2019

@Faketa I consider a version stable if our auto play test does not freeze over night, so say 8 hours. Please note that it is not enough to have the app open, you must have sounds start playing during the play test and the amount of sounds your app plays during a session might make a difference. So our 8 hours might be different for your case. We have created an auto play bot that plays our game by itself so we do not need to test the app manually for hours.

Also note that an Air app will not freeze if you loop a single sound endlessly, like a background music. That is the workaround I have described earlier in this thread.

@Faketa

This comment has been minimized.

Copy link

Faketa commented Jan 17, 2019

@rewb0rn I don'r really understand the purpose of playing the game while it's in foreground. Normally when the app is going to foreground we have to pause it.

@megajogos

This comment has been minimized.

Copy link

megajogos commented Jan 17, 2019

@Faketa how could you get the Adobe Air 34.0.0.81 ??? Is it right?

@Faketa

This comment has been minimized.

Copy link

Faketa commented Jan 17, 2019

@megajogos From this thread posted (if I'm correct) by the @viveknegi1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment