Lots of ANRs on Android (PackageStateChangedService, android.intent.action.SCREEN_OFF)

Solar2D Android
#1

Hello,

I have a lot of ANRs on Android, most of them are:

shared.google.play.services.base.PackageStateChangedService

and

Broadcast of Intent { act=android.intent.action.SCREEN\_OFF flg=0x50200010 (has extras) }

The app uses Build 2018.3301

Does anyone have the same problems, or a possible solution?

Here is one crashlog for each of them:

shared.google.play.services.base.PackageStateChangedService

"main" prio=5 tid=1 Native | group="main" sCount=1 dsCount=0 obj=0x762cd718 self=0xe7505400 | sysTid=26561 nice=-4 cgrp=default sched=0/0 handle=0xeab0f534 | state=S schedstat=( 0 0 0 ) utm=6741 stm=1850 core=7 HZ=100 | stack=0xff06c000-0xff06e000 stackSize=8MB | held mutexes= #00 pc 0000000000017520 /system/lib/libc.so (syscall+28) #01 pc 00000000000477bf /system/lib/libc.so (pthread\_join+146) #02 pc 0000000000015b58 /data/app/com.mycompany.myapp-2/lib/arm/libopenal.so (alcDestroyContext+516) #03 pc 0000000000008ed7 /data/app/com.mycompany.myapp-2/lib/arm/libalmixer.so (ALmixer\_Quit+230) #04 pc 000000000012ed6c /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #05 pc 00000000001311a0 /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #06 pc 00000000001412a4 /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #07 pc 000000000002bf9c /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #08 pc 000000000002f38c /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (Java\_com\_ansca\_corona\_JavaToNativeShim\_nativeDone+28) #09 pc 00000000000767b5 /data/app/com.mycompany.myapp-2/oat/arm/base.odex (Java\_com\_ansca\_corona\_JavaToNativeShim\_nativeDone\_\_J+80) at com.ansca.corona.JavaToNativeShim.nativeDone (Native method) at com.ansca.corona.JavaToNativeShim.destroy (JavaToNativeShim.java:290) at com.ansca.corona.Controller.destroy (Controller.java:286) - locked \<0x0e648bc9\> (a com.ansca.corona.Controller) at com.ansca.corona.CoronaRuntime.dispose (CoronaRuntime.java:88) at com.ansca.corona.CoronaActivity.onDestroy (CoronaActivity.java:1736) at android.app.Activity.performDestroy (Activity.java:7195) at android.app.Instrumentation.callActivityOnDestroy (Instrumentation.java:1161) at android.app.ActivityThread.performDestroyActivity (ActivityThread.java:4573) at android.app.ActivityThread.handleDestroyActivity (ActivityThread.java:4609) at android.app.ActivityThread.-wrap7 (ActivityThread.java) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1692) at android.os.Handler.dispatchMessage (Handler.java:102) at android.os.Looper.loop (Looper.java:154) at android.app.ActivityThread.main (ActivityThread.java:6682) at java.lang.reflect.Method.invoke! (Native method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1520) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1410)

android.intent.action.SCREEN_OFF

"main" prio=5 tid=1 Native | group="main" sCount=1 dsCount=0 obj=0x759a4268 self=0xf1305400 | sysTid=828 nice=-4 cgrp=default sched=0/0 handle=0xf4879534 | state=S schedstat=( 29406008451 3551627591 101341 ) utm=1914 stm=1026 core=0 HZ=100 | stack=0xff38b000-0xff38d000 stackSize=8MB | held mutexes= #00 pc 00000000000174b8 /system/lib/libc.so (syscall+28) #01 pc 000000000004774f /system/lib/libc.so (pthread\_join+146) #02 pc 0000000000015b58 /data/app/com.mycompany.myapp-2/lib/arm/libopenal.so (alcDestroyContext+516) #03 pc 0000000000008ed7 /data/app/com.mycompany.myapp-2/lib/arm/libalmixer.so (ALmixer\_Quit+230) #04 pc 000000000011d74c /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #05 pc 000000000011fb80 /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #06 pc 000000000012fc74 /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #07 pc 000000000002b704 /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (???) #08 pc 000000000002ea74 /data/app/com.mycompany.myapp-2/lib/arm/libcorona.so (Java\_com\_ansca\_corona\_JavaToNativeShim\_nativeDone+28) #09 pc 000000000008b8d5 /data/app/com.mycompany.myapp-2/oat/arm/base.odex (Java\_com\_ansca\_corona\_JavaToNativeShim\_nativeDone\_\_J+80) at com.ansca.corona.JavaToNativeShim.nativeDone (Native method) at com.ansca.corona.JavaToNativeShim.destroy (JavaToNativeShim.java:277) at com.ansca.corona.Controller.destroy (Controller.java:286) - locked \<0x0e8ee3ae\> (a com.ansca.corona.Controller) at com.ansca.corona.CoronaRuntime.dispose (CoronaRuntime.java:88) at com.ansca.corona.CoronaActivity.onDestroy (CoronaActivity.java:1736) at android.app.Activity.performDestroy (Activity.java:7165) at android.app.Instrumentation.callActivityOnDestroy (Instrumentation.java:1161) at android.app.ActivityThread.performDestroyActivity (ActivityThread.java:4582) at android.app.ActivityThread.handleDestroyActivity (ActivityThread.java:4618) at android.app.ActivityThread.-wrap7 (ActivityThread.java) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1696) at android.os.Handler.dispatchMessage (Handler.java:102) at android.os.Looper.loop (Looper.java:154) at android.app.ActivityThread.main (ActivityThread.java:6692) at java.lang.reflect.Method.invoke! (Native method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1468) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1358)
#2

