This page contains answers to frequently asked questions about GrapheneOS. It's not an overview of the project or a list of interesting topics about GrapheneOS. Many of the answers would be nearly the same or identical for the latest release of the Android Open Source Project. The goal is to provide high quality answers to some of the most common questions about the project, so the developers and other community members can link to these and save lots of time while also providing higher quality answers.

GrapheneOS has official production support for the Pixel 2 (legacy), Pixel 2 XL (legacy), Pixel 3, Pixel 3 XL, Pixel 3a, Pixel 3a XL, Pixel 4 and Pixel 4 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.

Support for the Pixel 4 and Pixel 4 XL is currently less mature, but those along with the Pixel 4a (once it's supported) will become the recommended devices due to longer support and incremental security improvements for the device support code and firmware. On the Pixel 4 and 4 XL, support for fingerprint unlock as a secondary unlock mechanism has been removed and replaced with IR-based 3D facial scanning. GrapheneOS plans to extend secondary unlock support with the option of 2-factor authentication using a secondary PIN or passphrase required for fingerprint / face unlock. It's likely this will be implemented first for fingerprint unlock, so that's another consideration. The Pixel 4a has a fingerprint scanner instead of the dual infrared face scanning cameras, so it would share the same implementation as the past generation devices.

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.

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.

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 maintenance 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.

As of Android 10, only the configured default input method editor (your keyboard of choice) and the currently focused app can access the clipboard. Apps without focus cannot access the clipboard. This is a stricter restriction than preventing apps in the background from accessing it, since an app in the foreground or a foreground service cannot access it, only the foreground app that's currently focused. Clipboard managers need to be implemented by the keyboard chosen as the default by the user.

GrapheneOS previously restricted background clipboard access as a much earlier and slightly less strict implementation of this feature. It provided a toggle for users to whitelist clipboard managers, which is no longer needed now that keyboards are expected to provide it.

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.

Since these restrictions became standard, 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. It used to need more extensive changes such as disallowing access to the serial number but those restrictions are now standard.

Apps can determine the model of the device (such as it being a Pixel 4) either directly or indirectly through the properties of the hardware and software. There isn't a way to avoid this short of the OS supporting running apps in a virtual machine with limited functionality and hardware acceleration. Hiding the CPU/SoC model would require not even using basic hardware virtualization support and these things could probably still be detected via performance measurements.

In addition to not having a way to identify the hardware, apps cannot directly identify the installation of the OS on the hardware. Apps only have a small portion of the OS configuration exposed to them and there is not much for device owners to change which could identify their installation. Apps can detect that they're being run on GrapheneOS via the privacy and security features placing further restrictions on them and hardening them against further exploitation. Apps can identify their own app installation via their app data and can directly (until that's removed) or indirectly identify a profile. Profiles should be used when separate identities are desired. Profiles can be used as temporary ephemeral identifies by creating them for a specific need and then deleting them. The rest of this answer only provides more technical details, so you can stop reading here if you only want an overview and actionable advice (i.e. use profiles as identities not inherently tied to each other).

Apps can generate their own 128-bit or larger random value and use that as an identifier for the app installation. Apps can create data in their app-specific external storage directory by default without needing permission, and in the legacy storage model before API 29 that data persists after the app is uninstalled, so it can be used to store an ID that persists through the app being uninstalled and reinstalled. However, external storage is under control of the user and the user can delete this data at any time, including after uninstalling the app. In the modern storage model, this data is automatically removed when the app is uninstalled. GrapheneOS includes Seedvault as an OS backup service which must be explicitly enabled, and it has the option to automatically restore app data when an app is reinstalled, so it wouldn't lose track of it being the same profile.

The ANDROID_ID string is a 64-bit random number, unique to each combination of profile and app signing key. The 64-bit limitation means it isn't particularly useful due to the possibility of collisions. It's tied to the lifetime of profiles and does not persist through profile deletion or a factory reset. This is comparable to an app targeting the legacy storage model storing a 64-bit random value in the app-specific external storage directory. In the future, GrapheneOS will likely change this to be tied to the lifetime of app installations rather than profiles. An app could still track the identity of the profile through data you give it access to or via data another app chooses to share with them.

The advertising ID is a Google Play services feature not included in the baseline Android API, so it isn't an API included in GrapheneOS. The advertising ID is unique to each profile. It isn't unique to each app signing key like ANDROID_ID , but that makes little difference since apps within the same profile can communicate with each other with mutual consent. It's comparable to ANDROID_ID but provides an 128-bit value so it provides a strong cryptographic guarantee against collisions, although a device messing with apps could set it to the same value used in another profile. The advertising ID is exposed via the Settings app and can be reset to a new random value, unlike ANDROID_ID which remains the same for the lifetime of the profile, but apps can tie it the previous ID since they can detect that it changed via their own ID in their app data.

