Usage guide

System navigation

By default, GrapheneOS uses gesture-based navigation. We recommend reading our guide on gesture navigation and giving it a chance even if you think you won’t like it. Our experience is that when armed with the appropriate knowledge, the vast majority of users prefer the newer gesture navigation approach.

The system navigation mode can be configured in Settings ➔ System ➔ Gestures ➔ System navigation. The same menu is also available in Settings ➔ Accessibility ➔ System controls ➔ System navigation.

Storage access

GrapheneOS inherits the same baseline approach to storage access as modern Android and extends it with our Storage Scopes feature as a fully compatible alternative to standard Android storage permissions. This section provides an overview of the standard approach to storage access primarily to provide context for explaining Storage Scopes.

There are two types of app-accessible storage:

• app-private (“internal”) storage:
  • inaccessible to other apps
  • doesn’t require any permission for full access
  • cleared when the app is uninstalled
• shared (“external”) storage:
  • shared with other apps
  • access is regulated with permissions
  • files persist after uninstallation

  Android/data/ and Android/obb/ directories aren’t considered to be parts of shared storage.

For modern apps, access to the shared storage is controlled in the following way:

• Without any storage permission, an app is allowed to:
  • create media files in standard directories (audio in Music/, Ringtones/, etc, images in Pictures/ and DCIM/, videos in DCIM/ and Movies/)
  • create files of any type (both media and non-media) in Documents/ and Download/
  • create new directories inside standard directories
  • rename/delete files that were created by the app itself
  • rename/delete directories if it can rename/delete all files within those directories
• Media access permission (“Allow access to media only”, READ_EXTERNAL_STORAGE) allows the app to read media files that were created by other apps. Non-media files remain invisible to it. For apps targeting Android 13, the media access permission is split into READ_MEDIA_IMAGES, READ_MEDIA_VIDEO and READ_MEDIA_AUDIO.
• Media management special access permission (“Allow app to manage media”, MANAGE_MEDIA) allows the app to delete and to rename media files created by other apps.
• “All files access” special access permission (MANAGE_EXTERNAL_STORAGE) allows the app to read, create, rename and delete files and directories of any type in any directory of the shared storage (including the root directory).

For legacy apps (those that target Android 9 or lower and those that target Android 10 and request legacy storage mode), storage access permissions have a different meaning:

• Without a storage permission, app is not allowed any type of access to any files or directories inside the shared storage.
• READ_EXTERNAL_STORAGE permission allows the app to read both media and non-media files in any directory.
• WRITE_EXTERNAL_STORAGE permission allows the app to create, rename and delete files (of any type) and directories in any directory of shared storage (including the root directory).

Additionally, both modern and legacy Android apps can open the system file picker interface to have the user store or load one or more files/directories on their behalf. This type of access doesn’t require any of the permissions listed above. Using this approach gives the user control over where files are stored in their home directory and which files/directories can be used by the app. This is based on the Storage Access Framework (SAF) introduced in Android 4.4. SAF allows the user to grant access to files/directories in their home directory, external drives and also app-based storage providers such as network shares, cloud storage, an encrypted volume, an external drive with a filesystem the OS doesn’t support for external drives, etc. This is the only way to use those app-based storage providers and modern Android has removed the legacy approach for accessing external drives.

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 accessibility service 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 work fine but have licensing issues. eSpeak NG has added Direct Boot based on our request for it, meaning it is able to function before the first unlock. RHVoice is missing Direct Boot and can’t run before the first unlock. 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.

adb sideload raven-ota_update-2021122018.zip

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 our 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 nearly all other apps embedding web content or using web technologies for other uses. It’s also used by many minor web browsers not forking Chromium as a whole. These apps using the WebView benefit from a subset of the Vanadium hardening.

Vanadium was previously primarily focused on security hardening but we plan on adding assorted privacy and usability features. In the near future, we plan to add support for always incognito mode, content filtering (ad blocking, etc.), improved state partitioning, backup/restore and many other features.

Chromium-based browsers like Vanadium 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, along with strict origin isolation.

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. 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 does not have internal sandboxing on Android. 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) and lacks full support for isolating sites from each other rather than only containing content as a whole. The sandbox has been gradually improving on the desktop but it isn’t happening for their Android browser yet.

Camera

GrapheneOS has the same camera capabilities and quality as the stock OS. It will match the stock OS when comparing the same app on each OS. GrapheneOS uses our own modern Camera app rather than the standard AOSP Camera app. GrapheneOS Camera is far better than any of the portable open source camera alternatives and even most proprietary camera apps including paid apps. On Pixels, Google Camera can be used as an alternative with more features. The section below has a detailed guide on using GrapheneOS Camera and the following section explains the remaining advantages of Google Camera on Pixels.

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 200ms 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.

This feature can be disabled via Settings ➔ Security ➔ Enable secure app spawning if you prefer to have faster cold start app spawning time and lower app process memory usage instead of the substantial security benefits and the removal of the only known remaining direct device identifiers across profiles (i.e. not depending on fingerprinting global configuration, available storage space, etc. or using side channels).

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.

