Hacker News Reader

Comment by Ninn | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

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.

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.

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

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.

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

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

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

Reply on news.ycombinator.com