Hacker News Reader

>We're trying to figure out the best way of telling users how to change their battery settings

The best way to do that is to remotely figure out on which devices the app is getting killed by sending data push notification messages and an in-app ack mechanism. And then show users an annoying popup message the next time they launch to make sure that they whitelist the app. We faced the same problem while building Flock, a team messenger and the details are outlined here.

https://hackernoon.com/notifications-in-android-are-horribly...

Samsung is part of OHA (Open Handset Alliance) & Others have access to Google Play Services; so Google can in-fact ask them to stick to the android specs.

Background services management was let loose in Android till 6.0; with doze mode & Job scheduler it has vastly improved. I think manufacturers shouldn't start killing apps themselves, as shaming apps which abuse background services, eat power inconsistently by displaying notification & allowing user to 'force stop' the app themselves does the job as in OxygenOS.

For all the flak iOS gets regarding multitasking, I was impressed by their uncompromising attitude towards background services from the start, even when I was bashing my head during iOS development to implement features on par with android version. The background operations should be completed within 3 minutes, but there's no guarantee that it will not be killed before that!

> We're trying to figure out the best way of telling users how to change their battery settings (which, for the avoidance of doubt, are usually on by default; and sometimes revert back to default on OS updates); some kind of annoying modal popup in the app before they begin a run, perhaps.

That seems to be exactly what TFA notes in various per-manufacturer segments (the color blocks with poop emoji are clickable and provide manufacturer-specific information and complaints) e.g. for Nokia:

> every [background] process gets killed after 20 minutes regardless it is actually supposed to be running and doing a useful job for the user.

or for OnePlus:

> Not only did users need to enable extra settings to make their apps work properly, but those settings even get reset with firmware update so that apps break again and users are required to re-enable those settings on a regular basis. […] On some OnePlus phones there is also a thing called App Auto-Launch which essentially prevents apps from working in the background.

Would it be possible to detect that the app was killed while engaged in such a situration as yours, i.e. similar how to systemd detects killed apps with a keepalive ping written to the fs while engaged.

Then on the next boot explain that you detected this, and guide the user to OP's page? Or is it way more complicated than so?

Whether this is possible or not is deeply missing the point as well as showing a vital misunderstanding about UX.

> as well as showing a vital misunderstanding about UX

The third party controlling your user's experience is forcibly killing your application while it's in use as intended. This somehow means you are misunderstanding UX?

People are suggesting ways to detect it and teach the user how to stop it, because they have no automated solution to this problem.

>a vital misunderstanding about UX.

What misunderstanding would that be exactly? App developer has to find a way to help customers work around an issue they cannot resolve themselves. Seems reasonable to me.

People were correct to downvote my comment. The tone was all wrong. For some reason, I take Android's many shortcomings as a personal affront. I guess that's what years of being a dev where all the piracy and user support are with Android issues while only returning a fraction of the profit compared to iOS will do to you.

The point is that this is entirely Google's fault and yet it's the devs who have to clear up the mess and take the blame, or alternatively we bombard the users with technical fixes and explanations. Quite clearly neither of these options is where we should be with a mature OS on a mass consumer device.

Now I'm getting all angry again just thinking about it. Time to up my meds.

As TFA notes (in the Nokia section, possibly others):

> This app kills apps in the most brutal way we have seen so far among Android vendors.

You can't detect that your application was kill -9'd. I don't think you can detect that "PowerSavingAppG3" is running either (I'd guess it's running as root and you're not), so you can't even infer from its existence that your application will be traumatically killed in short order.

I think you are reversing what the parent comment meant. You can continually write to the sandboxed filesystem of your app, say write the current timestamp every 10 seconds, and a status of if the app exited gracefully (which you can control). Then when restarting the app you check if there was a timestamp written in the last say 2 hours and no graceful exit then you know the app was terminated and can explain that the app didn't crash but that the OS vendor force quit it.

How do you differentiate an apps crash from an OS forceful kill?

Both would show a last good status and no good exit.

Presumably you would have an error log in the crash circumstance, unless it was very seriously broken.

You can detect which model of phone the app is running on, right? On these problematic models you should probably just assume that the app got killed in that circumstance.

Yes, but that's not a detection or even an inference, it's a loose assumption.

App crash leaves a crash dump generally. Also, if your app crashes too often on some oems, the phone will automatically clear the local data, to "fix" it. I forget which one did it or I'd shame them directly.

Please don't! This will wear out both the battery and the flash memory for no reason. It's exactly this kind of sloppy coding that made these manufacturers decide app killers were necessary.

Sure you can:

1. Create an empty file when the application launches

2. When the application terminates, write the reason for termination into the file.

3. When the app launches again, read the file. If it was empty, then you were SIGKILL'd, or you crashed.

A kill -9 wouldn't give you a chance to write the reason for termination to a file. It's the equivalent of the OS saying "you have already run your last CPU cycle, you will receive zero more CPU cycles, good bye".

You might be able to write the word "bad" in a file, and then clear the file if your app closes nicely. If you start and find the word "bad" in the file, then you know you were killed. A slight variation of what you suggested.

Which is why the absence of a reason in the file is indication it was killed.

You're right.

That's what the empty file tells you.

> you were SIGKILL'd, or you crashed.

"Might have been killed, might have crashed" is not helpful, and the inability to know is the very issue at hand here. You can't know whether your application crashed, the user forcefully killed it or you fell afoul a background killer. What now, do you start spamming the user anyway?

Most of the time when you crash there is a signal associated with that which can be handled. If you application terminated normally under an error case, then that has to be captured through the same mechanism.

Android doesn't offer any signal of normal termination. Your process gets killed when the OS needs memory for some other app.

There is a way to detect it but it's hacky. You need to use fcm xmpp to send data push notifications with delivery receipts and also send an acknowledgement from the apps background service. Devices where you don't get the app ack have an app which is force killed

Details outlined here : hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a

That sounds way over-complicated. Why not just keep a flag in the database that's updated during the Activity lifecycle?

Sorry, I didn't understand. We need a service side service to keep track of ack's that we received from the device. I am not able to understand how a db flag would help.

If all you need is to detect it on the next boot to notify the user, as the prior comment said, then for example:

onCreate - check "running" flag, then set to true

onDestroy - set flag to "ended"

If onCreate saw the flag was already "running" before it was set, then you have a crash to recover from or a kill to notify the user about.

Have an app priority defined by user

If Play Store allows to mark the app as incompatible with specific models, that might be the best recourse―since the app can't function properly on those phones anyway.

Isn't that basically a death knell - especially if you're not a top 10/50/100 app - when trying to reach customers? If you wait until the customer has downloaded your app, you'll probably have better retention. If you mark your app as incompatible, people won't even bother to install even though there could be a work around. You'd basically be trying to send a message to users about device manufacturers and the Android operating system while killing your own numbers.

Not even that: marking it as incompatible will render the app listing invisible for those devices (in both top lists and searches), and if you do reach the listing directly then the install button will be disabled.

Pulling the nuclear option for something with clear workarounds (or which only impacts peripheral features) is unacceptable.

I don't think it's just that. As an app user I can say I'm tired of apps running in the background that don't need to be, and there are tons of them that do it. Maybe Android needs to be more refined in how it handles apps that run in the background but as a user who prizes control of my phone I also think developers need to think twice about what they leave running in the background and why.

Seems like battery management has the traditional firewall problems.

Eg. Blocking legit services and obscure errors popping up.

Ps. Love zombies run