Apps do not have access to user data by default and cannot ever access the data of other apps without those apps going out of the way to share it with them. If apps are granted read access to user data like media or contacts, they could use it to identify the profile. If apps are granted write access to user data, they could tag it to keep track of the profile. Apps previously had little reason to do things like this because they were able to persist data through an uninstall and reinstallation by default. The modern storage model means they need to request access to user data to do this. The existence of ANDROID_ID means they don't yet need to bother with that but that will change on GrapheneOS and will likely change for baseline Android too. However, profiles are the only way to provide a strong assurance of separate identities since the application model of the OS is designed to support communication between apps within the same profile, but never between them.

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.

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:

The GrapheneOS Updater app fetches update metadata from https://releases.grapheneos.org/DEVICE-CHANNEL approximately once every four hours when connected to a permitted network for updates. Once an update is available, it tries to download https://releases.grapheneos.org/DEVICE-incremental-OLD_VERSION-NEW_VERSION.zip for a delta update, and then falls back to https://releases.grapheneos.org/DEVICE-ota_update-NEW_VERSION.zip. No query / data is sent to the server, so the only information leaked to it are the variables in these 3 URLs (device, channel, current version) which is necessary to obtain the update. Users are in control of which types of networks the Updater app will use and can disable the Updater app in extreme cases. It's strongly recommended to leave it enabled to quickly receive security updates including updates outside the regular monthly schedule. See the usage guide's section on updates for more information.

An HTTPS connection is made to https://time.grapheneos.org/ to update the time from the date header field. This is a full replacement of Android's standard network time update implementation, which uses the cellular network when available with a fallback to SNTP when it's not available. This can be disabled with the toggle at Settings ➔ System ➔ Date & time ➔ Use network-provided time. The time zone is still obtained directly via the time zone provided by the mobile network when available.

On devices with a Qualcomm baseband (which provides GPS), when location functionality is being used, GPS almanacs are downloaded from https://xtrapath1.izatcloud.net/xtra3grc.bin, https://xtrapath2.izatcloud.net/xtra3grc.bin or https://xtrapath3.izatcloud.net/xtra3grc.bin. GrapheneOS has modified all references to these servers to use HTTPS rather than a mix of HTTP and HTTPS. No query / data is sent to the server.

Connectivity checks designed to mimic a web browser user agent are performed by using HTTP and HTTPS to fetch standard URLs generating an HTTP 204 status code. This is used to detect when internet connectivity is lost on a network, which triggers fallback to other available networks if possible. These checks are designed to detect and handle captive portals which substitute the expected empty 204 response with their own web page. These need use a very common domain and URL in order to bypass whitelisting systems only permitting access to common domains / URLs so a domain like grapheneos.org would likely be inadequate. GrapheneOS leaves these set to the standard four URLs to blend into the crowd of billions of other Android devices with and without Google Mobile Services performing the same empty GET requests. For privacy reasons, it isn't desirable to stand out from the crowd and changing these URLs or even disabling the feature will likely reduce your privacy by giving your device a more unique fingerprint. GrapheneOS aims to appear like any other common mobile device on the network. HTTPS: https://www.google.com/generate_204 HTTP: http://connectivitycheck.gstatic.com/generate_204 HTTP fallback: http://www.google.com/gen_204 HTTP other fallback: http://play.googleapis.com/generate_204 Standard AOSP user agent for the GET request: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36 No query / data is sent to the servers and the response is unused beyond checking the response code. Similar connectivity checks are also performed by Vanadium. Providing a toggle in the Settings app for using connectivitycheck.grapheneos.org as an alternative is planned. The option to blend into the crowd with the standard URLs is important and must remain supported for people who need to be able to blend in rather than getting the nice feeling that comes from using GrapheneOS servers. It's possible to use connectivitycheck.grapheneos.org already, but not via the GUI.

DNS connectivity and functionality tests

DNS resolution for other connections

By default, the OS uses the network-provided DNS servers, whether those come from DHCP or static network configuration. If no DNS servers are provided, GrapheneOS uses Cloudflare DNS as the fallback rather than Google Public DNS. In practice, the fallback is rarely used and has little real world impact.

