Our sandboxed Google Play compatibility layer is open source code shipped as part of GrapheneOS which enables optionally installing and running Google apps as regular apps in the standard app sandbox without any special access, control or privileged integration into the OS.

In order to make it easy to install sandboxed Google Play, our App Store provides mirrors of the official releases. These have through extensive testing by users either opting into the Alpha and Beta channels for those in our App Store along or Beta releases in the Play Store.

Our compatibility layer teaches Play services and the Play Store how to function as regular apps via the standard Android APIs and permissions. It’s not necessary to grant any permissions to either of them in order to use them and provide compatibility with near 100% of apps.

Apps with mandatory or optional dependencies on Google Play are including Google Play libraries in their app. Many of these libraries such as Ads and Analytics work fine without Google Play services. These libraries could do everything sandboxed Google Play can do without it.

For example, Google could include fallback code in the Firebase Cloud Messaging library to support receiving push messages through a service run by the app itself. Google could also support using Play services and Play Store as sandboxed apps. We’ve shown it works fine that way.

It’s important to understand that our approach is not granting any access to them or allowing them to do anything they couldn’t do without it.

Our compatibility layer demonstrates a regulator could reasonably require Google to not use capabilities unavailable to regular apps.

Our approach also allows us to reimplement arbitrary portions of Google Play ourselves. For example, we reimplement the Play services location service by using the OS location service. By default, apps using Google Play location are redirected to standard GrapheneOS location.

We provide emulated network location support to use apps depending on network location without it. We’re in the process of implementing our own network location client with support for choosing between multiple services. It’s currently being tested and polished up to ship it.

Our opt-in network location that’s going to be shipped soon is not tied to Google Play compatibility. It’s available to any apps using the OS location API. Our default enabled redirection means that apps using Google Play location will transparently use this when it’s enabled.

We’ll also be providing support for using Apple’s location service or a GrapheneOS proxy to it as the starting point. We’re also going to be providing our own location service based on our own database built from data scraped/merged from multiple sources which is entirely legal.

Our own network location service will support downloading regional databases to use it entirely locally without sending location data to a service. We plan to provide the same features for the SUPL service used for A-GNSS which currently defaults to a GrapheneOS proxy to Google.

We’re also going to be providing our own implementation of geocoding (converting addresses to location) with a choice of providers which is currently in an experimental state. We can very easily host that ourselves too. We’ll be doing the same for many other things over time.

Our position is that useful features should be directly provided in the OS disconnected from Google Play compatibility. Apps using Google Play for it can be redirected to using the OS implementation instead with a toggle for it. We can also unify it with the provider toggles.

For network-based location, it’s completely legal for us to scrape enormous amounts of data from publicly available services not even requiring accounts to combine into our own multi-source database. It will allow us to provide non-satellite-dependent offline location detection.

We have additional extensions beyond the baseline compatibility layer to support Android Auto. It’s disabled by default, and Android Auto is a regular sandboxed app when installed. Users can choose to grant it extra USB access to use wired Android Auto. Wireless needs a lot more.

We have a separate toggle for Wireless Android Auto because we weren’t able to avoid it requiring any sensitive access as we were with wired Android Auto. We eliminated most of the access needed for wireless Android Auto but it still requires a lot of Wi-Fi/Bluetooth access.