Frequently Asked Questions

Table of contents

Device support

Which devices are supported?

GrapheneOS has official production support for the Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL, Pixel 3a and Pixel 3a XL. The release tags for these devices have official builds and updates available. These devices meet the stringent privacy and security standards and have substantial upstream and downstream hardening specific to the devices.

Many other devices are supported by GrapheneOS at a source level, and it can be built for them without modifications to the existing GrapheneOS source tree. Device support repositories for the Android Open Source Project can simply be dropped into the source tree, with at most minor modifications within them to support GrapheneOS. In most cases, substantial work beyond that will be needed to bring the support up to the same standards. For most devices, the hardware and firmware will prevent providing a reasonably secure device, regardless of the work put into device support.

GrapheneOS also supports generic targets, but these aren't suitable for production usage and are only intended for development and testing use. For mobile devices, the generic targets simply run on top of the underlying device support code (firmware, kernel, device trees, vendor code) rather than shipping it and keeping it updated. It would be possible to ship generic system images with separate updates for the device support code. However, it would be drastically more complicated to maintain and support due to combinations of different versions and it would cause complications for the hardening done by GrapheneOS. The motivation doesn't exist for GrapheneOS, since full updates with deltas to minimize bandwidth can be shipped for every device and GrapheneOS is the only party involved in providing the updates. For the same reason, it has little use for the ability to provide out-of-band updates to system image components including all the apps and many other components.

Some of the GrapheneOS sub-projects support other operating systems on a broader range of devices. Device support for Auditor and AttestationServer is documented in the overview of those projects. The hardened_malloc project supports nearly any Linux-based environment due to official support for musl, glibc and Bionic along with easily added support for other environments. It can easily run on non-Linux-based operating systems too, and supporting some like HardenedBSD is planned but depends on contributors from those communities.

The recommended devices with the best hardware, firmware and software security along with the longest future support time are the Pixel 3a, Pixel 3a XL, Pixel 3 and Pixel 3 XL. The Pixel 3a and 3a XL are budget devices meeting the same security standards as the more expensive flagship devices. Compared to the Pixel 3a and 3a XL, the flagship Pixel 3 and Pixel 3 XL have wireless charging, dual front-facing speakers, the Pixel Visual Core supporting HDR+ with compatible apps on GrapheneOS, IP68 dust and water protection, a higher-end screen, slightly more durable glass and of course a stronger CPU, GPU, cellular radio, etc. You should get one of the budget devices if these things aren't compelling to you. The Pixel 3a and 3a XL do have one extra feature: an analog headphone port as an alternative to wireless audio and digital USB-C audio.

Which devices will be supported in the future?

Devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas. Much of the work on the project involves changes that are specific to different devices, and officially supported devices are the ones targeted by most of this ongoing work.

Devices need to be meeting the standards of the project in order to be considered as potential targets. In addition to support for installing other operating systems, standard hardware-based security features like the hardware-backed keystores, verified boot, attestation and various hardware-based exploit mitigations need to be available. Devices also need to have decent integration of IOMMUs for isolating components such as the GPU, radios (NFC, Wi-Fi, Bluetooth, Cellular), media decode / encode, image processor, etc., because if the hardware / firmware support is missing or broken, there's not much that the OS can do to provide an alternative. Devices with support for alternative operating systems as an afterthought will not be considered. Devices need to have proper ongoing support for their firmware and software specific to the hardware like drivers in order to provide proper full security updates too. Devices that are end-of-life and no longer receiving these updates will not be supported.

In order to support a device, the appropriate resources also need to be available and dedicated towards it. Releases for each supported device need to be robust and stable, with all standard functionality working properly and testing for each of the releases.

Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware.

When will more devices be supported?

Broader device support can only happen after the community (companies, organizations and individuals) steps up to make substantial, ongoing contributions to making the existing device support sustainable. Once the existing device support is more sustainable, early research and development work for other devices can begin. Once a device is deemed to be a worthwhile target, the project needs maintainers to develop and maintain support for it including addressing device-specific issues that are uncovered, which will include issues uncovered in the device support code by GrapheneOS hardening features.

It's not really a matter of time but rather a need for community support for the project increasing. As an open source project, the way to get something to happen in GrapheneOS is to contribute to it, and this is particularly true for device support since it's very self-contained and can be delegated to separate teams for each device. If you want to see more devices supported sooner, you should get to work on identifying good devices with full support for alternative operating systems with verified boot, etc. and then start working on integrating and testing support.