It isn't possible to directly override the DNS servers provided by the network via DHCP. Instead, use the Private DNS feature in Settings ➔ Network & internet ➔ Advanced ➔ Private DNS to set the hostname of a DNS-over-TLS server. It needs to have a valid certificate such as a free certificate from Let's Encrypt. The OS will look up the Private DNS hostname via the network provided DNS servers and will then force all other DNS requests through the Private DNS server. Unlike an option to override the network-provided DNS servers, this prevents the network from monitoring or tampering with DNS requests/responses.

As an example, set the hostname to one.one.one.one for Cloudflare DNS. There are various other mainstream DNS-over-TLS options available including Quad9, Google and AdGuard.

Configuring a static IP address for a network requires entering DNS servers manually, but you should still use the Private DNS feature with it, and you shouldn't misuse the static IP address option just to override the DNS servers.

VPN service apps can also provide their own DNS implementation and/or servers, including an alternate implementation of encrypted DNS. Private DNS takes precedence over VPN-provided DNS, since it's just the network-provided DNS.

Apps and web sites can detect the configured DNS servers by generating random subdomains resolved by querying their authoritative DNS server. This can be used as part of fingerprinting users. If you're using a VPN, you should consider using the standard DNS service provided by the VPN service to avoid standing out from other users.

By default, in the automatic mode, the Private DNS feature provides opportunistic encryption by using DNS-over-TLS when supported by the DNS server IP addresses provided by the network (DHCP) or the static IP configuration. Opportunistic encryption provides protection against a passive listener, not an active attacker, since they can force falling back to unencrypted DNS by blocking DNS-over-TLS. In the automatic mode, certificate validation is not enforced, as it would provide no additional security and would reduce the availability of opportunistic encryption.

When Private DNS is explicitly enabled, it uses authenticated encryption without a fallback. The authentication is performed based on the hostname of the server, so it isn't possible to provide an IP address. The OS will look up the hostname of the Private DNS server via unencrypted DNS and then force all other DNS lookups via DNS-over-TLS with the identity of the server authenticated as part of providing authenticated encryption.

No, it only provides privacy for DNS resolution. Even authenticating DNS results with DNSSEC does not protect other connections, unless the DNS records are part of the system used to provide authenticated encryption, and DNS-over-TLS is not a substitute for DNSSEC. If connections have authenticated encryption, they're secure even if DNS resolution is hijacked by an attacker. If connections do not have authenticated encryption, an attacker can listen in and tamper with them without hijacking DNS. There are other ways to perform a MITM attack than DNS hijacking and internet routing is fundamentally insecure. DNS-over-TLS may make a MITM harder for some attackers, but don't count on it at all.

Private DNS only encrypts DNS, and an adversary monitoring connections can still see the IP address at the other end of those connections. Many domains resolve to ambiguous IP addresses, so encrypted DNS is part of what's required to take away a lot of the information leaked to adversaries. However, TLS currently leaks domains via SNI, so encrypted DNS is not yet accomplishing much. It's a forward looking feature that will become more useful in the future. Using it is recommended, but it's not an alternative to using Tor or a VPN.

VPNs can be configured under Settings ➔ Network & Internet ➔ Advanced ➔ VPN. Support for the following protocols is included: PPTP (insecure, obsolete), L2TP/IPSec PSK, L2TP/IPSec RSA, IPSec Xauth PSK, IPSec Xauth RSA and IPSec Hybrid RSA. Apps can also provide userspace VPN implementations and the following open source apps are recommended: Orbot (Tor), WireGuard, OpenVPN for Android and the Private Internet Access client (OpenVPN).

VPN configurations created with the built-in support can be set as the always-on VPN in the configuration panel. This will keep the VPN running, reconnecting as necessary and will force all connections through them. An app providing a VPN service can also be set as the always-on VPN via the entry in the Settings page. For app-based VPN implementations, there's also an additional "Block connections without VPN" toggle which is needed to prevent leaks when the app's VPN service isn't running.

Apps cannot monitor network connections unless they're made into the active VPN service by the user. Apps cannot normally access network stats and cannot directly request access to them. However, app-based stats can be explicitly granted by users as part of access to app usage stats in Settings ➔ Apps & notifications ➔ Special app access ➔ Usage access.

This was previously part of the GrapheneOS privacy improvements, but became a standard Android feature with Android 10.

Yes, GrapheneOS inherits the deeply integrated firewall from the Android Open Source Project, which is used to implement portions of the security model and various other features. The GrapheneOS project historically made various improvements to the firewall but over time most of these changes have been integrated upstream or became irrelevant.

GrapheneOS adds a user-facing Network permission toggle providing a robust way to deny both direct and indirect network access to applications. It builds upon the standard non-user-facing INTERNET permission, so it's already fully adopted by the app ecosystem. Revoking the permission denies indirect access via OS components and apps enforcing the INTERNET permission, such as DownloadManager. Direct access is denied by blocking low-level network socket access.

