Replacing Google with microG

A common criticism of free-software projects built for Android is that they all too often rely not just on the frameworks and libraries that are part of the official Android Open Source Project (AOSP), but on the proprietary APIs implemented in various add-ons from Google—such as the Google Maps API or the Google Cloud Messaging message-broker service. Working around these Google-supplied components is not trivial, but there is at least one effort underway to provide a drop-in free-software replacement: microG.

Google's proprietary Android service layer is currently called Google Play Services (although it went by other names in prior releases). It provides around a dozen APIs that link to online services run by Google; they include the Google Maps service, the Google Drive storage service, a network-based geolocation API, the Google Cast screen-sharing API, a social/sharing API for mobile games, and hooks for various services like Google+, Google Analytics, and Google Wallet. Google Play Services comes pre-installed in essentially all Android devices sold by major vendors or mobile carriers.

The importance of these APIs depends a great deal on what one wants to do. Certainly it is to be expected that Google's own Android apps will make use of the APIs. K-9 Mail does not depend on Google Play Services but Gmail, to no one's surprise, does. Where matters begin to get fuzzier is with apps like the Google Play Store app store itself: that app depends on Google Play Services, even if it is only used to download and install self-contained apps. While there are alternative app-installation and app-management mechanisms (F-Droid being the most familiar to the free-software community), they contain only a fraction of the main store's contents.

Where the issue peaks, however, is with Android apps that are, themselves, free software. Users wishing to have a fully free-software system (or to simply avoid Google products) can install AOSP alternative base systems like Replicant or CyanogenMod and either install apps directly from .apk packages or via F-Droid, but if a particular app uses one of the Google Play Services APIs, the device inherits that dependency in spite of all the groundwork. The pain felt by the would-be Google avoider is most keen where privacy- or anonymity-centric apps like Signal are concerned, since the APIs provide the potential for Google to fingerprint or track the device. At the very least, removing a dependency on Google Play Services is frequently highlighted as a feature in projects like Silent Circle's Blackphone and porting efforts like LibreSignal.

Free to the core

In general, there are two possible approaches to solving this dilemma: alter each app to replace Google Play Services calls with non-Google equivalents, or replace the Google Play Services framework itself. There are various efforts to patch out Google Play Services dependencies for individual free-software apps, but those efforts are, by their very nature, single-app solutions at best.

microG is an effort to take the latter approach instead. It grew out of an earlier project called NOGAPPS, started in 2012, that focused initially on the Maps and network-geolocation APIs. Early builds replaced Maps functionality with OpenStreetMap and the network-geolocation service with the Mozilla Location Service (MLS).

microG has since migrated to GitHub and expanded its scope, with the goal now stated as providing a "free-as-in-freedom re-implementation of Google's proprietary Android user space apps and libraries". The project's base library package is called GmsCore, which is designed to eventually serve as a full replacement for the Google Play Services library.

GmsCore currently supports the Cloud Messaging and network-geolocation APIs fully, and provides partial support for the Google Authentication API, Maps API, and Google+ API. That said, GmsCore is also known to cause crashes (rather than simple lack-of-functionality) for apps expecting the Google Auto and Google Cast APIs. The project also provides a stand-alone library package for the network-geolocation service (UnifiedNlp) and packages for two older APIs: the now-deprecated version one of the Maps API (mapsv1) and a stand-alone version of Google's Cloud Messaging library (GsfProxy).

In the past, the project had worked on a free-software reimplementation of the Play Store app itself, called BlankStore. That effort is no longer active, however, the project does provide a similarly named app called FakeStore. The purpose of FakeStore, though, is to fool other apps into believing that the authentic Play Store app is installed. Some apps will refuse to run otherwise. FakeStore, however, provides no other functionality.

At the moment, getting started with microG requires a fair amount of serious groundwork. First, only Android ROMs that support spoofing package signatures are currently supported. This is a bypass for the Android security feature that verifies the owner of the key used to sign packages. Spoofing allows GmsCore to pretend to be Google's actual Google Play Services library and FakeStore to pretend to be the official Play Store app, when other apps check for the presence of those specific packages. There are a few third-party Android ROMs that ship with that feature enabled; others will need to install a special package, patch their ROM, or build a custom Android ROM for their device.

Next, the real Google Play Services package must be removed if it was installed (and, with it, all of its dependent packages). Users can then install GmsCore, GsfProxy, and either BlankStore, FakeStore, or the real Play Store app.

Looking at the GmsCore wiki, one might think that only a few apps are supported by the limited functionality currently available: it notes only Signal, Play Music, and YouTube as known to work with the Cloud Messaging API. But the issue tracker tells a different story; users have reported quite a few functioning apps, including other popular offerings like Uber and Lyft, as well as various free-software apps like Matrix Console.

Mind the GApp

What any judgment on microG's viability comes down to, it seems, is an assessment of what constitutes an "important" app or API. No two users may ever agree on exactly where to draw that line. But, on that front, it is also important to remember that Google Maps is often cited as the "killer app" for Android. At the very least, many end users seem to find mapping and geolocation to be a critical feature: many other smartphone services boil down to little more than good network connectivity for general-purpose communication, but tying the device into its real-world location is a far more useful capability than Google Wallet's micropayments or any social-sharing feature found in a game.

Thus, it is undoubtedly a wise move for the microG project to focus first on the mapping and geolocation features. The project's team is still rather small: there are just 14 contributors to GsmCore, with founder Marvin W responsible for 85% of the commits. As the project's work gains more functionality and exposure, it will surely attract more contributors, although it will be a difficult battle to keep pace with the changes introduced in regular Google Play Services updates.

Perhaps the best chance microG has for widespread success would be to join forces with other like-minded free-software Android projects. The CyanogenMod community, for instance, has for years relied heavily on the quasi-legal redistribution of Google Android apps through projects like OpenGApps (which, despite the name, distributes only binary packages of the official Google apps). Having a real, free-software implementation of the needed libraries would be a boon to users and developers alike.

The Replicant and Blackphone communities would also likely find microG a welcome addition, removing a dependency on a large, proprietary blob and replacing it with a free-software package. Even further out, the fact that Google uses its Google Play Services framework as a (rather large) bargaining chip to keep Android vendors in line likely rankles some within the industry; losing access to the framework would mean a vendor must ship devices incompatible with many popular apps. Any project removing the power that Google Play Services holds over device-makers is surely valuable. Then again, microG has done quite well for itself so far; perhaps it has no need to change its game plan any time soon.