This is untrue when you're talking about app development, which this is about. It can be demonstrated by simply pointing out that Microsoft's, Amazon's and Baidu's Android derivatives are fully functioning commercially even though the Google Play Services are not available on these devices. The Amazon App Store even has 240,000+ apps.
There's an increasing amount of propietary Google software running on Android phones, but that has no consequences for other apps. No functionality of AOSP is being absorbed into Play Services at all.
This is not to say that pure AOSP is broken, or that it is impossible to have products like Kindle Fire and Nokia X. But it is a growing problem, and the fact that Amazon has to spend so much time replicating Play Services' APIs to have a decent app store (that is still considerable smaller than Google Play Store) is concerning.
It would be wrong to have AOSP depend on Google cloud APIs, and seperating those cloud APIs in Google Play Services also has problems. There's really no winning here for an open platform.
Google controls the API but Amazon is free to expand the functionality on their devices.
This way, the developer can simply call Context.getSystemService(CLOUD_SERVICE) and have access to whatever cloud service the user as installed.
Every other part of android, from keyboards to cameras, works this way and these services could as well.
Then, having an open source community contributing with open implementations could help filling the gaps to make life easier to those players (and probably lowering the bar to allow new ones to join) and, who knows, to make it possible to have an AOSP device fully compatible with Play Services APIs without the need for gapps, probably just using some private server or other custom solution. Maybe I'm misunderstanding something somewhere, but that seems to be the goal of this project. If it is, then I really hope for its success.
This project and some of Amazon's libraries basically take a subset of Google's Play Services API as canonical and reimplement those. That's not an ideal solution either, but at least it provides minimal pain for app developers.
The cloud service version and the client library code would not be coupled to OS version and updated with APKs just like how Google Play Services does. Its not any harder than exactly what Google is currently doing with play services.
I'm not proposing anything that isn't already being done besides some standardized calls and some extra service discovery.
That's technically correct. But apps that are in AOSP can be supplanted by Google proprietary apps and turn into abandonware.
Goggle has never outright misbehaved w.r.t. AOSP, and in some cases put things like ART into AOSP very early, ahead of commercialization by Google's OEM partners. BUT that doesn't mean that Google Play Services isn't effectively shrinking AOSP's share of the standard complement of apps.
mar-v-in and his µg are corner stones to build a nice free android. As for a server side I'd suggest ownCloud at the moment. I'm running one on ipv6 at home. Works great.
Only Replicant seem to be doing things the right way, but they are going so slow, and are so unwilling to use proprietary blobs anywhere that there's a space for something like you have here - blobs for hardware features only, no proprietary apps, strongly anti-Google, including F-droid by default - but it needs a bit of proper open source-style organization.
Sigh. The whole ROM scene is a big mess :(
I am still using the blobs, but I was thinking about gradually replacing parts once replicant reaches a good-enough (e.g. samsung rild, have to try it though).
Btw, if you are interested in building the ROM add me on jabber (firstname.lastname@example.org). I want to build the next version this weekend anyway and I may as well guide you through building roms, too. Plus I would appreciate help on porting to new devices :-P
[EDIT] I'm unhappy with the ROM scene, too. That's why I started my own ROM in the first place.
More importantly bitnami makes it a one-click install for all of the above, minus the IMAP server.
timing is fun
To be fair, it is awesome. Just got back from the store near my apartment.
Whether you know it or not, this has an actual effect on the ability of the project to spread by word of mouth (online or otherwise), therefore its success and number of contributors it'll get.
The Greek letter Mu is the SI prefix for "micro".
μTorrent seems to do fine with the Mu, even though most people write it as "uTorrent" and spell it as such.
You've said it yourself there; μTorrent was rebranded by the majority of users to uTorrent, and "uTorrent" is a distinct, mostly spelt-how-it-sounds and easily-Googleable name.
I doubt that an involuntary rebranding of μg to "ug" would be quite as successful, nor likely to happen.
Pronounced "MEE-KROG", right? First syllable rhymes with me, second frog.
I completely agree with you.
"What's that you're using?"
"Microgram, I think. It's cool, you should check it out"
sound of frantic typing
"I can't find it on Google, how do you spell it?"
Variants on the above conversation happen every day.
Adopting a name like μg only places petty and annoying barriers in front of potential users.