Hacker News Reader

Comment by masklinn | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com