Usage guide
This is a guide covering some aspects of using GrapheneOS. See the features page for a list of GrapheneOS features.
Accessibility
GrapheneOS includes all of the accessibility features from the Android Open Source Project and strives to fill in the gaps from not including Google apps and services. We include our own fork of the open source TalkBack and Switch Access accessibility services along with a Monochromacy option for the standard color correction menu.
GrapheneOS does not yet include a text-to-speech (TTS) service in the base OS due to limitations of the available options. Including one is planned in the future when a suitable option is available. RHVoice and eSpeak NG are both open source and are the most common choices by GrapheneOS users. Both of these mostly work fine but have licensing issues and don't support Direct Boot so they cannot be used before the initial unlock of the device. Installing and setting up either one of these or another TTS app will get TalkBack working. TalkBack itself supports Direct Boot and works before the first unlock but it needs to have a TTS app supporting it in order to do more than playing the activation sound before the first unlock. After installing a TTS service, you need to select it in the OS configuration to accept activating it. The OS will display one of them as already selected, but it won't simply work from being installed as that wouldn't be safe. This is the same as the stock OS but it comes with one set up already.
GrapheneOS disables showing the characters as passwords are typed by default. You can enable this in Settings ➔ Privacy.
Third party accessibility services can be installed and activated. This includes the ones made by Google. Most of these will work but some may have a hard dependency on functionality from Google Play services for some of their functionality or to run at all. Accessibility services are very powerful and we strongly recommend against using third party implementations if you can get by well without them. We plan to add safeguards in this area while still keeping them working without problematic barriers.
Auditor
See the tutorial page on the site for the attestation sub-project.
Updates
The update system implements automatic background updates. It checks for updates approximately once every four hours when there's network connectivity and then downloads and installs updates in the background. It will pick up where it left off if downloads are interrupted, so you don't need to worry about interrupting it. Similarly, interrupting the installation isn't a risk because updates are installed to a secondary installation of GrapheneOS which only becomes the active installation after the update is complete. Once the update is complete, you'll be informed with a notification and simply need to reboot with the button in the notification or via a normal reboot. If the new version fails to boot, the OS will be rolled back to the past version and the updater will attempt to download and install the update again.
The updater will use incremental (delta) updates to download only changes rather than the whole OS when one is available to go directly from the installed version to the latest version. As long as you have working network connectivity on a regular basis and reboot when asked, you'll almost always be on one of the past couple versions of the OS which will minimize bandwidth usage since incrementals will always be available.
The updater works while the device is locked / idle, including before the first unlock since it's explicitly designed to be able to run before decryption of user data.
Release changelogs are available in a section on the releases page.
Settings
The settings are available in the Settings app in System ➔ Advanced ➔ Update settings.
The "Check for updates" option will manually trigger an update check as soon as possible. It will still wait for the configuration conditions listed below to be satisfied, such as being connected to the internet via one of the permitted network types.
The "Release channel" setting can be changed from the default Stable channel to the Beta channel if you want to help with testing. The Beta channel will usually simply follow the Stable channel, but the Beta channel may be used to experiment with new features.
The "Permitted networks" setting controls which networks will be used to perform updates. It defaults to using any network connection. It can be set to "Non-roaming" to disable it when the cellular service is marked as roaming or "Unmetered" to disable it on cellular networks and also Wi-Fi networks marked as metered.
The "Require battery above warning level" setting controls whether updates will only be performed when the battery is above the level where the warning message is shown. The standard value is at 15% capacity.
Enabling the opt-in "Automatic reboot" setting allows the updater to reboot the device after an update once it has been idle for a long time. When this setting is enabled, a device can take care of any number of updates completely automatically even if it's left completely idle.
Security
The update server isn't a trusted party since updates are signed and verified along with downgrade attacks being prevented. The update protocol doesn't send identifiable information to the update server and works well over a VPN / Tor. GrapheneOS isn't able to comply with a government order to build, sign and ship a malicious update to a specific user's device based on information like the IMEI, serial number, etc. The update server only ends up knowing the IP address used to connect to it and the version being upgraded from based on the requested incremental.
Android updates can support serialno constraints to make them validate only on a certain device but GrapheneOS rejects any update with a serialno constraint for both over-the-air updates (Updater app) and sideloaded updates (recovery).
Disabling
It's highly recommended to leave automatic updates enabled and to configure the permitted networks if the bandwidth usage is a problem on your mobile data connection. However, it's possible to turn off the update client by going to Settings ➔ Apps, enabling Show system via the menu, selecting Seamless Update Client and disabling the app. If you do this, you'll need to remember to enable it again to start receiving updates.
Sideloading
Updates can be downloaded via the releases page and installed via recovery with adb sideloading. The zip files are signed and verified by recovery, just as they are by the update client within the OS. This includes providing downgrade protection, which prevents attempting to downgrade the version. If recovery didn't enforce these things, they would still be enforced via verified boot including downgrade protection and the attempted update would just fail to boot and be rolled back.
To install one by sideloading, first, boot into recovery. You may do this either by
using adb reboot recovery from the operating system, or by selecting the
"Recovery" option in the bootloader interface.
You should see the green Android lying on its back being repaired, with the text "No command" meaning that no command has been passed to recovery.
Next, access the recovery menu by holding down the power button and pressing the volume up button a single time. This key combination toggles between the GUI and text-based mode with the menu and log output.
Finally, select the "Apply update from ADB" option in the recovery menu and sideload the update with adb. For example:
adb sideload blueline-ota_update-2019.07.01.21.zip
You do not need to have adb enabled within the OS or the host's ADB key whitelisted within the OS to sideload an update to recovery. Recovery mode does not trust the attached computer and this can be considered a production feature. Trusting a computer with ADB access within the OS is much different and exposes the device to a huge amount of attack surface and control by the trusted computer.
USB peripherals
GrapheneOS defaults to ignoring connected USB peripherals when the device is already booted and the screen is locked. A USB device already connected at boot will still work. The purpose is reducing attack surface for a locked device with active login sessions to user profiles to protect data that's not at rest. This can be controlled in Settings ➔ Security ➔ USB accessories. The options are:
- Disallow new USB peripherals
- Allow new USB peripherals when unlocked (default)
- Allow new USB peripherals (like stock Android)
This option has no impact on the device acting as a USB peripheral itself when connected to a computer. Android defaults to charge only mode and requires opt-in to the device being used for file transfer, USB tethering, MIDI or PTP.
Web browsing
GrapheneOS includes a Vanadium subproject providing privacy and security enhanced releases of Chromium. Vanadium is both the user-facing browser included in the OS and the provider of the WebView used by other apps to render web content. The WebView is the browser engine used by the vast majority of web browsers and nearly all other apps embedding web content or using web technologies for other uses.
Using Vanadium is highly recommended. Bromite is a solid alternative and is the only other browser we recommend. Bromite provides integrated ad-blocking and more advanced anti-fingerprinting. For now, Vanadium is more focused on security hardening and Bromite is more focused on anti-fingerprinting. The projects are collaborating together and will likely converge to providing more of the same features. Vanadium will be providing content filtering and anti-fingerprinting, but it needs to be done in a way that meets the standards of the project, which takes time.
Vanadium is designed for use on GrapheneOS and does not duplicate the OS privacy and security features such as the hardened malloc implementation. This leads to some of the differences from Bromite, such as relying on OS support for encrypted DNS rather than enabling Chromium's DNS-over-HTTPS support.
Chromium-based browsers like Vanadium and Bromite provide the strongest sandbox implementation, leagues ahead of the alternatives. It is much harder to escape from the sandbox and it provides much more than acting as a barrier to compromising the rest of the OS. Site isolation enforces security boundaries around each site using the sandbox by placing each site into an isolated sandbox. It required a huge overhaul of the browser since it has to enforce these rules on all the IPC APIs. Site isolation is important even without a compromise, due to side channels. Browsers without site isolation are very vulnerable to attacks like Spectre. On mobile, due to the lack of memory available to apps, there are different modes for site isolation. Vanadium turns on strict site isolation, matching Chromium on the desktop. Bromite enables strict site isolation on high memory devices, including all the devices that are officially supported by GrapheneOS.
Chromium has decent exploit mitigations, unlike the available alternatives. This is improved upon in Vanadium by enabling further mitigations, including those developed upstream but not yet fully enabled due to code size, memory usage or performance. For example, it enables type-based CFI like Chromium on the desktop, uses a stronger SSP configuration, zero initializes variables by default, etc. Some of the mitigations are inherited from the OS itself, which also applies to other browsers, at least if they don't do things to break them.
We recommend against trying to achieve browser privacy and security through piling on browser extensions and modifications. Most privacy features for browsers are privacy theater without a clear threat model and these features often reduce privacy by aiding fingerprinting and adding more state shared between sites. Every change you make results in you standing out from the crowd and generally provides more ways to track you. Enumerating badness via content filtering is not a viable approach to achieving decent privacy, just as AntiVirus isn't a viable way to achieving decent security. These are losing battles, and are at best a stopgap reducing exposure while waiting for real privacy and security features.
Vanadium will be following the school of thought where hiding the IP address through Tor or a trusted VPN shared between many users is the essential baseline, with the browser partitioning state based on site and mitigating fingerprinting to avoid that being trivially bypassed. The Tor Browser's approach is the only one with any real potential, however flawed the current implementation may be. This work is currently in a very early stage and it is largely being implemented upstream with the strongest available implementation of state partitioning. Chromium is using Network Isolation Keys to divide up connection pools, caches and other state based on site and this will be the foundation for privacy. Chromium itself aims to prevent tracking through mechanisms other than cookies, greatly narrowing the scope downstream work needs to cover. Bromite is doing a lot of work in these areas and Vanadium will be benefiting from that along with this upstream work. The focus is currently on research since we don't see much benefit in deploying bits and pieces of this before everything is ready to come together. At the moment, the only browser with any semblance of privacy is the Tor Browser but there are many ways to bypass the anti-fingerprinting and state partitioning. The Tor Browser's security is weak which makes the privacy protection weak. The need to avoid diversity (fingerprinting) creates a monoculture for the most interesting targets. This needs to change, especially since Tor itself makes people into much more of a target (both locally and by the exit nodes).
WebView-based browsers use the hardened Vanadium rendering engine, but they can't offer as much privacy and control due to being limited to the capabilities supported by the WebView widget. For example, they can't provide a setting for toggling sensors access because the feature is fairly new and the WebView WebSettings API doesn't yet include support for it as it does for JavaScript, location, cookies, DOM storage and other older features. For sensors, the Sensors app permission added by GrapheneOS can be toggled off for the browser app as a whole instead. The WebView sandbox also currently runs every instance within the same sandbox and doesn't support site isolation.
Avoid Gecko-based browsers like Firefox as they're currently much more vulnerable
to exploitation and inherently add a huge amount of attack surface. Gecko doesn't have
a WebView implementation (GeckoView is not a WebView implementation), so it has to be
used alongside the Chromium-based WebView rather than instead of Chromium, which means
having the remote attack surface of two separate browser engines instead of only one.
Firefox / Gecko also bypass or cripple a fair bit of the upstream and GrapheneOS
hardening work for apps. Worst of all, Firefox runs as a single process on mobile and
has no sandbox beyond the OS sandbox. This is despite the fact that Chromium semantic
sandbox layer on Android is implemented via the OS isolatedProcess
feature, which is a very easy to use boolean property for app service processes to
provide strong isolation with only the ability to communicate with the app running
them via the standard service API. Even in the desktop version, Firefox's sandbox is
still substantially weaker (especially on Linux, where it can hardly be considered a
sandbox at all) and lacks support for isolating sites from each other rather than only
containing content as a whole.
Camera
The Camera app included in GrapheneOS is very basic and can't take full advantage of the hardware. It doesn't offer much in the way of configuration. In the long term, it's going to be replaced. In the short term, there are other apps available providing more capabilities and better support for taking advantage of the hardware.
The Pixel 3 (but not the Pixel 3a) and Pixel 4 (but not the Pixel 4a) have a Pixel Visual Core / Pixel Neural Core providing a hardware-based implementation of HDR+. HDR+ captures many images and intelligently merges data across them, taking into account motion, etc. It substantially improves the quality of images, especially in low light. This is used transparently for third party apps that are compatible with it, and there isn't an explicit switch to turn it on or off for most of them. An example of a compatible app is Open Camera's default configuration, or Open Camera with the Camera 2 API and other settings (including the the various knobs / toggles outside of the settings menu) left alone. In general, HDR+ will work transparently in most apps as long as they keep things simple and use a good minimalist approach to taking pictures. It should work transparently in most messaging apps, etc. with internal support for taking pictures.
In addition to supporting HDR+ via the Pixel Visual Core, or similar features on other devices with the same constraints, Open Camera offers advanced configuration and various advanced features. Make sure to enable the Camera 2 API in the settings, which should be the default, but the app doesn't have a great user interface / user experience. You probably don't want to use the traditional HDR feature in the app. That's not HDR+, but rather captures 3 images and merges them in a way that isn't at all intelligent and causes a lot of blur and distortion. The HDR+ implementation can actually benefit from the camera not being completely steady as it's smart enough to match up the picture and it provides it with more data vs. a traditional HDR implementation where it essentially doesn't work without a tripod and is not really at all useful on a phone unless you actually have that for it.
Exec spawning
GrapheneOS creates fresh processes (via exec) when spawning applications instead of using the traditional Zygote spawning model. This improves privacy and security at the expense of higher cold start app spawning time and higher initial memory usage. It doesn't impact runtime performance beyond the initial spawning time. It adds somewhere in the ballpark of 100ms to app spawning time on the flagship devices and is only very noticeable on lower-end devices with a weaker CPU and slower storage. The spawning time impact only applies when the app doesn't already have an app process and the OS will try to keep app processes cached in the background until memory pressure forces it to start killing them.
In the typical Zygote model, a template app process is created during boot and every app is spawned as a clone of it. This results in every app sharing the same initial memory content and layout, including sharing secrets that are meant to be randomized for each process. It saves time by reusing the initialization work. The initial memory usage is reduced due to copy-on-write semantics resulting in memory written only during initialization being shared between app processes.
The Zygote model weakens the security provided by features based on random secrets including Address Space Layout Randomization (ASLR), stack canaries, heap canaries, randomized heap layout and memory tags. It cripples these security features since every app has the values for every other app and the values don't change for fresh app processes until reboot. Much of the OS itself is implemented via non-user-facing apps with privileges reserved for OS components. The Zygote template is reused across user profiles, so it also provides a temporary set of device identifiers across profiles for each boot via the shared randomized values.
Bugs uncovered by security features
GrapheneOS substantially expands the standard mitigations for memory corruption vulnerabilities. Some of these features are designed to directly catch the memory corruption bugs either via an explicit check or memory protection and abort the program in order to prevent them from being exploited. Other features mitigate issues a bit less directly such as zeroing data immediately upon free, isolated memory regions, heap randomization, etc. and can also lead to latent memory corruption bugs crashing instead of the program continuing onwards with corrupted memory. This means that many latent memory corruption bugs in apps are caught along with some in the OS itself. These bugs are not caused by GrapheneOS, but rather already existed and are uncovered by the features. The features are aimed at preventing or hindering exploits, not finding bugs, but they do that as part of doing their actual job.
Similarly, some of the other privacy and security improvements reduce the access available to applications and they may crash. Some of these features are always enabled under the hood, while others like the Network and Sensors toggles are controlled by users via opt-in or opt-out toggles. Apps may not handle having access taken away like this, although it generally doesn't cause any issues as it's all designed to be friendly to apps and fully compatible rather than killing the application when it violates the rules.
If you run into an application aborting, try to come up with a process for reproducing the issue and then capture a bug report via the 'Take bug report' feature in Developer options. Report an issue to the GrapheneOS OS issue tracker and email the bug report capture zip to contact@grapheneos.org with the issue tracker number in the subject like "Bug report capture for issue #104". The bug report capture includes plain text 'tombstones' with logs, tracebacks, address space layout, register content and a tiny bit of context from memory from areas that are interesting for debugging. This may contain some sensitive data. Feel free to provide only the tombstone for the relevant crash and filter out information you don't want to send. However, it will be more difficult to debug if you provide less of the information. If the app doesn't work with sensitive information, just send the whole tombstone.
Wi-Fi privacy
Wi-Fi on GrapheneOS is very privacy-friendly and is essentially anonymous as long as apps do not leak uniquely identifying information to the network. GrapheneOS avoids allowing itself to be fingerprinted as GrapheneOS, other than connections which are documented (see the FAQ) and can be easily disabled or forced through a VPN service.
Scanning
MAC randomization is always performed for Wi-Fi scanning. Pixel phones have firmware support for scanning MAC randomization going significantly beyond a naive implementation. On many other devices, there are identifiers exposed by Wi-Fi scanning beyond the MAC address such as the packet sequence number and assorted identifying information in the probe requests.
Avoid using hidden APs (i.e. APs not broadcasting their SSID) since all known hidden SSIDs end up being broadcast as part of scanning for networks to find them again. SSIDs are not broadcast for standard non-hidden APs. Hidden APs are only hidden when no devices are connected. It makes little sense as a privacy feature, especially for a non-mobile AP where knowing the AP exists can't be used for tracking it since it doesn't move. The feature reduces your privacy rather than increasing it. If you need to use a hidden AP, make sure to delete the saved network afterwards.
Wi-Fi and Bluetooth scanning for improving location detection are disabled by default, unlike the stock OS. These can be toggled in Settings ➔ Location ➔ Wi-Fi and Bluetooth scanning. These features enable scanning even when Wi-Fi or Bluetooth is disabled, so these need to be kept disabled to fully disable the radios when Wi-Fi and Bluetooth are disabled. GrapheneOS doesn't yet have an implementation of a coarse location service to supplement GPS location, so enabling these options doesn't actually do anything at the moment. Implementing a supplementary location service is planned but we need a robust, secure and private implementation via a local database. The initial focus will likely be a cell phone tower database, so these features still wouldn't be relevant.
Associated with an Access Point (AP)
Associated MAC randomization is performed by default. This can be controlled per-network with Settings ➔ Network & Internet ➔ Wi-Fi ➔ <network> ➔ Advanced ➔ Privacy.
In the stock OS, the default is to use a unique persistent random MAC address for each network. It has 2 options available: "Use randomized MAC (default)" and "Use device MAC". In GrapheneOS, the default is generating a new random MAC address when connecting to a network. It has 3 options available: "Use fully randomized MAC (default)", "Use per-network randomized MAC" and "Use device MAC".
The DHCP client uses the anonymity profile rather than sending a hostname so it doesn't compromise the privacy offered by MAC randomization. When the per-connection MAC randomization added by GrapheneOS is being used, DHCP client state is flushed before reconnecting to a network to avoid revealing that it's likely the same device as before.
GrapheneOS also disables support for stable link-local IPv6 addresses, since these have the potential to be used as identifiers. It's more sensible to use typical link-local address generation based on the (randomized) MAC address since link-local devices have access to both. As of Android 11, Android only uses stable link-local privacy addresses when MAC randomization is disabled, so we no longer need to disable the feature.
LTE-only mode
If you have a reliable LTE connection from your carrier, you can reduce attack surface by disabling 2G / 3G connectivity in Settings ➔ Network & Internet ➔ Mobile network ➔ Preferred network type. Traditional voice calls will only work in the LTE-only mode if you have either an LTE connection and VoLTE (Voice over LTE) support or a Wi-Fi connection and VoWi-Fi (Voice over Wi-Fi) support. VoLTE / VoWi-Fi works on GrapheneOS for most carriers unless they restrict it to carrier phones. US carriers other than T-Mobile tend to be missing these features due to us not including their proprietary apps.
This feature is not intended to improve the confidentiality of traditional calls and texts, but it might somewhat raise the bar for some forms of interception. It's not a substitute for end-to-end encrypted calls / texts or even transport layer encryption. LTE does provide basic network authentication / encryption, but it's for the network itself. The intention of the LTE-only feature is only hardening against remote exploitation by disabling an enormous amount of legacy code.
Sandboxed Play services (experimental preview)
This feature is currently only available in experimental preview releases of GrapheneOS but will become available in the stable releases as an experimental feature in the near future.
GrapheneOS has experimental support for installing the official releases of com.android.vending (Google Play Store), com.google.android.gms (Google Play services), com.google.android.gsf (Google Services Framework) as regular sandboxed apps in a specific profile. These receive no special privileges and the OS itself doesn't include any of the usual integration to make use of them itself to provide services offered by the OS. They run as unprivileged, sandboxed apps like any others and GrapheneOS implements shims to make them work without the many privileged permissions and SELinux policy extensions these apps usually require. Only apps within the same profile can use it. Even within the same profile, apps not explicitly choosing to use Google services won't use them because the OS doesn't integrate support for it or use it as the backend for APIs in the OS like the stock OS.
You should install all 3 apps including the Play Store rather than only Play services or there will be missing functionality. Play Store is not simply a user facing app.
You can obtain the apps from the apps.grapheneos.org repository. We don't yet have a client app for our repository so you'll need to install the APKs manually. The Play Store APK has multiple split APKs which need to be installed together rather than separately, so you'll need to use an app providing split APK installation support. Once we have a client app for our repository, you'll be able to install these and receive automatic updates through the app. Fully automatic updates without user interaction won't be supported until Android 12 which adds support for unattended upgrades of API 29+ apps by the app responsible for the initial installation if it supports the feature.
Install com.google.android.gsf, then com.google.android.gms and finally com.android.vending via a split APK installer.
You should give a battery optimization exception to Google Play services for features like push notifications to work properly in the background. It shouldn't be needed for the other 2 apps.
Secondary user support has not yet been implemented so this currently won't work in secondary profiles. This will be a crucial part of the functionality and is currently the top priority for improving the feature and bringing it closer to being ready for production usage.
The Play Store app cannot install and update apps as it normally would since it depends entirely on privileged permissions for unattended app installation, updates and removal. GrapheneOS currently includes partial shims to make this partially work. It's currently unclear if we'll flesh this out and include it in the production version of this feature or whether we'll drop it and simply have people use Aurora Store with the Play Store only installed to provide APIs used by apps using Play services.
The core functionality and APIs are almost entirely supported already since GrapheneOS largely only has to coerce these apps into continuing to run without being able to use any of the usual invasive OS integration. Certain functionality is not yet supported. Play Store feature delivery and Play services functionality delivered via dynamite modules are not supported yet. Shims will be required to make this work without depending on weakening SELinux MAC and MLS policies to permit it like the stock OS. The current generation Maps API is a common example of functionality depending on a dynamite module.
Since there's no OS integration beyond shims to make it function without any special privileges, there isn't a way to launch the settings activity. We'll need to make a tiny app providing a way to launch it.