
Many Android bugs with 500+ stars closed as obsolete on December 25 - diafygi
https://code.google.com/p/android/issues/list?can=1&q=status:Obsolete&sort=-stars
======
cryptoz
Google's handling of Android bugs is unpleasant and difficult to swallow. The
QA seems minimal and little or no attention is paid to user filed bugs. The
barometer on the Nexus 5 is still broken after a year+ of software updates.
Infuriating. The bug with hundreds of stars is marked obsolete! The barometer
is still broken.

I'd like to debug and fix it but other things have priority, and I don't feel
confident that if I were able to fix, that my change would be merged. Oy!

[https://code.google.com/p/android/issues/detail?id=62938](https://code.google.com/p/android/issues/detail?id=62938)

Edit: I should mention, they did fix part of it after about 6 months in the
wild (the part where the barometer crashed _all the sensors_ ). What they
haven't fixed is that the barometer doesn't actually reliably work.

Edit #2: Interestingly, I might have to eat some of my words. I'm just testing
on 5.0.1 for the first time and haven't been able to reproduce the issues
present from 4.0 through 5.0. Maybe it's actually fixed in 5.0.1!! Of course,
I've only been testing for 10 minutes and it could still surface. For
reference, the remaining bug is that the barometer periodically reports
seemingly random values. 5mb, 730mb, 1004mb, 740mb, 300mb, 3mb, 750mb, etc.
Now it seems to be stable and generally reporting the same values.
Interesting.

Edit #3: A pastebin showing that it seems to be working after a few minutes of
use. [http://pastebin.com/RdBqbWzC](http://pastebin.com/RdBqbWzC)

Edit #4: If you're curious why I care, it's for PressureNet to make a better
weather forecast :)
[https://play.google.com/store/apps/details?id=ca.cumulonimbu...](https://play.google.com/store/apps/details?id=ca.cumulonimbus.barometernetwork)

~~~
mfisher87
Most major companies, to me, seem to be following Apple's example and forcing
a shorter support lifecycle for each device, expecting users to simply replace
their "obsolete" device with the newest one.

~~~
moca
Among major companies, Apple did a better job with supporting old devices.
Google Nexus devices become completely out of date after 2 years (too slow to
run latest software, and too hard to get hardware repair support). Software
wise, Apple could have done a better job as the newer version of iOS is indeed
bloated and doesn't run well on old devices. On the other side, Microsoft did
great job on supporting Windows XP for over a decade with wide variety of
hardwares.

~~~
bad_user
My Nexus 4 (released Nov 2012) has officially received the Lollipop upgrade
and is working very well. I barely have reasons to replace it.

Apple does indeed a better job at supporting older devices, however new iOS
releases are basically unusable on devices older than 2 years. I have for
example a 2-year old iPad 3 and iOS 8 is usable on it, but for iPhone 4S or
IPad 2 the upgrade turned usable devices into unusable ones.

~~~
digisign
My ipad 2 is running ios 8.1 well and i'm posting with it right now.

~~~
hubot
iPad 2 is one beast device, live through so many updates and is actually very
usable.

~~~
MBCook
It's showing it's age.

The real problem is they're still selling it brand new (in the form of the
non-retina Mini) and with Apple's policy of supporting devices for 2 or 3
years that means the device will get six years of updates, even though it's
already aging badly at this point.

------
fidotron
This should be just another wake up call to the fact that Android just isn't
open. Unless you're inside the OHA your view doesn't count, and even then you
have to go along with Google's vision of the future.

End users might think they have it bad, but the development experience is
basically an exercise in dealing with whatever hyped up shiny unfinished turd
is floating down from on high. It's a shame because some aspects of the system
are really damn good, but there is just so much crap.

Having seen all this develop has persuaded me that the future is lower level
APIs. On the web that means asm.js, Canvas, indexeddb etc. (discarding HTML
and CSS), and on Android it means C++ and OpenGL and staying the hell away
from as much of the higher level parts as possible. (Bonus points for
increased code portability). The reason for this is the lower level ones seem
to reach stable predictability much faster. It is better/easier to bundle any
high level UI toolkit in the application itself than to have to support
rendering on four different versions of the toolkit.

~~~
TillE
I'm not sure what you think "open" means. You're still free to fork Android
and do what you want with it. Google's negligence in fixing a variety of
issues doesn't change that one bit.

~~~
fidotron
You aren't really free to fork it at all.

Forking the SDK is explicitly not allowed, but the killer is if you want to
make one device which carries the Google Apps you have to agree that all
Android devices you make will. (i.e. you are forced to bundle Google Play
Services on all devices). This is why Amazon do what they do and it remains a
separate ecosystem.

~~~
bad_user
> _Forking the SDK is explicitly not allowed_

That is not true. The SDK's source-code, like much of Android, is licensed
under the APL 2.0 license. The SDK license you're referring to and that has
restrictions applies to the binaries, as packaged and distributed by Google.

------
allendoerfer
Enterprises are able to pay huge maintenance fees. Single consumers are not
and game theory teaches us, that they are unable to unite to get it (free
rider problem).

So I fear, that we need stronger consumer protection for software products. I
do not know the situation in the US, but in the EU we have a mandated 2 year
warranty for almost every product with very few sensible exceptions (food and
the like).

We need the same for software. Features that are advertised have to be
guaranteed. Of course software has bugs, so the law has to be about software
getting fixed, not being perfect. Actually that is the same with physical
products as they do not have to be replaced, they can be repaired, so this
does not even make a difference.

There has to be some lightweight definition of non-functional requirements.
This one is difficult and dangerous as the big players could unite and
regulate the small ones out.

Related to that, double or triple the warranty periods. This is not so much an
issue with smartphones and the like, as they become obsolete by superior
successors or fashion, but with stuff like printers, vacuum cleaners or
electric toothbrushes. Of course, this would hurt companies like hell and will
never happen. I imagine in the long run, it would actually be super beneficial
to those, who remain, because it would create a brand "Sold in the EU" much
like "Made in Germany" with all the mythos of the deregulated Autobahn but the
highly regulated warranties :D

~~~
maccard
> Related to that, double or triple the warranty periods.

I'm not convinced that this solves anything. When you buy a 50 euro/dollar
vacuum do you expect it to have the same life expectancy as the 500 dollar
vacuum made with higher quality parts? If the company is required to provide a
6 year warranty for a machine that they estimate to last 2 years, they will
simply stop producing the cheaper vacuums, meaning everyone who wants a vacuum
has to now pay 500 dollars. My knowledge of Vacuum cleaner economics is
limited, granted, but I can't see how this works out well in the longer term
for anyone, other than the people who would have anyway purchased the more
expensive product (that normally comes with a lifetime/extended warranty from
the manufacturer anyway)

~~~
madeofpalk
That's why Australian consumer law says that things should remain working for
a 'reasonable' amount of time.

The law makes distinctions between a manufacturers warranty (e.g. Apple says
it's devices come with a 12 months warranty, which is true and legal.) and,
and the manufacturers/retails obligation to resolve defects (Apple will
repair/replace devices for free even after that 12 months).

The law is purposefully vague around this (I believe it says products should
last for a reasonable period of time, depending on it's price and perceived
quality), and different retailers/manufacturers honour this in different ways.

This lead to some interesting situations, like Apple covering mobile devices
for 24 months since purchase OR last repair/replace date, so it's actually
possible to get infinite warranty on a device if you get to replace every 24
months.

------
gcb0
all my bugs from android 2.3 (still heavily used in the us and out) up to
android 4.2 were closed as obsolete.

several are somewhat fixed on 5.0 (most by removing the feature) but nothing
about support even nexus devices from 2.5 years ago.

3 were security ones confirmed by a few comments.

I've been getting obsolete emails on my low profile bugs since November all
the way to Dec 25...

Google just gave up. i think nobody there care about users after yahoo stole
JBQueru. they now focus exclusively on profit and easy/fun work (i.e. full
focus on new versions because maintaining old, stable software is the job of
interns)

~~~
gst
The last device sold by Google that now runs an Android release of 4.2 or
earlier was (afaik) the Nexus S - which was released in 2010. I think it's
reasonable to stop support for a particular device after something like 4
years.

Yes, there are other 3rd party manufacturers that sold devices based on such
outdated versions up until recently. But why should it be Google's task to
provide updates for these devices? That sounds like something that the
manufacturers are supposed to do.

~~~
microtherion
That depends on whether you see Google's role in the Android ecosystem as
primarily an OS vendor or as a hardware vendor. In the latter view, your
position certainly seems plausible.

However, if one sees Google as an OS vendor, then, considering that 60% of
Android phones are running 4.2 or older (according to
[https://developer.android.com/about/dashboards/index.html](https://developer.android.com/about/dashboards/index.html)),
supporting somewhat older phones would seem to be desirable.

~~~
bestnameever
They do support them as much as they are able to through play services.

The fact remains is that many of those phones are unlikely to receive updates
through 5.0.. How are you supposed to support them if the hardware vendors are
unwilling to update them?

------
edent
6 years after being reported, Android _still_ doesn't support downloading .ics
files.

[https://code.google.com/p/android/issues/detail?id=1257](https://code.google.com/p/android/issues/detail?id=1257)

Makes it impossible to add events from websites.

It's very frustrating that there doesn't seem to be anyone at Google who looks
at bugs. It's all about creating "cool" experiences without the tedious work
of fixing bugs.

~~~
runn1ng
That seems like a feature request, not a bug, to me.

~~~
hayksaakian
If you can download everything else normally without an error, but downloading
a file with .ics crashes then its a bug.

If you want special functionality associated with .ics files as you download
them then that's a feature.

Which is this?

------
krschultz
At some point in a long living project, you have to declare some bugs are
#wontfix. You are just lieing to yourself if you think you will ever get to
the end of the bug backlog. It also can become an anchor, the team is focused
solely on fixing bugs here and there instead of moving the ball forward (and
hopefully fixing more fundamental problems along the way). I've made the call
to mass close tickets like this. It's never fun, but sometimes you have to do
it.

These ticket seem to fall into two buckets.

1) Pre Android 5.x bugs. I can understand why they don't want to invest here.
Effort is definitely better spent trying to get more devices onto Android 5.x

2) Feature requests for apps. I bet a lot of these are either on a roadmap for
a future version of Android, or are simply never going to be added.

~~~
diafygi
Then mark them as WontFix with a comment explaining why. Marking Obsolete
without comment and restricting further comments is a huge slap in the face to
your biggest supporters (those who went through the trouble of trying to
contribute positively by filing/commenting/starring the bug).

~~~
mrec
Yup. They did the same thing with Chrome a couple of years back - just had a
bot go through and close everything older than some threshold en masse. As you
might expect, I don't bother reporting Chrome bugs any more.

~~~
keithpeter
Suppose the Chrome team closed everything older than some cut-off date but
explained why (perhaps on a blog) and encouraged people to open new tickets
about issues that carried forward to currently supported versions.

Would that gesture have kept you motivated to report bugs?

~~~
mrec
IIRC there was something (unconvincing) on a blog, and they did (nominally)
encourage people to open new tickets for issues they cared about. No, that
didn't keep me motivated. Words are cheap; actions speak louder. If they
_really_ wanted to encourage people to open tickets, they wouldn't robo-close
them.

There are a lot of ways they could have avoided that mess. Keepalive anything
with recent comment traffic is one that springs to mind, since those comments
are often along the lines of "yup, still an issue as of version X.Y.Z" or
"Hey, it's been N years, any word on a fix?".

~~~
drdaeman
Auto-closing is not an issue and could be implemented in community-friendly
fashion. Just make a bot post "this ticket is dated, leave a comment if it's
still important and revelant" then wait a few days and close only ones that
don't get much attention. Simple and user-friendly.

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

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

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

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

------
mik3y
It's not a shock; if anything I'm surprised they didn't shut down the issue
tracker altogether. It's been little more than a glorified pastebin of
generally poor-quality, unreviewed reports.

Perhaps this is a sign someone's going to start triaging things, but I'd doubt
it..

------
josephhainline
You say "bugs" but many of these are clearly feature requests. There's a
pretty big difference.

------
munchhausen
This is very unpalatable, and makes me reconsider whether my next phone will,
again, be an Android device.

This sort of "fuck you" attitude towards legitimate feedback and valid bug
reports from users doesn't bode well for Google, and indicates that any talk
of "openness" of Android is just that - empty talk. If the Android development
process is going to be a 100% closed, cathedral-type endeavour, I might as
well get an iPhone.

~~~
seccess
Well, the only reason you can make this criticism in the first place is
because Android has an open issue tracker. You can't criticize iOS for doing
this, because you can't see their issue tracker.

I can just as easily change my search query and show you all the bugs that
were in fact fixed [0]. That seems to counter the claim that "the Android
development process is going to be 100% closed". I'm not saying one OS is
better than the other, but your comment seems more like angry ranting than a
well thought out response.

[0]
[https://code.google.com/p/android/issues/list?can=1&q=status...](https://code.google.com/p/android/issues/list?can=1&q=status%3AReleased&sort=-stars&colspec=ID+Type+Status+Owner+Summary+Stars&cells=tiles)

~~~
userbinator
_You can 't criticize iOS for doing this, because you can't see their issue
tracker._

Instead, Apple's forums provide a crude approximation of one.

------
dsr_
For the casual onlooker: that's not closed as in resolved, that's closed as in
irrelevant.

The people who are unhappy with those bugs probably consider them very
relevant.

------
mariuolo
Just wait long enough until the bug becomes obsolete.

It's the same as the Ubuntu(™) way.

The user (if still alive) can re-submit it for the newer version, if
applicable and the cycle goes on.

~~~
droidist2
Haha, Attrition Driven Development?

------
realrocker
Since many of these bugs are also simultaneously raised by OEM's they are
closed internally without feedback. And feedback to what bug, they are so many
for the same! Also lot of them are feature enhancements and are really
opinionated actually to work on. It could be better but it's not that bad. You
won't believe the hoops you gotta jump to get anything done. Too many
stakeholders in AOSP!(which has both pros and cons). I work on the AOSP for an
OEM.

------
TillE
That's a shame. I had 1285 (USSD API) starred, which would have allowed for
some interesting carrier-specific apps. Do any mobile OSes let apps get a USSD
response?

~~~
wasyl
Same for me, I got an email recently that bug I starred has been closed.
Pretty disappointing, this would open so many possibilities

------
mpdehaan2
Managing any project with thousands of contributors is very hard - namely,
duplicate bugs, low quality bug reports, bugs that are no longer valid given
OS or version changes, etc.

I can't imagine how hard it is to manage something on the scale of Android,
where it's so consumer-oriented, half of everyone with a phone (roughly)
potentially could be using the bug tracker.

There may be some interesting room to build a bug tracker that can better
semantically sort, and ensure better quality bug reports - templates for bug
reports are a _start_ , but there are very few if any good triage tools for
the people on the other end of the system.

In this case, yes, there should have been at least a canned template response
such as "if this still affects you,..." etc, but even that is difficult - with
50 people replying to a bug report, it's a good way to get 50 duplicates.

Ultimately, it's a sign where open source project management practices get
increasingly hard the larger a project gets, and while it may be possible to
keep up with the contributors, keeping up with userland can be an even larger
feat.

In some ways, proprietary software has a it a LOT easier, and I don't envy the
task.

While not every project can hire 15-30 extra people to manage and prune a
gigantic issue tracker - Android probably can, and probably should, given the
spirit of what it is.

Longer term, I still think we can do a lot better with bug tracker technology
to provide more semantic views into what's there and needs to be done -
eliminating the need to keep things pruned in this way. But we are no where
close yet.

~~~
chralieboy
StackOverflow provides a good example of how this could work. They identify
duplicates as you type the questions and have many moderators dedicating time,
for free, on cleaning things up.

Of course that doesn't solve the difficult matter of actually fixing the bugs,
but I'm sure the Android developers would sincerely appreciate it. Closing
duplicates or reports with little information sets a standard for the bugs
that do get fixed.

------
arthursilva
Android dev is smelly, even if you target 4.0+. Any mid sized app need several
workarounds/hacks in order to work properly.

~~~
cpncrunch
We target 2.3/3.0 and have required very few workarounds/hacks. iOS is a hell
of a lot worse - there are various bugs either introduced or "fixed"
(requiring a workaround) in each release.

~~~
e28eta
We may be writing very different kinds of iOS apps, but most of our SDK
upgrade problems stem from (often accidental) misuse of Apple's APIs, or a
documented change that Apple made.

------
MichaelEGR
Closing the very recent and ongoing with no hope in sight BLE bugs which are
very real and heinous is BS:
[https://code.google.com/p/android/issues/detail?id=58381](https://code.google.com/p/android/issues/detail?id=58381)

BLE stack is even worse in Lollipop.

~~~
tdkl
This comment exactly explains the frustration :
[https://code.google.com/p/android-developer-
preview/issues/d...](https://code.google.com/p/android-developer-
preview/issues/detail?id=1570#c31)

Hardware supports it, but Google for some unknown reason just disables
software support, it did it in the past with 4.3 BLE support and apparently
nothing changed.

------
51Cards
I saw several email alerts come through as these were being closed. 3 of them
were submitted by myself and at least one I would say is still relevant in
Android 5.0 That said with the history of how bugs have been handled there I
wasn't very surprised.

------
tehabe
Some of the bugs I reported were also marked "obsolete", but they were mostly
fixed in Android 5.0, so I can't really complain about it.

But yeah, the handling of bugs is awful, no comparison to the way Chromium
handles bugs. They might not be perfect. But it feels much better handled.

------
diafygi
EDIT: The original title of this post was "Someone silently closed 37% (19/52)
of Android bugs with 500+ stars on Dec 25th" (it has been involuntarily
changed by the mods).

Here's the list (all marked Obsolete silently by e...@google.com):

[https://code.google.com/p/android/issues/detail?id=82](https://code.google.com/p/android/issues/detail?id=82)

[https://code.google.com/p/android/issues/detail?id=1257](https://code.google.com/p/android/issues/detail?id=1257)

[https://code.google.com/p/android/issues/detail?id=1211](https://code.google.com/p/android/issues/detail?id=1211)

[https://code.google.com/p/android/issues/detail?id=2117](https://code.google.com/p/android/issues/detail?id=2117)

[https://code.google.com/p/android/issues/detail?id=2361](https://code.google.com/p/android/issues/detail?id=2361)

[https://code.google.com/p/android/issues/detail?id=1386](https://code.google.com/p/android/issues/detail?id=1386)

[https://code.google.com/p/android/issues/detail?id=1730](https://code.google.com/p/android/issues/detail?id=1730)

[https://code.google.com/p/android/issues/detail?id=2207](https://code.google.com/p/android/issues/detail?id=2207)

[https://code.google.com/p/android/issues/detail?id=2845](https://code.google.com/p/android/issues/detail?id=2845)

[https://code.google.com/p/android/issues/detail?id=1285](https://code.google.com/p/android/issues/detail?id=1285)

[https://code.google.com/p/android/issues/detail?id=2305](https://code.google.com/p/android/issues/detail?id=2305)

[https://code.google.com/p/android/issues/detail?id=2412](https://code.google.com/p/android/issues/detail?id=2412)

[https://code.google.com/p/android/issues/detail?id=1089](https://code.google.com/p/android/issues/detail?id=1089)

[https://code.google.com/p/android/issues/detail?id=1698](https://code.google.com/p/android/issues/detail?id=1698)

[https://code.google.com/p/android/issues/detail?id=2318](https://code.google.com/p/android/issues/detail?id=2318)

[https://code.google.com/p/android/issues/detail?id=1041](https://code.google.com/p/android/issues/detail?id=1041)

[https://code.google.com/p/android/issues/detail?id=63793](https://code.google.com/p/android/issues/detail?id=63793)

[https://code.google.com/p/android/issues/detail?id=1284](https://code.google.com/p/android/issues/detail?id=1284)

[https://code.google.com/p/android/issues/detail?id=1106](https://code.google.com/p/android/issues/detail?id=1106)

~~~
sarciszewski
[https://code.google.com/p/google-security-
research/issues/li...](https://code.google.com/p/google-security-
research/issues/list?can=1)

cevans => cev... (Chris Evans is known to be part of Project Zero.)

Given their censorship scheme, I can't help but wonder if e...@google.com
means eric@google.com?

If so, the culprit is likely Eric Schmidt.

EDIT: Okay, can anyone explain WHY they're downvoting this?

~~~
yourad_io
The same person/profile[1] who closed these issues has been merging issues as
far back as 2013[2]. I doubt that would have been him.

[1]
[https://code.google.com/u/116776574616066648526/](https://code.google.com/u/116776574616066648526/)

[2]
[https://code.google.com/p/android/issues/detail?id=63433](https://code.google.com/p/android/issues/detail?id=63433)

~~~
shortstuffsushi
If you guys are really interested, the profile you linked has a list of
projects. Glancing at the "vogar" project which it says is owned by
e...@google.com (first I happened to pick), you can see links to the blog of
Elliott Hughes. His site indicates he's a Google employee. So, not exactly
proven, but seems to fit the bill.

~~~
sarciszewski
Except Ellion Hughes shows up elsewhere as elliot...@google.com

[https://code.google.com/p/enh/](https://code.google.com/p/enh/)

~~~
shortstuffsushi
True, and as I said, my single link research is by no means proof, just the
nearest I could find that seemed to make sense.

------
therealmarv
I know Android devs have a internal bugtracker, so there are two bugtrackers
at least (internal and external). This horrible external bugtracker on Google
Code is maybe not as relevant as you might think. I can imagine it is a pain
in the *ss to sync them.

------
thomaslutz
What's even more infuriating is that devices with LTE like razorg get delayed
multiple weeks if not months with software updates. Still waiting on Android 5
with what I thought is the 'better' device compared to razor.

------
kelukelugames
Silently? This isn't that dramatic.

edit. title has been fixed.

~~~
yourad_io
Silently == closing without comment. Dramatic or not depends on the issue:

This[1] issue (note the id) has 6275 people following it and 1659
comments/activities.

Marking it obsolete with "(No comment was entered for this change.)" is kinda
middle-finger-ish, don't you think?

[1]
[https://code.google.com/p/android/issues/detail?id=82](https://code.google.com/p/android/issues/detail?id=82)

~~~
sduclos
Wifi ad hoc network (82) seem like good thing to have in an emergency.
Searching around I found _Wi-Fi Peer-to-Peer_ in Android doc at

[http://developer.android.com/guide/topics/connectivity/wifip...](http://developer.android.com/guide/topics/connectivity/wifip2p.html)

~~~
alvarosm
Well, that's kind of a minor feature and it's understandable that they might
decide not to prioritize it. But there are many serious bugs out there that
are being ignored.

~~~
Zak
It would also be trivial for them to ad, as several third-party builds support
it and a couple patches have been offered over the years. It's almost certain
there's a business/policy reason they don't want to support it.

Sharing a PC's wired connection via ad-hoc WiFi is still a pretty common use
case. Mesh networking for communication in emergencies would be an awesome use
case, but it depends on a lot of people using it for most of its benefit, and
the installation procedure starts with "first, root your phone".

------
lnanek2
It's unfortunate, but Google pretty much ignores most outside bug reports and
a bot marks them obsolete automatically. Rather than improving things, the
situation has actually gotten worse and worse over the years and they started
adding tags to prevent people from commenting. Even if Google rarely fixed
things the comments were often pretty good for working together with other
developers to come up with work arounds.

------
curiously
Had a phone from 2010ish. Recently switched to a Motorolla G smartphone with
latest Android on it.

I am absolutely amazed how far Android has come. It feels so smooth and good.
I thought about jumping to iPhone but my view of Android has changed
drastically.

(My old phone was Galaxy Nexus and it was rife with randomly restarting during
calls and sluggy OS).

------
Kapura
Lizard Squad strikes again!

