Posted on

Most Common Android Bug


common android bug

There’s two basic bug types up there that I consider: ones that appear on your device during development and ones that appear only on other devices when you have you app up there on Play Store already. Let’s get deeper into each one and in the end I have one bug that’s super easy to miss out on, but it belongs to the first category.

First Category

This one is the percent category and everybody faces them almost every day during early development. Why it’s perfect, because you catch bugs in the perfect state: debug build, you have your Android Studio logcat by your hand.

It’s very easy to trace back line from your source code that caused it. Then you just fix it or Google how to fix it.

common android bug

And of course by no means you’re not going to publish an app that you know crashes at a certain screen.

Here’s the funniest thing about bugs: they do exist despite all your attempts by not trying to discover them. Or refusing to do testing. It’s like trying to convince yourself that everything’s fine, scared to open the door. Here comes Schrödinger’s cat theory comes to mind, which I truly dislike, there’s one just reality. That theory is more about perception. Which leads us to the second category

Other Users Have Them

This one is the worst. At the very moment when you thought you fixed your last bug and thought your app 100% bug-free – there’s people having crashes!Obviously, you don’t expect them to have errors at those places, because it works totally fine for you. How do you fix or test that you fixed it?

First of all, I always try to recreate the bug, this leads to two subcategories: ones that possible to recreate, ones that not.

Possible to Recreate

One of the most common here is Android OS version. And the most obvious is pre L version and 6.0. If you’re having L+ version that you use during development, which is most likely, always test on pre L phones. Preferably for every build.

There’s quite a difference between those API’s and you can get errors on pre L when it works totally fine on L+.Then there’s 6.0 with runtime permissions, which you could’ve missed to ask at run time. And there’s also 7.0 FileUriExpossed one.

(Almost) Impossible to Recreate

Those you can’t ever recreate on any Android version, those are the worst. How can you kill what’s invincible? No, that’s from some other area! How can you fix a bug that you cannot recreate and assure that you fixed it?Most likely you’re having a log with device model, so you could get one of those somewhere and test on it.But it was a device specific bug, there’s possible cases that’s it’s an account specific bug as well.

That’s why you should trace the account that you got that error on with Firebase Crash Reporting or Crashlytics or any other possible api’s. Ain’t saying it will be easy.For example if you couldn’t fix that bug – you could wrap that code bloc with try/catch and it catch send all the needed data to your crash tracking tool for you to process later. Hence, Analytics, Crashlytics etc. Then publish that update and wait for reports

Weird Bug

This one actually belongs to the first category, ones that can appear on your device. But you don’t get those in your regular flow. They appear after you open your app after a while. Or they could appear in like 3 days after you used your app.Know already what that bug is? I”m taking about state restoration. This one can go into Activity Life Cycle bugs, but in occurs only on configuration changes (device rotation) or on state restoration. When Android kills your app after it’s been in background for a while.

So what happens after few days in background or maybe hours (if your app is heavy on memory), Android kills your app. But it’s still visible in latest apps. When you reopen it will crash or UI will be in some messed up state. And I’m not talking about just lost EditText inputs. That’s a restore state bug and fortunately you can recreate it just by rotating/changing your phone.How often is your activity fixed to just portrait mode? I truly understand, you don’t want to build landscape layouts or it just makes no sense for some activities. Well, at least for development purposes remove that restriction.

Changing orientation for every activity is just as important to test as everything else.You can read this tutorial to get into more details.

Testing is really important part, I think in few following posts I’ll write more about testing

Thanks for reading, don’t forget to subscribe, follow me on Twitter, Facebook, G+ and share with friends if you think they will benefit from it!


  • Andres Garcia

    Nice job.
    I knew about that rotation screen trick to trigger some bugs but I’m sure many Devs don’t.
    Reading this article gives me an idea for one of your future one: avoiding Memory Leaks.
    At work, I can see way too many Devs still passing the Activity as a Context rather than a WeakRef of it or the ApplicationContext whenever possible.
    So in my humble opinion, it’s good to know from the beginning what not to do, why and how to chase Memory Leak with Android Studio (Canary Leaks is not as precise).
    Just an idea…^^
    Cheers

    • You damn right haha. Working on post in this direction!

      Thanks Andres!