5

The Play Store has a lot of ANRs for which it refuses to give me a stack trace. This is my top ANR without a stack trace:

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

Since it says android.intent.action.SCREEN_OFF, is it safe to assume that my app is causing the ANR while some Activity is having onPause or onStop or similar method called on it?

Any other suggestions for how to figure this out?

Edit: as far as I can tell nothing is registered for that broadcast in my code or third party libraries. I looked at the generated manifest after compiling even.

Edit: Here is a screenshot of what I see. It says SCREEN_ON but when I look at it on the previous screen it says SCREEN_OFF. One day it'll say ON and another OFF. Regardless of what it says, there is never a stack trace.

enter image description here

casolorz
  • 8,486
  • 19
  • 93
  • 200
  • That's unrelated. Someone turned the screen off, which causes that message. But unless your app has a BroadcastReceiver listening for that message, that didn't cause your ANR. However yes, onPause or onStop taking too long can cause an ANR. Those are meant to be brief operations, taking more than a second or two will trip a watchdog. – Gabe Sechan Mar 21 '22 at 01:36
  • I've search my code and the generated manifest after it is compiled and nothing appears to be registered for that broadcast. Feels a bit odd that it would be listed as the broadcast that caused the ANR. – casolorz Mar 21 '22 at 02:00
  • That line doesn't say the broadcast caused it. It just says the phone sent that broadcast. Post the rest of the data around the ANR, including the stack trace if any – Gabe Sechan Mar 21 '22 at 02:02
  • My problem is that it says `Stack trace not available` and this is my top ANR. Other than the title of the ANR, what other data would be useful? It is happening on all version of Android I support, various phone models. – casolorz Mar 21 '22 at 15:27
  • Don't tell us what it says. Actually post it. If necessary with some context around it., if you're not sure what may or may not be part of it. We don't know what you're missing off of a description when you don't know for sure what's going on. – Gabe Sechan Mar 21 '22 at 16:04
  • I added a screenshot. Is that what you wanted to see? – casolorz Mar 21 '22 at 16:43
  • Do you have any analytics to attempt to figure our certain user-paths that may contribute to this? – Martin Marconcini Mar 21 '22 at 16:44
  • I have firebase, however I suspect the ANRs that say `stack trace not available` do not show up on crashlytics. The Play Store Console doesn't give me any more info than this as far as I know. I've never reproduced this issue myself. – casolorz Mar 21 '22 at 16:46
  • Is there something in your app that would cause the Main thread to be blocked for over 5 seconds? *anything* you can think of? is it all java? kotlin? are you using coroutines, RXJava? Async Tasks? Any Services? Foreground Services? MediaPlayers? ContentResolvers? SQLite DBs? Those tend to be the _first suspects_. – Martin Marconcini Mar 21 '22 at 16:48
  • Yeah, lots of things, MediaPlayer, ContentResolvers, SQL, etc. What I'm trying to figure out is if this broadcast gives me a hint that this issue is happening at a specific time so that I can focus on what goes on at those times. – casolorz Mar 21 '22 at 16:51
  • Consider what happens when a MediaPlayer is playing and the screen goes off for a while. If the foreground service doesn't behave, or memory becomes an issue, it could die and depending how your app is designed, some components (media player being one of them) tend to be more delicate (given they are written in C++ and use JNI). I'd start by running your app with "Don't Keep Activities" checked and see if it still behaves; most apps horribly fail this simple test ;) – Martin Marconcini Mar 21 '22 at 16:53

0 Answers0