

µg: Open-source replacements of Google Apps and API on Android - Aissen
https://github.com/microg

======
ricardolopes
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.

~~~
DCKing
> 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.

~~~
ricardolopes
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.

~~~
DCKing
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.

~~~
jayd16
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.

~~~
DCKing
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.

~~~
jayd16
>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.

------
otikik
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?)

~~~
richdougherty
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)

------
erikano
Interesting. Do they have a public road map so one can see how far they've
come with this project?

------
nacnud
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?

~~~
treffer
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...](http://forum.xda-developers.com/galaxy-
nexus/development/rom-source-software-t2701580)

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.

~~~
rquirk
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 :(

~~~
treffer
Huh, I have everything on github if you are interesting.
[https://github.com/gfreed](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
(arty@jabber.ccc.de). 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.

------
agumonkey
just when lwn talks about Google free Android
[https://news.ycombinator.com/item?id=7952550](https://news.ycombinator.com/item?id=7952550)

timing is fun

~~~
privong
My guess is someone posted this link after seeing the LWN piece linked on HN.

------
devindotcom
Mu-G! If it's anywhere near as good as Muji...

~~~
wyager
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.

------
donniezazen
Google Apps =/= GAPPS.

------
mantraxD
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.

~~~
lvillani
"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.

~~~
mootothemax
_μ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.

~~~
Curmudgel
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".

------
pbreit
I'n sorry bit even insinuating that something like this could remotely stand
in for Google Apps is completely insulting to everyone's intelligence.