It should also be clear that the expectation is for people to buy a device to run GrapheneOS, rather than GrapheneOS supporting their existing devices. This will only become more true if GrapheneOS is successful enough to accomplish the goal of having devices produced based on an SoC reference design with minor improvements for privacy and security. Broad device support is the opposite of what the project wants to achieve in the long term.

Why are older devices no longer supported?

GrapheneOS aims to provide reasonably private and secure devices. It cannot do that once device support code like firmware, kernel and vendor code is no longer actively maintained. Even if the community was prepared to take over maintainance of the open source code and to replace the rest, firmware would present a major issue, and the community has never been active or interested enough in in device support to consider attempting this. Unlike many other platforms, GrapheneOS has a much higher minimum standard than simply having devices fully functional, as they also need to provide the expected level of security. It would start to become realistic to provide substantially longer device support once GrapheneOS controls the hardware and firmware via custom hardware manufactured for it. Until then, the lifetime of devices will remain based on manufacturer support. It's also important to keep in mind that phone vendors claiming to provide longer support often aren't actually doing it and some never even ship firmware updates when the hardware is still supported by the vendors...

GrapheneOS also has high standards for the privacy and security properties of the hardware and firmware, and these standards are regularly advancing. The rapid pace of improvement has been slowing down, but each hardware generation still brings major improvements. Over time, the older hardware starts to become a substantial liability and holds back the project. It becomes complex to simply make statements about the security of the project when exceptions for old devices need to be listed out. The project ends up wanting to drop devices for this reason but has always kept them going until the end-of-life date to provide more time for people to migrate.

Security and privacy

Can apps access hardware identifiers?

As of Android 10, apps cannot obtain permission to access non-resettable hardware identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial numbers and subscriber IDs. Only privileged apps included in the base system with READ_PRIVILEGED_PHONE_STATE whitelisted can access these hardware identifiers. Apps targeting Android 10 will receive a SecurityException and older apps will receive an empty value for compatibility.

GrapheneOS only makes a small change to remove a legacy form of access to the serial number by legacy apps, which was still around for compatibility.

What kind of connections do the OS and bundled apps make by default?

GrapheneOS makes connections to the outside world to test connectivity, detect captive portals and download updates. No data varying per user / installation is sent in these connections. There aren't analytics / telemetry in GrapheneOS.

The expected default connections by GrapheneOS (including all base system apps) are the following:

What does GrapheneOS do about cellular tracking and silent SMS?

GrapheneOS always considers the network to be hostile and does not implement weak or useless mitigations. Therefore, it does not have the assorted gimmicks seen elsewhere providing privacy/security theatre to make users feel better about these issues. One of the core tenets of GrapheneOS is being honest with users and avoiding scams/frills based around marketing rather than real world privacy/security threat models.

Activating airplane mode will fully disable the cellular radio transmit and receive capabilities, which will prevent your phone from being reached from the cellular network and stop your carrier (and anyone impersonating them to you) from tracking the device via the cellular radio. The baseband implements other functionality such as Wi-Fi and GPS functionality, but each of these components is separately sandboxed on the baseband and independent of each other. Enabling airplane mode disables the cellular radio, but Wi-Fi can be re-enabled and used without activating the cellular radio again. This allows using the device as a Wi-Fi only device.

Even if interception of the connection or some other man-in-the-middle attack along the network is not currently occurring, the network is still untrustworthy and information should not be sent unencrypted. Legacy calls and texts should be avoided as they're not secure and trust the carrier / network along with having weak security against other parties. Trying to detect some forms of interception rather than dealing with the root of the problem (unencrypted communications / data transfer) would be foolish and doomed to failure.

Receiving a silent SMS is not a good indicator of being targeted by your cell carrier, police or government because anyone on the cell network can send them including yourself. Cellular triangulation will happen regardless of whether or not SMS texts are being sent or received by the phone. Even if an SMS did serve a useful purpose for tracking, a silent SMS would be little different than receiving unsolicited spam. In fact, sending spam would be stealthier since it wouldn't trigger alerts for silent SMS but rather would be ignored with the rest of the spam. Regardless, sending texts or other data is not required or particularly useful to track devices connected to a network for an adversary with the appropriate access.