You can enable our exploit protection compatibility mode via Settings ➔ Apps ➔ App ➔ Advanced. The exploit protection compatibility mode toggle will switch from hardened_malloc to Android’s standard allocator (Scudo) and will reduce address space size from 48 bit to Android’s standard 39 bit. There are also separate toggles for these features in the Configure hardening menu if you want to narrow down the cause to a specific feature.

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 default connections FAQ) and can be easily disabled or forced through a VPN service.

LTE-only mode

If you have a reliable LTE connection from your carrier, you can reduce attack surface by disabling 2G, 3G and 5G connectivity in Settings ➔ Network & Internet ➔ SIMs ➔ 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. Some carriers may be missing VoWi-Fi due to us not including their proprietary apps. Please note that AT&T users may see “5Ge” being used when LTE Only mode is enabled as AT&T intentionally mislabel LTE services as “5Ge” to mislead users.

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 both legacy code (2G, 3G) and bleeding edge code (5G).

Sandboxed Google Play

GrapheneOS has a compatibility layer providing the option to install and use the official releases of Google Play in the standard app sandbox. Google Play receives absolutely no special access or privileges on GrapheneOS as opposed to bypassing the app sandbox and receiving a massive amount of highly privileged access. Instead, the compatibility layer teaches it how to work within the full app sandbox. It also isn’t used as a backend for the OS services as it would be elsewhere since GrapheneOS doesn’t use Google Play even when it’s installed.

Since the Google Play apps are simply regular apps on GrapheneOS, you install them within a specific user or work profile and they’re only available within that profile. Only apps within the same profile can use it and they need to explicitly choose to use it. It works the same way as any other app and has no special capabilities. As with any other app, it can’t access data of other apps and requires explicit user consent to gain access to profile data or the standard permissions. Apps within the same profile can communicate with mutual consent and it’s no different for sandboxed Google Play.

Sandboxed Google Play is close to being fully functional and provides near complete compatibility with the app ecosystem depending on Google Play. Only a small subset of privileged functionality which we haven’t yet ported to different approaches with our compatibility layer is unavailable. Some functionality is inherently privileged and can’t be provided as part of the compatibility layer.

The vast majority of Play services functionality works perfectly including dynamically downloaded / updated modules (dynamite modules) and functionality provided by modular app components such as Google Play Games. By default, location requests are rerouted to a reimplementation of the Play geolocation service provided by GrapheneOS. You can disable rerouting and use the standard Play services geolocation service instead if you want the Google network location service and related features.

Our compatibility layer includes full support for the Play Store. Play Store services are fully available including in-app purchases, Play Asset Delivery, Play Feature Delivery and app / content license checks. It can install, update and uninstall apps with the standard approach requiring that the user authorizes it as an app source and consents to each action. It will use the standard Android 12+ unattended update feature to do automatic updates for apps where it was the last installer.

Banking apps

Banking apps are a particularly problematic class of apps for compatibility with alternate operating systems. Some of these work fine with any GrapheneOS configuration but most of them have extensive dependencies on Play services. For many of these apps, it’s enough to set up the GrapheneOS sandboxed Google Play feature in the same profile. Unfortunately, there are further complications not generally encountered with non-financial apps.

Many of these apps have their own crude anti-tampering mechanisms trying to prevent inspecting or modifying the app in a weak attempt to hide their code and API from security researchers. GrapheneOS allows users to disable native code debugging via a toggle in Settings ➔ Security to improve the app sandbox and this can interfere with apps debugging their own code to add a barrier to analyzing the app. You should try enabling this again if you’ve disabled it and are encountering compatibility issues with these kinds of apps.

Banking apps are increasingly using Google’s SafetyNet attestation service to check the integrity and certification status of the operating system. GrapheneOS passes the basicIntegrity check but isn’t certified by Google so it fails the ctsProfileMatch check. Most apps currently only enforce weak software-based attestation which can be bypassed by spoofing what it checks. GrapheneOS doesn’t attempt to bypass the checks since it would be very fragile and would repeatedly break as the checks are improved. Devices launched with Android 8 or later have hardware attestation support which cannot be bypassed without leaked keys or serious vulnerabilities so the era of being able to bypass these checks by spoofing results is coming to an end regardless.

The hardware attestation feature is part of the Android Open Source Project and is fully supported by GrapheneOS. SafetyNet attestation chooses to use it to enforce using Google certified operating systems. However, app developers can use it directly and permit other properly signed operating systems upholding the security model. GrapheneOS has a detailed guide for app developers on how to support GrapheneOS with the hardware attestation API. Direct use of the hardware attestation API provides much higher assurance than using SafetyNet so these apps have nothing to lose by using a more meaningful API and supporting a more secure OS.

A 3rd party community-sourced effort containing banking app compatibility information is maintained by PrivSec.dev. GrapheneOS does not make any guarantees regarding the list’s validity.

App link verification

