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

@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

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)

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!

I’ve recently dived into the ANR issue on my apps and although my latest update is using build 3362, I still see quite a few ANRs especially the ones with: Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50200010

Is there something we can do on our end to reduce these?

@rune7 can you use a service like pasetbin, copy and paste the entire backtrace to one of these ANR’s to it and share a link to the pastebin here?

Rob

Sure, here is an example - https://pastebin.com/6AeG0JP6

It may not be as clear when pasting all threads. If its enough to get specific threads please let me know.

It was taken from: Sony Xperia Z5 Compact (E5823), Android 7.1

Hello! Thank you for your report. I have several questions:

  1. What is the name of ANR?

  2. How many ANRs of this type you get (percentage, or if absolute numbers, please provide total number of launches)"

  3. Do you have a reproduction of this ANR?

  4. What plugins are you using?

@vlad, wake locks and ANRs from one of my games…

ANR over bad threshold level and wake locks are still not fixed yet.  This is with 3335 - last 30 days.

Mostly Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50000010 } or 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: 4. Wait queue head age: 378834.9ms.)

Raised from  com.ansca.corona.CoronaActivity 

Hi @vlads,

  1. The one I pasted the error stack for was titled on Google Developer console: 

Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50200010.

Looking at what STS sent I see these two as the dominant ones as well.

  1. My ANR ratio is still high ~1.35% which is way over their bad behavior threshold of ~0.5%. Out of the total I’d say these two take over 90% of the total. So, overall I’d say they affect around 1.3%+ of our total sessions.

  2. On our test devices I could not reproduce these. But we only have 2 different devices to test on.

  3. Plugin used on Google: advertisingId, flurry, iap.v3

List of ANRs from last 3 days (note that we don’t have a lot of daily users):

Amount: 15

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: 19. Wait queue head age: 99153.1ms.)

Amount: 5

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

They consist 20 out of 21 total reports for the period.

On a side note, it seems that our last update introduced the issue of wake lock which was not there on our previous build from last year. I don’t have enough data yet to give good confidence percentage but I can say that it exist while it didn’t previously.

I currently use build 3362. 

Just to note that latest builds have vastly improved ANR situation compared to last year, so well done!

Adi

I too have ANR problems with my game, so it can’t get a feature on Google Play. It has to be below the trash-hold. I’m using the play services and now thinking about removing the auto-login or just remove them at all.

Could they be the problem?

[member=‘d.mach’], are you getting same types of ANRs? If you can dump some tracebacks & names on pastebin, we may be able to help

Hello, I also regularly get this error

Android vitals logs is here:

https://pastebin.com/FdyK13Yn

Version 2018.3372 (2018.9.18)

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!

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!

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

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

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