6 ms·

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 cho

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 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.

deleted 12y ago
[deleted]
joelhaasnoot 12y ago
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.
- jspaetzel 12y ago
  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.
  - scrollaway 12y ago
    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...
nailer 12y ago
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
- jspaetzel 12y ago
  and also has not been updated since May 28, 2013
- tdkl 12y ago
  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
umustbjoking 12y ago
Why look so far down the list? https://code.google.com/p/android/issues/detail?id=82 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?
- kyrra 12y ago
  There could be patent issues behind preventing it? Maybe telecom companies telling Google not to implement it.
  - izacus 12y ago
    Then why doesn't someone just write that and close the bug?
- p_l 12y ago
  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
joshstrange 12y ago
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 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 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 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 https://code.google.com/p/android/issues/detail?id=1041) * Allow longer SMS (https://code.google.com/p/android/issues/detail?id=2318 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.
- bestnameever 12y ago
  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.
- digi_owl 12y ago
  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.

deleted 12y ago

[deleted]

joelhaasnoot 12y ago

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.

jspaetzel 12y ago
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.
- scrollaway 12y ago
  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...

nailer 12y ago

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

jspaetzel 12y ago
and also has not been updated since May 28, 2013
tdkl 12y ago
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

umustbjoking 12y ago

Why look so far down the list? https://code.google.com/p/android/issues/detail?id=82 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?

kyrra 12y ago
There could be patent issues behind preventing it? Maybe telecom companies telling Google not to implement it.
- izacus 12y ago
  Then why doesn't someone just write that and close the bug?
p_l 12y ago
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

joshstrange 12y ago

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 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 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 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 https://code.google.com/p/android/issues/detail?id=1041) * Allow longer SMS (https://code.google.com/p/android/issues/detail?id=2318 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.

bestnameever 12y ago
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.
digi_owl 12y ago
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.