[Galaxy S I9000 General] bitbang3r:
Truth be told, hardware problems aren't inconceivable, but from everything I've read, they're likely to be the least of anyone's problems. As a practical matter, all phones have GPS antennas that suck. Some suck worse, but none of them are really good enough for it to make a real difference.

In reality, the way Android handles location services is totally wrong... or at least immature and incomplete. Take the fact that for all intents and purposes, Coarse=network, Fine=GPS. In reality, it's simultaneously naively simplistic and needlessly brittle. As a user, I don't really care *how* the phone figures out my location, I just want it to generally work, and work quickly when I want it to work. A far better approach would be to have an integrated wrapper interface like FineLocationProvider and CoarseLocationProvider that uses the best of whatever information is available, but rounds it down a bit if it's a coarse provider.

My personal vote for rounding would be to take the double-precision decimal latitude & longitude, multiply them by 256, round them to the nearest whole integer, then divide them back down by 256 if desired. That will get you slightly better than 1/4 mile accuracy in the US (where imperial matters), and at least 1/2km or better everywhere else in the world (it would be worse than 1/4 mile near the equator, but nobody near the equator uses miles so it doesn't matter). IMHO, that's close enough to figure out whether something is less than a mile away, a mile away, or some number of whole miles away... enough precision to be useful for casual geolocation, but not enough to really enable someone to triangulate you if they have access to that info by walking around the block.

With a little creative escaping and bit-repurposing, it also enables you to neatly pack latitude & longitude with 8 bits of fractional-degree precision into 4 bytes -- 9 bits for whole longitude, 7 bits for whole latitude (with a bit of fudging and flag values to identify and repurpose bits for polar latitudes). I don't remember the exact latitudes, but I figured it out one afternoon as being enough to cover basically everything from Tierra del Fuego at the southern tip of S. America to the city with ~50,000 residents in extreme northern Russia whose name escapes me at the moment. Set aside a few values to just hardcode a table for McMurdo & Vostok, the poles, and the few other meaningful locations outside of that 127-degree latitude band that might nevertheless have a picocell or two, and you're set ;-)

Another weakness of the current Android implementation in general is that it's very either/or -- the phone is either making no effort at all to discern location, or is absolutely hellbent on finding its location no matter what because the timer expired. A better approach would be to let someone for whom battery life is a concern, but not life-or-death critical, to allow the phone to get a location update from the network every 15 minutes or so, sniff the air for SSIDs every 15-30 minutes, and do a "sky survey" opportunistically without necessarily going all the way and computing the location itself.

For example, right now, if you launch the GPS provider, it's going to hunt down the satellites, get the telemetry data, then go all the way to the final calculation to figure out the current location. That's a LOT of processor-intense floating point math. HOWEVER, suppose the phone went halfway -- powering up the GPS, buffering the satellite telemetry, then just stashing it away until something actually needed to use it. Kind of like a compromise between the way original aGPS worked (the phone grabbed the satellite telemetry and relied on the tower to do the math) and the way Android tries to do it now (calculating it all the way to the bitter end, so you really don't want to casually do it or you'll kill the battery life). Assuming I'm right, and it's the floating point calculations that account for a lot of the power consumption during GPS use, that would be a nearly ideal compromise... you could collect telemetry data on a regular basis, whether you have an immediate need for it or not, and have it available for nearly instantaneous use when you do.

The nature of how Android handles location now also makes it brutally hard for apps to put it to good use. As a developer, you run into all kinds of quandries that really HAVE no good solution right now. You have to either reinvent the wheel and try juggling gps, network, & try handling the oddball use case with none at all without crashing, or try blindly grabbing one source and pray it works. If you blindly grab at GPS, it probably won't work at all if the user is indoors, and will return null current location values until the user figures out he needs to wave the phone in front of a window to proceed. If you blindly grab at network, it will go down in flames if the user has 3G/4G networking disabled and insists on trying to use wi-fi exclusively. Under the current API, there IS NO way to say, "I don't care how you find out, or even how precise it is, just give me a halfway decent idea of where I am RIGHT NOW (or at least within 700ms or so) dammit!". At least, not unless your app has already run in the recent past since the last reboot and a value is already cached. There's a big, gaping hole surrounding the use case for that first awful app launch of the day.

By the same token, if there are multiple location-aware apps running, there's no real way for them to share a common umbrella location provider like I've described, so if each one independently reinvents its own, your battery use will probably double because each one will have to poll the upstream location providers for their own information. What we urgently need is a happy middle ground with some kind of background service doing all the stuff I've described above -- rarely, when the phone seems to be sleeping and nonmoving, more often when the phone seems to be in active use, in a way that tries to take into account how phones get used in real daily life. It's a huge project that's way too big for any one app to really do a good job of implementing itself, and exactly the kind of thing that really needs API-level support. If not officially, then as a guerrilla API extension available to people running apps on rooted phones (which would almost certainly get Google's attention, and get it mainstreamed into the next release of Android ASAP).

Oh, and I almost forgot about permissions. For a location-aware app to meaningfully implement the stuff I've mentioned, it would need a laundry list of permissions in its manifest that would likely scare the bejesus out of lots of potential users. These are things that the app *itself* really doesn't need to know, but its GPS-handler DOES if it's going to do anything besides blindly ask the network for its location and crash if it can't get it. By separating out the location-determination into a separate app/shared library, you get back to the originally-intended scheme where an app can simply ask for COARSE_LOCATION permission, instead of asking for access to coarse location, fine location, network, wi-fi, wi-fi settings, accelerometers, light sensor, etc.