Hacker News Reader

I think what bothers people who feel this way (and I'm one of them) is that Google is taking things that Android used to include (like the browser) and moving all future development to closed-source versions, leaving the open-source version stagnant[0].

> Rather the author seems to be trying to redefine "operating system" to include things that have never been a part of such a term before, like online message routing and mapping services.

This doesn't really ring true in the face of what's happened; Google has kept a lot of things proprietary, sure, but they've also moved a lot of things proprietary that weren't before and abandoned the rest. They're making platform improvements in closed-source rather than open-source, making it difficult and impractical for a lot of developers to build apps that will work on Android, rather than 'Android plus Google Play services etc'.

This even includes the keyboard; Google has made improvements to the Android keyboard, but not in AOSP.

Fundamentally, this feels like an attempt to maintain both the user-visible branding (now everything is Google this and Google that, which reminds users that Google had its hand in things) but also to prevent carriers from shipping stock Android and cutting Google out of the loop.

[0] http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-...

I find the browser complaint funny because they've moved to Chrome which even has an open development model[1] (Android does not). Chrome is also used for the WebView implementation starting in KitKat[2] (made updateable via Play Store in Lollipop). All of this code is open-source and also openly developed (which means code review, bug tracker, mailing lists, design docs are public).

[1] https://news.ycombinator.com/item?id=12578134

[2] https://developer.chrome.com/multidevice/webview/overview

Chrome for Android is only open source as of a few months ago. Before that, the UI was entirely proprietary.

This may seem like pedantry, but neither Chrome for desktop, nor Chrome for Android are open source.

I'd see the main general motivations for something like MicroG as being a sense of trust, privacy, control. As long as even 0.1% of any packaged end-product is closed source, this isn't possible.

From https://developer.chrome.com/multidevice/faq :

> Is Chrome for Android open source?

> Chrome for Android is derived from Chromium. Since the launch of the first version, we have steadily open sourced all the critical components. You can build various Chromium components for Android as used in Chrome for Android using the instructions here.

This is just a long way of saying "no"

Ah, yes the UI was upstreamed only recently. However it was possible to build Chromium on Android either as "content_shell" (minimalistic UI on top of Chromium) or as WebView.

Exactly this, already it seems a little weird now how rose colored people's vision of Google was some ~5-10 years ago (I too was a fan). Give it 5 more and it will be late 90's Microsoft.

I believe that is the pun the name "MicroG"is meant to imply.

While you're technically right, no other operating system has the problem that its most popular applications will not work without an additional proprietary platform being installed. It's kind of like if amazon services were a critical layer to ubuntu's independently developed apps functioning properly.

>mapping services arn't part of OS, thus don't have to be open

The mapping services in question was built by scraping the location and details of wifi ap's from publicly broadcast packets, received and logged by your and other consumer's hardware so you would think that this is public information and could be opened up, but it isn't - which seems poor.

>don't see why they care. Even if they reimplement the client libraries Signal and other apps will still be dependent upon the proprietary servers.

The goal is to prevent google from controlling the hardware you paid for and the software you're using. This, while not 100% stable, is better than having no options.

> While you're technically right, no other operating system has the problem that its most popular applications will not work without an additional proprietary platform being installed. It's kind of like if amazon services were a critical layer to ubuntu's independently developed apps functioning properly.

The better way to fix that isn't to reimplement the Google Maps and Google Play clients, it's improving OpenStreetMap and a GNU/Linux-style package manager for Android.

> improving OpenStreetMap

Sure, but in order to actually make apps work (without forking every map project out there) you'd need to fake the Google APIs anyway...

> GNU/Linux-style package manager for Android.

That's basically what f-droid is.

Google Location Services API is required for OSM to work properly.

So you put location services on the list of things to replace.

...and, that's what this project is doing.

It's doing both things.

When you're trying to compete with a huge incumbent you always have the Wine vs. Qt/GTK question, where you have to choose between compatibility and design freedom.

But even when you choose compatibility and reimplement the incumbent's API, you don't want to do it using their servers. What happens when they suddenly change the protocol they never promised not to change?

Their clients would have to be updated as well, so there would be an indefinite period of time where the unchanged protocol still works giving microG a chance to upgrade as well.

Google has all the data that makes it work + you would need to analyze all that data to end up with server that can take radio levels and output location. It's not as easy saying lets use our own servers.

If google were nefarious, they can secretly ship a new version that supports both versions of the protocol, wait weeks, months, or even years for it to become installed almost everywhere, and then silently remove support for the old version from their servers.

That would give microG zero time to prevent their software from working uninterrupted.

That sort of thing can happen for all sorts of legitimate reasons, it's not necessarily nefarious. For instance if the client side of the project is running ahead of the server side, rollout may begin with usage controlled by server-side variables. Once the servers are ready to go, usage may be ramped up much faster than software rollouts themselves happen.

Also IIRC the Google services are updated automatically in the background anyway by the Play Store app. So I guess rollouts can happen quite quick regardless.

OsmAnd appears to work fine on my phone, which as far as I know does not have any of Google's proprietary components currently installed (by way of a vanilla CopperheadOS install).

You need a location service provider for OsmAnd to work. Not sure what CopperheadOS pre-installs, but it could well be microG.

You need a location service provider, which can be fulfilled by GPS or network location. You don't need the fusion location provider, which is the proprietary one.

I think you're underestimating the number of 3rd-party apps that use the Google APIs. This dependency is in no way restricted to Google-branded clients like Maps and Play - the APIs are required for the majority of behind-the-scene things, not least anything involving location (including in most OSM clients).

GNU/Linux-style package manager for Android is F-Droid, which bans apps that depend on Google's APIs. The effect of this policy can be clearly seen in the dearth of apps on F-Droid.

No. 99% of users are not going to want a Linux style package manager. That's not a solution that will work in any way for normal people.

The main difference between a package manager and an app store is that a package manager can allow you to install apps from more than one source and can do proper dependency management. What part of that is supposed to frighten the townsfolk?

Why not? I'm personally aware of plenty of normal people for whom that works perfectly well.

If you truly think Android is an open system you might want to read this eye opener:

http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-...

I think this article, while informative, could stand to be a little more charitable towards the Android team.

Another perspective: Karim Yaghmour, author of Embedded Android, a book I highly recommend for anyone looking to learn about how the Android platform works, writes, "despite its awkward development model from an open source community perspective, it remains that Google's work on Android is a godsend for a large number of developers. Plus, it has accomplished one thing no other open source project was ever able to: created a massively successful Linux distribution. It would, therefore, be hard to fault Android's development team for its work."

Saying things like "the second you try to take Android and do something that Google doesn't approve of, it will bring the world crashing down upon you" diminishes how much the AOSP does. Because of AOSP, developers and tinkerers have dozens of popular choices for custom ROMs and custom kernels that can be flashed on a bootloader-unlocked device. Google itself tries to make getting bootloader-unlocked devices easy, though carriers and OEMs often have their own policies.

On the other hand, Skyhook v. Google (http://www.gpsbusinessnews.com/Google-Settles-Litigation-wit...) is compelling evidence that Android's value to the rest of Google is as a medium for presenting Google apps and services.

Taken altogether I think the most fair evaluation is that Android's ubiquity is valuable to Google, but that doesn't mean its open-source-ness is any less valuable to developers and users.

I honestly don't think Google needs anyone's charity. And bear in mind that Ron Amadeo is far from a anti-Google critic here. He's a former writer for Android Police, a fan blog. I've found his articles incredibly fair.

Thanks for the post, It really is an eye opener!

This is not totally true. Andoid itself is very much open, you are correct. However, there is a significant portion of userspace applications and services provided by Google that ARE NOT OPEN AT ALL, and are heavily depended on by the majority of the Android ecosystem. That is what it looks like this project is trying to address.

If you've ever installed a 3rd party distribution of Android based on the open source project (AOSP), you know how hamstrung things are after a fresh install until you drop Google closed source apps in.

There are two different meanings of "operating system" depending on context. One is the old computer sciency definition which basically just encompasses the kernel and essentials, the colloquial and more common one is the definition that means the de facto application platform.

In your CS interpretation, OS X is also an open source OS since it's proprietary bits on top of the open source Darwin OS.

I don't know much about Android, is this FUD and/or not really relevant?

https://twitter.com/CopperheadOS/status/772592323112869888

https://www.reddit.com/r/Android/comments/516z23/according_t...

What blobs is this guy talking about? Device drivers and/or the APKs that support them? Those have existed since forever. Google used to publish them to the AOSP repo. If they've stopped doing that, it's not that important, since they can be easily extracted from the system images, or from the devices themselves.

Google apps/libs? That's a growing problem, as more and more apps are starting to rely on those, hence MicroG.

One of the problems is that the blobs are preoptimized and stripped. You can see some of the crazy hoops people are jumping through to make AOSP work here, https://github.com/anestisb/android-prepare-vendor

What's obvious is that google isn't building AOSP themselves at all anymore and it's suffering from neglect.

He is talking about the possibility to build AOSP without certain propriatry (native) libraries that are used to communicate with the device components. While you always need them at runtime for a lot of features (but some devices run in wifi-only mode without prorietary libs) it was possible to build without them because of the way they're linked. This was changed in Nougat where it became impossible to build the source code for certain Nexus devices, because during build process there are references to the source code of some proprietary libraries. I had this problem myself while building AOSP for Nexus 5X and can confirm it.

Stuff like the VoLTE calling apks – those are now shipped as precompiled .oat libs, but CopperheadOS has to recompile them to get properly verified boot with the same key for all system APKs.

They can’t do that anymore.

Completely the opposite: Android has never been as proprietary as it is today. Almost every app you can get on your phone requires Google's proprietary services. Even Google's direct competitors, like Microsoft. Neither Skype nor Outlook run without Google's proprietary spyware installed.

Yep, Google have said as much. One of the cited motivations is that devices don't get major OS updates, so it's better to move platform infrastructure under Play services. (They could have done this in an open way too, of course...)

Google is very good at coming up with benign official motivations for decisions that just so happen to also result in them getting access to more of your personal data.

That was a choice made by Microsoft to enable those services at the app level - that does not take away from the argument that the operating system is open.

It's like saying Linux is more proprietary because Oracle is closed and runs on Linux.

No, that's a strawman analogy. Almost every major app is built on Google's proprietary fork of Android. Android, as an open source project, has a nearly nonexistent distribution, globally, and has almost no apps that run on it.

This is more like if 9 of every 10 apps required a Red Hat subscription, and you said "but technically it's built on an open operating system".

Really... The fact that many of those apps run on Amazon's FireOS version of Android completely disproves your point.

Most of them do not. The use of any of Google Play Services features must be stripped out, in most cases hamstringing or losing functionality. Not to mention that they all then must be uploaded via Amazon's own store, kept up to date, and let's really hope that your interactions don't include upswiping.

And most of them do because they've been modified to work without Google services. As for keeping those Amazon versions up to date - that's not Google's problem. It's the developer's / Amazon's problem.

I recommend you check your facts before you open your mouth. Check the version of the Skype app in the Amazon Appstore. Then download that version, try to sign in, and discover it doesn't work anymore at all. :)

Because I did all of those things, before I gave up and bought a Windows device. Which isn't open either, but at least is honest about it.

So you're blaming Google for a Microsoft issue in failing to update their Amazon app? Maybe you should check your facts next time.

No, the issue is that their current application is now dependent on Google's proprietary infrastructure, because Google has moved away from an open source application platform.

Skype is relying on proprietary infrastructure anyway?!?

So? The point is, there is no up to date version of Skype for Android. There is one for Android-based Google Play platform, but none for Android itself.

Android lacks apps so badly it's almost unusable. People should stop calling Android open when in fact they mean Google Play platform and do not realize what's really left there when you leave it pure Android.

I have to use Skype's infrastructure to use Skype. Obviously. That doesn't mean my data should also be transiting Google's infrastructure as well. Especially if I supposedly have an open source phone.

MicroG is to Google's AOSP (for mobile), what PureDarwin[1] is to Apple's Xnu[2] (for desktop).[3]

[1] http://www.puredarwin.org/

[2] https://github.com/opensource-apple/xnu

[3] Almost, sort of.

> Rather the author seems to be trying to redefine "operating system" to include things that have never been a part of such a term before, like online message routing and mapping services. Since when do we define "operating system" as including libraries for specific online services? User interface libraries, kernels, drivers, multimedia frameworks, sure ... but mapping services?

Mobile devices have an expectation of having more built-in features than other devices, so it makes sense that we would expand what we define as an OS.

Not to mention that the map services are implemented as core pieces of the OS within Android, so it's very much like having a proprietary libc with other proprietary libraries. You could create a program that doesn't use libc, but nobody does that because of duplicated effort (and the fact that Google won't hold your hand if you don't use their libc).

So I would very much argue that Android is on the path to becoming even more proprietary (it always was proprietary, just because of the fact that effectively all phones require blobs in the kernel as well as other firmware that is updateable but is proprietary).

More and more of Google apps depends on Google Play services, and that isn't open-source at all.

AOSP might be open-source, but running Android without these services makes it much less usable.

And some systems built into Google Play Services like SafetyNet have their purpose and their reason of being present (Android Pay and ensuring the stored data remain secure), but in some case they might stop an enthusiastic user of using a customized version of the OS because of missing features.

So replace "operating system" with "important parts of Android". Now does it make sense?

That sounds to me analogous to calling GNU an operating system. But then again maybe I misunderstand how GNU perceives itself.

Its comments like "it’s also on the way to become a proprietary operating system" which turn me off supporting something like MicroG. I like the idea, but it such a gross mischaracterization of Android and it leads to uninformed people to believe weird things. Over on Reddit I often see people thinking Play Services is absolutely required to make an Android app. Which is just not true, I know from personally experience that Play Services is easily replaceable with other App Store SDKs. Also as you have said, Play Services deals solely with communication with Google.

It also reminds me of when Cyanogen became a business. It was sorta interesting at first until I listened to the CEO talking about putting a bullet in Google's head. Now Cyanogen tries to sell app space on its users devices.

Mischaracterization in what sense?

With the new deep Doze modes in Android, FCM is becoming integral to stuff as simple as push notifications (since FCM is supposed to be what wakes up the phone).

The APIs that let you do stuff like nearby communication are also getting locked down. From 6 and up you can't get a Bluetooth MAC address for Rfcomm without a system level permission, conveniently Googles Nearby API gladly gets around that.

I work on hardware without Play Services and I think what you're forgetting is stuff like FCM requires Play Services. FCM isn't an end all be all BaaS, but it's getting more and more ingrained in how Android works, and it's a little scary

Google is constantly pushing their proprietary APIs so a lot apps in practice only work with play services, if you even can get hold of them without the Play store app. they also abandon more and more of the AOSP builtin Apps, new features and are added mostly only to the proprietary counterparts. So a lot of things people might attribute to Android are in fact part of the Google Apps. The direction is clear and AOSP is entirely controlled by google, they could simply decide to not open the next Version or parts of it.

I know from personal experience how hard it is to actually use AOSP phone. I eventually gave up, installed microG and started using apk mirrors, which makes things a lot better, though not ideal yet.

There's F-Droid which is bringing some hope, but pure AOSP with F-Droid still cannot even compete with Nokia N900.

I tried rolling the Google-free Android strategy for a while, but I found it was so unusable I took the first non-iPhone path off Android I could find. It's just too much frustration to try to deal with all the missing pieces. Currently I'm using a Lumia 929, but I'd kill for like an Ubuntu phone or something that works on Verizon.

Yes, what does that have to do with Android becoming a "proprietary operating system". Web services are integral in a modern smart phone. Google adds their own to Android. Others do as well, for example MicroG, Amazon, MIUI, etc.

Android as a useable system is not open at all. If you attempt to install say a native Debian system onto a phone it will fail because of unsupported hardware (I don't consider useable something with no audio or networking, touch screen etc), so you must rely on precompiled binaries ripped by some Android ROM. At the same time, if you strip Android of all closed source code, the resulting image could probably be installed only on a virtual machine. So though technically we can agree on Android being mostly OSS, that "mostly" part alone would be unsatisfactory for about all users. That makes Android a closed system to me.

about DroidGuard: https://github.com/microg/android_packages_apps_GmsCore/issu...

> Since when do we define "operating system" as including libraries for specific online services?

Since apps started relying on Google's proprietary Android components. This problem is apparent on ROMs which do not include GApps (like CyanogenMod by default and - in my case - CopperheadOS); there are plenty of applications which depend on things like Google Play Services (Slack being among them), for example. It's very similar (albeit not quite as severe) as the macOS ecosystem's dependence on a proprietary framework (Cocoa) despite otherwise running on a FOSS platform (Darwin).

> Android is not on its way to becoming a proprietary operating system, it's as open as it's ever been.

So how do you go about to modify software on your phone? I love it all, but pretending as if Google is not skewing the ecosystem in a way to maintain control is a bit naive. There is economic reason to do so, but it clashes with the intrerests of the wider ecosystem.

> In the case of Maps (which I worked on some years ago) it's because Google's licenses for some data sets are specific to Google, they aren't allowed to just throw it all out there via an open protocol,

Hm, so HTTP is not an open protocol?

The "proprietary" protocols are unlikely to be replaced, since this would disable probably 30% of phones in the field. (not all update play services)

> [...] The microG implementation contains fake data that is sent back to the servers. This risks legitimate users being mis-identified as abusers [...]

The straight forward approach for any malware or threat this system is up against. - If this causes "good" users to be excluded, then google messed up big time. - I assume they anticipated this, making the point moot.

I see no malicious intent here and see no reason to be upset.

>trying to redefine "operating system" to include things that have never been a part of such a term before,

That ship has sailed. All mainstream users expect those things to be standard in any mobile OS.

> it's as open as it's ever been

You're out of the loop. A lot of apps/APIs/frameworks which were maintained as part of AOSP have been abandoned to the point of being useless after Google introduced proprietary playstore versions.

>Given that both the protocols and client libraries can change at any time without announcement,

How do you then claim that android is "as open as it has ever been", when this was not the case before since android had fewer proprietary libs.

With things like Doze, the only thing that can wake the device is a push message FROM GOOGLE.

That doesn't sound open in the least.

"The underlying theme connecting these libraries is that they're clients for Google's proprietary protocols."

Protocols which are quite difficult to change out. If you're a person who doesn't want to use Google's maps, you're SOL for most applications that show maps within the app, as most of them are using Google, because it's easy. Whereas if the location services were just a system plugin, the user could choose the mapping data provider they wished, and the app would just receive map data and continue as normal.

> With things like Doze, the only thing that can wake the device is a push message FROM GOOGLE.

That isn't entirely true: https://source.android.com/devices/tech/power/mgmt.html#doze

You still have the choice to use many different mapping applications within an app you create on Android - Bing, Where, Mapbox, OpenStreetMap etc.

If you're using an app created by another developer that uses Google Maps as part of its functionality - you have no right to change that anyway.

I run Cyanogen Mod on my phone without any Google services. I would like to see local bus times on my phone, but the app for that won't run without the Google map API. It's the same with many other day-to-day things I would like to do with my phone, but can't. Android without Google is a hobbled and limited experience.

> you have no right to change that anyway.

§69df UrhG

> zur Herstellung der Interoperabilität des unabhängig geschaffenen Programms

"For purposes of interoperation with an independently created software", decompiling and modifying software is legal.

So, yes, under German (and in general also EU law), you have the right to do exactly that.

The point is, there should be a plugin system, where the developer doesn't have to care what the mapping API is, so the user can slot in whatever they want.