Android apps can declare associations with domains in order to handle those URLs in the app automatically. For security reasons, app links are disabled by default to prevent apps intercepting arbitrary URLs. First party apps associated with a domain are expected to be authorized by the domain. Apps can ask for their app links to be verified by the OS by marking them with autoVerify in their manifest. The OS will securely confirm that the domain authorizes the app to handle the domain’s URLs. Users can also manually enable an app’s link associations via Settings ➔ Apps ➔ App name ➔ Open by default ➔ Add link. Apps can ask users to enable the associations and send them to this page in the Settings app.

As an example, the first party YouTube app will have the app links verified by the OS automatically while the NewPipe app requires manually enabling handling links for YouTube and other sites.

Verification of app links by the OS is done by the Intent Filter Verification Service system app. It will use an HTTPS GET request to fetch https://example.com/.well-known/assetlinks.json in order to process a request to verify that an app can handle example.com links. The app needs to have their app id and signing keys authorized by the domain in order for the verification to succeed.

These network requests by the Intent Filter Verification Service to verify app associations with domains are commonly confused for network requests made by the apps. It’s simply an HTTPS GET request without identifying information and doesn’t offer a communication channel with the app. Redirects won’t be followed so there will be a single request for each attempt to verify a domain.

If you don’t want automatic app link verification, you can disable the Network permission added by GrapheneOS for the Intent Filter Verification Service system app. In the future, we may provide a way to disable verification directly instead of stopping it from working. It will make heavily throttled attempts to verify a domain after the check failed which won’t negatively impact battery life due to the conservative JobScheduler-based implementation.

For more details, see the developer documentation on app link verification.

Carrier functionality

GrapheneOS aims to work with all carriers that are officially supported by Google on the stock operating system on Pixel devices. Wi-Fi Calling, VoLTE, Visual Voicemail, MMS, SMS, Calling and 5G (SA and NSA) all are supported, however some functionality may not be usable due to Google not supporting carriers on the stock OS officially or due to GrapheneOS not shipping proprietary apps required in order for this functionality to work on some carriers. GrapheneOS extracts CarrierConfigs, APNs, modem configurations, Visual Voicemail configurations and MMS configurations from the stock operating system to ensure users get easy carrier support that “just works”.

Please note that in some regions, LTE is referred to as 4G.

Generally 5G, SMS, MMS, Calls and VoLTE will work fine on GrapheneOS with officially supported carriers by Google. Wi-Fi calling may vary due to a reliance on proprietary Google apps which GrapheneOS does not ship.

If you are having issues with Visual Voicemail, please be aware that AT&T USA users are unable to use this feature currently due to a lack of AOSP support. Other carriers are done on a best effort basis. We would suggest using Google Dialer with sandboxed Google Play if you are unable to get this feature working.

If you are having problems sending or receiving SMS/MMS messages, we suggest that you perform the following steps:

• Deregister your phone number from Apple iMessage
• Deregister your phone number from Google Chat Features
• Deregister your phone number from your carrier’s RCS service (Not all carriers have this)

If you continue to have problems despite following the instructions above or you have another carrier related issue, we suggest that you perform the following steps:

• Some carriers require you to explicitly opt in to use services such as Wi-Fi calling. Consult your carrier’s documentation on the process for this or contact them.
• Reset Mobile Network settings in Settings ➔ System ➔ Reset options ➔ Reset Wi-Fi, mobile & Bluetooth and then reboot the device.
• USA users only: You may need to request your carrier to enable CDMA-less mode if you have issues.
• Follow your carrier’s instructions for setting up APNs, this can be found in Settings ➔ Network & Internet ➔ SIMs ➔ Access Point Names
• If calls do not work and you have LTE-only mode enabled, try toggling it off. If “Allow 2G” is disabled, try toggling it back on. Your carrier may not properly support VoLTE.
• As a last resort you may need to ask your carrier for a replacement SIM card.

Some carriers may restrict functionality, such as VoLTE, on imported Pixel devices as they only whitelist the IMEI ranges of Pixel device SKUs which were sold locally. You can check your SKU on GrapheneOS by going to Settings ➔ About phone ➔ Model ➔ Hardware SKU and using the official Google documentation. You should check if such functionality works on the stock OS to troubleshoot. It is not possible to change the IMEI on a production device and GrapheneOS cannot add support for it since the hardware doesn’t support it.

Android 12 introduced support for the GSMA TS.43 standard where provisioning for VoLTE, VoNR and Wi-Fi calling may be handled by Google Firebase. Currently it is very rare for carriers to be using Firebase to handle this. It is unlikely, but technically possible, that with such carriers you may be required to install sandboxed Google Play in order to obtain the former mentioned functionality where the carrier has not implemented fallback provisioning via SMS. Currently only US Cellular, Orange France, Cspire US, and Cellcom US are using this standard.

GrapheneOS includes bypasses for carrier restrictions on APN editing, tethering via USB, Ethernet, Bluetooth and Wi-Fi and the ability to disable 2G (only on 6th and 7th generation Pixel devices), actions which would not necessarily have been possible on the stock operating system.