Hacker News Reader

Comment by csarva | Hacker News Reader

> AOSP is the carrot, the compliance necessary for google's value add software is the stick.

"Because cloud!" seems to be the answer to most of the points raised in the original article, which kinda sounds ok on the face of it; but why can't those backend services be abstracted out as well? Why shouldn't I be able to choose some other provider for all these services, like location?

It reminds me of a commonly suggested solution to the browser wars in the 90s, when the reasoning for Microsoft's integration of IE directly into the OS was all the new possibilities from such deep integration: why not just allow different browsers/engines (e.g. mozilla) to be swapped in? Well, because then you wouldn't be using MS products anymore!

And I think a lot of that is repeating itself here.

View on HN

The location example is bothersome, but the point about 4.4 adding the storage API to enable Dropbox (a competitor) access to apps and the systems in precisely the same way as Google Drive does demonstrate they aren't nearly as closed as many like to portray them as being. Android has the most pervasive mechanisms of this kind of any widespread system, and the best approach for adding them with applications. This is, by far, the single most underappreciated part of the platform, including by many Googlers outside the Android team.

That said, it pisses me off violently that to get weather from a non-Google source my device still insists that Google get my location data. The location system very much should be pluggable, and it doesn't present the kind of technical hurdles stuff like a generic purchasing API (discussed elsewhere) would.

If you make your own location provider, Google will call you non-compatible and not let you have the Google Play store. They consider users using someone else's location services to be terrible for their company, as per internal emails: http://www.engadget.com/2011/05/10/internal-emails-reveal-go...

> Why shouldn't I be able to choose some other provider for all these services, like location?

You can, just provide an implementation of LocationProvider: http://developer.android.com/reference/android/location/pack...

The problem is Google wrapping those in such a way that sends them the data of the underlying sensors before reporting up the stack to the requesting app. They (rightly) point out this enables different sorts of location stuff, like the network parts, but it doesn't allow you to say to the Google Services I only want you using GPS, and no you can't report back without that whole layer becoming completely unusable, unless the app developer wrote it for the lower level stuff before and manually bypasses it in the case they detect Google's service is disabled.

Why do you want to skip the sensor fusion step? The entire point is it gives you more accurate data.

Because I don't trust Google with this data, and will sacrifice battery life and accuracy to prevent them having it. Frankly the weather is the same for a few hundred metres around me in each direction!

They proved with the WiFi slurping on Street View cars they can't be trusted with this stuff at all.

Settings > Location > Mode > Select "Device Only"

and

Settings > WiFi > Advanced > Uncheck "Scanning always available" (which asked for permission on first boot)

These are user settings, not app settings.

On my devices doing the first causes apps using the Google Play Services to report that you've disabled the location service completely, while the direct GPS based apps continue just fine.

The broader point here is wanting to be able to remove Google's service software from the equation, and run only code you can actually inspect the contents of for this kind of data. To be honest those apps having direct GPS access isn't ideal either and this should all be proxied through a standardised open source app on the device.

On a Nexus 5 doing the first doesn't change anything for me; it's just less accurate (I did so, then opened up Google Maps to double check).

But you're going to have to define what you mean by "Google code", because ostensibly all of Android is "Google code". Doing what I outlined above will stop it from going through any form of sensor fusion. If you want to remove Google's service software then just create a build without Play Services on it, it's that simple. AOSP boots, on the Nexus devices at least, without it, so it's easy to do and gets you exactly what you want.

So really I guess I'm saying: What else do you want? Remove Play Services, the Google Apps, etc, using an AOSP based build and you get a Google free phone.

Also the argument: the cloud is proprietary so the app is as well.

If the cloud part is the hard part to implement why not make the app open source ?

Reply on news.ycombinator.com