MicroG Project: A re-implementation of Google's Android apps and libraries(microg.org)
microg.org
MicroG Project: A re-implementation of Google's Android apps and libraries
https://microg.org/?=
168 comments
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-...
> 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
[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"
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.
>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.
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.
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?
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.
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 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.
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.
[deleted]
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.
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-...
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.
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.
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.
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...
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.
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.
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.
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.
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".
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.
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.
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.
[deleted]
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.
[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).
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.
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.
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
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.
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).
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.
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.
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.
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
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.
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.
§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.
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'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).
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).
Cool! Do you have any blog post explaining how to do it?
This is not very detailed but it might help: https://blog.adilparvez.com/post/2016/10/31/1/cyanogenmustar...
>Signal: End-to-end encrypted messaging over the internet. (You can get it on APKMirror.)
Isn't that a good way to get a modified / malware version of Signal? Anyone can upload to APKMirror, can't they?
Isn't that a good way to get a modified / malware version of Signal? Anyone can upload to APKMirror, can't they?
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.
[1]: https://fdroid.eutopia.cz/
[1]: https://fdroid.eutopia.cz/
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.
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.
This is a very clean and straightforward article demonstrating how to do it! Nice work.
the Izzy on droid blog has a series of posts about it: https://android.izzysoft.de/articles/named/android-without-g...
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.
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.
It's nothing complicated or special. Just install your AOSP-based ROM of choice, and only use software from F-Droid.
Only once f-droid stop being such big security hole.
In which way is it a security hole?
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.
Thats not entirely correct, if the build is reproducible the upstream apk with the upstream signature can be published:
https://f-droid.org/wiki/page/Deterministic,_Reproducible_Bu...
Oops, I didn't know about that feature. Thanks for pointing that out!
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?
Edit: [0] https://f-droid.org/wiki/page/Setup_an_FDroid_App_Repo
Edit: [0] https://f-droid.org/wiki/page/Setup_an_FDroid_App_Repo
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.
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.
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.
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.
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.
OT and FYI: I think you meant 'censor' instead of 'sensor'
Oops, was writing on my mobile. Can't edit it now, thanks though.
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.
See Moxie's explanation here: https://github.com/WhisperSystems/Signal-Android/issues/127#...
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.
In other words, moxie is wrong. Again.
In other words, moxie is wrong. Again.
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_...
What do you mean?
See Moxie's explanation here: https://github.com/WhisperSystems/Signal-Android/issues/127#...
The whole thread is a good read too haha
The whole thread is a good read too haha
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.
And apparently f-droid has reproducible builds now.
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.
[0] http://www.theverge.com/2013/8/15/4625502/microsoft-responds...
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.
[0] http://www.theverge.com/2013/8/15/4625502/microsoft-responds...
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.
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.
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...
[1] http://forum.xda-developers.com/showthread.php?t=1715375
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...
[1] http://forum.xda-developers.com/showthread.php?t=1715375
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.
Apps put a lot of effort into working on old Android devices, they actually have a pretty good position in this respect.
While they certainly have some catching up to do every now and then, it's been working for me pretty well for over a year, now.
The only real answer is to stop using operating systems and software developed by Google entirely.
While severely Stalman, your point is valid. But, the apps momentum will never allow that to happen.
Oh, I'm definitely not particularly Stallman. Stallman wouldn't be carrying a Windows phone.
If you want to go GApps free, I recently wrote about this. It's very short but points to where to find more.
https://blog.adilparvez.com/post/2016/10/31/1/cyanogenmustar...
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.
Also this might be useful a desktop play store client: http://www.onyxbits.de/raccoon
Also this might be useful a desktop play store client: http://www.onyxbits.de/raccoon
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 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.
Previously : https://news.ycombinator.com/item?id=11373435
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, ...?
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've been using MicroG on my phone for several months. Works very well.
This will be popular in China, where phones that run Android but not Google services are big.
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.
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.
Any issues with app security, hacking, etc?
Or random apps able to monitor the SMS, voice calls?
Or random apps able to monitor the SMS, voice calls?
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.
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.
the WINE team is comprised of 100% sorcerers.
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.
This is completely and totally wrong, FWIW.
The federal circuit ruling was that apis are copyrightable, so ....
Google won on fair use.
Google won on fair use.
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.
already there and heavily relying on EU software directive 2009/24/EC :)
You must have missed the CAFC ruling that declared API's copyrightable.
Oracle is appealing that decision. The case is going before the CAFC, which means a likely win for Oracle.
>The case is going before the CAFC, which means a likely win for Oracle
LOL Really? A likely win? The CAFC isn't going to overturn a jury verdict.
LOL Really? A likely win? The CAFC isn't going to overturn a jury verdict.
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.
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.
> The case is going before the CAFC, which means a likely win for Oracle.
Frankly, everything else would be a travesty.
My personal wet dream is that in response to this, Google will partner with Microsoft to get dotNET as a VM backend.
Frankly, everything else would be a travesty.
My personal wet dream is that in response to this, Google will partner with Microsoft to get dotNET as a VM backend.
LOL.
"dotNET"? sometimes I just don't know where people come up with their capitalization schemes.
Oh jeez, I'm so sorry for pointing out that .NET has literally never been branded as "dotNET".
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.
[deleted]
They still might have an ounce of the hacker spirit in the company - so maybe they'll be lenient!
Jokes aside, implementing a program with the same API should be fine, right? Would love to hear from someone better versed in copyright law!
Jokes aside, implementing a program with the same API should be fine, right? Would love to hear from someone better versed in copyright law!
> 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.
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.
Middle of still. Oracle filed for appeal of their most recent loss[0].
[0] http://arstechnica.com/tech-policy/2016/10/its-official-orac...
[0] http://arstechnica.com/tech-policy/2016/10/its-official-orac...
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. "
https://developer.amazon.com/public/apis/experience/maps/doc...
"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. "
https://developer.amazon.com/public/apis/experience/maps/doc...
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.
Nearly the entire point of the project is to have an Android system that isn't reliant on Google services.
Edit: I see I misunderstood. This page talks about opting in to Google services: https://github.com/microg/android_packages_apps_GmsCore/wiki
So they are using them.
Edit: I see I misunderstood. This page talks about opting in to Google services: https://github.com/microg/android_packages_apps_GmsCore/wiki
So they are using them.
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?
They could use their safetynet to check
> But won't Google have any objections on the licensing and patents regarding reimplementation of their stuff?
They'll sue you for using Java.
They'll sue you for using Java.
It would be cool if these + standard AOSP APIs can run as a window on top of regular Linux. (X, KDE + OpenGL, or Ubuntu).
(Natively and not as slow emulator/VM).
Maybe that will unify the Linux Mobile, Desktop, Tablet better than the Gnome?
(Natively and not as slow emulator/VM).
Maybe that will unify the Linux Mobile, Desktop, Tablet better than the Gnome?
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.
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.
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.
Then perhaps they should use software that is not dependant on Google rather than harass developers to degrade their apps to conform to their desires.
> perhaps they should use software that is not dependant on Google
Isn't this what MicroG does?
If you're referring to the system as a whole, the only real alternative is ios, which is far worse in terms of user control over what the system does.
In an ideal world, I would be running some linux distribution on my phone and be finished with it. We don't live in an ideal world.
Isn't this what MicroG does?
If you're referring to the system as a whole, the only real alternative is ios, which is far worse in terms of user control over what the system does.
In an ideal world, I would be running some linux distribution on my phone and be finished with it. We don't live in an ideal world.
By your logic, an emergency brake in my Ford Escape will be usable only if I have their sync software on the system.
Gps is a basic selling feature, get over it.
Gps is a basic selling feature, get over it.
By your logic Chinese cars shouldn't work at all and yet they do. Get over that.
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.