Please try with 3306. We’e made some changes to help address some of the openal based crashes and ANRs

Rob

#3

Seems like all ANRs are gone with 3306.

Thank you for fixing this!

Best regards!

#4

Are you sure?

shared.google.play.services.base.PackageStateChangedService still happens in version 3308.

#5

You are right, they have not gone entirely - but the amount reduced a lot.

Additionally, I now have >6% Stuck partial wake locks (background).

They are tagged with AudioMix.

Best regards!

#6

Yeah I still have lots too

#7

Did 3311 help for you? I’m not sure about that, seems like my last release still has those wake locks. However, reporting for wake locks is delayed some days (other than ANRS/Crahes) - or is there a faster way to see the data?

I will report again in the next days.

Best regards

#8

I still have quite a few ANR’s, but they have reduced the % of errors below the bad behavior threshold.

I am now experiencing this error, but not sure what it means. It’s under Android vitals, and overview under “Bad Behavior”: and listed as Stuck Partial Wake Locks (background): Can someone please tell us how this can be fixed?

Percentage of battery sessions during which users experienced at least one partial wake lock longer than one hour. Note that some apps require long wake locks to enable core functionalities such as streaming music. A battery session is the period between two full charges of a device. Data is collected only when the device is off-charger and the screen is off

#9

I believe daily build 3311 mostly fixes the wake lock issue and 3314 should completely fix it. We are seeing drastic improvements from people who’ve updated with 3311 and are waiting for updates based on 3314 to get enough data for vitals.

Rob

#10

@Rob Miracle - thank you so much for the info. We updated to 3315 just to be safe.

Were wake lock issues a problem all along, or was this an issue with one of the more recent daily builds that ended up being patched? The reason I ask is because I had one app with a 3% rate and google tagged it as “Bad Behavior” but other apps don’t seem to have as high of an occurrence.

I prefer not to go through and update those apps again unless the rate is over the threshold, but lmk if you have any info on when this error started happening. Thank you!

#11

@JBean, I’d need to get an engineer to try and explain the problem. This is just me speculating, but I don’t think this is something new we created in a daily build. I think it’s more likely that Google is “*finding*” more problems by refining that they now consider “Bad Behavior”. It’s creating a moving target.

Rob

#12

@Rob Miracle

I think you are right on google finding more problems. It seems that they started tracking that back in late May of this year, as I see some apps had a spike in bad behavior around that time. Thank you for clarifying!

#13

It is most definitely a Corona problem @Rob.  I only get this on 2 of 3 apps and the one that hasn’t got any bad behaviour hasn’t been updated in the past 6 weeks so it is using a pre GPDR build.

FYR, the “problem” was introduced with build 3306.

#14

@SGS:

It’s not just a Corona problem. We’ve seen this issue pop up around the same timeline as Corona built apps compared to other apps built with other engines. In fact, one of the apps where the issue popped up (not built with Corona) hadn’t been updated in over 12 months, and this issue became a new one. We took a peek into the android vitals, and it has been an issue since before March of this year, but it was never targeted until recently as a bad behavior issue.

My guess is that many apps have had this issue all along,  but google has recently decided to add that as part of the bad behavior stats, and will down-rank apps as a result.

It is most definitely a newly targeted issue by Google play and not specific to this engine. After having compared the data, this is almost a 100% certainty.

#15

The “wakelock bug” was introduced with daily 3306 (maybe changes made surfaced the issue, I don’t know), specifically “changing how audio library memory is handled, should reduce amount of AL related crashes”.  Prior to his build I was running at 0.01% for the previous 3 months.

It was then (mostly) fixed - after we all alerted Corona - with 3311, specifically “Suspending audio thread in background”.  3314 promises to fix it completely but it is too early for conclusive data as yet.

If it was purely a Google change then all my apps would have been affected (same plugins, same backend, same code libraries, etc.)

​Maybe the truth is somewhere in between?

#16

@SGS

Yeah it could be, but given my specific scenario, I’m not 100% sure.

One of our apps that we hadn’t updated in awhile though was also impacted (in greater %), and was a Gamesalad built app. This one shows in the stats that the partial wake lock has been an issue for at least 3 months (It won’t let me look back further on the timeline).

It leads me to believe that it has been an issue all along, but perhaps google has recently tagged this issue as “bad behavior” and is now asking developers to fix it. 

The interesting thing is, this app has the same string of partial wake lock issues since March, but didn’t impact the apps ranking until late May. So it leads me to conclude that Google (during late May) decided to add this to the list of issues that devs need to fix in order to keep their app rank in good standing, even though this has been an issue for quite some time.

I would advise digging into your stats under Android Vitals - Overview - then click on “View details” under the Stuck Partial Wake Locks stat and see how long some of your apps have had that isuse over time. There’s a grid there, and you can look back as far as 3 months. That should answer your question as to whether or not it’s a new or old issue.

#17

The important thing is we think we have it fixed. 

#18

I think you can see when I published with 3306…

And you can probably also tell when I pushed a panic fix with 3311 too (which seems to be really helping).

When I said it was build related I really meant it lol

#19

@SGS:

Yes, yours clearly indicates that an update could have impacted the release with that new issue…

It is very bizarre for sure, because I’m seeing apps that have this issue dating back to March of 2018. (Both Corona and Gamesalad).

Oh well, at least in the end it is fixed!

#20

@Rob Miracle: I’m still geting about a 1.71% rate of partial wake locks after updating with the latest daily build (3315).

We are using Applovin and Admob paid ad plugins as well as the google play iAP plugin.

Can you please check this for us, and make sure these may not be causing these issues?