Hacker News Reader

Comment by jspaetzel | Hacker News Reader

I'm not sure if you guys actually even looked at what these requests were but most of them are irrelevant and rightly so... obsolete/irrelevant features. To choose one particular example that stood out to me from the first page with 198 stars: https://code.google.com/p/android/issues/detail?id=1140

I wont even get started on how much information this is lacking for it to be actually executed. The point being that most of the ones in the list have not even been touched in over a year and more closely resemble a Christmas wishlist than actual issues. They should be closed since they are cluttering up the workflow of real problems and it would be a waste of an engineer's time to respond to them all adequately.

If they are still relevant a year later maybe you should go through and do something productive like creating a new issue with updated details.

View on HN

Good job cherry picking that ticket! Also right in your comment "first page with 198 stars", let me direct you to the title of this post "Many Android bugs with 500+ stars closed as obsolete on December 25". 198 !>= 500, if YOU ACTUALLY EVEN LOOKED at what these requests are you would see a number of them are VERY relevant:

* iCal .ics support (https://code.google.com/p/android/issues/detail?id=1257)

* Phone burning battery while idle (https://code.google.com/p/android/issues/detail?id=22878)

* API to access in-call audio (https://code.google.com/p/android/issues/detail?id=2117)

* Unable to connect to hidden SSID (https://code.google.com/p/android/issues/detail?id=1041)

* Allow longer SMS (https://code.google.com/p/android/issues/detail?id=2318)

> If they are still relevant a year later maybe you should go through and do something productive like creating a new issue with updated details.

I wouldn't be surprised at all if the people filing these bugs or replying to them just gave up after waiting multiple years and switched to a custom ROM that does address the issue or even switched OS's.

Sadly the battery issue is painfully generic, and the built in battery UI hopelessly inaccurate.

I have experienced that the UI claimed that Play services were eating battery. But when i brought up a good old top report and looked at CPU time i find that Facebook was blocking the CPU from reaching sleep state.

killed the Facebook process and the problem went away rapidly.

And recently i have seen Plume having a similar issue. I can actually observe the CPU time rising when it is nowhere to be found outside of the top readout (no entry in the task switcher etc). But checking the Android battery readout i see nothing about Plume being a battery hog.

I think that's the real problem. A tool designed to help you determine what is chewing up your battery seems to be fundamentally broken and is not being addressed.

I also wouldn't be surprised if they have switched phones and are no longer experiencing the issue. For instance the phone burning battery while idle was made obsolete over a year ago and no comments have been made in the last year either. Maybe it should be marked as obsolete.

I do support for an app with several million downloads. While it may not make sense on a technical level, it's really powerful for your app and your users to reach out and explain this. For us this is a quick two line reply that the wish is on the wishlist and may be picked up later. Many of the wishes you get are completely logical, some are for very specific use cases, and some are completely off topic. We still track them in a list, and each ticket becomes a vote (we happen to use Trello). It gives us a great view of what users want, miss and would like to see. And yes, our engineers also answer support emails.

I think this would be great if they could do that.. but when it comes to millions of users I dont think even google can handle that much feedback publicly without falling seriously short. It's amazing they are able to address as many issues as they do, after all there are like 14000 open issues right now in that tracker.

You're focusing on the wrong numbers. "Millions of users"? You're talking about 14000 open issues, a FRACTION of which were closed.

The android team is large and the closed bugs surely have been reviewed by the team before being closed (otherwise they're just closing randomly in which case: WTF?). So really, doesn't it make sense to give an actual reply for even just the more popular ones? We're not talking about millions here, we're talking about dozens...

Why look so far down the list?

https://code.google.com/p/android/issues/detail?id=82

Bug 82. Number one on the list. Been open 6 years. Patch offered and integrated into CyanogenMod for years. Y u no integrate the patch Google?

I think the real issue is that nobody[1] really cares about ad-hoc networking, especially in anything linux related. I recall times when NetworkManager team, back then the only "nice" tool for wifi, outright claimed they don't ever care about ad-hoc (or even static IP).

Similarly, barely anything appears to support ad-hoc, and I am not sure if many current users recall that it exists at all…

[1] an obvious hyperbole, but that's the feeling I get

There could be patent issues behind preventing it? Maybe telecom companies telling Google not to implement it.

Then why doesn't someone just write that and close the bug?

Conversely, the first one I saw was support for calendar attachments (.ics files). Which:

a) GMail sends

b) Google Experience devices still can't recieve

They actually open them in the browser now, at least it worked with Chrome, who imported the .ics with Google Calendar website. Still hilariously clunky though and surely confusing to the user.

But hey at least dat Material design amirite ? /s

and also has not been updated since May 28, 2013

Reply on news.ycombinator.com