The recommended approach to system-wide ad-blocking is setting up domain-based ad-blocking as part of DNS resolution. You can do this by choosing a Private DNS (DNS-over-TLS) server with support for blocking ad domains. As an example, AdGuard DNS can be used by setting dns.adguard.com as the Private DNS domain. In the future, GrapheneOS plans on adding back an efficient user-defined blacklist for the local DNS resolver. This feature used to be included by the project many years ago, but it needs to be reimplemented, and it's a low priority feature depending on contributors stepping up to work on it.

Apps and web sites can detect that ad-blocking is being used and can determine what's being blocked. This can be used as part of fingerprinting users. Using a widely used service like AdGuard with a standard block list is much less of an issue than a custom set of subscriptions / rules, but it still stands out compared to the default of not doing it.

Content filtering apps are fully compatible with GrapheneOS, but they have serious drawbacks and are not recommended. These apps use the VPN service feature to route traffic through themselves to perform filtering.

The approach of intercepting traffic is inherently incompatible with encryption from the client to the server. The AdGuard app works around encryption by supporting optional HTTPS interception by having the user trust a local certificate authority, which is a security risk and weakens HTTPS security even if their implementation is flawless (which they openly acknowledge in their documentation, although it understates the risks). It also can't intercept connections using certificate pinning, with the exception of browsers which go out of the way to allow overriding pinning with locally added certificate authorities. Many of these apps only provide domain-based filtering, unlike the deeper filtering by AdGuard, but they're still impacted by encryption due to Private DNS (DNS-over-TLS) and require disabling the feature. They could provide their own DNS-over-TLS resolver to avoid losing the feature, but few of the developers care enough to do that.

Using the VPN service to provide something other than a VPN also means that these apps need to provide an actual VPN implementation or a way to forward to apps providing one, and very few have bothered to implement this. NetGuard is an one example implementing SOCKS5 forwarding, which can be used to forward to apps like Orbot (Tor).

GrapheneOS has entirely automatic background updates. More details are available in the the usage guide's updates section.

Updates can be sideloaded via recovery.

No, since this is strictly a theft deterrence feature, not a security feature, and the standard implementation depends on having the device tied to an account on an online service. The only advantage would be encouraging thieves to return a stolen device for a potential reward after realizing that it has no value beyond scrapping it for parts.

Google's Factory Reset Protection ties devices to a Google account using a tiny, special region of persistent state not wiped by a factory reset. It prevents a thief from wiping the device to a fresh state for resale without being stuck at a screen for authenticating with the Google account persisted on the device after wiping.

It would be possible to make an implementation not reliant upon an online service where the user has the option to enable Factory Reset Protection and is given a seed phrase required to use the device after wiping data from recovery. However, since this has no security value and the ability to deter theft is questionable, implementing this is an extremely low priority.

Providing the option to disable wiping from recovery would be simpler, but would be incompatible with features designed to wipe data automatically in certain cases. This will not be implemented by GrapheneOS since it isn't a good approach and it conflicts with other planned features.

There are drawbacks to bundling apps into the OS and few advantages in most cases. Rather than GrapheneOS bundling a bunch of apps, it makes far more sense for users to install their preferred apps via F-Droid, Aurora Store or other sources. GrapheneOS is also working on designing and implementing a first party app update system for a first party repository with higher robustness and security than the existing options. Rather than bundling apps, it could just offer recommendations as part of an initial setup wizard. Users have unique needs and preferences and there has to be a very compelling reason to bundle additional apps with the OS. For example, it's useful to have the Auditor app available before connecting to the internet (see the installation guide documentation on this).

Bundling additional apps with the OS can increase attack surface, unless users go out of the way to disable apps they aren't using. Bundling an app into the base OS is also painful to reverse, since removing the app without implementing a migration mechanism will lose user data stored in the app. Some users are also going to take issue with the choices made by the project or will want to make suggestions for bundling more apps, and having this as a regular topic of discussion and debate is unproductive and distracts from the real work of the project. Each bundled app also increases the size of the base OS, and shipping the app updates as part of the OS updates results in more overall bandwidth usage. It would be possible to ship only out-of-band app updates to avoid wasted bandwidth for apps users have disabled, but then the apps would be temporarily out-of-date and vulnerable to patched security issues after a factory reset or the user re-enabling them. If the updates aren't going to be shipped with the OS, it really makes no sense to bundle them.

GrapheneOS is focused on making meaningful improvements to privacy and security, and bundling assorted apps into the OS is not only usually outside of that focus but often counter to it.