µg: Open-source replacements of Google Apps and API on Android(github.com)
github.com
µg: Open-source replacements of Google Apps and API on Android
https://github.com/microg
45 comments
Great project. The importance of something like this is increasingly growing, as Android ecosystem is getting more and more dependent on Google's proprietary software.
For the next steps, it would be nice to have some onboarding document for this project, as otherwise it will probably look to complex and unwelcoming. I see that most of the replacements are in a very early phase (and one of them is empty), so I hope that this project manages to survive this early state to grow into something we can actually rely on.
> as Android ecosystem is getting more and more dependent on Google's proprietary software
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 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.
Google is frequently pushing new Google Play Services that developers can use for their apps. Those services have the massive advantage over AOSP APIs of having OTA updates for all, not having to rely on carriers and manufacturers for full OS upgrades. In addition, those services offer new and useful functionality that is not always present in AOSP. Therefore, it is only natural that, on a general basis, developers start using more and more of Google's proprietary APIs.
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.
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.
That is true. Although AOSP in itself is a complete operating system, most apps require the need for the "extras" that are provided by some cloud service. Although you can manage without, apps assume an "ecosystem" with additional cloud services rather than an OS to be present.
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.
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.
I think a good solution would be to abstract the Google Play Services behind some 'cloud-api service' that others, such as Amazon, could re-implement and drop in. The Google play store would be the canonical implementation.
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.
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.
This would, IMO, be the best approach. We already have players (Amazon, Nokia, etc) that would certainly be interested in having such a layer that they could apply on top of their services.
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.
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.
That would be difficult, I think. "Cloud service" does not really define any capabilities present or absent in the library. Even if you split it up in things like "mapping service" and "cast service" then a lot of details will differ between otherwise equivalent providers. It's not something you can easily generalize. And if you generalize it, you're stuck with this generic API until your phone gets updated.
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.
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.
>And if you generalize it, you're stuck with this generic API until your phone gets updated.
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.
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.
Isn't it a copyright violation to copy API signatures? It'd be interesting turn of events if Google who lost the case of copying API signatures ends up enforcing the same violations if a strong contender pops up.
That ruling was overturned on appeal a whole back.
> but that has no consequences for other apps. No functionality of AOSP is being absorbed into Play Services at all.
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.
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.
Android 3.0 wasn't released by AOSP until Android 4.0 came out. That was certainly a strange time.
Go back and use a 3.0 device. It was a mess.
It wasn't a mess. There was never a good reason to withhold the source code. It was eventually released, and there was nothing terrible in it.
My guess for withholding Android 3.x was to prevent Amazon from using Android 3.x on the original Kindle Fire. Instead, the original Fire was stuck using a modded Phone OS (Android 2.3) while Android 3.x remained exclusive to tablets licensed by Google.
This needs more docs or pointers to docs. I understand what's trying to do on a high level, but I have no idea of how to use it, or its state (like, is it still in initial dev, or has it reached alpha?)
This forum post looks like it gives an overview:
http://forum.xda-developers.com/showthread.php?t=1715375
http://forum.xda-developers.com/showthread.php?t=1715375
Interesting. Do they have a public road map so one can see how far they've come with this project?
Great start. So will I be able to run a server where I can gradually switch out Google's implementation of services with these as they mature?
Not that easy. I'm trying that right now on a second phone. I've rolled my own ROM which I'll update this weekend with all the cool new stuff (especially the mock play services / maps v2): http://forum.xda-developers.com/galaxy-nexus/development/rom...
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.
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.
I commend your efforts, but a small rant: One thing that really puts me off xda is that the posts say "open source" but there is no link to anything like how to build the distribution yourself. Just a frickin' binary zip download. And that's served over http from a random site, with no checksums and unsigned.
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 :(
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 :(
Huh, I have everything on github if you are interesting. https://github.com/gfreed
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 ([email protected]). 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.
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 ([email protected]). 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.
I couldn't agree more. I'm using ownCloud with InstandUpload to handle photo backup, and ownCloud itself for the DropBox equivalency. With Cal-DAV and Card-Dav enabled, owncloud let me disconnect from Google Contacts/Calendar. Owncloud support for rainloop means that I have GREAT webmail (which I never use) and more importantly, an IMAP server I run on top of this. It's becoming a lot easier to disconnect, with the sole exception of the Google Play store.
More importantly bitnami makes it a one-click install for all of the above, minus the IMAP server.
More importantly bitnami makes it a one-click install for all of the above, minus the IMAP server.
[deleted]
just when lwn talks about Google free Android https://news.ycombinator.com/item?id=7952550
timing is fun
timing is fun
My guess is someone posted this link after seeing the LWN piece linked on HN.
Mu-G! If it's anywhere near as good as Muji...
Man, I'm suffering from a major case of Baader-Meinhof Phenomenon today. I heard of Muji for the first time from three independent, unrelated sources today.
To be fair, it is awesome. Just got back from the store near my apartment.
To be fair, it is awesome. Just got back from the store near my apartment.
Google Apps =/= GAPPS.
I know open source folks don't consider branding important, to the point they intentionally give their projects stupid names for the "irony" and so on, but I don't even have this key on my keyboard, and I don't even know how to say this. Mewjee? Mewg? Ug? Come on, folks, you can do better.
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.
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 URL is https://github.com/microg, so I'd have to guess "micro g".
"microG"?
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.
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.
> "microG"
Pronounced "MEE-KROG", right? First syllable rhymes with me, second frog.
Pronounced "MEE-KROG", right? First syllable rhymes with me, second frog.
Its a ballache though, especially in 8.1 (u1) with classic start. Press the first letter and get a list of programs that start with that letter? U doesn't bring it up. Because it doesn't start with a U.
μ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.
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.
The funny thing is that in Modern Greek the letter μ is pronounced "me", so the name of the software could be pronounced "meTorrent". Spelling it with a u makes the name of the software sound like "youTorrent".
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
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.
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.
Micro G... seems pretty reasonable.
I thought the same. Branding can make or break the success of a project. I think OSS is no exception. Patio11 wrote a great piece on the branding of Heartbleed. [1]
[1] http://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teac...
[1] http://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teac...
[deleted]
Here on Hacker News, I momentarily mistook "µg" for "pg". So I thought Paul Graham was making an announcement about APIs for Android. If that had been intentional, it could have been a homograph attack.
I'n sorry bit even insinuating that something like this could remotely stand in for Google Apps is completely insulting to everyone's intelligence.