# microG GmsCore: A Free Replacement for Google Play Services

> microG GmsCore reimplements the Play Services interfaces that Android apps bind to, so they can run on systems without Google's stack. Here is what it actually covers, how to install it, and where it stops.

**microg/GmsCore** — Free implementation of Play Services

- Repository: https://github.com/microg/GmsCore
- Website: https://microg.org
- Stars: 14,717 · Forks: 3,222
- Language: Java
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/microg-gmscore

## What GmsCore replaces, and for whom

Google Play Services is not a normal app. It is a set of Android services that other apps bind to at runtime, and it ships with the device rather than being installed from a store. When a ROM or a device has no Play Services, apps that call those interfaces either crash, silently lose a feature, or refuse to start. microG GmsCore is a FLOSS framework that provides those interfaces again, so an app written for Play Services can run on a system where Play Services is not available. That is the whole scope of the project, and the README states it in one sentence.

The audience is narrow but real. It is people running an Android build that deliberately excludes Google's stack, and developers who want to check whether their app's Play Services usage has a free counterpart. It is not a general-purpose Android utility, and it does not add features to apps that never used Play Services in the first place. If every app you run is self-contained, GmsCore has nothing to do on your device.

## The module layout mirrors the Play Services SDK surface

The most informative thing about the repository is its top-level directory list. It is not one monolithic service. It is a series of Gradle subprojects named after the Play Services client libraries: play-services-auth, play-services-base, play-services-location, play-services-maps, play-services-gcm, play-services-iid, play-services-cast, play-services-fitness, play-services-games, play-services-pay, play-services-mlkit, play-services-nearby, play-services-fido, play-services-cronet and more, alongside separate firebase-auth and firebase-dynamic-links trees. That layout is a map of what the project has chosen to reimplement, module by module, against the API each client library exposes.

Two entries stand out for what they say about the mechanism. play-services-core is where the service implementation lives, and play-services-core-proto holds protobuf definitions, which tells you that some of the wire formats are reproduced rather than guessed. Then there is fake-signature. A module with that name exists because Android's signature checks would otherwise reject a service that is not signed by Google, so the project carries code to present the expected signature. That is the single most important architectural fact about GmsCore: it does not merely implement behaviour, it also has to satisfy identity checks that assume Google's signing key.

The topics list on the repository (auth, cloud-messaging, firebase, geolocation, maps, push-notifications) matches the module names, and it is a reasonable summary of the ground covered. What it does not tell you is completeness per module. The README does not publish a compatibility matrix, so the only way to know whether a given app works is to check which play-services-* subprojects it binds to against the directories that exist.

## Installing microG GmsCore: where the project points you

The README does not contain install steps. It says to refer to the wiki for downloads and instructions, and the homepage field points at microg.org. There is no package name, no version string and no command in the README itself, so anything beyond that would be invention. What the repository does give you is the source tree and its build entry points.

The top level contains a Gradle wrapper, gradlew, together with gradlew.bat, build.gradle, gradle.properties and a gradle/ directory. Those are the files a checkout build would go through. The README does not spell out the invocation, so the entry point to look at is the wrapper script named in the repository root:

```bash
./gradlew
```

On Windows the same wrapper appears as gradlew.bat, which is the batch counterpart listed alongside it:

```bash
./gradlew.bat
```

There is also an Android.mk at the top level, which indicates the tree can be built inside an AOSP-style source tree rather than only through Gradle. The README does not document that path, so treat it as a build-system entry point you would need to read the makefile to use.

For a first real use, the honest sequence is: get the build or APK from the wiki, install it on a device or ROM that has no Play Services, then open an app that binds to one of the covered client libraries and see whether it starts. The README gives no expected output and no verification command, so there is no documented way to confirm success other than the app's own behaviour.

## Where GmsCore is the wrong tool

The directory list is the limitation. It is long, but it is finite, and it is visibly uneven. There are entries for ads, cast, fitness, games, pay, panorama, places and drive, but a directory existing is not the same as the API behind it being complete. The README makes no completeness claim at all, and there is no published list of supported or unsupported APIs. If an app depends on a Play Services surface that has no corresponding subproject, or on behaviour inside one that has not been reproduced, GmsCore is not a substitute and no amount of configuration will make it one.

