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