3 ms·
While differing in nitty-gritty details, the googler basically confirms what I interpreted to be the main thrust of the Ars article. AOSP is the carrot, the co
by forgottenpass 13y ago
While differing in nitty-gritty details, the googler basically confirms what I interpreted to be the main thrust of the Ars article.
AOSP is the carrot, the compliance necessary for google's value add software is the stick.
The last paragraph concludes saying that Android with google apps is the least bad offering out there. That's why I both use it personally, and why I'm not super pumped about the future of any mobile platform these days.
- outside1234 13y agoThis. There will continue to be improvements to AOSP, but only as that makes driving Google's proprietary apps easier and faster. Its exactly like Chromium in other words and we see that with Blink.
- mdwrigh2 13y ago> This. There will continue to be improvements to AOSP, but only as that makes driving Google's proprietary apps easier and faster. This isn't remotely true, work continues on the platform in a number of areas beyond just feature requests from other teams. Having application teams able to explain the pain points they feel in the platform and then having the platform team come up with solutions that work for the general use case is a good thing though, it improves everybody's experience. It isn't like there are hidden "makeGmailFaster" APIs that other people can't use.
- Agathos 13y agoYeah, it reads more like an explanation than a rebuttal.
- hahainternet 13y agoNo it doesn't, I have no idea how such utter rot makes it onto HN. Peter is a tabloid journalist, he stopped writing interesting balanced articles a long time ago and now just posts linkbait. His points are thoroughly refuted, but I guess you didn't bother to read them.
- csarva 13y ago> 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.
- mdwrigh2 13y ago> 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/package-summary.html http://developer.android.com/reference/android/location/pack...
- fidotron 13y agoThe 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.
- mdwrigh2 13y agoWhy do you want to skip the sensor fusion step? The entire point is it gives you more accurate data.
- 13y ago