“This tool sucks ”
“Ugh WTF this is so stupid ”
These are just some of the things I have heard developers say over the years whilst working on Android. Sometimes they are trying to figure something out and there is not enough documentation, other times they are trying to make their tools do something and it just won’t work. Oftentimes, it is because they are expecting something to happen and it does not.
I know it can be frustrating, I have been a dev for more than a 12 years now after all. But then again, no matter how much or how loudly you curse the Android gods, where does that get you? Does it fix the issue? Does it improve the situation? I do not think so.
So what should we do then?
My answer has, and always will be, “have you filed a bug for it?”
Android has its own dedicated issue tracker organised into several components. This page enumerates those components and have some very good tips on how and when to file a bug.
It is important to select the correct component because (1) it makes the relevant team aware of your issue, and (2) each component may have a template for reporting issues.
When writing up a bug report, think of what you, as a developer, would find useful if it were you receiving the issue. “This app sucks” is way less helpful than “I have trouble logging in with my credentials that work on my computer”.
I try to be as helpful to the developer as much as I can because we both have the same end-goal: to fix a verified issue.
It might be time-consuming, but when the bug you reported gets fixed and other devs start to notice and benefit from it, it is very rewarding.
I might be totally wrong but I’d like to think my bug report helped nudge this along
Sometimes, my feature requests actually get built too!
Do you want to get your issues fixed too?
The trick is to make the bug report as great as possible. Let’s take this bug for example. I encountered an issue whilst running “Remove Unused Resources” from Android Studio and wanted to report it.
To gather the relevant information about my machine, I opened Android Studio and then chose “About Android Studio”. I then clicked on the copy icon in the dialogue box that appeared; that copies into my clipboard almost all the information asked for by the template!
I then provided a short overview of the reproduction steps; I try to follow the given-when-then pattern. Set the scene first to give the developers some context of what we are trying to achieve. In this case, I have provided a zip file of sample project that reproduces the error.
Next, I reported what I was trying to do and what happened as a result. If there are multiple steps that need to happen first, I enumerate them all in order. In this bug, I have also provided a screenshot so that the team can quickly verify that they have reproduced my error exactly as I see it.
And finally, I tried to provide as much as detail as possible. Were there scenarios where this does not happen?
It looks like Studio detects layouts inflated through the generated binding file’s
.inflate()method as unused. Views inflated using DataBindingUtil are not removed. (From here)
If it is a feature request, what would I like to see as the end result? What are the benefits of fixing this issue?
If I am beginning data binding, “user defined types” might be unfamiliar. (From here)
Are there any workarounds that I am aware of?
Found another way to fix it. Remove the spaces before and after the arrow, as such:
When I found a use case that was missed by the initial fix, I provided another sample project.
Really, a sample project is like a picture. It paints a thousand words.
EDIT (20190221): I cannot believe I need to say this but I will say it anyway: BE NICE. No one wants to talk to a jerk.
A good bug report is like a good story.
It presents the characters, introduces conflict, and finally, a denouement.
Be a good storyteller and hold your audience captive. After all, it’s the stories that make this world much more fun and interesting.