Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Lots of ANRs on Android (PackageStateChangedService, android.intent.action.SCREEN_OFF)
Started by bjoern May 29 2018 11:52 PM

22 replies to this topic
[TOPIC CONTROLS]
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

bjoern

[GLOBAL: userInfoPane.html]
bjoern
  • Enthusiast

  • 54 posts
  • Corona SDK

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)


[TOPIC: post.html]
#2

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 23,955 posts
  • Corona Staff

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

 

Rob



[TOPIC: post.html]
#3

bjoern

[GLOBAL: userInfoPane.html]
bjoern
  • Enthusiast

  • 54 posts
  • Corona SDK

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

 

Rob

 

Seems like all ANRs are gone with 3306.

Thank you for fixing this!

 

Best regards!



[TOPIC: post.html]
#4

mateusz8

[GLOBAL: userInfoPane.html]
mateusz8
  • Observer

  • 17 posts
  • Corona SDK

Are you sure?

 

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



[TOPIC: post.html]
#5

bjoern

[GLOBAL: userInfoPane.html]
bjoern
  • Enthusiast

  • 54 posts
  • Corona SDK

Are you sure?

 

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

 

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!



[TOPIC: post.html]
#6

SGS

[GLOBAL: userInfoPane.html]
SGS
  • Corona Geek

  • 1,813 posts
  • Corona SDK

Yeah I still have lots too



[TOPIC: post.html]
#7

bjoern

[GLOBAL: userInfoPane.html]
bjoern
  • Enthusiast

  • 54 posts
  • Corona SDK

Yeah I still have lots too

 

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



[TOPIC: post.html]
#8

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

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



[TOPIC: post.html]
#9

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 23,955 posts
  • Corona Staff

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



[TOPIC: post.html]
#10

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

@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!



[TOPIC: post.html]
#11

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 23,955 posts
  • Corona Staff

@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



[TOPIC: post.html]
#12

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

@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!



[TOPIC: post.html]
#13

SGS

[GLOBAL: userInfoPane.html]
SGS
  • Corona Geek

  • 1,813 posts
  • Corona SDK

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.



[TOPIC: post.html]
#14

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

@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.



[TOPIC: post.html]
#15

SGS

[GLOBAL: userInfoPane.html]
SGS
  • Corona Geek

  • 1,813 posts
  • Corona SDK

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?



[TOPIC: post.html]
#16

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

@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.



[TOPIC: post.html]
#17

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 23,955 posts
  • Corona Staff

The important thing is we think we have it fixed. 



[TOPIC: post.html]
#18

SGS

[GLOBAL: userInfoPane.html]
SGS
  • Corona Geek

  • 1,813 posts
  • Corona SDK

I think you can see when I published with 3306...

 

Attached File  Image2.png   29.88KB   0 downloads

 

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



[TOPIC: post.html]
#19

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

@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!



[TOPIC: post.html]
#20

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

@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?



[TOPIC: post.html]
#21

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 23,955 posts
  • Corona Staff

@JBean how long have your apps been published with 3315? It seems like it can take a couple of days for Google's Vitals to settle out.

 

Rob



[TOPIC: post.html]
#22

davebollinger

[GLOBAL: userInfoPane.html]
davebollinger
  • Corona Geek

  • 1,127 posts
  • Enterprise

the "overall rate" can take a long time to decrease, particularly if you have lots of samples from older releases that exhibit the problem relative to the activity on your newest release, especially if the older-releases are still actively sending in samples (fe user doesn't update)

 

you'll gradually see the daily graph start to "wash out", but the overall rate may not change significantly - you may have to wait for those older-release samples to "age out".  look for a decreasing trend in the daily graph after say a week, then expect a corresponding change to the overall rate after perhaps a month? (all depending on volume of downloads/updates of new release vs existing installs of problem releases)



[TOPIC: post.html]
#23

JBean

[GLOBAL: userInfoPane.html]
JBean
  • Contributor

  • 174 posts
  • Corona SDK

Yeah, it could be that the other releases are impacting the statistics.

 

I don't know if I was reading the dashboard correctly, but it appeared that the "latest" apk I had published about 4 days ago still had over 1% rate of issues with the wake lock stat. I think it said specifically that version was still having issues vs prior versions. Again, I could be reading the dashboard incorrectly.

 

I updated it again today for safe measure, and will report back next week if the stats are lowering. Thanks for the help!




[topic_controls]
[/topic_controls]