The second boundary is the fake-signature module. Signature spoofing is what lets a non-Google service answer calls made by apps that verify the caller. That mechanism has to be permitted by the ROM, and the README does not describe how a given ROM grants it. On a stock, locked-down Android build the whole approach can fail at the identity check before any service code runs. That is not a bug to file; it is the design meeting a platform that was built to prevent it.

Finally, GmsCore is the wrong tool if what you actually want is Play Services. It reimplements interfaces, not the backend. Anything that requires Google's servers to answer will not be answered by a local reimplementation, regardless of how many modules are present.

## How it differs from shipping the real Play Services

The obvious alternative is simply to install Google Play Services, which is what most Android devices already have. The difference in approach is total. Play Services is a closed binary distributed by Google and updated on Google's schedule; GmsCore is Apache-2.0 source that you or your ROM vendor build and ship. The first gives you the complete, current API surface with no control over what runs; the second gives you a partial surface you can read, modify and rebuild, and the gaps are yours to live with.

That trade is the reason the project exists, and it is also why comparisons between the two on feature count miss the point. If your requirement is maximum app compatibility with minimum effort, the real Play Services wins on both counts, and GmsCore is not competing there. If your requirement is a device with no Google binary on it, GmsCore is one of the few options that keeps Play Services dependent apps running at all, and the missing pieces are the price of that constraint.

A second alternative is to patch the apps instead of the platform, which is where the ReVanced-related searches come from. That is a different layer of the stack: it changes the app, while GmsCore changes what the app can bind to. The README does not discuss ReVanced, so the relationship between the two is not something the project documents.

## Maintenance, releases and the Apache-2.0 terms

The repository is not archived, and the last push was on 2026-09-10, which is recent enough that the project is being worked on. Releases are tagged with a version and a build number, for example v0.3.16.252432 on 2026-07-14, preceded by v0.3.15.250932 on 2026-04-24 and v0.3.14.250932 on 2026-04-10. The cadence is irregular: two releases nine days apart in April, then a gap of roughly three months to the July tag. Anyone pinning a version should expect to track tags rather than a schedule.

Upgrade cost is the part the README does not cover. There is no migration guide, no changelog in the repository root, and no documented rollback procedure. The README is silent on what happens when a new release changes a service interface that an installed app depends on. For a component that sits between apps and the platform, that silence is a real operational gap, and it means upgrade testing is on you.

The licence is Apache-2.0, with the copyright line reading 2013-2025 microG Project Team. Apache-2.0 permits use, modification and redistribution, and it includes a patent grant; it also requires that notices be preserved and that modified files be marked. There is a LICENSES/ directory at the top level, which suggests bundled components carry their own terms, and those should be checked separately. This is a description of the licence text, not legal advice.

## Conclusion

Adopt microG GmsCore if you run an Android build without Play Services and need apps that bind to the Play Services interfaces, and check the wiki's downloads and instructions page before flashing anything. Do not adopt it if an app depends on a Play Services module that the repository does not contain, or if you need a locked-down device profile, because the fake-signature module exists precisely to work around signature checks. Verify first which play-services-* subprojects your target apps actually bind to, and confirm the current release tag against the version you install.

## FAQ

### What is GmsCore used for?

It is a FLOSS framework that lets applications designed for Google Play Services run on systems where Play Services is not available. It provides the interfaces those apps bind to, rather than adding features of its own.

### Is GmsCore safe to use?

The project is Apache-2.0 licensed and the source is public, so the code can be read and built. The repository includes a fake-signature module, which means the service presents a signature that apps and ROMs may check; whether your ROM permits that is a platform decision the README does not document.

### Where can I download gms core?

The README points to the wiki for downloads and instructions, and the repository homepage is microg.org. It does not list a download location directly.

### How do I install GmsCore on Android?

The README gives no install steps and directs readers to the wiki for downloads and instructions. Building from a checkout goes through the Gradle wrapper at the repository root.

### What apps use gms core?

The repository does not list apps. It is organised as play-services-* subprojects named after the Play Services client libraries, such as play-services-auth, play-services-maps and play-services-gcm, so an app is covered only if it binds to a surface that has a corresponding subproject.

## Sources

- [License: Apache-2.0](https://github.com/microg/GmsCore/blob/master/LICENSE)
- [microg/GmsCore on GitHub](https://github.com/microg/GmsCore)
- [Project website](https://microg.org)
- [README](https://github.com/microg/GmsCore/blob/master/README.md)
- [Releases](https://github.com/microg/GmsCore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microg-gmscore