How to submit a useful bug report on Android
“Logcat or GTFO,” is a common phrase when you’re browsing through development forums for help with a problem. It might seem as though this is a rather harsh response to a real problem, but with developers being given hundreds of useless bug reports that they’re expected to deal with, it’s frustrating to have to request the same information over and over.
Not to say that some developers aren’t saying that just to be a jerk, there are total jerks out there, but there are useful and non-useful ways to submit a bug report and I’m going to try to give you the tools you need to submit a good one.
Here’s an extremely long guide on quality bug reports, and human interaction in general.
Be descriptive. B E Descriptive
Yes, that should be read in a cheer. There’s absolutely nothing more frustrating than when someone comes to you and says “it’s broken.” This requires a game of twenty questions in order to find out what “it” is, and figure out how it is currently deviating from how it’s supposed to function.
An example of this is “texting is broken on release X.” Well, how is it broken? When you open the text application does it crash? When you enter text does it crash? Is there just no send button? Does it attempt to send but fail to ever send? Do you write “I love you,” and the recipient gets “I’ve got a chemical imbalance that causes me to favor you over others,” etc.
And really, no developer is expecting you to come to them and say that when an incoming text triggers Android’s text notification event, and it’s from a non-contact number, that it’s causing an overflow exception in a spam-checking routine that just pops up the message “unfortunately, texting has stopped,” but a description of “when someone I don’t know texts me the application crashes” goes an insanely long way toward figuring out what the problem is.
Give them the logs
Assuming you’re dealing with development ROMs, or you’re rooted, you can easily provide system logs. You might be able to provide them on some versions of Android without root, but it’s been a while so I don’t know if this is possible any more (it appears it is).
You can ask what logs they want and send them manually, or you can preemptively include them in your bug report. You’ll have to decide what works here as some developers and some issues are easy to figure out, and some they’ll want every log of every event your device has.
You can easily give them the logs they need with Andy Log assuming you’re rooted, or you can use any program you feel you want to. Andy Log was just the last good log thing I’ve reviewed, there may be infinitely better.
I’ve checked and alogcat appears to work without root on Android 5.0.1, your experience may vary based on device manufacturer though.
Tell them what you’re running
There are about 19,000 distinct Android devices in the wild according to 9to5Google. While a ROM developer is going to have a pretty good idea what device you’re running except for details like carrier, expansion SD capacity and format, an app developer likely has no clue why the app they wrote that works perfectly on their system and most others doesn’t work on yours.
So let them know your phone type (EG HTC One M8) and specific variation/carrier (CDMA/Sprint) operating system (Android 5.0.1) stuff the manufacturer put on to pollute the operating system (HTC Sense 6.0 / Touchwiz). If you’re rooted include the ROM and kernel info if you can.
A couple of reports with decent information can turn a problem with a few random unrelated devices into “ah, that’s only crashing on Android 5.0.1 on CDMA carriers!” and then real problem solving can occur.
No really, tell them what you’re running
With the advent of below root-level applications like Xposed developers now have a mystery to solve. Is this application misbehaving because it’s being overlaid with something from an Xposed module? Has the API that their application uses been modified by something else? Did you use something that re-wraps their application so that it doesn’t auto-start?
Task killers, Xposed modules, startup managers, power or performance applications, memory managers, tweak apps, etc all can mess up another program. While each Android app is designed to play in its own sandbox, task killers yank the sandbox out from underfoot, startup managers may take the shovel out of the sandbox, your tweaks may be causing system instability making the sandbox walls fail and all the sand spill out, etc.
What can you do to reproduce the problem? What seemingly unrelated elements are there?
Something to remember these days is that nearly everything is connected in some way, and finding out the links can be maddening.
I was attempting to track down why an application I was running, AMIDuOS was crashing randomly. I’d note that every time it crashed within two seconds either before or after I heard my phone notify me some event had happened, with no real connection to the tablet containing AMIDuOS I’m playing with.
I additionally noticed that every time I posted a photo of my daughter on Instagram using my phone, I’d have a crash of the OS on the tablet within two minutes. The tablet wasn’t running Instagram.
What was happening was Instagram was posting to Facebook, Facebook was announcing to my daughter’s great aunt that there was a new picture, daughter’s great aunt was clicking like, Facebook on the tablet (and phone,) was picking it up and triggering an event, I’d hear the notification pop on my phone that Facebook demanded my attention, I’d shortly see the application had crashed on the tablet.
Facebook in this case was doing a fine job of crashing a virtual OS, and I was able to repeat with notifications and viewing one specific video.
What have you done to troubleshoot?
Got Xposed? Try disabling, still getting the issue? Overclocked your phone by 170% and experiencing stability issues in WhatsApp? How about stepping off the overclocking even it it does work fine in games and see if that doesn’t solve it.
Listing what you tried and failed or seemed to do something is great because then the developer doesn’t have to say “have you tried this? Well what about this? Ok why didn’t you tell me you’d tried this at the first? Are you… why do you have a knife?”
You don’t have to write a novel
A lot of users are scared of developers, especially in ROM threads these days. While submitting a decent bug report is common courtesy if you’re wanting the issue fixed on your device, you don’t have to worry about covering every base all the time.
A concise to the point bug report is good enough to start. Device, options, carrier, Android version, maybe external SD card info if you have it, and a brief description of the problem, how you can trigger the problem, and logs if you feel it’s appropriate.
If you feel it merits it, throw in the troubleshooting info and any seemingly unrelated events you’ve observed that appear to be associated.
Example of a short but useful bug report:
MailX client app crashes when you switch out of it while drafting a message to answer a text in the stock text client. HTC One M8, Android 5.0.1, Sense 6, CDMA/Sprint.
Doesn’t appear to be a low memory issue as I have X free. Have tried turning it off and turning it on again.
Include logs if you know they’re not on the same device you are. If you’re not sure get logs ready and provide if requested.
Don’t bow down
You’re running their app, ROM, etc. They’re not feeding you. You are asking them to fix something you probably enjoy and play with, play being the operative term for most of what we do on our phones if you get down to it.
They’ve written something and it makes your life easier, or more fun or interesting. You’d like it to function better. They don’t owe you anything so you’re asking nicely, however asking nicely doesn’t involve lowering yourself to your knees and saying “I’m just a poor unwashed end-user, ignernt of your developer god ways, please help my infinitely less intelligent self with your most holy of devil-upr powers.”
Chances are the developer actually wants to get the problem fixed. It doesn’t look great when a large portion of your audience runs your product and it fails. It makes them look bad. They want to know what the problem is and fix it. Then again maybe they don’t want to fix it and do want to look bad. Who knows.
However, don’t turn around and say “looks like you couldn’t code a cat out of a paper sack” as that’s just being rude.
Back in the HTC EVO 4G days I took 100 posts of a development thread and figured that roughly a quarter of the content was people bowing down to a developer to tell him that his product had failed. That did nobody any good.
Offering respect is one thing, lowering yourself another.
I’ll take my toys and go home
There are a lot of threats on Google Play that if bug X is not fixed they’ll leave, or that the developer is a moron for not supporting a phone nobody’s ever heard of, mmmm yeah… think about that. There’s not much useful in a threat.
Alternately some developers have said the same based on users, turning entire threads of followers into vigilantes against the perceived toy-supply-threatener.
State the problem, state the requested resolution, there’s no need to throw in any mention of going elsewhere because that’s implied.
Understand what is going on
With most developers you’re dealing with someone who wakes up in the morning, changes a diaper or walks a dog or both, heads to work, realizes halfway there they forgot a step in the morning routine, works a full day at a job that has nothing to do with development, spends some quality time with loved ones, and then stops spending time with loved ones so they can work on a project.
These projects are your apps, ROMs, etc. If there’s a note that says “support development by donating,” or the app is free, this is a hobby. Your giving of $50 doesn’t entitle you to anything more than warm and fuzzy feelings because the developer has now received 1/80th minimum wage for the work that’s gone into this project.
Sure the fix may be as simple as plunking in a new API, or changing a few lines of code, but the time one takes is the time one makes away from other activities.
Now pay apps and professionally developed major apps are a slightly different story. Use your judgement here.
Don’t listen to the old guy writing this
I’ve been following ROM and root development since 2010. I’ve watched fights between teenagers and grandpas break out over feature support requests. There’s no universally accepted way to submit a proper bug report, and unfortunately in some cases it may just be your phone.
Just avoid the negative, provide the information, and attempt to not be part of the problem but part of the solution.
And if someone jumps all over you, so be it. Move on to something else.
