Question: Is DeadSystemException related to the issues mentioned here?

[AndroidDeveloperLB]

I've noticed this exception from time to time, and I've read on StackOverflow there is nothing I can do, as it's probably harsh battery optimizations.

Is it related here?

[petrnalevka]

I think it is. In fact I'm seeing a much increased number of those exceptions across my apps. So maybe this is some new kind of app killing in production. I will keep an eye on which vendors are typically producing this..

[AndroidDeveloperLB]

Wow this was a quick answer. I think I saw it on Samsung and LG mainly, but also on various others. The thing is that it occurs on random places on the app, so it is very suspicious and can't be from my app.

And it's very annoying to see it because each time I mute it on Firebase Crashlytics, new ones come as it thinks it's a new issue (because it's on some other random place).

I wish I could at least mute them all.

[petrnalevka]

I now went trough ~50 last DeadSystemException reports and you are right that Samsung is dominant but this can simply reflect the landscape, but I'm also seeing Pixels and Motorolas, which we do not know about any app killing processes on, but it may be coincidence as I only have few of such reports. Than there are OPPO, 1+, Xiaomi and few other exotic Chinese vendors, so devices where we would expect such issues..

[AndroidDeveloperLB]

There are Pixel devices there? Could be rooted with custom roms? I don't think I saw it on Pixel devices yet.

[petrnalevka]

Ok I checked that and I have exactly 10 cases of Pixels involved in a DeadSystemException..

9 of them are the activity recognition engine - so I guess this is specific to this use-case IMHO..

Only on unrelated case of DSE on a Pixel:

RuntimeException: Unable to start service com.urbandroid.lux.TwilightService@71788c0 with Intent { act=com.urbandroid.lux.action_command_restart_on_low_memory flg=0x4 cmp=com.urbandroid.lux/.TwilightService (has extras) }: java.lang.RuntimeException: android.os.DeadSystemException

And this seems to be related to low memory..which probably is a reason for dead system even on Pixel I guess..

I also checked the Motorola cases and I only have 2.. both of them when starting a foreground service..

So I guess the theory that this is a battery optimization is still quite probable.. at the moment I did respond to users by explaining the issue and trying to get more info on what was happening with the system - but never get anything useful back..

Now I will approach this by sending them a https://dontkillmyapp.com/samsung link mostly..I guess this happens on Samsung them the system puts the app on the Sleeping apps list - but just a further theory so maybe I will get some feedback if this helps..

[AndroidDeveloperLB]

@petrnalevka Wait, how did you communicate with users who got this crash on Crashlytics ?

[petrnalevka]

We are using our own custom error reporting system, whenever a crash occurs we open the email client with the details including a full logcat, so we can communicate with the affected users and get more details on issues.. we do not use Crashlytics.. We use this system since 2010 in our apps and it is very effective especially because we have contact with users..

[AndroidDeveloperLB]

@petrnalevka How do you open the email client, if the app is about to crash... Especially with this kind of crash? Also, I think it's better to have both. Not all users will send you an email.

[petrnalevka]

No problem, you can use the top level exception handler in Android for that which can start an activity after the crash without issues..

And we have both, as you say the emails are just part of the picture - although the more useful one..

Than we have standard crash reporting in the Play Store console to see occurrences - how much users are really affected with a particular crash..

[petrnalevka]

"Especially with this kind of crash?".. this depends, normally we open the email straight away, but if do not manage that we will open the email client at the next app start.. although I do not know which case is this..

But from our thread here and from feedback from users who report that this happens suddenly and they do not observe any other issues with the system .. I think it is really probable that this is a app killing mechanism and at this event the system is in fact in great condition definitely not dying :).

[AndroidDeveloperLB]

@petrnalevka I see. May I ask how much memory the app you work on take normally? Maybe the OS prefers to do it for apps that use a lot of memory.

According to what I've found (using the "profile app" feature of Android Studio), if you create a new project and run it, it already takes about 60-80MB of RAM on Pixel 4 with Android 11, and adding Admob banners, it will take another ~100MB. Even though I've worked hard on my app to be efficient, for some reason, in total, it takes 300MB. I tried to optimize it further, but it didn't change. I think some of the memory is cached by the OS or other dependencies I use (Firebase etc...), as the graph says it's mostly "native" and also "graphics".

I wonder if moving to native ads will reduce this memory usage, and if it's worth it (fill rate and how much it pays in general compared to banner ads).

[petrnalevka]

If you look at https://dontkillmyapp.com/ at the top vendors there memory isn't the issue IMHO, typically they simply kill any app running for more than ~20 minutes.. I don't know it, but I guess higher memory use will make it more likely to be killed when system runs low on memory which is the normal scenario when the app can get killed..

I expect the 60-80 MB after start up is reserved memory by the VM - so this does not need to be memory the app really physically uses.. also 300 MB may be all the references the app made in that time - but if garbage collected I guess this would drop significantly.. so I guess you should not look at the peaks but rather at the minimum in the chainsaw chart..

Regarding ads I guess you can move them into a separate process..

[AndroidDeveloperLB]

@petrnalevka My app runs more than 20 minutes. As for memory, I tried GC, but it didn't drop much at all. As for ads, I don't think this is possible using the API of Admob. It's within the Activity/Fragment.