I don't know about this. Android is not on its way to becoming a proprietary operating system, it's as open as it's ever been. 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?
The underlying theme connecting these libraries is that they're clients for Google's proprietary protocols. Sometimes there are good reasons for these protocols to be proprietary. 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, and they are expected to discover and block non-Google client apps. In the case of the Market, they want to defend against things like abusive install count inflation. They also like to redesign products and change features whenever they want. All these things are easier when you can change the protocol at will because there's only one client to support, and the client team sit next to the server team.
Note for example that the microG folks have had to implement "DroidGuard", a system that tries to spot scripting of Google's servers from non-approved clients. The microG implementation contains fake data that is sent back to the servers. This risks legitimate users being mis-identified as abusers and potentially having their accounts suspended. That risk must be understood by the microG authors but they don't inform you of it anywhere, which seems poor.
Given that both the protocols and client libraries can change at any time without announcement, I don't see how microG users will ever have stable devices. Nor do I see why they care. Even if they reimplement the client libraries Signal and other apps will still be dependent upon the proprietary servers.
If they want a version of Signal that's entirely Google independent the right thing to do is set up and run a competitor to the actual messaging service, not just reimplement a thin protocol wrapper and call it a day.
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.
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).
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.
> 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.
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.
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.
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, 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.
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?
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.
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.
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.
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.
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".
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
Will this, by any chance, increase the number of open-source apps available in f-droid? Every now and then, I spot a wonderful app that is only not available due to dependencies on one or two proprietary Google APIs or components.
I'm trying to run a totally open-source android installation, and have opted-out of Google entirely. It's worked out fairly well so far, but the app choices are fairly limited, of course.
I don't think f-droid will accept apps that have a requirement on the Google play services framework, even if you can somehow reproducibly compile against the microg version instead.
But it does mean you can install apps on the play store that have a dependency on gsf but are otherwise open-source (e.g. maps.me, signal, tomahawk).
There's an fdroid repo[1] for it, but I'm not sure I trust the person running it. Because of the lovely conversations with moxie the main fdroid repo got taken down. Don't you just love free software projects that hate giving users freedom.
That is a really good point, I actually got someone else to get it from the play store then copied it, the updates from apkmirror are then fine since the signatures match. I'll edit the post to say, get it from a trusted source.
This is also useful: http://www.onyxbits.de/raccoon
It's a dektop play store client.
I tried it out a while back and it worked, don't know about now.
Edit: The series is a little out of date, but should give you the general idea. ROMs that are probably new since that article was published that have no google dependencies are Replicant (entirely libre), OmniROM, Copperhead OS, and CyanagenMod w/ a no-gapps-script.
I think what OP is referring to is that the apps on F-Droid are not signed by their respective developers but by the people behind F-Droid. This is the reason (or one of the reasons?) for instance why Moxie from OpenWhisperSystems doesn't want Signal to be available through F-Droid.
Fdroid allows you to run your own repo and up your own builds. MicroG does this, so these are built by them. More devs should do this. Fdroid building everything isn't scalable nor is it a good trust paradigm. I agree with them that they should only build from source, but others should maintain their own. Email is federated, why not app stores?
Because adding a repo via some random online URL is the exact same reason why downloading random Windows executables creates tons of opportunities for malware to infect computers.
The whole point of software stores is giving users the ability to trust the motives of the software they install, because the store and / or its users would never condone hostile software being hosted there.
Once you start having everyone run their own F-Droid repos, you are having independent developers give you their own trust keys, but you have no one else who needed to verify those developers were legitimate.
F-Droid itself is not particularly secure, given anyone can upload anything there, but in the same way the Archlinux AUR, OpenSUSE Build Service, Ubuntu Launchpad, etc work those third party software repositories are at least hosted by a trusted maintainer of the store / repo itself. If anyone ever uploaded malware there, once found out, it would be taken down and the responsible users banned.
With distributed app stores under F-Droid, or the equivalent third party repos for Arch / Suse / Ubuntu, the host has absolutely no control over the behavior of third parties, and thus anyone can host all the hostile malware they want, and if users add those repos they give them absolute trust in doing so.
That isn't a valid security model by any estimation.
You trust Facebook when you log into Facebook.com. Facebook.com/fdroid would be the hypothetical trusted endpoint for Facebook apps. You should not have one gatekeeper that ensures everything is safe. They can sensor content, fail to catch something or prioritize some apps over others. Having a default repo where there are restrictions, rules and vigilance makes sense, but you should be able to opt into another circle of trust AND get notified of updates, changes, version numbers etc. If you can't trust a company enough to run their binary, then don't add their repo.
The alternative is download static apks today and maintain updates yourself(bad) or remove the freedom to install what you want on your device.
For the vast majority of software I imagine most users do not have a relationship with the vendor going in. Independent repos naturally can (and do) work for large software. For example, the Mega client for Linux is provided as its own self-hosted repo by Mega Ltd, where they provide repositories for most distros.
But for, say, an app for a restaurant or a document reader, you would not know or have any reason to trust the vendor, so if they are self-hosting their own repos you are taking a tremendous risk trusting them.
The end result would probably remain the same - users might use third party repos for huge popular apps, but small apps would still need to stay centralized because there is no way to introduce a viable trust model against an organization you never interacted with before.
I think people trust too much generally. That's not going to change with any paradigm put forth. However if you're running binaries from vendors you don't trust, you're playing with fire even in a regulated app store.
Most people don't change their default browser, adding third party repos would be similar. Removing the ability for the owner of a device to install software they want fixes one symptom, not the main issue of trust. Also it makes your device into a glorified feature phone. No thanks.
Isn't that precisely the same way it works on a normal GNU/Linux system, though? Packages are compiled and signed by Debian or Red Hat (or whatever distribution you're running), not by the original developer, and that's perfectly fine – in fact better, because there's some level of quality control being performed by the distribution packagers. Just like the F-Droid packagers.
Which is not correct. If F-Droid’s reproducible build system can get the same result as your own build, you can distribute your own, self-signed version through F-Droid.
To be fair, Moxie appears to have been right at the time of writing the linked comment according to the commit timestamp. Thanks to you (and the comment or above for the link) for pointing this out though. TIL. The documentation does say it is unlikely and other documentation has not been updated to point to this feature, such as the developer FAQ: https://f-droid.org/wiki/page/FAQ_-_App_Developers#Can_APKs_...
Even without reproducible builds, that's as "insecure" as any Linux distro. Frankly, I can very well live with the F-Droid maintainers keeping the signing keys.
This [0] is why we both need something like MicroG, and why Google will never allow it to succeed. I realize it's an old story, but it shows Google's ruthlessness in protecting platform dominance, even against a single-digit percentage Windows Phone platform. Even if MicroG ships good, working code, Google will break it. And if MicroG fixes that, Google will break it again, until the people writing MicroG give up.
I'd love open options instead of Google's services, but when 95% of your revenue is advertising, you have to own the platform, and Google does.
This is not entirely correct. Google has no possibility to break things in short time if they work exactly like the Google implementation. Although Google can update their clients through automatic updates there are still devices only connected via low-bandwidth and similar things which will receive the update heavily delayed. And finally there are devices that will never receive certain update.
Example: The Android Market API (yes android market, the name it had before play store) is still available and can be used, although it was replaced by a Play Store API years ago and there exist public client libraries for using it and the API is heavily used to grab free apps from the play store. However, as Google Play was never available for Android < 2.3 and there are still some users with this OS, the only way to disable this old API would be to remove Play Store access for a few hundred thousand users, which they refused to do until now.
I'm a little wary about projects like this. While it is true that Google Play Services kind of subverts the free nature of Android, it's also one of the only things that is keeping fragmentation from becoming a big(ger) problem. Google is unable to update the OS on every Android phone in the wild, but they can update Play Services as needed to patch critical security bugs or add new features. The more that developers rely on it, the more they are relying on something that will be properly maintained.
As another commenter said, they could, however, make parts (if not all) of their Android libraries open source without interfering with the goal of preventing fragmentation.
There were some attempts years ago, the author implemented the same stuff as MicroG does now, I wonder if MicroG is forked...
However 3 years ago I was super excited and got the Alternative Google Store (I think it was BlankStore) installed. It crashed randomly and I was not able to download any App. However I thought that the author would work on it and in some time it would be useable.
Still waiting for that day.
That's why I'm a bit pessimistic about this project...
A better way would be to implement a true container/vm system so google only knows what is in this container, no contacts, no calendar, no mails.
Heck, maybe it's even possible to link into that container for the host system apps.
Yes, the NOGAPPS Project[1].
I used MicroG on a Galaxy Mini (tass) running Android 4.4 based ROM. It is a bit tricky to get it running, but I got some of my paid apps running afterwards (I sideloaded the apk, extracted from my backup).
Using the phone with Google Framework and modern OS made it so slow, MicroG (at least when I used it) didn't make it any slower.
I found the Galaxy Mini thrown by it's owner, picked it up and flash the ROM for shit and giggles...
MicroG is in fact the continuation of the project or "attempt" you're talking about (NOGAPPS). It's still the same author, too. You're right though in that the BlankStore hasn't seen an update.
This is a really cool project. It is scary that there isn't a really open mobile platform a la desktop Linux as usable as Android as iOS when it looks like more and more computing will be done on mobile devices. This looks like a really smart way to let Android be what it claimed to be -- an open phone operating system.
While i wish them luck, i suspect they will be caught in eternal catching up mode. This because Google have a whole lot of programmer-hours to throw at adding and changing things.
I neglected to mention that the first time you install Signal it should come from a trusted source (e.g. copy it from someone who is happy to use the play store), then updating via apkmirror is safe, since the signatures will match.
I've heard people recommend Raccoon in the past but my phone is something so vital that makes me worried about stuff breaking (the combination of using a lot of 3rd party parts like MicroG, Racoon, apkmirror, ...).
I wonder if it's possible to dual boot without root and also keeping encryption on, that way I can have a safe option if anything breaks.
Damn, why is it so hard to have control over your things these days. It wears me down.
I've installed MicroG on my (supported) phone via their XDA threads (installed BlankStore,etc..), however some apps claimed to be working are not functional at all due to Google Apps dependencies.
Does anyone know what main apps actually work for an average phone user, i.e. Maps, CityMapper, Dropbox, ...?
Google Maps, Play Store DropBox and practically all apps requiring a Google account used to work fine for me. However, with the latest update of Maps, Maps stopped working, unfortunately, and just crashes upon start-up. I'm not sure, though, whether this is related to MicroG.
I live in China and I use MicroG / NOGAPPS since the early days.
But I really don't see why it should be of any interest for the average Chinese user?
The is a very healthy Android ecosystem here in China, independent of Google. For example apps usually depend on Baidu Maps / 高德地图 for viewing maps.
There is simple no reliance on any Google apps here. Payment is usually done with WeChat Pay or AliPay.
I would actually say it is more seamless than in the West.
The only strange thing is, that for app downloads usually the APK is directly linked - while still using the Play Store logo. That is because there are many different app store providers. However, as soon as the app is installed, it gets updated by that respective app store.
Amazing stuff. But won't Google have any objections on the licensing and patents regarding reimplementation of their stuff? If so what would be the implications?
Actually Google kind of screwed themselves there because just this year they set the legal precedent that all APIs are public domain so if they sued they would lose the case against oracle(and 8.8 billion dollars).
I would not call it 'screwed'. Yes, they established, that APIs are free to reimplement.
However, just having an API to follow does not mean, that the task of reimplementation is easy - following someone's else API is actually harder than designing your own. Just ask the WINE team.
That's actually not the argument that was made, as I understand it. The argument was that the Java API -- by virtue of being part of Java, which was openly released -- was also open. The APIs that MicroG is reimplementing don't seem to have been openly released in a similar fashion.
Then the microG developer just has to move to the EU, where APIs aren’t copyrightable, even if closed, and you have the right to reverse engineer existing software for interoperability with your own software, or for third-party reimplementations.
You overestimate the willingness of the American courts to render justice, play by the rules, or indeed make any sense.
According to the CAFC's ruling overturning Judge Alsup's initial decision that APIs are not copyrightable, APIs have enough unique expressikn in them to indeed be covered by copyright. Hackers are fond of a loosey-goosey, asterisk-ridden interpretation of copyright law under which copying is OK provided the author doesn't lose money in its primary line of business. (For example, that pirating abandonware is OK, etc.) The CAFC is considerably more strict and applies the letter of the law to copyright cases. While fair use is a concept ill-defined by statute, it is generally acceptes to mean extremely limited copying for express purposes, such as: scholarship, commentary, or parody. Google's copying of Oracle's Java API IP was extensive and directly related to their Android line of business. Therefore, any sensible court would rule that fair use doesn't apply, else American IP law has no meaning.
I did not downvote you, but the reason I used dotNET is that I don't want to keep in mind whether the markdown-flavor-du-jour interprets leading dots as special or not.
> implementing a program with the same API should be fine, right?
If this is all it comes down to, Google certainly should be fine with it being that they're in the middle of (end of?) a lawsuit with Oracle over their implementation of the Java API in Android.
Amazon has been providing drop-in replacement implementations of Google APIs (for proprietary Google services) for some time now. For instance:
"The Amazon Maps API offers interface parity with version 2 of the Google Maps API. Most classes and method calls in your Google Maps app work the same on Amazon devices. "
I would imagine the problems they might have with this project is that it, I assume, calls private remote Google APIs -- which would by definition be an unlicensed use.
What does breaking a terms of service mean legally though? Like they're spoofing the signatures so it all appears to google that it's the same, so I'm not sure how they'd enforce it?
Might be a good idea to reconsider the visual effect of these pages. It looks nice, but it is indistinguishable from genuine Google trade dress, which is a bit misleading.
Some People seem to think they're entitled to Google's Play Services without having to install Google's software. AOSP is entirely free and you can do with it as you please. If you want to run Android apps on AOSP then install FDroid, the Amazon App or any other free app store out there. This isn't about AOSP, it's about being jealous that they can't run Android apps that use Google Play Services and using any other app store is an insult to them. If you don't want to install GPS then be content with your free app stores and quit bitching about AOSP not being completely open. But, they want their cake and they want to be able to eat it too so they resort to complaining about Android not being open and trying to write shims to replace GPS so they can get their app fix on.
This isn't a question of entitlement. It's like being given a distribution that has a proprietary libc and then everyone losing their shit once you start re-implementing the libc because you don't want to run proprietary code.
GPS, maps and other such features are fundamental features of modern phones. They're no longer "additional addons" on a phone OS.
Also, many apps within FDroid still require some play services, and it's only because of microG that you can even use those free software apps. For example, Signal requires GCM and the project will not consider fixing this (and in fact demanded that FDroid stop distributing binaries). What is a user of that free software meant to do? Maintain a fork? People did that, but Signal won't federate. Move to another messaging service? Maybe, but there's nothing that matches Signal right now (I'm hoping that Matrix gets there soon so I can get the fuck away from Signal).
Personally I'm planning on rewriting some of the bus timetable apps for Sydney and using OpenStreetMaps instead of Google Maps. But I don't know if it's possible to have any form of meaningful GPS information without Google's proprietary services. I'm shit-out-of-luck as a developer, not an entitled brat.
* What people want is to run apps on their phones.
* Most apps now depend on google services because google actively promotes play services over base system services, and doesn't really invest in the later anymore.
* Many people don't want to run google services on their phones (Me included).
* MicroG solves this problem by replacing google services with equivalent services.
* People can now run the apps they want.
This has nothing to do with entitlement or google. This is a way for people to run software on their phones without needlessly going through google.
The underlying theme connecting these libraries is that they're clients for Google's proprietary protocols. Sometimes there are good reasons for these protocols to be proprietary. 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, and they are expected to discover and block non-Google client apps. In the case of the Market, they want to defend against things like abusive install count inflation. They also like to redesign products and change features whenever they want. All these things are easier when you can change the protocol at will because there's only one client to support, and the client team sit next to the server team.
Note for example that the microG folks have had to implement "DroidGuard", a system that tries to spot scripting of Google's servers from non-approved clients. The microG implementation contains fake data that is sent back to the servers. This risks legitimate users being mis-identified as abusers and potentially having their accounts suspended. That risk must be understood by the microG authors but they don't inform you of it anywhere, which seems poor.
Given that both the protocols and client libraries can change at any time without announcement, I don't see how microG users will ever have stable devices. Nor do I see why they care. Even if they reimplement the client libraries Signal and other apps will still be dependent upon the proprietary servers.
If they want a version of Signal that's entirely Google independent the right thing to do is set up and run a competitor to the actual messaging service, not just reimplement a thin protocol wrapper and call it a day.