Among all the new additions to Android P including new navigation gestures, Slices API, and new biometrics API, there are some other changes which may also be impactful in a more subtle way. One of these is the removal of App Not Responding (ANR) dialogue boxes for foreground apps. The ANR dialogue appears when something is preventing the main UI thread from responding. When this happens in Android Oreo or below, the ANR dialogue is shown to the user to let them know. Now, in Android P, the application will just crash without any kind of notification for the user.
You know how some people will insist that iOS applications are more stable than Android applications? That’s because on iOS, when applications crash, they just… Vanish. No dialog, no notification, nothing. Android will now be adopting the same behaviour, which, while less informative, does remove a silly dialog that you couldn’t really do anything useful with anyway.
Good move. Dialogs you can’t take any actions with are useless.
As a moible developer who writes both iOS and Android apps, and I use something really scientific like Crashlytics to measure my own apps crashing pattern.
I can say with certainty that iOS app, with simular user base (size-wise) times as much users crash 40% less than it’s Android counterpart.
Android just shows WAY more random crashes than iOS. I do not know why, but it’s a fact that I have experienced with every app I have written / supported throughout the years.
On my game, crashes have mostly three reasons:
– file system access – it asks user for permission but sometimes user won’t give, or simply android won’t understand.
– very strange device or odd android version behaves badly.
– random crash – something like updating the screen or sound system gives an exception from lower API to SDL I use, and bump!
Random crashes is around 10% of total crashes, most are due to different pieces of hardware running different pieces of operating system. And that bad thing is that, those, I simply can’t fix.
On Error Resume Next….
A stupid solution to shitty software: just pretend everything is fine and the user doesn’t need to know something went wrong.
When apps just ‘disappear’, it’s infuriating – i’d like at least a small informative note that shit hit the fan.
Agreed. I don’t want my running app to vanish without a trace, especially when is a slow starting app or one I want to stay running .
To be fair, this isn’t On Error Resume Next, this is On Error End.
Indeed… I used the analogy because it’s a similar type of thinking that made “On Error Resume Next” so popular in VB apps… It’s not “error handling”, it’s just “error ignorance”.
Agreed. On iOS, you can at least go to the system log and look at the error there, but I’d still like to see something indicating a crash so I know to look.
Not to mention that on slow phones (or on when there is lots of syncing going on in the background) your foreground app may have its main activity “not respond” for a while. Up until now you could just allow the application to continue using the relevant option in the App Not Responding dialog (yes, that dialog has a use Thom) now the app will be forcefully killed by the OS without the user being given a choice. Great.
Edited 2018-05-16 00:29 UTC
Google does copy Apple! I knew it!
</sarcasm>
While a dialog box without any possible action/recovery option is pretty useless in this case, there should still be some notification to the user.
I fired up Android recently on a spare device and one service I had installed would crash about every 30 seconds. The flood of dialogs was terrible and disrupted workflow. But obviously the system should notify the user something has gone wrong. Otherwise your apps/services are just disappearing without explanation and that’s a huge bug.
Ideally, there should be a message posted in the notification area letting the user know a crash happened, without displaying a pop-up that breaks flow.
That’s another thing that drives me nuts: Restarting a crashed app automatically without giving the user the chance to make it go away.
Any non-critical “service” that is set to automatically restart on failure needs some kind of kill switch to prevent it from taking control away from the user.
I’ve had multiple situations where I get into a google play services failure/restart loop, interrupting my ability to actually do anything about it. In at least one of those situations, I had to reflash the ROM (it was a custom rom, and i had recently installed it) – in another situation, I had to use ADB to go in and fix the problem via shell. What a lovely user experience.
I’m ignorant, as I’ve not owned many Smartphones, and tend not to run many apps on the one I do own, a Blackberry, thus cannot remember crash behaviour.
However, surely the point of a crash dialogue box is always to alert the user that they might have lost data, or might need to restart the app, no? Its information you can choose to act on be restarting it or going into a blind panic about losing something important.
As I say, this is from someone who doesn’t actually know how apps on Android or iOS really work. So I am interested. Why would it be OK to casually ignore crashing applications?
Edited 2018-05-14 19:03 UTC