That's just incorrect as far as I know. It remains possible to support all drivers with an AOSP build.
B&N decided they wanted to "mainstream" their Android in terms of enabling it to be a "Google-logo" device. Probably a good choice if you haven't got the scale of Amazon's ecosystem.
One of our apps rely on GPS, and the manufacturers that bought that app from us could only make it work after installing Play Services, and they could not figure a way to make it work without Play Services.
Location Services is a special API, in that Google bears some costs to enable it for geocoding, for example.
It is possible to have access to basic location data from a built-in GPS receiver in AOSP, so the system is not completely dependent on Google Play Services.
But access to e.g. Google's giant wifi-to-location database isn't part of that API. And it's a good service, and something that is hard to replicate and thus a competetive advantage.
But to speak to the upthread parent: it has nothing to do with "drivers". The HAL interface for GPS data is part of AOSP.
If Google had allowed this, it would mean using Google branded android apps that use a completely different location API. I would be nervous about this if I were Google, when something goes wrong or doesn't work with the API, my apps will take the heat since the average user won't know the difference between Skyhook and Google location APIs. Further, as a consumer I would have never been able to switch back to the Google location APIs without flashing. Of course, manufacturers can still have their own apps using Skyhook's SDK.
That's not exactly correct. Amazon, for example, is free to use whatever location services they want, since they use an Android-based system that uses no part of the Google ecosystem.
So if you want Google Play and everything else Google in your device, you have to take Google's location services, too. That may not be unreasonable.
That may be true, but it's not an issue of denying "GPS" data, which is what the upthread parent was confused about. You can get location output from GPS (or in fact anything else that your platform has wired into the HAL -- it's not specific to GPS per se) data.
It's Google's extra, proprietary services that are, well, proprietary. And that's hardly notable IMHO. There are lots of players in this space, it just happens that Google has done it better and is using that (among other features obviously) to drive sales of its "Play Services" product to OEMs.
Non-free software is non-free. If you care about that stuff, you wouldn't use it anyway.
> Google has done it better and is using that to drive sales of its "Play Services" product to OEMs
Google aren't competing in the "Wifi to location" space on merit. They're competing on "we won't let you use our platform if you use a competitor in this space". They're becoming the 1990's Microsoft. This is exactly the shit people talk about when they say Android isn't open anymore.
I think there might be a need for providing a decent layer between the various closed layers created by Amazon, Google et al. At least, that would allow apps to be friendly to Android without marrying Google Play.
I'm not sure what drivers you refer to, but Play definitely isn't mandatory to use the AOSP. Barnes and Noble presumably had all the drivers they needed to make the Nook functional without Play?
Interesting. Everyone put it as an attempt to keep the Nook relevant (because you get all the google apps with it), but I'd be interested in seeing more on that side of things. Which drivers, though? Usually you'd get the graphics driver from the chipset manufacturer, for instance, who they would already be contracting with because they make the device.
B&N decided they wanted to "mainstream" their Android in terms of enabling it to be a "Google-logo" device. Probably a good choice if you haven't got the scale of Amazon's ecosystem.